Amazon S3 入門：バケット、オブジェクト、セキュリティ、バージョニング

S3 が重要な理由

Amazon S3 は AWS の中核ビルディングブロックで、しばしば無限にスケールするオブジェクトストレージと説明される。ウェブの多くと多くの AWS サービスが S3 と連携する。

代表的な用途：

バックアップと一般的なファイル保管
災害復旧（例：別リージョンへレプリケートまたはコピー）
アーカイブ（Glacier クラスなど安価な階層）
オンプレミスストレージからのハイブリッドクラウド拡張
静的アセット（メディア、画像、動画）のホスティング
データレイクと分析
ソフトウェア配信と静的ウェブサイトホスティング

教材で挙げられる実例には、長期の規制保管（例：Nasdaq 規模のアーカイブパターン）や S3 上データのビジネス洞察のための分析がある。

バケットとリージョン

データはバケット（最上位コンテナ）に置かれる。
バケット名はすべての AWS アカウントとリージョンでグローバルに一意である必要がある — 試験でよくある落とし穴。
バケットは特定のリージョンで作成されるが、コンソールは全リージョンのバケットを一つのリストに表示する。S3 はグローバルに感じられるが、バケットはリージョナル。

バケット命名ルール

概要として覚えること：

小文字、数字、ハイフンのみ（大文字、アンダースコア不可）
長さ 3～63 文字
IP アドレスのように見えてはならない
英字または数字で始まる
禁止プレフィックスを避ける（完全な一覧は最新の AWS ドキュメント参照）

オブジェクトとキー

S3 内のファイルはオブジェクト。
各オブジェクトにはキーがある：フルパス文字列（例：myfile.txt や folder1/subfolder/myfile.txt）。
コンソールには「フォルダ」が見えるが、S3 に実ディレクトリ階層はない — すべてキー；スラッシュはキー内の文字に過ぎない。
キーは概念的にプレフィックス（パス状の部分）とオブジェクト名（最後のセグメント）に分かれる。

サイズとアップロード

オブジェクト最大サイズ：5 TB。
5 GB 超のオブジェクトにはマルチパートアップロードが必須（パートに分割）。

メタデータ、タグ、バージョニング

メタデータ： オブジェクトを説明するシステムまたはユーザーのキー/値ペア。
タグ： 最大 10 個のキー/値；ライフサイクル、セキュリティ、コスト配分に有用。
Version ID： バケットでバージョニングが有効なときに付与。

コンソールの基本：バケット作成とアップロード

典型的な流れ：

バケット作成前にリージョンを選ぶ。
バケットタイプの選択肢がある場合、標準的な試験向けワークロードは General purpose（directory bucket は特殊ケース）。
グローバルに一意なバケット名を選ぶ。
Object Ownership： ACL 無効が推奨デフォルト。
Block Public Access： 意図的にパブリック読み取りが必要でない限りオンのまま（下記セキュリティ参照）。
Versioning： 多くは最初無効、安全な更新と復旧が必要になったら有効化。
デフォルト暗号化： 例：SSE-S3、多くのワークロードでは任意のバケットキーでコスト/性能向上。

アップロード後、コンソールの Open は認証フローで動くことがあり、素のオブジェクト URL はオブジェクト/バケットがパブリックでないか要求者が権限を持たない限り Access Denied のまま — 一時的な認証を埋め込むプリ署名 URL と対比する。

整理のため UI で**プレフィックス「フォルダ」**を作れる；「フォルダ」削除はそのプレフィックス配下のオブジェクトを削除する。

S3 セキュリティモデル

ユーザーベース（IAM）

ユーザー、グループ、ロールに IAM ポリシーをアタッチし S3 API アクション（例：GetObject、PutObject）を許可/拒否。

リソースベース

