Amazon S3 Object Lock設計入門｜WORM準拠ストレージの保持ポリシー・ガバナンスモード・バケット設定をコンプライアンス要件別に整理する実践ガイド

「コンプライアンス要件で監査ログを一定期間改ざん不可で保存しなければならないが、S3で実現できるのか？」「誤操作や内部不正でバックアップデータを削除されるリスクをゼロにしたい」

オンプレ環境では、NetApp SnapLockやEMC DataDomainのWORM機能、あるいは物理テープ媒体で対応してきた要件です。AWSに移行した際、これと同等の不変ストレージをどう設計するかは、金融・医療・公共系のインフラエンジニアが避けて通れないテーマです。

この記事では、Amazon S3 Object Lockの仕組みと2つの保持モードの使い分け、バケット設定の手順、コンプライアンス要件別の設計パターンを現場目線で解説します。S3の基本操作を理解している方を対象に、設計判断に直結する知識を整理します。

S3 Object Lockとは何か？オンプレWORMとの比較

S3 Object Lockは、Amazon S3のオブジェクトをWORM（Write Once Read Many）方式で保護する機能です。指定した保持期間中は、オブジェクトの上書き・削除が不可能になります。

オンプレのWORM製品と比較すると、以下のように対応関係を整理できます。

Object Lockを使う前に押さえておくべき前提条件が2つあります。

・バージョニングが必須: Object Lockはバージョニングが有効なバケットにのみ適用できます。Object Lockを有効化すると自動的にバージョニングもオンになります。
・バケット作成時のみ有効化可能: 既存のバケットにObject Lockを後から追加することはできません。コンプライアンス要件が見込まれる用途のバケットは、設計段階からObject Lockを想定して作成する必要があります。

2つの保持モードを理解する（Compliance vs Governance）

S3 Object Lockには「保持モード（Retention Mode）」が2種類あり、その選択が設計の核心です。

1. Compliance Mode（コンプライアンスモード）

Compliance Modeは、AWSアカウントのrootユーザーを含むすべてのユーザーがオブジェクトを削除・上書きできない最高レベルの不変性を提供します。保持期間を短縮することも、保持モードをGovernanceに変更することも不可能です。

注意点として、設定ミスが起きた場合でも保持期間中は修正できません。本番環境に適用する前に、Governance Modeで十分なテストを行うことを強く推奨します。

2. Governance Mode（ガバナンスモード）

Governance Modeは、特別なIAM権限（s3:BypassGovernanceRetention）を持つユーザーであれば、保持設定を上書きして削除できるモードです。通常のユーザーには削除・上書きの防止が効きますが、管理者は緊急時に対応できます。

Governance Modeが適している場面は以下のとおりです。

・Compliance Mode適用前のリハーサル: 本番移行前に設定値や動作を検証するステージング用途
・内部監査ログの保管: SEC規則のような外部規制は課されないが、意図しない削除・改ざんを防ぎたい場合
・テスト・開発環境のデータ保護: 一定期間データを保持するが、誤設定の場合に管理者が修正できる余地を残したい場合

Governance Modeで削除をバイパスするには、リクエストヘッダーに x-amz-bypass-governance-retention: true を付加し、かつ s3:BypassGovernanceRetention IAM権限が必要です。この操作はCloudTrailに記録されるため、証跡として残ります。

Legal Hold（リーガルホールド）の仕組みと使い分け

Legal Holdは、保持期間（Retention Period）とは独立して動作するオブジェクト保護の仕組みです。

保持期間は「X年間保存」という時間軸で管理しますが、Legal Holdは「このオブジェクトにホールドをかけている限り削除不可」という状態管理です。訴訟・調査期間中にオブジェクトを確実に保護し、調査終了後に解除します。

2つの仕組みは組み合わせて使えます。保持期間が満了した後でも、Legal Holdが残っていればオブジェクトは削除できません。証拠保全が必要な場面では、保持期間の設定とは別にLegal Holdを追加するのが安全な設計です。

S3 Object Lockのバケット設定手順

実際の設定の流れを押さえておきましょう。

1. バケット作成時にObject Lockを有効化する

AWSマネジメントコンソールでバケットを新規作成する際、「詳細設定」セクションに「Object Lockを有効化する」オプションがあります。これを有効化すると、自動的にバージョニングもオンになります。

AWS CLIを使う場合は以下のように実行します（AWS CLI v2）。

# バケット作成時にObject Lockを有効化（ap-northeast-1）
aws s3api create-bucket \
  --bucket my-compliant-logs-bucket \
  --region ap-northeast-1 \
  --create-bucket-configuration LocationConstraint=ap-northeast-1 \
  --object-lock-enabled-for-bucket

2. バケットレベルのデフォルト保持設定を構成する

バケット全体にデフォルトの保持モードと保持期間を設定しておくと、新しく追加されるオブジェクトに自動的に適用されます。個別のオブジェクトに毎回設定する手間が省けるため、大量のログを保存する用途では有効です。

# バケットのデフォルト保持設定（Governance Mode、180日間）
aws s3api put-object-lock-configuration \
  --bucket my-compliant-logs-bucket \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "GOVERNANCE",
        "Days": 180
      }
    }
  }'

3. オブジェクトレベルで個別に保持設定を指定する

特定のオブジェクトだけ保持期間を長くしたい場合や、バケットのデフォルトを上書きしたい場合は、オブジェクトアップロード時に個別設定できます。

# オブジェクトアップロード時にCompliance Mode・7年保持を設定
aws s3api put-object \
  --bucket my-compliant-logs-bucket \
  --key "audit-logs/2026/10/cloudtrail.log.gz" \
  --body cloudtrail.log.gz \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "2033-10-20T00:00:00Z"

