高い耐久性とスケーラビリティを持つオブジェクトストレージサービス
S3(Simple Storage Service)はAWSのオブジェクトストレージサービスです。ファイルシステム(フォルダの中にファイルがある構造)とは根本的に異なり、「バケット」の中に「オブジェクト」がフラットに並んでいる構造をとります。
イメージとしては、巨大な倉庫にラベル(キー)付きの箱(オブジェクト)が平置きされている状態です。ラベルには photos/2024/cat.jpg のようにスラッシュが含まれることがありますが、これはあくまで文字列であり、実際のフォルダ構造は存在しません。
S3は容量無制限で、99.999999999%(イレブンナイン)の耐久性を持ちます。これは1000万個のオブジェクトを保存した場合、1万年に1個程度しか失われない計算です。この高い耐久性は、データを複数のアベイラビリティゾーン(AZ)に自動的にレプリケーションすることで実現しています。
オブジェクトストレージはフラットな名前空間を持ち、各オブジェクトはキー(一意な識別子)で管理されます。ブロックストレージ(EBS)やファイルストレージ(EFS)と異なり、階層構造を持ちません。HTTP/HTTPS 経由で API アクセスするため、インターネットから直接アクセス可能です。
ファイルシステムではファイルの一部だけを更新(上書き)できますが、S3ではオブジェクト全体を置き換える必要があります。また、ファイルシステムはディレクトリをたどる操作(cd, ls)が基本ですが、S3はキーを指定して直接アクセスします。この設計により、大規模データでも一定のパフォーマンスを実現しています。
S3は用途が非常に幅広く、Webアプリケーションの静的アセット配信(画像・CSS・JS)、データレイク(分析用の大量データ蓄積)、バックアップ・アーカイブ(サーバーログやDBスナップショットの長期保存)、静的Webサイトホスティング(HTMLを直接S3から配信)などに使われます。CloudFrontと組み合わせたCDN配信や、Athenaと連携したサーバーレス分析基盤としても広く活用されています。
バケットはオブジェクトを格納するコンテナです。名前は全世界で一意(他のAWSアカウントと重複不可)で、リージョンを指定して作成します。例えば my-company-photos-tokyo というバケット名は世界で1つだけです。
バケット名はURLの一部になるため、ドメイン名の命名規則に従います。小文字の英数字とハイフンのみ使用可能で、3〜63文字の範囲です。ピリオドは使用可能ですが、SSL/TLS証明書の問題からピリオドの使用は非推奨です。アカウントあたり最大100バケット(申請で1000まで拡張可能)を作成できます。
バケットには重要な制約があります。まず、バケット名はAWS全体でグローバルに一意でなければなりません。つまり、他のAWSアカウントが既に使っている名前は使用できません。また、一度削除したバケット名は他のアカウントに取得される可能性があるため、重要な名前を安易に削除しないことが推奨されます。バケットはリージョンに紐づきますが、名前のスコープはグローバルです。この設計はS3のURLが世界中で一意であることを保証するためです。
S3バケットには2つのURL形式があります。パス形式: https://s3.amazonaws.com/bucket-name/key と、仮想ホスト形式: https://bucket-name.s3.amazonaws.com/key です。AWSは仮想ホスト形式を推奨しており、パス形式は2023年以降に作成されたバケットでは利用できません。
小文字の英数字、ハイフン(-)のみ推奨。先頭は英小文字または数字。IPアドレス形式(例: 192.168.1.1)は禁止。xn-- で始まる名前も禁止(国際化ドメイン名のプレフィックスと衝突するため)。sthree- や sthree-configurator で始まる名前も予約されています。
1アカウントあたりデフォルト100バケット(Service Quotasから申請すれば最大1,000まで拡張可能)。バケット内のオブジェクト数は無制限です。バケットのリージョンは作成後に変更できないため、レイテンシやコンプライアンス要件を考慮して事前に選定しましょう。また、バケットポリシーやACLによるアクセス制御はバケット単位で設定するため、用途別にバケットを分けるのがベストプラクティスです。
キーはバケット内でオブジェクトを一意に識別する文字列です。ファイルパスのように見えますが、実際には単なる文字列です。
photos/2024/cat.jpg というキーの中の / は区切り文字に過ぎず、photos/2024/ というフォルダが存在するわけではありません。S3コンソールがフォルダのように見せているだけです。
キーの最大長は1,024バイト(UTF-8エンコード)です。安全に使える文字は英数字、ハイフン、アンダースコア、ピリオド、スラッシュです。スペースや特殊文字も使用可能ですが、URLエンコードが必要になるため推奨されません。バケット名とキーの組み合わせでオブジェクトのURLが決まります。
キー設計のベストプラクティスとして、先頭にランダムなプレフィックスを付けないことが現在は推奨されています。以前はパーティション分散のためにハッシュプレフィックスが推奨されていましたが、2018年以降S3は自動的にパーティションを最適化するようになりました。代わりに、日付ベースのプレフィックス(例: 2024/01/15/data.csv)や用途別のプレフィックス(例: raw/, processed/)を使い、人間が理解しやすく管理しやすいキー設計を心がけましょう。
S3のコンソールで「フォルダ」のように見える photos/ や docs/ は、実際にはキーの先頭部分(プレフィックス)に過ぎません。S3にフォルダやディレクトリという概念は存在しません。
では、なぜフォルダのように見えるのでしょうか? それは S3 API がプレフィックスで絞り込み検索できるからです。photos/ で始まるキーだけを取得すれば、あたかもフォルダの中身を表示しているように見えます。
Prefix="photos/" を指定した API コールに変換されています。「フォルダを作成」すると、実際には photos/ という0バイトのオブジェクトが作られるだけです。S3オブジェクトには2種類のメタデータがあります。メタデータはオブジェクトと一緒に保存されるキー・バリュー形式の付加情報で、HTTP ヘッダーとして送受信されます。オブジェクトのアップロード時にのみ設定可能で、既存オブジェクトのメタデータを変更するにはオブジェクトをコピー(上書き)する必要があります。
重要な注意点として、メタデータの後から変更にはオブジェクトのコピーが必要です。S3にはメタデータだけを更新するAPIは存在せず、CopyObject APIで同じキーに自分自身をコピーし、その際に新しいメタデータを指定します。この操作はオブジェクトサイズ分の転送・書き込みが発生するため、大きなオブジェクトではコストとパフォーマンスに影響します。頻繁に変わる属性情報はDynamoDBなど別のストアに持たせるのがベストプラクティスです。
S3が自動的に付与・管理するメタデータです。一部はユーザーが設定可能です。
Content-Type — オブジェクトのMIMEタイプ(image/jpeg, application/json 等)Content-Length — オブジェクトのサイズ(バイト)Last-Modified — 最終更新日時ETag — 整合性チェック用ハッシュ値Content-Encoding — 圧縮方式(gzip 等、ユーザー設定可能)Cache-Control — キャッシュの制御(ユーザー設定可能)ユーザーが自由に設定できるメタデータです。HTTP ヘッダーでは x-amz-meta- プレフィックスが付きます。合計サイズは2KB以内(キーと値の合計)。
x-amz-meta-photographer — 撮影者名x-amz-meta-project-id — プロジェクトIDx-amz-meta-upload-source — アップロード元ETag(Entity Tag)はオブジェクトの整合性チェックに使われるハッシュ値です。オブジェクトが変更されるとETagも変わるため、データの整合性や変更検知に利用できます。
ETagの計算方法はアップロード方式によって異なります。
マルチパートアップロードで生成されるETagは、各パートのMD5ハッシュを連結した文字列のMD5を計算し、末尾にハイフンとパート数を付加した形式になります。例えば3パートに分割した場合、MD5(MD5(part1) + MD5(part2) + MD5(part3))-3 という計算になります。このため、マルチパートでアップロードしたオブジェクトのETagをローカルファイルのMD5と直接比較して整合性を検証することはできません。検証したい場合は、同じパート分割でローカル側でも同じ計算を行うか、Content-MD5 ヘッダーを各パートのアップロード時に指定して個別検証する方法があります。
ETag = オブジェクトのMD5ハッシュ値(SSE-S3暗号化の場合)。例: "d41d8cd98f00b204e9800998ecf8427e"。ダブルクォートで囲まれた32文字の16進数文字列です。SSE-KMSやSSE-Cで暗号化されている場合はMD5と一致しません。
ETag = 各パートのMD5を連結したもののMD5 + "-" + パート数。例: "a1b2c3d4e5f6..."-3(3パートの場合)。末尾の -N がマルチパートアップロードの目印です。この形式のETagはオブジェクト全体のMD5とは一致しません。
If-None-Matchヘッダー)に使えます。クライアントがキャッシュしているオブジェクトのETagをサーバーに送り、変更がなければ304 Not Modifiedが返り、転送コストを削減できます。また、マルチパートアップロード後のデータ整合性検証にも利用されます。
高い耐久性とスケーラビリティを持つオブジェクトストレージサービス

高い耐久性とスケーラビリティを持つオブジェクトストレージサービス

高い耐久性とスケーラビリティを持つオブジェクトストレージサービス

高い耐久性とスケーラビリティを持つオブジェクトストレージサービス

世界中のエッジロケーションからコンテンツを高速配信するCDNサービス

高い耐久性とスケーラビリティを持つオブジェクトストレージサービス