まずここで事故らない
SAA-C03のS3は「知っているつもり」で落ちやすい分野です。理由はシンプルで、設定項目が多いのに、試験では“要件に合う最小構成”を選ばされるから。
この記事では、S3で頻出の論点を要点20に圧縮し、暗号化・ポリシー・ライフサイクル・レプリケーションを軸に「落ちない判断基準」を作ります。
S3の最小前提
- バケット：入れ物（リージョンに属する）
- オブジェクト：データ本体＋メタデータ
- キー（Key）：オブジェクトのパスのように見える識別子（実体はフラット）
「耐久性」と「可用性」は別モノ
- 耐久性：データが消えない確率（設計思想）
- 可用性：利用できる時間の割合（サービス提供の安定度）
試験では「99.999999999% durability」などの数字よりも、要件が“消えない”なのか“止まらない”なのかを見ます。
S3で頻出の出題テーマ
- アクセス制御：IAM / バケットポリシー / Block Public Access / 所有権
- 暗号化：SSE-S3 / SSE-KMS / SSE-C / 転送時暗号化
- データ管理：Versioning / ライフサイクル / ストレージクラス / Object Lock
- 複製・DR：CRR/SRR / KMS / 所有者 / レプリケーション範囲
ここからは、試験対策として覚えるべき「要点20」をブロックごとに潰していきます。まずは全体の地図として、この記事の要点を先に提示します。
S3で落ちない要点20
暗号化（1〜5）
1. SSE-S3 / SSE-KMS / SSE-Cの違いを言語化できる
2. SSE-KMSは「KMS権限（キー/ポリシー）」がセットで問われる
3. バケットポリシーで「暗号化必須」を強制できる
4. 転送時暗号化は aws:SecureTransport 条件で強制が鉄板
5. KMSコスト対策に Bucket Key が出ることがある
ポリシー・アクセス制御（6〜12）
6. IAMは“主体（誰）”、バケットポリシーは“資源（どこ）”を軸に考える
7. Block Public Accessは「公開事故を止める最後の砦」
8. ACLは原則避ける（出るのはクロスアカウントの古い設計や例外）
9. Object Ownership（Bucket owner enforced）で所有権の罠を回避
10. 条件キー（IP制限/VPCエンドポイント/HTTPS強制）を使い分け
11. S3 Access Pointsは大規模権限設計で強い（試験でも出る）
12. 静的Webホスティングは「公開＝危険」ではなく“要件次第”で設計
ライフサイクル・管理（13〜17）
13. ストレージクラスは“頻度と復元要件”で選ぶ
14. ライフサイクルは「移行」「期限切れ」「非現行バージョン」が軸
15. Versioningは事故対策（上書き/削除）で頻出
16. Object Lock（WORM）は規制・監査要件で出る
17. Inventory/イベント通知は運用系のシナリオで刺さる
レプリケーション・DR（18〜20）
18. CRR/SRRはVersioning必須＋条件あり（削除含む範囲に注意）
19. レプリケーション＋SSE-KMSはKMS権限不足で詰みやすい
20. DR要件（RPO/RTO）に対してS3単体で何ができるか判断する
暗号化で落ちない（SSE-S3 / SSE-KMS / SSE-C＋キー管理）
S3の暗号化は、問題文で「暗号化が必要」と書いてあっても**“どの暗号化か”で答えが変わる**のが罠です。試験で迷ったら、次の順で要件を分解します。
要点1：SSEの種類を一言で言えるようにする
- SSE-S3：S3管理の鍵（最も手軽、追加のKMS設計不要）
- SSE-KMS：KMS管理の鍵（監査/鍵ローテ/権限制御が強い、試験頻出）
- SSE-C：顧客提供鍵（ユーザーが鍵を毎回提供、運用が重く試験では“要件が強いとき”に登場）
試験の判断軸
- 「監査証跡」「鍵の管理を自社で」「キーの無効化/ローテ」→ SSE-KMS寄り
- 「とにかく簡単に暗号化」→ SSE-S3
- 「鍵をAWSに保存させない」→ SSE-C（ただし運用負荷が高い）
要点2：SSE-KMSは“権限セット”で出る
SSE-KMSにすると、IAMだけでなく KMSキー側の権限（Key policy） が絡みます。
試験のありがちな落とし穴はこれです。
- バケットへのPutObjectは許可しているのに、KMS:Encrypt / GenerateDataKey が足りず失敗
- レプリケーション先で KMSキーが別 → 送信側/受信側で権限が噛み合わない
覚え方はシンプル：
S3に書ける権限 + KMSで暗号化できる権限 = SSE-KMSが動く
要点3：バケットポリシーで「暗号化必須」を強制できる
「S3に保存するデータは必ず暗号化されている必要がある」系は頻出です。
このとき、**“設定で暗号化をON”**だけだと「ユーザーが暗号化せずにPUTしたら？」が残ります。
試験が求めるのは、ポリシーで強制です。
例（考え方）：
s3:x-amz-server-side-encryptionヘッダが無いPUTを Deny- SSE-KMS必須なら
aws:kmsを要求する（SSE-S3ではなくKMSを強制）
※記事なのでコードは省略しますが、「Denyで強制」という考え方がポイントです。
要点4：転送時暗号化（HTTPS）を強制する鉄板
「転送中も暗号化（in transit）」は、S3では HTTPS（TLS） を強制するのが定番。
頻出の条件キーが aws:SecureTransport です。
aws:SecureTransport = falseを Deny
→ HTTPアクセスを拒否できる
要点5：KMSコスト対策に Bucket Key が出る
細かいですが、問題文に「KMSコストを下げたい」や「大量PUTでKMS呼び出しが増える」が出たら S3 Bucket Key を疑います。
Bucket Key は、S3側でデータキーの利用を最適化して KMSリクエスト回数を抑える方向の機能です（“KMSを使う”前提の話）。
ポリシーで落ちない（IAM / バケットポリシー / ACL / ブロックパブリック / 所有権）
S3のアクセス制御は、試験の中でも特に“ひっかけ密度”が高いです。
ここは丸暗記ではなく、**「誰を制御したい？」「どのバケットを制御したい？」**の2軸で整理すると落ちにくくなります。
要点6：IAMは主体（誰）、バケットポリシーは資源
- IAMポリシー：ユーザー/ロール/グループに付ける → “この人に何をさせる”
- バケットポリシー：バケットに付ける → “このバケットに誰が何できる”
試験での使い分け例
- 「特定のアプリロールだけこのバケットにPUTできる」→ IAMでも可、バケットでも可
- 「クロスアカウントでアクセスさせたい」→ バケットポリシーが出やすい
- 「複数バケットにまたがる権限」→ IAMでまとめたくなる
要点7：Block Public Accessは最後の砦
S3公開事故の対策として Block Public Access は超頻出。
ポイントは「バケットポリシーで公開していても、Blockが有効なら止まる」ケースがあること。
問題文が「誤設定で公開されたくない」「会社の標準で公開禁止」と言うなら、Block Public Access を強めに疑います。
要点8：ACLは原則使わない
最近の設計ではACLは避けがちですが、試験では以下のような“歴史的/例外的”文脈で出ます。
- 他アカウントからログを配信してもらう古いパターン
- 所有権がズレて読み出せない → ACL/所有権の話になる
とはいえ結論はだいたいこれ：
**「ACLで頑張る」より「Object Ownershipで所有権問題を潰す」**が正解になりやすいです。
要点9：Object Ownership（Bucket owner enforced）で所有権の罠を回避
クロスアカウントでオブジェクト所有者が書き込み側になると、バケット所有者が扱いにくくなります。
この罠を避けるために、Object Ownership（Bucket owner enforced） を使う設計が頻出です。
（ACLを無効化し、バケット所有者がオブジェクトを所有する方向）
要点10：条件キーを使い分ける
SAA-C03でよく見る条件パターン：
- HTTPS強制：
aws:SecureTransport - IP制限：送信元IPで許可/拒否（オフィス固定IPなど）
- VPCエンドポイント経由に限定：VPC Endpoint条件（インターネットを通さない要件）
- 特定のプレフィックスのみ許可：パス（キー）で制御して“部署ごと”を表現
要点11：S3 Access Points
「部署ごとにアクセスを分けたい」「同一バケットに対して複数アプリがそれぞれ別の制御」
この条件が出たら S3 Access Points が正答になりやすいです。
バケットポリシーを1枚に肥大化させず、アクセスポイントごとにポリシーを分割できます。
要点12：静的Webホスティングは“要件で選ぶ”
静的Webホスティング（S3 Website）は「簡単に公開」できますが、HTTPSや認証の要件があると、CloudFrontを前段に置く設計が出ます。
試験でよくある分岐：
- 「世界中に高速配信」「HTTPS」「WAF」→ CloudFront + S3
- 「とにかく簡易な静的サイト」→ S3 Website（ただし公開範囲に注意）
ライフサイクルで落ちない（Versioning / ストレージクラス / 削除 / 保持）
ライフサイクルは「コスト最適化」だけでなく、「保持」「監査」「復元時間」が絡んできます。
問題文のキーワードで、答えがガラッと変わるので注意です。
要点13：ストレージクラスは“頻度と復元要件”で選ぶ
代表的な判断軸だけ押さえればOKです。
- Standard：頻繁アクセス
- Standard-IA：たまにアクセス、取り出し料金あり
- One Zone-IA：1AZで良い（安いがAZ障害耐性は下がる）
- Intelligent-Tiering：アクセス頻度が読めない（自動階層化）
- Glacier系（Instant/Flexible/Deep Archive）：長期保管、復元要件により選択
試験のコツ：
「数年保管」「監査でたまに取り出す」「復元は数時間でもOK」などの条件が、Glacier系を指します。
要点14：ライフサイクルは3点セット
ライフサイクルルールは、問題で混ぜてきます。
- 移行（Transition）：一定日数後にIAやGlacierへ
- 期限切れ（Expiration）：一定日数後に削除
- 非現行バージョン（Noncurrent）：Versioning有効時の古い版の扱い
「Versioning有効」なのに「削除したのに容量が減らない」
→ 非現行バージョンの期限切れを設定していない、という“あるある”が試験に出ます。
要点15：Versioningは事故対策（上書き/削除）で頻出
- 誤上書き
- 誤削除
- ランサムウェア対策（文脈として）
これらが出たら、まず Versioning。
さらに強い要件として「削除も簡単にできないように」→ MFA Delete（ただし運用負荷あり）や Object Lock に繋がります。
要点16：Object Lock（WORM）は規制・監査で出る
「改ざん不可」「一定期間は削除不可」「法令で保持」
こういう要件は WORM（Write Once Read Many） の世界で、S3なら Object Lock が候補になります。
モード（Compliance/Governance）の概念もありますが、試験的には「削除できない要件ならObject Lock」をまず出せればOKです。
要点17：Inventory・イベント通知は運用シナリオで刺さる
- 「バケット内オブジェクトの一覧が欲しい」「メタデータを定期的に棚卸し」→ S3 Inventory
- 「PUTされたらLambdaで処理」「アップロードをトリガにETL」→ イベント通知（Event Notification）
単発暗記より、“要件→機能”で繋げると強いです。
レプリケーションで落ちない（CRR/SRR＋KMS＋運用・監査）
レプリケーションは「設定項目が多い」上に、暗号化・所有権・削除の扱いまで絡むので、S3の中でも難所です。
ただし、試験の“よくある形”は決まっています。
要点18：CRR/SRRはVersioning必須
- CRR（Cross-Region Replication）：別リージョンへ複製
- SRR（Same-Region Replication）：同一リージョン内で複製
どちらも基本として Versioningが必要。
問題文が「レプリケーションしたい」なら、選択肢にVersioningが含まれているかを必ず確認します。
また、レプリケーションの“範囲”も注意：
- 既存オブジェクトは自動では複製されない（条件や設定次第）
- 削除マーカーや削除の伝播は設計/設定に依存する
試験はここを曖昧にして「最も適切なもの」を選ばせます。
要点19：レプリケーション＋SSE-KMSはKMS権限で詰む
CRR/SRRでSSE-KMSを使うと、暗号化の章で触れたとおり KMS権限が両側で必要になります。
ありがちな失敗パターン：
- 複製先バケットへの権限はあるが、複製先KMSキーに権限がない
- レプリケーションロールにKMS権限が足りない
試験対策の合言葉：
「S3の権限」＋「KMSの権限」＋「複製ロール」
要点20：DR要件（RPO/RTO）に対してS3単体で何ができるか
DR（災害対策）系のシナリオでは、RPO/RTOが匂わされます。
- 「リージョン障害でもデータを失いたくない」→ CRRを疑う
- 「同一リージョン内でコピーが必要」→ SRR
- 「読み取り遅延なく別リージョンで使う」→ アプリ側の設計も含めて検討（S3だけでは完結しない場合もある）
監査・可視化：何を使う？
運用・監査系の頻出もまとめておきます。
- CloudTrail：API操作（誰がPut/Deleteしたか）
- S3サーバアクセスログ：アクセスログ（要件次第で出る）
- S3 Storage Lens：利用状況や最適化の可視化（組織全体の把握）
仕上げ：S3で落ちない要点20チェックリスト
SAA-C03本番直前に必ず確認したい、S3の“落とし穴回避チェックリスト”です。
暗号化・ポリシー・ライフサイクル・レプリケーションの頻出論点を20項目に集約しているので、「何となく理解」を「確実に選べる判断基準」に仕上げる最終確認として使ってください。
暗号化
- SSE-S3 / SSE-KMS / SSE-C の違いを説明できる（要点1）
- SSE-KMSはKMS権限が別途必要（要点2）
- ポリシーで暗号化必須を“Deny”で強制（要点3）
aws:SecureTransportでHTTPS強制（要点4）- KMSコスト最適化のBucket Keyを思い出せる（要点5）
アクセス制御
- IAM（主体）とバケットポリシー（資源）の使い分け（要点6）
- Block Public Accessの役割と優先度（要点7）
- ACLは原則避け、例外を説明できる（要点8）
- Object Ownershipで所有権トラブルを防ぐ（要点9）
- 条件キー（IP/VPCE/HTTPS/Prefix）を使い分け（要点10）
- Access Pointsのユースケース（要点11）
- 静的サイトはCloudFront併用が頻出（要点12）
管理・最適化
- ストレージクラスを頻度/復元要件で選ぶ（要点13）
- ライフサイクル：移行/期限切れ/非現行（要点14）
- Versioningの目的（誤削除/誤上書き）を言える（要点15）
- Object Lock（WORM）の要件を判断できる（要点16）
- Inventory/イベント通知の使いどころ（要点17）
レプリケーション
- CRR/SRRはVersioning必須（要点18）
- SSE-KMS併用時のKMS権限不足に注意（要点19）
- DR要件に合わせてCRR/SRRを選ぶ（要点20）
Udemyでの学習
S3は、用語暗記だけだと「ポリシー条件」や「KMS権限の絡み」を本番で取り違えがちです。一度でもコンソールで設定して詰まった経験が、そのまま得点力になります。
Udemyで選ぶときの基準はこの3つがおすすめです。
- SAA-C03対策として“ハンズオン”が多い（S3/CloudFront/KMS/IAMを触る）
- 模試が付いていて、解説で選択肢の切り捨て理由が書かれている
- S3のセキュリティ（ポリシー/暗号化）に時間を割いている
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
SAA-C03のS3は、暗号化・ポリシー・ライフサイクル・レプリケーションが絡み合うため、ふわっと理解していると落とし穴にハマりやすい分野です。
対策のコツは、S3の論点を「要点20」に絞り、**①暗号化（SSEの選択＋KMS権限＋HTTPS強制）→②アクセス制御（IAM/バケットポリシー/Block Public Access/所有権）→③データ管理（Versioning/ライフサイクル/ストレージクラス/Object Lock）→④レプリケーション（CRR/SRR＋KMS＋範囲）**の順で、要件から逆算できる判断軸を作ることです。
最後はUdemyなどで一度ハンズオンを回し、ポリシー条件やKMS権限の“詰まりどころ”を体験しておくと、本番で迷う時間が一気に減ります。S3は「設定できる＝選べる」なので、この記事のチェックリストを使って弱点を潰し、確実に得点源にしていきましょう。
