保管規制で「消せない」が出たらS3オブジェクトロックを思い出す
監査・金融・法務・医療など、規制が絡むシステム設計でよく出てくるのが「一定期間、絶対に消せない形で保存したい」「あとから改ざんされたくない」という要件です。ここで大事なのは、“アクセス制御で消せない” ではなく “仕組みとして消せない（WORM）” を求められているケースがある、という見分け方です。
SAA-C03の学習でも、この手の要件が出ると「S3のバージョニング？」「MFA Delete？」「KMS？」「CloudTrailで追跡？」と候補が増えて混乱しがちです。結論から言うと、WORM（Write Once Read Many）を明示されたら、まず S3 Object Lock（S3オブジェクトロック） を思い出すのが筋が良いです。
この記事では、暗記ではなく「要件→機能→設計判断」をつなげて、WORM要件で迷わない整理をします。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
S3オブジェクトロックの全体像と前提条件
S3オブジェクトロックは、S3上のオブジェクトを一定期間（または無期限）“上書き・削除できない”状態にする機能です。規制要件が求めるWORM保管を満たすため、あるいはランサムウェア対策として「削除されない最後の砦」を作る目的でも使われます。
ここで重要な前提が2つあります。
新規バケットで有効化する前提がある
オブジェクトロックは、バケット作成時に有効化しておく必要があります（あとから「このバケットをWORM対応に変更したい」ができない場面が出ます）。
バージョニング前提で動く
オブジェクトロックは、オブジェクトの“バージョン”単位で保護します。つまり、設計の頭の中ではこう考えるのが分かりやすいです。
- 「ファイル」は実体としては オブジェクトの“バージョン列”
- その各バージョンに「保持期限」や「ホールド」を付ける
この“バージョン単位”という考え方は、SAA-C03でS3を扱うときの理解にも直結します（「上書き禁止＝PUT禁止」ではない、という勘違いが減ります）。
保持期間と2つのモード、リーガルホールドの整理
オブジェクトロックの保護は、大きく 保持期間（Retention） と リーガルホールド（Legal Hold） の2系統です。
保持期間は「期限つきの改ざん防止」
保持期間を設定すると、その期限（retain-until-date）まで対象のオブジェクトバージョンは上書き・削除できなくなります。保持期間には、保護の強さが違う2つのモードがあります。
コンプライアンスモード
- 最も強い固定
- 期限内は、rootユーザーを含めて誰も削除・上書きできない
- 一度このモードでロックすると、モード変更不可／保持期間短縮不可
規制で「絶対に消せない形式で保存」を求められている場合、このニュアンスが近いです。
ガバナンスモード
- ほとんどのユーザーは削除・上書きできない
- ただし、特別な権限を持つユーザーは保持をバイパスして削除できる（“例外ルート”がある）
「運用上、管理者だけはどうしても救済できる余地を残したい」要件にフィットします。逆に「誰にも例外を許したくない」ならコンプライアンス寄りです。
リーガルホールドは「期限なしの保護スイッチ」
リーガルホールドは、期限（日付）を持たない保護です。オンにしている間は、保持期間とは別枠で削除・上書きを止め続けるイメージです。監査や訴訟対応など「いつ解除できるか未確定」な状況で使いやすい設計になります。
どれを使うか迷ったら
- 「◯年保存」など期限が明確 → 保持期間
- 「調査が終わるまで凍結」など期限が不明 → リーガルホールド
- 「例外なし」 → コンプライアンスモード
- 「管理者だけ救済可」 → ガバナンスモード
設計・運用でつまずきやすい点と実務的な落とし穴
S3オブジェクトロックは強力な反面、「分かったつもり」で設計すると運用で詰みます。ここはSAA-C03でも前提として扱われやすい部分なので、考え方を押さえておくと楽です。
まず「消せない」の対象を言語化する
WORM要件の文章は、だいたい次の3パターンに分解できます。
- 人為ミス対策：誤削除を防ぎたい
- 内部不正対策：権限者による改ざんも防ぎたい
- 規制準拠：一定期間、非改ざん・非消去が必要
このうち「規制準拠」や「内部不正対策」色が濃いほど、アクセス制御（IAM/バケットポリシー）だけでは不十分で、オブジェクトロックが候補に上がってきます。AWS自身も、WORM要件や規制要件に対してS3オブジェクトロックを位置づけています。
“設定した保持期間”はコストと運用を縛る
例えば「100年保持」みたいな極端な要件が来たとき、技術的に設定できても、実際は次を必ず考える必要があります。
- ストレージクラス移行（ライフサイクル）をどうするか
- “保持の強さ”と“運用救済”のバランス
- 監査対応として「ロック状態を証明できる」設計にするか
特に「証明できる」は盲点になりがちです。金融業界向けのAWS Well-Architectedの観点では、S3インベントリレポートでオブジェクトロック状態を追跡できることにも触れています。
一括適用が必要ならBatch Operationsも視野
大量のオブジェクトへ保持期限を適用する場合、S3 Batch Operationsでオブジェクトロックの保持日付を一括設定できます。実務で「過去データにも適用したい」が出たときの逃げ道として覚えておくと安心です。
「評価済み」という言葉の意味を正確に理解する
S3オブジェクトロックは、特定の規制（例：SEC 17a-4、CFTC、FINRA）の環境での利用について第三者（Cohasset Associates）による評価がある、とAWS公式が説明しています。
ただし、これは「あなたの業務が自動的に準拠する」ことを保証する話ではなく、機能として要件に対応できる設計土台があるという理解が安全です。試験対策でも、ここを“合格ワード”として丸暗記するより、要件を聞いて機能へ落とすプロセスを持っておく方が強いです。
SAA-C03目線の判断軸と典型シナリオ、学び方
ここまでを、SAA-C03での判断に落とし込むと「要件文からキーワードを拾う」ではなく、次の判断軸で整理できます。
判断軸は「誰が消せないのか」「いつまで消せないのか」
- いつまで：期限あり→保持期間、期限なし→リーガルホールド
- 誰が：例外なし→コンプライアンス、救済あり→ガバナンス
この2軸で、だいたいの設計判断がスッと決まります。
典型シナリオの考え方
シナリオ：監査ログを一定期間改ざんできない形で保存したい
- 監査ログは「消されたら困る」だけでなく「改ざんされたら困る」
- 期限が明確なら保持期間
- 規制色が強いならコンプライアンス寄り
シナリオ：法務から「この案件の関連資料は当面凍結」と言われた
- いつ解除できるか不明
- 期限なしのリーガルホールドがイメージしやすい
シナリオ：ランサムウェア対策で「消せないバックアップ」を作りたい
- “権限を取られても消せない”を目指すなら、アクセス制御だけでなく不変性（immutability）のレイヤーが効く
- その選択肢としてS3オブジェクトロックはAWS公式のユースケースにも沿う
学び方のコツ
S3オブジェクトロックは、細かいAPIや権限を全部暗記するより、まずは次の3点を“自分の言葉で説明できる”状態にするのが近道です。
- 保持期間とリーガルホールドの違い
- コンプライアンスとガバナンスの違い
- バージョニング前提で「オブジェクトバージョンを守る」仕組みであること
そのうえで、体系的にS3全体（暗号化、バージョニング、ライフサイクル、アクセス制御、設計パターン）と合わせて学ぶと理解が固まりやすいです。教材の一例としては、SAA-C03向けにストレージ設計をまとめて扱うUdemy講座のような“章立てで復習できる形式”が相性が良いと思います（断片知識をつなげやすいので）。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
WORM要件が出たときに大事なのは、「S3に置けばOK」ではなく、“仕組みとして消せない”を作る必要があるかを見分けることです。AWSでは、その代表的な答えが S3オブジェクトロック です。
押さえるべき整理はシンプルで、判断は主に2軸で決まります。
- いつまで消せないか：期限ありは保持期間、期限なしはリーガルホールド
- 誰が例外になれるか：例外なしはコンプライアンス、救済ありはガバナンス
さらに「バケット作成時に有効化する前提」「バージョニングとセットで“バージョンを守る”」という構造を理解しておくと、SAA-C03の設計問題でも迷いにくくなります。WORMという言葉が見えたら、まずは落ち着いて「期限」と「例外」の2つを要件文から拾い、S3オブジェクトロックへ自然に接続できる状態を目指しましょう。