バケットポリシー： バケット上の JSON（多くは bucket/* でオブジェクトも）。パブリック読み取り、アップロード時の暗号化強制、VPC/送信元制限、CloudFront OAC/OAI パターン、MFA 条件、クロスアカウントアクセスに一般的。
ACL： 細かいが現在はあまり使わない；Object ACL と Bucket ACL は多くの場合無効にしバケットポリシーと IAM に寄せる。

アクセスが許可される条件

IAM が許可するかリソースポリシーが許可し、かつ明示的 Deny がない（Deny が勝つ）とき、IAM プリンシパルはアクションを実行できる。

EC2 とクロスアカウント

S3 アクセスには IAM ロール（長寿命 IAM ユーザーではない）を EC2 に推奨。
自バケットへのクロスアカウントアクセスは、他アカウントのプリンシパルを信頼するバケットポリシーが典型。

Block Public Access

アカウントまたはバケットレベルの Block Public Access は追加の安全装置：誤ったパブリックバケットポリシーも Block Public Access が有効な間は効かないことがある。意図的にパブリックオブジェクトが必要でリスクを理解するときだけオフにする。

オブジェクトをパブリックにする（実践パターン）

必要な場合のみバケットの Block Public Access を編集しパブリックポリシーを許可。
リソース arn:aws:s3:::bucket-name/* に対しプリンシパル "*"（または狭いプリンシパル）へ s3:GetObject を許可するバケットポリシーを追加。

ポリシージェネレータの注意： GetObject はオブジェクトに適用されるためリソース ARN は多くの場合 bucket-arn/*。ListBucket はバケットリソースそのもの（ARN に /* なし）。

高度なバケットポリシーの考え方（把握でよい）

試験で JSON をすべて暗記する必要はないが、バケットポリシーで表現できることは知っておく：

AWS Organization 内プリンシパルに制限（aws:PrincipalOrgID 条件）
暗号化ヘッダがない限りアップロードを Deny（アップロード時の暗号化強制）
送信元 IP（パブリック/elastic IP レンジ；説明されている形ではプライベート IP ではない）
VPC / VPC エンドポイント条件（エンドポイント利用とセット）
機密読み取りには MFA 必須
オリジンオブジェクトをCloudFrontだけが読めるパターン

バージョニング

バケットレベルでバージョニングを有効化。
同一キーの上書きごとに新しいバージョン ID が付き、古いバイトが黙って失われない。
バージョニング前にアップロードされたオブジェクトは多くの場合そのレガシーオブジェクトのバージョン null。
バージョニングを一時停止しても既存バージョンは削除されない — 新バージョンの作成だけ止まる。

初回バージョニング有効化：伝播遅延（試験メモ）

バケットで初めてバージョニングを有効にすると、AWS ドキュメントでは変更が完全に伝播するまで短時間かかることがある（教材では多く約 15 分）。

伝播が未完の間、新規作成または更新されたオブジェクトへの読み書きが 404 NoSuchKey（または類似の「見つからない」挙動）で失敗しうる。推奨： クリティカルな書き込みに頼る前にバージョニングが完全に有効になるまで待つ。最新ドキュメントを確認 — このガイダンスが変われば試験問題も変わりうる。

削除：削除マーカー vs 完全削除

コンソールで「現在」のオブジェクトを削除（バージョンを指定しない）すると多くの場合削除マーカーが付く：オブジェクトは消えたように見えるが古いバージョンは残る；削除マーカーを取り除くと最新の未削除バージョンを復元できる。
特定のバージョン ID を削除すると完全削除 — 破壊的で元に戻せない。

ロールバック

コンテンツ（例：静的 index.html）を戻すには、現在として望ましくない新しいバージョン ID を完全削除し、古いバージョンを最新に残す。

S3 レプリケーション

レプリケーションはソースバケットから宛先バケットへオブジェクトを非同期にコピーする（AWS がバックグラウンドで実行）。

CRR と SRR

CRR（Cross-Region Replication）： ソースと宛先が異なるリージョン。
SRR（Same-Region Replication）： ソースと宛先が同一リージョン。

バケットは同一または異なる AWS アカウントに置ける。

前提条件

ソースと宛先の両方でバージョニングが有効であること。
S3 レプリケーションがソースから読み取り、宛先へ書き込み（および AWS が必要とする関連操作）できる IAM ロール（または同等のサービス権限）。

レプリケーションの用途

CRR： コンプライアンス、別リージョン利用者への低遅延、クロスアカウントコピー、DR 型パターン。
SRR： 多数バケットからログ集約、環境間（例：本番とテスト）のライブコピー（教材で説明されるパターン）。

何がレプリケートされるか（デフォルトと任意）

レプリケーションルール作成以降にアップロード（または変更）されたオブジェクトのみがレプリケートされる — 既存オブジェクトは自動ではバックフィルされない。
既存オブジェクト（または失敗したレプリケーションの修正）をレプリケートするにはS3 Batch Replication（バッチ操作）を使い、ライブのレプリケーションルールとは別。
削除マーカーのレプリケーションは任意。有効なら削除マーカーが宛先にコピーされうる；無効ならソースにのみ残る。
完全削除（特定のバージョン ID の削除）はレプリケートされない — ソースでの悪意または誤ったハードデリートがレプリカのバージョンを自動では消さない（設計上）。

チェーンなし

バケット A が B に、B が C にレプリケートしても、A で作られたオブジェクトがそのチェーンで自動的に C に行くわけではない。中間バケット経由のレプリケーションチェーンはない。

Replication Time Control（RTC）

RTC は S3 レプリケーションのオプションで、新オブジェクトがどれだけ速くレプリケートされるかについてSLA 型の保証を与える（教材では RTC 有効時99.99% が 15 分以内にレプリケートと引用）。

重要な理由：

コンプライアンスや厳しいビジネス要件向けの予測可能で監査可能なレプリケーション遅延
レプリケーションを監視し遅延を検知するための CloudWatch メトリクス（とアラート）
同一リージョンまたはリージョン間のレプリケーション（同じ CRR/SRR 基盤）で動作

コスト： RTC を有効にすると追加料金（レプリケートデータ関連でGB あたり — 最新の S3 料金を確認）。ステークホルダーがその保証されたレプリケーションウィンドウを必要とするときに使い、すべてのワークロードではない。

実践で覚えるパターン

オリジンとレプリカバケットを作成し、どちらもバージョニングオン。
Management → Replication rules でルール作成（バケット全体またはプレフィックス）、宛先バケット/リージョン（リージョンが異なれば CRR）、IAM ロールを作成/割り当て。
既存オブジェクトのレプリケーションの質問 → 履歴データが必要なら典型的には Batch Operations；「いいえ」なら新規オブジェクトのみレプリケート。
レプリカのバージョン ID はレプリケートされたバージョンについて多くの場合ソースと一致（コピーの対応付けに便利）。
ソースの削除マーカー → 削除マーカーレプリケーションが有効なときのみ宛先に現れうる。
ソースでバージョンの完全削除 → レプリカからそのバージョンを消さない。

クロスアカウントレプリケーションとオブジェクト所有権

別アカウントのバケットへレプリケートする場合：

宛先バケットポリシーがソースアカウントのレプリケーション IAM ロールを信頼し、オブジェクトのレプリケーション、該当する場合の削除のレプリケーション、ロールが必要とするバケットレベルバージョニング API（GetBucketVersioning、PutBucketVersioning など、構成に応じて）を許可する必要がある。

レプリケートオブジェクトのデフォルト所有権

デフォルトでは、宛先バケットのオブジェクト所有者はソースアカウント（書き込み時のオブジェクト所有者）のままかもしれない。バックアップにはよいが、アカウント B が自ポリシーで完全に所有し読む必要があると期待とずれる。

所有者オーバーライド（宛先がオブジェクトを所有）

宛先アカウントをレプリケートオブジェクトの所有者にするには：

レプリケーションルールで適切な所有者オーバーライド（bucket-owner-enforced / 宛先所有者）を有効化（コンソール文言は変わりうる）。
ソースのレプリケーションロールに s3:ObjectOwnerOverrideToBucketOwner（または現在の IAM での同等権限）を付与。
宛先バケットポリシーも、そのロールが所有権オーバーライドを実行し新オブジェクトが宛先バケットアカウント所有になるよう許可する必要がある。

試験の観点： レプリケーションは「動く」（オブジェクトは見える）が所有権と権限が間違っているとアカウント B は読めない — owner override と整合した IAM + バケットポリシーで修正。

ストレージクラスとライフサイクルルール

オブジェクトは時間とともにストレージクラスを遷移できる（コースの図では S3 Standard、Standard-IA、Intelligent-Tiering、S3 One Zone-IA、Instant Retrieval / Flexible Retrieval / Deep Archive など Glacier 階層の間のパス — 現在の遷移マトリクスは AWS ドキュメントで確認）。

アクセス頻度が低い → Standard-IA（耐久性要件に合う IA 階層）を検討。
アーカイブ → 取得時間とコストのトレードオフが合えば Glacier クラスへ。

ライフサイクル設定での自動化

ライフサイクルルールは次を組み合わせる。

遷移アクション — N 日後に別クラスへ移動（例：60 日後に Standard-IA、180 日後に Glacier）。
期限切れアクション — 一定期間後にオブジェクト削除（例：365 日後にアクセスログ）、バージョニング有効時は非現行バージョンの期限切れ、または N 日後に未完了マルチパートアップロードの中止（例：アップロード完了想定が 7～14 日）。

ルールはバケット全体、プレフィックス、またはオブジェクトタグ（例：department=finance のみ）を対象にできる。

試験風シナリオ：サムネイルとオリジナル

ソースのプロフィール画像： 最初は Standard；ユーザーが遅い取得に耐えうるなら（例：フレキシブル階層で数時間まで — 問題の SLA に合わせる）Glacier へライフサイクル遷移（例：60 日後）。
サムネイル： 安価な階層でよい（再生成可能で耐久性が下がってよければ One Zone-IA）；オリジナルから再生成できるなら 60 日で期限切れ。異なるプレフィックス（例：originals/ と thumbnails/）で別ルールを付ける。

試験風シナリオ：バージョニングでの削除オブジェクト保持

バージョニングを有効にし、削除は削除マーカーを作り古いバージョンは復旧可能のままに。
非現行バージョンをまず Standard-IA に遷移し即時に近い復旧窓を確保し、後から長期・低速/低コストの Glacier Deep Archive へ — 問題文の「30 日は即時復旧」「最大 1 年は 48 時間以内」などの方針に合わせる。

ライフサイクルルールのアクション（コンソール）

Management → Lifecycle rules では次を含む。

現行バージョンのストレージクラス間遷移（複数ステップのタイムラインをサポート）
非現行バージョンを安価/アーカイブクラスへ遷移
N 日後に現行バージョンを期限切れ
N 日後に非現行バージョンを完全削除
期限切れオブジェクトの削除マーカーの削除および/または未完了マルチパートアップロードの中止

コンソールは現行と非現行の遷移・期限切れのタイムラインを表示できる。

S3 アナリティクス（ストレージクラス推奨）

S3 Storage Class Analysis（コースでは S3 アナリティクスと呼ばれることが多い）は遷移日選びの推奨を生成（CSV レポート）；教材では Standard と Standard-IA を対象とし（One Zone-IA や Glacier は対象外）、レポートは日次更新；有用な分析までおおよそ 24～48 時間。CSV でライフサイクルルールを調整。

S3 イベント通知

S3 はオブジェクト作成、削除、復元、レプリケーションなどのイベントを発行できる。プレフィックス/サフィックスでフィルタ（例：*.jpg）。

宛先（クラシック）：

SNS トピック
SQS キュー
Lambda 関数

配信は多くの場合数秒以内だが1 分以上かかることもある。

権限パターン

これらの宛先に対してバケットに IAM ロールは使わない。代わりに宛先側にリソースポリシー（SNS トピックポリシー、SQS キューポリシー、Lambda リソースポリシー）があり S3 サービスの公開または呼び出しを許可する。バケットポリシーと同様だが宛先リソース上。

実習の注意： キューポリシーを更新せず SQS を設定すると、S3 に SendMessage（または同等）が許可されるまで検証が失敗しがち；保存時に S3 がテストメッセージを送ることがある。イベントペイロードには eventName（例：ObjectCreated:Put）やオブジェクトキーなどが含まれる。

Amazon EventBridge 連携

バケットで EventBridge を有効にするとイベントも EventBridge に流れ、ルールで多数の AWS サービスへファンアウトできる（教材では18+宛先）。メタデータ、サイズ、名前によるリッチなフィルタ、複数ターゲット、アーカイブ/リプレイ、レガシー通知単体より信頼性の高い配信パターンが利点。

S3 パフォーマンス：ベースラインと最適化

ベースライン

S3 は非常に高いリクエストレートと低遅延にスケール（コースの目安：多くのワークロードで TTFB 約 100～200 ms）。
スループットは多くの場合プレフィックスあたりで議論：プレフィックスあたり秒間おおよそ 3,500 PUT/COPY/POST/DELETE と 5,500 GET/HEAD（最新のクォータ/ドキュメントを確認）。プレフィックスはオブジェクト名「上」のパスセグメント；異なるプレフィックスは別のスケーリングパーティション — キーを複数プレフィックスに分散すると集約スループットが上がる（例：4 プレフィックスで並列設計の GET 容量を倍増イメージ）。

マルチパートアップロード

約 100 MB 超では推奨；5 GB 超では必須。
オブジェクトをパートに分割（最大 10,000 パート）、パートを並列アップロード（帯域改善、失敗したパートのみリトライ）、ETag リストで CompleteMultipartUpload し S3 が最終オブジェクトを組み立てる。未完了アップロードが残りうる；N 日後に未完了マルチパートを中止するライフサイクルルールで掃除。
CLI： バケット作成は aws s3 mb；マルチパートは aws s3api（create-multipart-upload、upload-part、list-parts、complete-multipart-upload、list-multipart-uploads）。完了までパートはコンソール上通常オブジェクトとして現れない。

Transfer Acceleration

データを近いエッジへ送り、AWS バックボーンでバケットリージョンへ転送して高速化。マルチパートと併用可。地理的に離れた転送（例：米クライアント → 豪バケット）に有用。

バイトレンジ GET

クライアントがオブジェクトの範囲を並列に要求してダウンロード高速化や先頭 N バイトのみ読み取り。失敗した範囲はより小さいチャンクでリトライ。

KMS（試験で把握）

暗号化オブジェクトは KMS API 上限の対象になりうる；非常に高いレートでは S3 に加えスロットリング意識が必要（最新ドキュメントで上限確認）。

S3 Batch Operations

1 つのジョブ定義で多数の既存オブジェクトに対する一括ジョブ：メタデータ/タグ置換、バケット間コピー、未暗号化オブジェクトの暗号化、ACL 変更、Glacier からのリストア、オブジェクトごとにLambda 呼び出しでカスタムロジックなど。

スクリプトとの違い： 組み込みリトライ、進捗追跡、完了レポートとレポート。

マニフェスト： CSV（バケット、キー、任意でバージョン）または S3 Inventory レポートでオブジェクト一覧。Athena でインベントリ出力をクエリしマニフェストに入れるキーをフィルタ（例：未暗号化オブジェクトを見つけ一括暗号化）。

権限： S3 Batch Operations が信頼する IAM ロール（マニフェスト読取、対象オブジェクト読み書き、レポート書き込みの最小権限）。

S3 Inventory

Inventory はオブジェクトとメタデータを一覧（大きなバケットで List API を繰り返すより良い）。

用途： 暗号化とレプリケーション状態の監査、オブジェクト数、クラス別ストレージ、非現行バージョンサイズ、コンプライアンスレポート。

出力： CSV、ORC、Apache Parquet；日次または週次。初回配信は最大 ~48 時間かかることがある。出力を Athena、Redshift、Spark、Hive、Presto などでクエリ。

レポートの宛先バケットはソースバケット設定と同じリージョンである必要がある（デモでよくある設定ミス）。

クリーンアップ： 不要ならインベントリ設定を無効化または削除し、レポート生成を止める。

マニフェストファイル： manifest.json とチェックサムが CSV/Parquet パートとスキーマを記述。

Amazon Athena

Athena は S3 上データ向けのサーバーレス SQL クエリサービス（エンジン系譜：Presto/Trino クラス）。サーバーやウェアハウスをプロビジョニングしない；スキャンしたデータ（TB あたり）に課金。

形式： CSV、JSON、ORC、Avro、Parquet など。

典型用途： アドホック分析、BI、レポート、ログのクエリ（ALB、CloudTrail、VPC Flow Logs、S3 アクセスログ）。

試験の手がかり： 「S3 上データのサーバーレス SQL」→ Athena。

性能とコスト

列指向（Parquet、ORC）を優先し列を少なくスキャン；多くは CSV から Glue ETL で変換。
スキャンバイト削減のためデータを圧縮。
S3 キーをパーティション（例：year=1991/month=01/day=01/）し述語でパーティションを剪定。
極小ファイル大量より少数の大きいファイル（例：≥ ~128 MB 目安）でオーバーヘッド削減。

フェデレーテッドクエリ

Athena は Lambda で実装されたデータソースコネクタで外部データソースをクエリ可能：例：DynamoDB、RDS/Aurora、CloudWatch Logs、Redshift、オンプレ DB。結果を S3 に書き戻せる。

実践パターン（S3 アクセスログ）

Athena 設定で S3 にクエリ結果の保存場所を設定。
CREATE DATABASE、次にログバケットプレフィックスを指す CREATE TABLE（ドキュメントのテンプレートが多く、バケット名とプレフィックスだけ編集；末尾 / が重要）。
SQL 実行：プレビュー、集計（例：HTTP ステータス別件数）、403 / 404 パターン調査。

MFA Delete

MFA Delete はバージョニング関連の破壊的操作に追加制御：呼び出し元は通常の認証に加え有効な MFA コード（仮想 MFA アプリ、ハードウェアトークンなど）を渡す必要がある。

有効化後に MFA が必要な操作

特定オブジェクトバージョンの完全削除（削除マーカーだけでない真のバージョン削除）。
バケットのバージョニングの一時停止。

MFA が不要な操作

バージョニングの有効化。
オブジェクトバージョンの一覧（「削除済み」/非現行バージョン含む）。

要件と操作

先にバケットでバージョニングが有効（MFA Delete はバージョニング関連の制御）。
バケット所有者のルートユーザーのみが MFA Delete をオン/オフできる（教材 — 最新 AWS ドキュメントで確認；狭く敏感なフロー）。
AWS 管理コンソールでは多くの場合 MFA Delete を切り替えられない；通常 AWS CLI（例：MFA デバイス ARN + シリアル + 現在の TOTP を API パラメータに含む put-bucket-versioning）。

運用上の注意： デモでは CLI にルートアクセスキーを使う — ルートの長期アクセスキーを残さない；作業後は無効化/削除。

S3 サーバーアクセスログ

サーバーアクセスログはバケットに対するリクエスト（許可/拒否）ごとにログレコードを別の宛先バケットにログファイルとして書く。監査と後続分析（例：Athena）に使う。

ログ記録（宛先）バケットはソースバケット設定と同じリージョンにある必要がある（コース）。
監視しているのと同じバケットをログ宛先にしない：ログオブジェクトの各 PUT がさらにアクセスを生み、さらにログが生じる → 無限増加とコスト暴走。

コンソールでログを有効にすると多くの場合宛先バケットポリシーが更新され、S3 ログ配信サービスがログオブジェクトを PUT できる。ログ配信は遅れる（実務では数分～数時間）。

ログの行形式は AWS が文書化（パース用フィールド配置）。宛先の任意プレフィックスでキーを整理（例：logs/）。

WORM：Glacier Vault Lock と S3 Object Lock

S3 Glacier Vault Lock（クラシック Glacier ボールト）

Glacier ボールト型ワークフロー（コースの枠）：Vault Lock ポリシーを適用し、そのポリシーをロックして編集・削除不可にする。コンプライアンス/保管向け WORM（write once, read many）モデル：そのポリシー下のオブジェクトは不変（教材の表現：管理者/AWS もロックされたポリシーを迂回できない強い不変性）。

S3 Object Lock（S3 バケット上）

Object Lock も WORM を可能にするが、バージョン付きバケット上でオブジェクト/バージョン粒度。

前提： バージョニング有効（Object Lock はバケット作成時または特定制約で設定 — 最新のコンソール/ドキュメントに従う）。

保持モード：

モード	厳しさ
Compliance	誰も（root 含む）が保持期間の短縮、保護バージョンの早期削除、モード弱化ができない — 定めた保持期間での最大不変性。
Governance	多くのユーザーは迂回不可；適切な IAM 権限（例：`s3:BypassGovernanceRetention`）を持つ特権プリンシパルは保持調整や許可範囲での削除が可能。

保持期間を設定（多くは延長可能；compliance モードでは短縮不可）。

リーガルホールド： 保持とは独立 — オブジェクトを訴訟などで無期限に凍結する印。ガバナンスが許すなら s3:PutObjectLegalHold（および関連）を持つユーザーが設定/解除。

試験の焦点： compliance と governance、保持期間とリーガルホールド、Object Lock はオブジェクト/バージョン単位であるのに対し Vault Lock は Glacier 型ボールトのボールトポリシーレベルであることを把握。

VPC からの S3 へのプライベートアクセス

ゲートウェイエンドポイント（S3）— プライベートサブネットのデフォルト試験解答

S3 ゲートウェイエンドポイントに時間課金なし。
その VPC 内リソースがルートテーブル経由で利用（プレフィックスリストがリージョン内 S3 を指す）。
インスタンスが正しく名前解決・ルーティングするには VPC DNS サポートが必要；標準の S3 DNS 名を使い続ける（トラフィックはパブリックインターネット経路ではなく AWS ネットワーク上で S3 へ）。
設計に応じエンドポイント経路に届くアウトバウンドをセキュリティグループで許可。

プライベートサブネットの EC2 が NAT 経由のパブリック経路なしで S3 に届けるのに向く。

S3 のインターフェースエンドポイント（PrivateLink）

サブネットに ENI を作成しAZ あたりコスト（コース目安：AZ あたり ~$0.01/時 — 料金確認）。
VPC 経由の VPN または Direct Connect でオンプレからエンドポイントへのアクセスをサポートしうる。
プライベート名が期待どおり動くには VPC の DNS サポートと DNS ホスト名が必要。

試験： プライベート EC2 → S3 で無料・VPC 内アクセスが論点ならゲートウェイエンドポイントを優先；PrivateLink とハイブリッドパターンではインターフェースエンドポイントがあることを知る。

Amazon S3 向け IAM Access Analyzer

IAM Access Analyzer（S3 に適用）がリソースポリシーと関連制御 — バケットポリシー、ACL、アクセスポイントポリシーなど — を評価し、パブリックにアクセス可能または外部 AWS アカウントと共有されているバケットを報告（意図しない露出）。

所見をレビューし、期待どおりか誤ったクロスアカウント/パブリックかを見てポリシーを絞る。意図しない共有を 1 問にすることがある継続的監査機能。

要点

S3 はリージョナルバケットで名前はグローバル一意；オブジェクトはキーで実フォルダではない。
大きなオブジェクトは 5 GB 超でマルチパート必須（~100 MB 超推奨）；最大 5 TB；最大 10k パート；ライフサイクルで古い MPU を中止；低レベルマルチパートは aws s3api。
セキュリティは IAM、バケットポリシー、任意 ACL、暗号化、Block Public Access の組み合わせ。
プリ署名 URL はバケットをパブリックにせず時間限定アクセスを付与。
バージョニングと削除マーカー vs バージョン削除の理解は安全な更新と復旧に不可欠。
初回バージョニング有効化後は重要な書き込み前に伝播を待つ；その間 NoSuchKey が出うる（最新ドキュメントで確認）。
レプリケーションは両方でバージョニング、IAM ロール、デフォルトでは新規オブジェクトの非同期コピー、バックフィルは Batch Replication、削除マーカー同期は任意、バージョン完全削除はレプリケートされない、チェーンなし；任意 RTC で製品条項に沿った 15 分ウィンドウ型 SLA、CloudWatch 可視性、追加 GB 料金。
クロスアカウントレプリケーションは多くの場合宛先バケットポリシーとオブジェクト所有権計画（宛先アカウントが所有・読取するなら owner override）。
ライフサイクルが遷移と期限切れ（現行/非現行、削除マーカー、未完了 MPU）を自動化；プレフィックスまたはタグでスコープ；Standard → IA 調整に S3 Analytics。
イベント通知 → 宛先のリソースポリシー経由で SNS / SQS / Lambda；EventBridge でリッチなルーティング；配信は速いが厳密なリアルタイムではない。
性能： プレフィックスあたり非常に高いベースライン RPS；マルチパート、Transfer Acceleration、バイトレンジ GET、プレフィックス分散で最適化。
Batch Operations + Inventory（マニフェストフィルタに Athena）で大規模修正（例：未暗号化をすべて暗号化）。
Athena = S3 上のサーバーレス SQL；Parquet/ORC、圧縮、パーティション、適切なファイルサイズでスキャン最小化；コネクタでフェデレートクエリも可。
MFA Delete（バージョニングバケット）：CLI/ルート所有者ワークフロー；バージョン完全削除とバージョニング一時停止に MFA — バージョニング有効化やバージョン一覧には不要。
アクセスログ： 別宛先バケット、同一リージョン；ソースバケットにログを書かない（フィードバックループ回避）；Athena で分析。
WORM： Glacier Vault Lock（ロックされたボールトポリシー）vs S3 Object Lock（compliance vs governance、保持 vs リーガルホールド、s3:PutObjectLegalHold）。
VPC からのプライベート S3： ゲートウェイエンドポイント（無料、ルートテーブル）；インターフェースエンドポイント（ENI コスト、PrivateLink、オンプレ経路）；DNS 設定が重要。
Access Analyzer がポリシー/ACL/アクセスポイントからパブリックとクロスアカウントの S3 アクセスを表面化。

Claudeによる翻訳