AWS S3 VISUALIZER

S3 オブジェクトの構造

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

シナリオ
S3のバケット・キー・オブジェクト・メタデータの構造をステップで学びます
ステップ1 / 3
ステップ
S3 = バケットの集合体
S3 はバケットの集合体として構成されています。各バケットはオブジェクトを格納するコンテナで、バケット名はグローバルで一意です。まずは全体像を確認しましょう。
ARCHITECTURE DIAGRAM
S3のバケットとオブジェクトの構造を見ていこう
STEP 1
CODE VIEW
── S3 サービス概要 ──
 
$ aws s3 ls
2024-01-15 my-app-images
2024-02-20 my-company-logs
2024-03-10 my-website-static
 
✓ 3 バケットが存在
完了
アクティブ
プレフィックス
未到達
解説

📌
S3 とは何か

S3(Simple Storage Service)はAWSのオブジェクトストレージサービスです。ファイルシステム(フォルダの中にファイルがある構造)とは根本的に異なり、「バケット」の中に「オブジェクト」がフラットに並んでいる構造をとります。

イメージとしては、巨大な倉庫にラベル(キー)付きの箱(オブジェクト)が平置きされている状態です。ラベルには photos/2024/cat.jpg のようにスラッシュが含まれることがありますが、これはあくまで文字列であり、実際のフォルダ構造は存在しません。

イメージで理解: S3は巨大な倉庫のようなものです。倉庫の中に「バケット」という名前の部屋があり、各部屋にラベル付きの荷物(オブジェクト)が平置きされています。棚やフォルダのような階層構造はなく、ラベル(キー)で荷物を識別します。
Amazon S3バケットmy-app-imagesmy-company-logsmy-website-static

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が世界中で一意であることを保証するためです。

バケットの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によるアクセス制御はバケット単位で設定するため、用途別にバケットを分けるのがベストプラクティスです。

// バケット作成コマンド
$ aws s3 mb s3://my-company-photos-tokyo \
--region ap-northeast-1

🔑
キーとは何か

キーはバケット内でオブジェクトを一意に識別する文字列です。ファイルパスのように見えますが、実際には単なる文字列です。

photos/2024/cat.jpg というキーの中の / は区切り文字に過ぎず、photos/2024/ というフォルダが存在するわけではありません。S3コンソールがフォルダのように見せているだけです。

キーの最大長は1,024バイト(UTF-8エンコード)です。安全に使える文字は英数字、ハイフン、アンダースコア、ピリオド、スラッシュです。スペースや特殊文字も使用可能ですが、URLエンコードが必要になるため推奨されません。バケット名とキーの組み合わせでオブジェクトのURLが決まります。

キー設計のベストプラクティスとして、先頭にランダムなプレフィックスを付けないことが現在は推奨されています。以前はパーティション分散のためにハッシュプレフィックスが推奨されていましたが、2018年以降S3は自動的にパーティションを最適化するようになりました。代わりに、日付ベースのプレフィックス(例: 2024/01/15/data.csv)や用途別のプレフィックス(例: raw/, processed/)を使い、人間が理解しやすく管理しやすいキー設計を心がけましょう。

S3 URL = Bucket Name + Keyhttps://my-app-images.s3.amazonaws.com/photos/2024/cat.jpgBucket NameKeyBucket + Key の組み合わせで世界に一つのURLが決まる
// キーの例と URL の対応
Key: photos/2024/cat.jpg
URL: https://my-bucket.s3.amazonaws.com/photos/2024/cat.jpg
// フォルダの「/」は単なる文字列
Key: photos/2024/cat.jpg
= photos/2024/cat.jpg
^-- prefix ^-- object name

📁
プレフィックスの仕組み

S3のコンソールで「フォルダ」のように見える photos/docs/ は、実際にはキーの先頭部分(プレフィックス)に過ぎません。S3にフォルダやディレクトリという概念は存在しません。

では、なぜフォルダのように見えるのでしょうか? それは S3 API がプレフィックスで絞り込み検索できるからです。photos/ で始まるキーだけを取得すれば、あたかもフォルダの中身を表示しているように見えます。

バケット内の全オブジェクト(実態はフラット)photos/cat.jpgphotos/2024/dog.jpgdocs/readme.mdconfig.jsonPrefix="photos/"プレフィックスで絞り込んだ結果photos/cat.jpgphotos/2024/dog.jpgdocs/ や config.json は除外されるこれがコンソールで「フォルダをクリック」した時の正体
# プレフィックスで絞り込み検索
$ aws s3api list-objects-v2 \
--bucket my-app-images \
--prefix "photos/"
# → photos/ で始まるキーだけが返る
{
"Contents": [
{ "Key": "photos/cat.jpg" },
{ "Key": "photos/2024/dog.jpg" }
]
}
ポイント: S3コンソールで「photos フォルダを開く」という操作は、裏側では Prefix="photos/" を指定した API コールに変換されています。「フォルダを作成」すると、実際には photos/ という0バイトのオブジェクトが作られるだけです。

🏷️
メタデータの種類

S3オブジェクトには2種類のメタデータがあります。メタデータはオブジェクトと一緒に保存されるキー・バリュー形式の付加情報で、HTTP ヘッダーとして送受信されます。オブジェクトのアップロード時にのみ設定可能で、既存オブジェクトのメタデータを変更するにはオブジェクトをコピー(上書き)する必要があります。