保持終了日はISO 8601のUTC形式で指定します。タイムゾーンのズレによって1日早く保護が解除されるミスが起きやすいため、必ずUTCで計算してください。

コンプライアンス要件別の設計パターン

どの保持モードを選ぶかは、対象の規制要件によって変わります。代表的なパターンを整理します。

1. 金融・証券業（SEC Rule 17a-4 / CFTC規制）

米国の証券規制SEC Rule 17a-4(f)では、電子的な書面・通信記録を改ざん不可能な形式で最低3年以上保管する義務があります（一部は最低6年）。この規制を満たすにはCompliance Modeが必須です。

以下は証券会社が顧客注文記録をS3に保存する場合の設計方針の想定例です。

・保持モード: Compliance Mode
・保持期間: 6年（2,190日）
・バケットデフォルト保持を設定し、個別オブジェクトレベルでの設定漏れを防ぐ
・AWS Configルールで「Object Lockが有効なバケットにのみ記録が保存されているか」を継続的に監視
・AWS Audit ManagerでSEC Rule 17a-4対応の証拠収集を自動化

2. 医療・ヘルスケア（HIPAA対応）

HIPAAでは患者の医療記録を最低6年間（各州法によってはそれ以上）保持する義務があります。改ざん防止は必須ですが、SEC規則ほど厳格な外部WORM要件は課されていないため、運用上の柔軟性を持たせたい場合はGovernance Modeも選択肢になります。

以下は電子カルテデータを保管するバケットの設計方針の想定例です。

・保持モード: Governance Mode（誤設定への対応余地を残す）または Compliance Mode（最高レベルの保証が必要な場合）
・保持期間: 2,190日（6年）以上
・暗号化: AWS KMSのカスタマー管理キー（CMK）でSSE-KMSを適用し、暗号化とアクセス制御を一元管理
・AWS Macieでバケット内の個人情報・医療情報の保存状況を自動検出・モニタリング

3. 内部監査ログの保管（CloudTrailログ等）

外部規制ではなく、社内セキュリティポリシーとして監査ログを改ざん不可で保管したい場合は、Governance Modeが現実的です。誤設定や保持期間の変更が必要になった際に管理者が対応できる柔軟性を持ちながら、一般ユーザーからの誤操作を防げます。

以下はCloudTrailのログをS3 Object Lockで保護する設計の想定例です。

・S3バケットにはCloudTrailのみが書き込む（バケットポリシーで書き込み元を制限）
・保持モード: Governance Mode
・保持期間: 365日（1年間）
・保持期間満了後はS3ライフサイクルルールでS3 Glacier Flexible Retrievalへ移行してコストを削減
・S3クロスリージョンレプリケーション（CRR）を組み合わせて別リージョンにもコピーを保持し、リージョン障害時のログ消失リスクを排除

料金への影響とコスト設計の注意点

S3 Object Lock機能自体に追加料金はかかりません。ただし、設計を誤るとストレージコストが想定外に膨らむリスクがあります。

・ストレージ料金の積み上がり: 保持期間中はオブジェクトを削除できないため、不要になったデータでもコストが発生し続けます。特にCompliance Modeでは誤って長い保持期間を設定すると修正できません
・ストレージクラスの選択: Object LockはS3 Glacier Instant Retrieval・Flexible Retrieval・Deep Archiveとも組み合わせられます。アクセス頻度が低い長期保管データはGlacierクラスを選ぶことで料金を大幅に抑えられます（2026年10月時点: S3 Standard 約$0.025/GB/月に対しGlacier Deep Archive 約$0.00099/GB/月）
・バージョニングによるストレージ増加: Object Lockはバージョニングが前提のため、同じオブジェクトに対して上書きが発生すると旧バージョンも残り続けます。書き込みパターンによっては想定の数倍のストレージが必要になることがあります

長期保管データのS3ライフサイクルルールによるストレージクラス自動移行との組み合わせが、コスト最適化の基本戦略です。

よくあるつまずきと対処法

S3 Object Lockは一度有効化すると取り消しが難しいため、設定前に一般的なミスを把握しておくことが重要です。

・既存バケットへの後付け有効化を試みてエラーになる: Object Lockはバケット作成時のみ有効化できます。既存バケットにObject Lockを適用したい場合は、新しいバケットを作成してデータを移行する必要があります
・Compliance Modeで保持期間を誤設定する: テスト目的でComplianceモードを試す際に、保持期間の単位を「Days」と「Years」で混同して長すぎる期間を設定してしまうケースがあります。本番環境で使う前にGovernance Modeで動作を十分確認しましょう
・Legal Holdの解除を忘れる: 訴訟・調査が完了した後もLegal Holdを解除し忘れると、保持期間が満了してもオブジェクトが削除できない状態が続きます。Legal Hold解除の手順を運用フローに組み込んでおくことが必要です
・バージョンIDの指定忘れによる削除失敗: バージョニングが有効なバケットでオブジェクトを削除しようとする際、バージョンIDを指定しないと削除マーカーが挿入されるだけで、Object Lockで保護されている旧バージョンは残り続けます。意図した削除を行うには必ずバージョンIDを指定してください
・MFADeleteとの混同: MFADeleteはバージョン削除にMFA認証を要求する別機能です。Object Lockとは独立して動作するため、両方の要件を整理してから設計することをお勧めします

本記事のまとめ

Amazon S3 Object Lockは、クラウドにおけるWORM準拠ストレージを実現するために欠かせない機能です。本記事の要点を整理します。

S3 Object Lockと暗号化設計を組み合わせることで、コンプライアンス要件への対応を包括的に実現できます。AWSデータ暗号化設計入門もあわせてご確認ください。