重要な注意点として、メタデータの後から変更にはオブジェクトのコピーが必要です。S3にはメタデータだけを更新するAPIは存在せず、CopyObject APIで同じキーに自分自身をコピーし、その際に新しいメタデータを指定します。この操作はオブジェクトサイズ分の転送・書き込みが発生するため、大きなオブジェクトではコストとパフォーマンスに影響します。頻繁に変わる属性情報はDynamoDBなど別のストアに持たせるのがベストプラクティスです。

S3 Object: photos/cat.jpgSystem-definedContent-Type: image/jpegContent-Length: 245760Last-Modified: 2024-01-15User-defined (x-amz-meta-*)photographer: tanakaproject-id: PRJ-001upload-source: web-appSystem: S3が管理 / User: x-amz-meta- prefix 付き(合計2KB以内)
システムメタデータ(System-defined)

S3が自動的に付与・管理するメタデータです。一部はユーザーが設定可能です。

Content-Type — オブジェクトのMIMEタイプ(image/jpeg, application/json 等)
Content-Length — オブジェクトのサイズ(バイト)
Last-Modified — 最終更新日時
ETag — 整合性チェック用ハッシュ値
Content-Encoding — 圧縮方式(gzip 等、ユーザー設定可能)
Cache-Control — キャッシュの制御(ユーザー設定可能)
ユーザー定義メタデータ(User-defined)

ユーザーが自由に設定できるメタデータです。HTTP ヘッダーでは x-amz-meta- プレフィックスが付きます。合計サイズは2KB以内(キーと値の合計)。

x-amz-meta-photographer — 撮影者名
x-amz-meta-project-id — プロジェクトID
x-amz-meta-upload-source — アップロード元
// メタデータ付きアップロード
$ aws s3api put-object \
--bucket my-app-images \
--key "photos/2024/cat.jpg" \
--body cat.jpg \
--content-type image/jpeg \
--metadata '{"photographer":"tanaka"}'

#️⃣
ETag とは何か

ETag(Entity Tag)はオブジェクトの整合性チェックに使われるハッシュ値です。オブジェクトが変更されるとETagも変わるため、データの整合性や変更検知に利用できます。

ETagの計算方法はアップロード方式によって異なります。

マルチパートアップロードで生成されるETagは、各パートのMD5ハッシュを連結した文字列のMD5を計算し、末尾にハイフンとパート数を付加した形式になります。例えば3パートに分割した場合、MD5(MD5(part1) + MD5(part2) + MD5(part3))-3 という計算になります。このため、マルチパートでアップロードしたオブジェクトのETagをローカルファイルのMD5と直接比較して整合性を検証することはできません。検証したい場合は、同じパート分割でローカル側でも同じ計算を行うか、Content-MD5 ヘッダーを各パートのアップロード時に指定して個別検証する方法があります。

Single PUTFileMD5"d41d8c..."= MD5 hashETag = File MD5Multipart UploadP1P2P3MD5 each, concat, MD5 again"a1b2c3..."-3ETag = MD5(MD5s) + "-N"
単一PUTアップロードの場合

ETag = オブジェクトのMD5ハッシュ値(SSE-S3暗号化の場合)。例: "d41d8cd98f00b204e9800998ecf8427e"。ダブルクォートで囲まれた32文字の16進数文字列です。SSE-KMSやSSE-Cで暗号化されている場合はMD5と一致しません。

マルチパートアップロードの場合

ETag = 各パートのMD5を連結したもののMD5 + "-" + パート数。例: "a1b2c3d4e5f6..."-3(3パートの場合)。末尾の -N がマルチパートアップロードの目印です。この形式のETagはオブジェクト全体のMD5とは一致しません。

活用例: ETagは条件付きリクエストIf-None-Matchヘッダー)に使えます。クライアントがキャッシュしているオブジェクトのETagをサーバーに送り、変更がなければ304 Not Modifiedが返り、転送コストを削減できます。また、マルチパートアップロード後のデータ整合性検証にも利用されます。

📝
AWS 認定試験(SAA)レベルの問題

Q1.S3バケットに photos/2024/summer/beach.jpg というキーでオブジェクトを保存しました。この時、photos/、photos/2024/、photos/2024/summer/ というディレクトリは自動的に作成されますか?
A.はい。S3はキーのスラッシュを解析して自動的にディレクトリ構造を作成します
B.いいえ。S3はフラットな名前空間であり、ディレクトリは存在しません。スラッシュはキーの一部に過ぎません
C.はい。ただし空のディレクトリオブジェクト(0バイト)として作成されます
D.コンソールで「フォルダを作成」した場合のみディレクトリが作成されます
Q2.S3バケット名の命名規則として正しいものはどれですか?
A.リージョン内で一意であればよい
B.グローバルで一意。3〜63文字の小文字英数字とハイフンで構成。大文字は使用不可
C.グローバルで一意。1〜255文字の英数字で構成。大文字も使用可能
D.アカウント内で一意であればよい。命名規則に制限はない
Q3.マルチパートアップロードで保存されたオブジェクトのETagは、そのオブジェクト全体のMD5ハッシュと一致しますか?
A.はい。アップロード方式に関わらずETagはオブジェクト全体のMD5です
B.いいえ。マルチパートの場合、ETagは各パートのMD5から計算された値にパート数が付加された形式になります
C.はい。ただしSSE-KMSで暗号化している場合のみ一致しません
D.ETagはランダムなUUIDであり、MD5とは無関係です

関連コンテンツ