AWS Backup サイバーレジリエンス Vol2 — 論理エアギャップ保管庫

1. ランサムウェア時代のバックアップ保護課題とAWS Backup新機能全体像

クラウド上のデータ保護において、バックアップは「最後の砦」として機能してきました。しかし近年、この砦そのものを標的にした侵害が増加しています。バックアップを暗号化あるいは削除することで復旧経路を断つ手口は、サイバーインシデントの深刻度を格段に高めます。

AWS Backupは2024年から2025年にかけて、この課題に正面から向き合う新機能群を追加しました。logically air-gapped vault（論理エアギャップ保管庫）を中心に、Vault Lock compliance mode、restore testing、primary backup target、Organizations多者承認、EKS/FSx対応まで、バックアップ保護の層を根本から厚くする機能が揃っています。東京リージョン（ap-northeast-1）でも利用できるため、国内企業のハンズオン環境でそのまま試せます。

1-1. バックアップ自体が標的となる侵害の実態

従来のデータ保護設計では、バックアップは安全な場所にある「副本」として扱われていました。しかし現代の侵害者はこの前提を崩しにきています。侵入後に管理者権限を奪取し、バックアップシステムにアクセスして副本を消去するか暗号化する手口が、インシデント報告で繰り返し確認されています。

こうした手口が成立する背景として、以下の3点が挙げられます。

バックアップシステムへの横断的アクセス

多くの組織では、バックアップシステムへのアクセス制御が本番環境と同一の認証基盤に依存しています。管理者アカウントが侵害されると、バックアップシステムへのアクセスも同時に失われるリスクがあります。IAMロールやサービスアカウントが本番・バックアップで共用されているケースでは、単一の認証情報の流出が全体に影響します。

削除操作のアラート遅延

バックアップの削除操作は、リアルタイムアラートではなくバッチ処理で検知される場合があります。削除完了後にアラートが届く設計では、検知と対処が間に合いません。特に保持期間の設定変更は通常の運用操作と区別しにくく、異常を見逃すリスクがあります。

バックアップ用ストレージの書き換え可能性

通常の書き換え可能なストレージにバックアップを保存している場合、削除や上書きに対する技術的な保護がありません。WORM（Write Once Read Many）ポリシーや不変性保護がなければ、副本は本番環境と同様に脆弱な状態に置かれます。S3バケットにバックアップを保存するシステムでも、バケットポリシーやObject Lockを適切に設定していなければ、同じ問題が生じます。

Veeam Software社の「Data Protection Trends Report 2024」によると、調査対象の85%が過去12か月に少なくとも1度のサイバーインシデントを経験したと報告されています。復旧できた組織においても、バックアップの完全性検証に予想外のコストと時間を要するケースが多く、RTOの達成が困難になる事例が相次いでいます。

攻撃者がバックアップを標的にする理由

攻撃者の立場から見ると、バックアップを削除または暗号化することには明確な動機があります。被害組織がバックアップから復旧できてしまえば、身代金交渉の優位性が失われるためです。このため、高度な侵害では本番データへの影響と並行し、バックアップシステムへの侵入も同時進行するケースが増えています。

こうした脅威への対応策として、バックアップそのものを「侵害者が手を出せない場所」に置く仕組みが必要です。AWS Backupのlogically air-gapped vaultは、まさにこの要求に応える目的で設計された機能です。AWSが管理する分離環境に保管庫を置き、通常のAWSアカウントからの操作を原則として受け付けない構造で、副本の不変性を技術面から保証します。

1-2. 従来のリージョン間DR運用では防げない課題

リージョン間バックアップコピーは、自然災害やリージョン障害に対する可用性確保として有効な手法です。しかし、侵害者がAWSアカウントの管理者権限を奪取した場合、リージョンをまたいで作成されたバックアップも同一のIAM権限で削除できることがあります。リージョン間コピーは「場所の分散」を実現しますが、「アクセス制御の分離」を提供するものではないためです。

この違いを理解することが、リージョン間DRとサイバーレジリエンスの使い分けの出発点になります。

「リージョン間コピーを設定しているから安全」という思い込みは、サイバーインシデントのシナリオでは成立しません。両者は補完関係にあり、目的に応じて組み合わせることが推奨されます。

1-3. AWS Backup新機能の全体像

2024年から2025年にかけてGA（Generally Available）になった主な新機能を以下に整理します。

logically air-gapped vault（2024-08-07 GA）

AWSが管理する論理的に分離された保管庫です。通常のAWSアカウントからの直接アクセスが制限されており、Vault Lock compliance modeが内蔵されています。保存されたバックアップは、保持期間が終了するまで削除・変更が不可能な設計です。Tokyo（ap-northeast-1）を含む主要リージョンで利用できます。preview期間（2023年8月〜）を経て2024年8月7日にGAを迎えました。

Vault Lock compliance mode

保管庫に設定するロックモードです。compliance modeでは、ロック適用後は管理者を含むあらゆるプリンシパルが設定を変更または削除できなくなります。governance modeと異なり、一度適用した保持ポリシーは上書きできません。不変性の証明が規制対応で必要な場合は、compliance modeが適切な選択になります。

restore testing（復旧テスト自動化）

定期的に復旧テストを自動実行し、バックアップからの実際の復旧時間を計測・記録する機能です。復旧テストの証跡はAudit Managerのコンプライアンスレポートと連携し、規制対応の証拠として活用できます。「このバックアップは復旧テストを通過済み」という事実を、定期的な自動検証で確認できます。

primary backup target

バックアップジョブの書き込み先として、logically air-gapped vaultをprimary targetに指定する構成です。バックアップが最初にエアギャップ保護下の保管庫に書き込まれるため、保護の開始タイミングが早まります。通常のvaultを補助先（copy destination）として組み合わせることもできます。

Multi-party approval（Organizations連携）

AWS OrganizationsのBackup policyと組み合わせ、バックアップの削除・設定変更に複数承認者の合意を必須とする機能です。単一アカウントの侵害で復旧経路を断たれるリスクを、組織レベルで低減します。

EKS・FSx対応の拡大

EKS（Elastic Kubernetes Service）へのbackup/restore対応が2026年3月にGAを迎えました。FSx for Lustre・FSx for Windows File Server・FSx for OpenZFSなど、サポート対象リソースが継続的に拡大しています。Kubernetesワークロードへのサイバーレジリエンス適用が可能になっています。

新機能の東京リージョン対応状況

本記事で取り上げる新機能はいずれも東京リージョン（ap-northeast-1）でサポートされています。logically air-gapped vaultの対応リージョン一覧はAWS公式ドキュメントで最新状態を確認してください。制限リストに東京リージョンが含まれていないことが、国内環境での活用に向けた重要な前提条件です。

既存バックアップ運用との統合

これらの新機能は、既存のバックアッププランやバックアップポリシーを大幅に変更せずに統合できます。既存のリージョン間コピー設定を維持しながら、logically air-gapped vaultを追加の保護層として組み込む段階的な導入が可能です。全機能を一度に導入する必要はなく、組織のリスク評価とコスト計画に応じて順次展開することをお勧めします。

1-4. 本記事の構成と読み方

本記事は以下の流れで展開します。§2でlogically air-gapped vaultの仕組みと作成手順を解説し、§3でrestore testingの自動化と証跡管理を扱います。§4でprimary backup targetとOrganizations多者承認を、§5でEKS・FSxへの対応拡大を説明します。§6では組織レベルのバックアップポリシー、Audit Manager連携、コスト最適化をまとめ、§7で実戦統合パターン、§8で詰まりポイントとまとめを提供します。

既存のリージョン間DR設計に追加でサイバーレジリエンス層を導入したい方は、§2から§4を優先して読むことをお勧めします。コスト管理や監査対応を検討している方は§6が特に参考になります。東京リージョンでの試験環境構築については、§2の作成手順から始めることができます。

本記事の想定読者

本記事は以下の課題を持つ読者を主な対象としています。

• AWS Backupを既に運用しており、サイバー侵害への耐性をさらに高めたいエンジニア
• リージョン間DRを既に設定しているものの、logically air-gapped vaultの導入がまだの組織
• ISO 27001・SOC 2・PCI DSSなどの規制対応でバックアップの不変性証明が必要な担当者
• EKSワークロードやFSxのバックアップ保護を検討しているインフラ担当者

AWSの基本的なIAM操作やEC2/RDSバックアップの設定経験があることを前提としています。AWS Backupの基礎については、関連記事も合わせてご参照ください。

本記事で確認できる主な設定例

本記事では以下の設定や手順を具体的に紹介します。

• logically air-gapped vaultの作成手順とVault Lock compliance modeの有効化
• restore testingの設定とvalidation window・自動削除の制御
• AWS Organizations Backup policyのJSON構造とSCPによる保護
• Audit Managerのコンプライアンスフレームワーク作成とレポートのS3出力設定
• EKSおよびFSxへのbackup/restore適用パターン

それぞれの設定において、東京リージョンでの動作確認済みの手順を提供します。

2. logically air-gapped vaultの基礎

2-1. logically air-gapped vaultとは何か

logically air-gapped vaultは、AWS Backupが2024年8月7日に一般提供(GA)を開始した保管庫の新しいタイプです。2023年8月から開始されたプレビュー期間を経て、約1年の検証を重ねてGAに至りました。

「論理エアギャップ」という名称は、物理的な切断ではなく、論理的にアクセスを遮断するアーキテクチャに由来します。従来の標準vaultはバックアップを作成したAWSアカウントと同じアカウント内に存在します。そのため、本番アカウントが侵害された場合、同アカウント内のバックアップも暗号化・削除の標的になりえます。

logically air-gapped vaultはこの課題を解決するために設計されました。バックアップデータはAWSが管理する分離されたアカウントに格納されるため、本番アカウントの管理者権限が奪われた場合でも、保管庫内のデータを直接操作できません。

標準vaultとの違い

logically air-gapped vaultと標準vaultの主な違いを整理します。

標準vaultとの最も重要な違いは「保管場所の分離」と「Vault Lockの自動適用」の2点です。これらが組み合わさることで、バックアップデータに対する不変性が保証されます。

2-2. 2024-08-07 GA概要とPreview期間との差異

GA移行によって変化した主要点を解説します。

東京リージョン(ap-northeast-1)の正式サポート

GA移行とともに、東京リージョン(ap-northeast-1)を含む主要リージョンでの利用が可能になりました。日本国内のお客様にとって、このGAが実運用導入の実質的な起点となります。

Vault Lockの必須化

プレビュー期間中はVault Lockの設定が任意でしたが、GA版ではcompliance modeのVault Lockが保管庫作成時から自動的に組み込まれる設計です。これにより、「Vault Lockを設定し忘れた」という構成ミスをアーキテクチャレベルで防止できます。

RAM共有によるリストア設計の明確化

復元(リストア)時にResource Access Manager(RAM)を介して保管庫にアクセスする仕組みが整備され、復旧時間目標(RTO)の設計がより精密に行えるようになりました。別アカウントの復旧環境へのRAM共有を事前設定しておくことで、インシデント時の迅速な復元が可能になります。

課金モデルの確定

GAにより料金体系が正式に確定しました。ストレージ料金とAPI呼び出し料金が発生します。最新の料金は公式料金ページをご参照ください。

2-3. アーキテクチャ: 別アカウント分離とRAM共有

logically air-gapped vaultのアーキテクチャを「データ格納場所」と「アクセス経路」の2点から解説します。

データが格納される場所

バックアップデータは、お客様のAWSアカウントとは別のAWSマネージドアカウントの保管庫へ格納されます。バックアッププランのスケジュールやオンデマンドバックアップジョブを実行すると、データはAWS Backupサービス内部でこの分離アカウントに転送されます。

データへのアクセス経路: RAM共有

リストアを実行する際は、AWS Resource Access Manager(RAM)を介して保管庫のリカバリポイントにアクセスします。RAM共有することで、複数のアカウントや環境からリストアジョブを起動できます。事前にRAM共有設定を行っておくと、インシデント発生時に迅速なリストアが可能になります。復旧専用アカウントへの事前付与が推奨されます。

アーキテクチャ構成(テキスト表現)

[本番アカウント(ap-northeast-1)]
  バックアップジョブ実行
  |
  v (AWS Backup内部転送)
[AWSマネージドアカウント]
  logically air-gapped vault
  (Vault Lock compliance mode 内蔵)
  (東京リージョン: ap-northeast-1)
  |
  v (RAM共有 → リストア権限付与)
[復旧アカウント / 復旧用IAMロール]
  リストアジョブ実行 → 復元完了

この構成により、本番アカウントの管理者権限を持つ侵害者がいても、logically air-gapped vault内のデータへの直接削除は拒否されます。

2-4. Vault Lock compliance mode内蔵: 設定方法・保持期間・削除不可保証

logically air-gapped vaultには、作成時からVault Lock compliance modeが組み込まれています。

compliance modeとは

Vault Lock compliance modeは、設定した保持期間が満了するまでバックアップを削除できないようにするロック機能です。一度設定すると、保持期間の短縮と解除は不可能です。AWSサポートへの依頼を含め、いかなる手段でも設定の変更はできません。

保持期間パラメータ

保管庫作成時に以下のパラメータを設定します。

MinRetentionDays: 最小保持期間(1以上の整数、単位: 日)
MaxRetentionDays: 最大保持期間(MinRetentionDaysより大きい整数、単位: 日)

このパラメータは保管庫に割り当てられるバックアッププランのライフサイクル設定に作用します。バックアッププランでDeleteAfterDaysをMinRetentionDaysより小さく設定した場合、バックアップジョブはエラーになります。

削除不可保証の範囲

compliance mode適用後のバックアップに対して、以下はすべて不可能です。

• バックアッププランのライフサイクルによる自動削除
• コンソール・CLIからの手動削除
• IAMポリシーを経由した削除操作
• AWSサポートへの削除依頼

保持期間が満了したバックアップは、自動的に削除対象になります。

2-5. compliance mode vs governance mode の違いと使い分け

AWS Backup Vault Lockには「governance mode」と「compliance mode」の2種類があります。

governance modeの特徴

governance modeは、backup:PutBackupVaultLockConfiguration権限を持つユーザーがロック設定を変更または解除できるモードです。設定を誤った場合に修正できるため、段階的な導入やテスト環境での利用に向いています。

compliance modeの特徴

compliance modeは、一度設定すると変更も解除もできないモードです。保持期間は延長のみ可能で、短縮は不可です。金融・医療・行政など、データ保護の規制要件を満たす必要がある環境に適しています。logically air-gapped vaultではcompliance modeのみが使用されます。

使い分けの指針

2-6. AWS所有キー vs カスタマー管理KMSキーの選択

logically air-gapped vaultの暗号化キーには2種類のオプションがあります。

AWS所有キー(デフォルト)

• AWSが管理するデフォルトの暗号化キーを使用します
• 追加コストは発生しません
• キー管理の運用負荷がかかりません
• 「暗号化キーを自社管理する」という規制要件がない場合に推奨です

カスタマー管理KMSキー(CMK)

• 自社AWS KMSキーでバックアップデータを暗号化します
• キーポリシーによるきめ細かなアクセス制御が可能です
• CloudHSM連携でHSMバックドキーも利用できます
• 重要な注意点として、キーが無効化または削除されるとバックアップへのアクセスが永続的に不可能になります

CMKを選択する場合のキー管理設計

CMKを選択する場合は、以下の運用設計が必須です。

1. キーの無効化・削除を制限するキーポリシー設定
2. キーのローテーション設定(KMS自動ローテーション)
3. CloudTrailによるキー操作の監査ログ有効化
4. キー管理者と使用者のIAMロール分離

通常の本番環境ではAWS所有キーで十分な保護が実現できます。規制要件でキーの自社管理が義務付けられている場合のみCMKを選択します。

2-7. コンソール・CLIでのvault作成手順(ハンズオン)

logically air-gapped vaultの作成手順を具体的に示します。

コンソールから作成する手順

1. AWSマネジメントコンソールにサインインし、AWS Backupサービスを開きます
2. 左サイドバーから「バックアップボルト」→「バックアップボルトを作成」を選択します
3. ボルトタイプで「Logically air-gapped vault」を選択します
4. 保管庫名を入力します(例: airgapped-prod-apne1)
5. 暗号化キーを選択します(「AWS所有のKMSキー」または「カスタマーマネージドキー」)
6. Vault Lock設定を入力します:
7. 最小保持期間: 7(日)
8. 最大保持期間: 365(日)
9. タグを追加します(任意)
10. 「バックアップボルトを作成」をクリックします

CLIから作成する手順(東京リージョン設定例)

東京リージョン(ap-northeast-1)でlogically air-gapped vaultを作成する場合のCLIコマンドです。

# 東京リージョンにlogically air-gapped vaultを作成
aws backup create-logically-air-gapped-backup-vault \
  --backup-vault-name "airgapped-prod-apne1" \
  --encryption-key-arn "alias/aws/backup" \
  --min-retention-days 7 \
  --max-retention-days 365 \
  --region ap-northeast-1

作成後のステータス確認:

# 保管庫一覧からlogically air-gapped vaultを確認
aws backup list-backup-vaults \
  --region ap-northeast-1 \
  --query "BackupVaultList[?BackupVaultType=='LOGICALLY_AIR_GAPPED'].{Name:BackupVaultName,ARN:BackupVaultArn}"

東京リージョン固有の注意点

東京リージョン(ap-northeast-1)はlogically air-gapped vaultの正式サポートリージョンです。クロスリージョンコピーを使用して他のリージョンのlogically air-gapped vaultに転送する場合は、コピー先リージョンにも別途保管庫を作成する必要があります。

2-8. バックアッププランへの統合

作成したlogically air-gapped vaultは、AWS Backupプランのターゲットとして指定することで利用できます。

{
  "BackupPlanName": "cyber-resilience-plan-apne1",
  "Rules": [
 {
"RuleName": "daily-airgapped-backup",
"TargetBackupVaultName": "airgapped-prod-apne1",
"ScheduleExpression": "cron(0 20 * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 180,
"Lifecycle": {
  "DeleteAfterDays": 30
}
 }
  ]
}

Lifecycle.DeleteAfterDaysの値はMinRetentionDays以上に設定する必要があります。この値がMinRetentionDaysを下回ると、バックアップジョブが失敗します。

# バックアッププランを作成
aws backup create-backup-plan \
  --backup-plan file://cyber-resilience-plan-apne1.json \
  --region ap-northeast-1

3. 復旧の信頼性とrestore testing

3-1. バックアップだけでは不十分な理由

バックアップを取得するだけでは、実際に復旧できるかどうかを保証できません。インシデント発生後に初めて「バックアップデータが壊れていた」「復旧に想定外の時間がかかった」という事態が判明するケースは、実際の現場で繰り返し報告されています。

restore testingは「バックアップが正常に取得されているか」ではなく「バックアップから実際にシステムを復旧できるか」を定期的に検証する仕組みです。AWS Backupが提供するrestore testing機能は、スケジュールに従って自動的にrestore jobを実行し、復旧の成否と所要時間を記録します。

バックアップが持つ3つの主要な欠点を整理します。

欠点1: バックアップデータの内部破損

バックアップ取得時のエラーや暗号化処理の不整合によって、バックアップデータが内部的に破損している場合があります。ファイルサイズや取得ステータスだけでは検出できない種類の破損も存在するため、実際にrestore jobを実行して検証することが重要です。

欠点2: 復旧手順の陳腐化

システム構成変更や依存関係の変化によって、以前は機能していた復旧手順が現在は動作しないケースがあります。データベースのバージョンアップやネットワーク構成の変更後は特に、復旧手順のドリフトが起きやすい状況です。

欠点3: RTO(目標復旧時間)の未検証

バックアップサイズの増大やインフラ変更に伴い、実際の復旧時間が計画値を超過している場合があります。インシデント発生時にRTOを超過することは、事業継続性の観点で重大な問題です。

restore testingはこれら3つの欠点を、定期的な本番同等の復旧演習によって補完します。

3-2. RAM経由の復旧テスト実装

logically air-gapped vaultのバックアップを使った復旧テストは、Resource Access Manager(RAM)を介した別アカウントへの共有によって実現します。air-gapped vaultが存在するソースアカウントから、テスト専用の隔離アカウントにバックアップを共有し、そこでrestore jobを実行します。

RAM共有の設計方針

テスト用アカウントはソースアカウントとネットワーク的に分離することを推奨します。本番環境とテスト環境を同一VPCに配置すると、テスト中の操作が本番に影響するリスクがあります。

RAM共有の設定では、ソースアカウントのlogically air-gapped vaultを共有リソースとしてRAMに登録します。共有先アカウントのIDを許可リストに追加し、テスト実行に必要な権限のみを付与します。

air-gapped vaultのアクセスポリシーに、共有先アカウントからのrestore job開始を許可するエントリを追加します。

{
  "Effect": "Allow",
  "Principal": {
 "AWS": "arn:aws:iam::TEST_ACCOUNT_ID:root"
  },
  "Action": [
 "backup:StartRestoreJob",
 "backup:DescribeRestoreJob"
  ],
  "Resource": "*"
}

共有先アカウントからのrestore job起動

共有先アカウントでrestore jobを起動する際は、IAMロールの権限設計が重要です。restore jobが対象リソースを作成するための権限と、バックアップへのアクセス権限を分離して管理します。

restore jobの実行には、対象リソース種別ごとに必要な権限セットが異なります。EC2の場合はec2:RunInstancesやec2:CreateVolumeが必要で、RDSの場合はrds:RestoreDBInstanceFromDBSnapshotが必要です。これらの権限を最小権限原則に従って付与します。

テスト実行の分離設計

テスト用VPCはソースアカウントとピアリングせず、インターネットゲートウェイも持たない完全隔離構成を推奨します。テスト環境のリソースは復旧確認後に自動削除することで、不要なコストと攻撃面を削減できます。

共有されたair-gapped vaultのバックアップから直接restore jobを起動できるため、バックアップデータをコピーする必要はありません。これにより、追加のデータ転送コストを抑えつつ、本番同等の復旧テストを実現します。

3-3. AWS Backup restore testingの設定方法とスケジュール

AWS BackupのManagement Consoleで「Restore testing」を選択し、restore testing planを作成します。スケジュール設定では、テスト対象のバックアップボールト、テスト頻度、復旧先の設定を指定します。

restore testing planの主要設定項目

StartWindowHoursは、スケジュールされた時間からrestore jobを開始するまでの許容時間を設定します。例えば8を指定すると、スケジュール時刻から8時間以内にrestore jobが開始されます。この期間内に開始できなかった場合はテストがスキップされます。

CompletionWindowHoursは、restore jobを完了させるまでの許容時間です。RTO目標値をここに設定することで、目標時間内に復旧が完了しない場合をテスト失敗として記録できます。

{
  "RestoreTestingPlanName": "AirGappedVaultRestoreTest",
  "ScheduleExpression": "cron(0 2 ? * MON *)",
  "StartWindowHours": 8,
  "RecoveryPointSelection": {
 "Algorithm": "LATEST_WITHIN_WINDOW",
 "ExcludeVaults": [],
 "IncludeVaults": [
"arn:aws:backup:ap-northeast-1:SOURCE_ACCOUNT_ID:backup-vault:AirGappedVault"
 ],
 "RecoveryPointTypes": ["SNAPSHOT"],
 "SelectionWindowDays": 7
  }
}

対象バックアップの選択戦略

RecoveryPointSelectionの設定では、テストに使用するバックアップポイントの選択条件を指定します。LATEST_WITHIN_WINDOWを指定すると、指定期間内の最新バックアップポイントが選択されます。全バックアップをテストするとコストが増大するため、代表的なポイントを選択することを推奨します。

SelectionWindowDaysを7に設定すると、直近7日以内のバックアップポイントから選択します。業務要件やバックアップサイクルに合わせて調整します。

東京リージョン(ap-northeast-1)での注意点

東京リージョンでのrestore testingは対応済みです。アジア太平洋リージョン向けのストレージエンドポイントを使用するため、レイテンシや転送コストの観点から、テスト先リージョンをソースと同一の東京リージョンに設定することが多いです。リージョン間でのrestore testingも可能ですが、転送コストとテスト時間の増大を考慮した設計が必要です。

3-4. 復旧時間(RTO)検証の実装

restore testingの主要な価値の一つは、RTO(目標復旧時間)の定期的な実測にあります。インシデント発生時に「実際に何時間かかるか」を事前に把握しておくことが、事業継続計画の信頼性を支えます。

RTO測定の仕組み

restore jobには開始時刻と完了時刻が記録されます。AWS Backupのrestore testing結果にはStatusMessageフィールドに詳細情報が含まれ、CloudWatch Logsにも転送できます。

CloudWatch Logs Insightsを使用して、リソース種別ごとの平均復旧時間を集計できます。

fields @timestamp, @message
| filter @logStream like /RestoreTestingJob/
| stats avg(duration_minutes) by resource_type
| sort avg_duration_minutes desc

RTO超過の検知

CompletionWindowHoursを超えてもrestore jobが完了しない場合、テストは失敗ステータスとして記録されます。この結果をEventBridgeでキャプチャし、SNSトピックを経由してメールや通知ツールに転送することで、RTO超過を即時検知できます。

RTO目標値はリソース種別ごとに異なります。EC2インスタンスはボリュームサイズに依存し、RDSはスナップショットサイズとインスタンスクラスに依存します。定期的なrestore testingによって、システム規模の成長に伴うRTO変化を継続的に把握できます。

マルチリソースRTOの集計

本番システムが複数のリソースで構成される場合、最長のrestore時間が全体のRTOを決定します。restore testingの結果から、RTO上の「ボトルネックリソース」を特定し、優先的な改善対象として選定できます。

例えば、大容量EBSボリュームのrestore時間が長い場合は、スナップショット間隔を短縮してデルタサイズを減らす、またはEBSボリュームを分割して並列復旧を可能にするといった対策を検討します。

3-5. コンプライアンス証跡とAudit Manager連携

金融機関や医療機関など規制業種では、「バックアップが定期的にテストされていること」をコンプライアンス要件として求められる場合があります。AWS Backup restore testingはAWS Audit Managerとの連携により、証跡の自動収集と監査レポートの生成を支援します。

Audit Managerによる証跡収集

AWS Audit Managerは、AWS Backupのrestore testing結果をコントロールのエビデンスとして自動収集します。restore testing planの設定、実行履歴、成否ステータスが証跡として保存されます。

監査担当者はAudit Managerのダッシュボードから、特定期間のrestore testing実施率や成功率を確認できます。手動での証跡収集作業を排除し、監査準備のコストを大幅に削減できます。

CloudTrailによる操作ログ

restore testing planの作成・変更・削除はCloudTrailに記録されます。backup.amazonaws.comのAPIコールとして記録されるため、設定変更の追跡と不正な変更の検知が可能です。

{
  "eventSource": "backup.amazonaws.com",
  "eventName": "CreateRestoreTestingPlan",
  "requestParameters": {
 "RestoreTestingPlan": {
"RestoreTestingPlanName": "AirGappedVaultRestoreTest",
"ScheduleExpression": "cron(0 2 ? * MON *)"
 }
  }
}

証跡の長期保存

restore testing結果をS3バケットに長期保存することで、規制要件に応じた保存期間管理が可能です。S3 Intelligent-Tieringを使用すれば、アクセス頻度の低い証跡データのストレージコストを最適化できます。バックアップポリシーと証跡保存ポリシーを一元管理することで、コンプライアンス対応の全体像を把握しやすくなります。

3-6. restore job実行後の確認手順とクリーンアップ

restore jobが完了した後、復旧されたリソースの整合性を検証し、テスト用リソースをクリーンアップします。このクリーンアップステップを自動化しないと、テスト環境のリソースが蓄積し続けてコストが増大します。

復旧リソースの整合性検証

EC2インスタンスの場合は、システムステータスチェックとインスタンスステータスチェックがpassしているか確認します。RDSの場合は、データベースエンジンが正常に起動し、接続テストが成功するか確認します。

アプリケーション層の整合性検証では、Lambda関数やスクリプトによる自動化が効果的です。restore job完了のEventBridgeイベントをトリガーに、検証スクリプトを自動実行する設計を推奨します。

自動クリーンアップの実装

テスト完了後のリソース削除をLambda関数で自動化します。リソース名やタグに「RestoreTest」などの識別子を付与しておくことで、誤って本番リソースを削除するリスクを回避できます。

クリーンアップの失敗は即座にアラートを発報するよう設定します。テストリソースが残存したままになると、不要なコストが継続的に発生します。タグベースのコスト配分レポートを設定することで、テストリソースのコストを可視化できます。

クリーンアップ後の結果サマリ記録

クリーンアップ完了時に、restore jobの実行結果サマリをDynamoDBやS3に記録します。復旧時間、成否ステータス、検証結果を一元的に管理し、RTO推移のトレンド分析に活用します。

3-7. 復旧テスト失敗時のアラート設定

restore testingが失敗した場合、その原因を速やかに特定し、次回のテスト実行までに対策を講じることが重要です。

EventBridgeによる失敗検知

AWS Backupのrestore testing完了イベントはEventBridgeに通知されます。失敗ステータスのイベントをフィルタリングし、SNSトピックを経由してメールや通知チャネルに転送するルールを設定します。

{
  "source": ["aws.backup"],
  "detail-type": ["Restore Testing Job State Change"],
  "detail": {
 "status": ["FAILED", "TIMED_OUT"]
  }
}

失敗原因の分類と対応方針

restore testingの失敗原因は主に3つに分類されます。

第1の原因は権限エラーです。IAMロールの権限不足や、RAMで共有されたバックアップへのアクセス権限の変更によって発生します。CloudTrailでAccessDeniedエラーを確認し、IAMポリシーを修正します。

第2の原因はキャパシティ不足です。テスト先リージョンのサービスクォータを超過した場合に発生します。テスト用リージョンのEC2インスタンスやEBSボリュームのクォータを事前に確認し、必要に応じてクォータ引き上げを申請します。

第3の原因はバックアップデータの問題です。バックアップ取得時のエラーや内部破損が原因の場合があります。バックアップ取得プロセスのCloudWatch Logsを確認し、エラーパターンを特定します。

アラート疲れの防止

テスト環境の一時的な問題で多数のアラートが発報されると、重要な通知を見落とすリスクがあります。restore testing用のSNSトピックを本番システムのアラートとは分離し、担当者を適切に割り当てることを推奨します。

また、同一の失敗が繰り返される場合はアラートを抑制するルールを設定し、根本原因の対処を優先させる運用が効果的です。

4. primary backup targetと保護強化

4-1. primary backup targetとしての直接書き込み

従来の仕組みと新機能の違い

logically air-gapped vaultが登場した当初、バックアップデータをこの保管庫に格納するためには「別保管庫からコピーする」という間接的な手順が必要でした。バックアップジョブを通常の保管庫に向けて実行し、そこで生成されたリカバリーポイントをコピールールによってlogically air-gapped vaultへ転送する二段構えの設計です。この方式はコピー操作のコストと時間がかかるだけでなく、コピー完了までの間は保護が不完全な状態になるという課題を持っていました。

2025年に一般提供（GA）となった primary backup target 機能は、この制限を解消します。バックアッププランやオンデマンドバックアップの設定でlogically air-gapped vaultを「プライマリの保存先」として直接指定できるようになり、バックアップジョブの実行と同時にデータが保管庫へ書き込まれます。コピー操作を挟まずに済む分、保護までのタイムラグが大幅に縮小されます。東京リージョン（ap-northeast-1）を含む主要リージョンでこの機能を利用できます。

バックアッププランでの指定方法

バックアッププランのルール設定でprimary backup targetを指定するには、バックアップルールの DestinationBackupVaultArn にlogically air-gapped vaultのARNを直接指定します。以下はAWS CLIでバックアッププランを作成する例です。

aws backup create-backup-plan \
  --backup-plan '{
 "BackupPlanName": "CriticalDataProtection",
 "Rules": [{
"RuleName": "DailyToAirGappedVault",
"TargetBackupVaultName": "airgapped-vault-prod",
"ScheduleExpression": "cron(0 3 * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 180,
"Lifecycle": {
  "DeleteAfterDays": 365
}
 }]
  }' \
  --region ap-northeast-1

TargetBackupVaultName には、ソースアカウントからアクセス権限を付与されたlogically air-gapped vaultの名前を指定します。このルールがprimary backup targetとして機能し、バックアップジョブの結果が直接保管庫へ書き込まれます。

組織ポリシーによる一括適用

AWS Organizationsを利用している環境では、管理アカウントからバックアップポリシー（Organizations Backup Policy）を適用することで、複数のメンバーアカウントのリソースをまとめてlogically air-gapped vaultへバックアップできます。以下のポリシー定義の例を参考にしてください。

{
  "plans": {
 "OrgWideCriticalBackup": {
"regions": {
  "@@assign": ["ap-northeast-1"]
},
"rules": {
  "DailyRule": {
 "schedule_expression": {
"@@assign": "cron(0 3 * * ? *)"
 },
 "target_backup_vault_name": {
"@@assign": "arn:aws:backup:ap-northeast-1:SECURITY-ACCOUNT-ID:backup-vault:airgapped-vault-prod"
 },
 "lifecycle": {
"delete_after_days": { "@@assign": "365" }
 }
  }
},
"selections": {
  "tags": {
 "CriticalData": {
"iam_role_arn": {
  "@@assign": "arn:aws:iam::$account:role/AWSBackupOrgRole"
},
"tag_key": { "@@assign": "DataClass" },
"tag_value": { "@@assign": ["Critical"] }
 }
  }
}
 }
  }
}

このポリシーを組織のルートまたはOUにアタッチすると、対象アカウント内のタグ条件に一致するリソースが自動的にlogically air-gapped vaultへバックアップされます。管理アカウントから一元的に保護対象を制御できるため、個々のメンバーアカウントでの設定漏れを防げます。

オンデマンドバックアップでの指定

スケジュールバックアップだけでなく、手動実行のオンデマンドバックアップでもprimary backup targetを指定できます。インシデント対応などで即時保護が必要な場面でも活用できます。

aws backup start-backup-job \
  --backup-vault-name airgapped-vault-prod \
  --resource-arn arn:aws:rds:ap-northeast-1:SOURCE-ACCOUNT-ID:db:prod-db \
  --iam-role-arn arn:aws:iam::SOURCE-ACCOUNT-ID:role/AWSBackupRole \
  --region ap-northeast-1

4-2. 不変性保護の設計

Vault Lock compliance modeによる完全不変性

logically air-gapped vaultには、作成時点でVault Lock compliance modeが内蔵されています。通常のAWS Backup保管庫に対してVault Lockを後から設定する場合と異なり、logically air-gapped vaultはこのロックが初期状態から組み込まれています。

Vault Lock compliance modeは、設定した保持期間が経過するまでリカバリーポイントの削除を不可能にします。この制限はAWSルートアカウントを含めたいかなるユーザーも解除できません。保持期間を短縮する変更も禁止されるため、設定後は外部からの削除操作に対して完全な不変性が保証されます。

不変性が保証される範囲は以下のとおりです。

「禁止」とされた操作はAPIレベルで拒否されるため、IAMポリシーの設定ミスや管理者権限の奪取があっても保護が機能します。

削除保護設定の実装

logically air-gapped vaultのVault Lock設定は、保管庫の作成後に最低限の猶予期間（最短3日）を経てロックが確定します。ロック確定前であれば保持期間の設定変更が可能です。本番環境では猶予期間の終了前に設定を最終確認し、ロック確定の操作を意図的に行う運用フローを組み込んでください。

# Vault Lockのステータス確認
aws backup describe-backup-vault \
  --backup-vault-name airgapped-vault-prod \
  --region ap-northeast-1 \
  --query '{
 VaultState: VaultState,
 MinRetentionDays: MinRetentionDays,
 MaxRetentionDays: MaxRetentionDays,
 LockDate: LockDate
  }'

LockDate が設定されていれば、その日時以降はVault Lockが確定し変更不可になります。VaultState が LOCKED となっていることで不変性が有効であることを確認できます。

4-3. Organizations多者承認（Multi-party approval）

概要と保護原理

Organizations Multi-party approval（多者承認）は2025年にGAとなった機能で、バックアップに関わる重要な操作を複数の承認者の合意を経てからのみ実行可能にする仕組みです。

この機能の核心にある問題意識は「単一アカウントの侵害によってバックアップ保護が無効化されるリスク」です。バックアップ保管庫を所有するアカウントの管理者権限が奪われた場合でも、多者承認が設定されていれば、バックアップの削除や保持ポリシーの変更といった重要操作を阻止できます。承認者アカウントを独立した管理ドメインに置くことで、所有アカウントの侵害が直接的な保護解除につながらない設計が実現します。

多者承認の対象となる操作には、リカバリーポイントの削除、バックアッププランの変更、Vault Lockの設定変更などが含まれます。これらの操作が要求されると承認ワークフローが起動し、指定した承認者からの明示的な承認を得るまで実行が保留されます。

要求者・承認者の役割分離

多者承認では「要求者（Requester）」と「承認者（Approver）」の役割を明確に分離します。要求者は保護された操作を要求するアカウントまたはIAMエンティティであり、承認者は要求の可否を判断する独立したアカウントです。

設計上の重要な原則として、要求者と承認者に同一のAWSアカウントを使用しないことが推奨されます。同一アカウント内に両ロールを持つと、単一アカウントの侵害で多者承認が形骸化します。以下のようなアカウント構成が望ましい形です。

Organizations構成例
├── 管理アカウント（Organizations管理・ポリシー設定）
├── セキュリティアカウント（logically air-gapped vault所有・承認者）
├── 本番アカウントA（バックアップ対象・要求者）
└── 本番アカウントB（バックアップ対象・要求者）

この構成では、本番アカウントからの重要操作要求はセキュリティアカウントの承認者が審査します。セキュリティアカウントへのアクセスは厳格に制限されるため、本番アカウントが侵害されても承認者側を制御できません。

承認フローの実装

Organizations管理アカウントで多者承認ポリシーを設定します。承認者として指定するIAMプリンシパルを定義し、どの操作に多者承認を適用するかを指定します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": {
  "AWS": [
 "arn:aws:iam::SECURITY-ACCOUNT-ID:role/BackupApproverRole"
  ]
},
"Action": [
  "backup:ApproveRestoreOperation",
  "backup:DisapproveRestoreOperation"
],
"Resource": "*"
 }
  ]
}

承認要求が発生すると、承認者はAWSマネジメントコンソールのAWS Backup画面またはAPIを通じて要求の詳細を確認し、承認または拒否を判断します。承認の有効期限が設定されており、期限内に承認が得られない場合は要求が自動的にキャンセルされます。

承認者不在時のエスカレーション設計

多者承認の運用で見落としがちな点が、承認者が不在の場合の対応です。24時間365日の運用を想定する場合、一次承認者が応答できない状況に備えて代替承認者を設定します。

承認者の不在によって緊急の復旧操作がブロックされる状況を防ぐため、以下の設計を検討してください。

• 複数の承認者を設定する: 一次承認者に加えて二次・三次の承認者ロールを定義し、組織内の異なる担当者にアサインする
• 承認期限の設定: 要求の有効期限を業務サイクルに合わせて設定する（例：72時間）
• エスカレーション通知: EventBridgeとAmazon SNSを組み合わせて、承認要求の発生をリアルタイムで承認者へ通知する
• オンコールローテーション: 承認者役割をオンコールローテーションと組み合わせ、常に応答可能な担当者を確保する

# 承認要求の一覧確認（承認者側で実行）
aws backup list-restore-testing-plans \
  --region ap-northeast-1 \
  --query 'RestoreTestingPlans[?Status==`PENDING_APPROVAL`]'

コンプライアンス証跡への活用

多者承認の承認・拒否ログはAWS CloudTrailに記録されます。SOC2やPCI-DSSといったコンプライアンスフレームワークでは、重要なデータ操作に対する承認プロセスと証跡の保持が要件として求められることがあります。

多者承認ログをCloudTrail経由でS3へ保存し、そのS3バケットにもVault Lockと同等の削除保護を設定することで、改ざん不能な証跡チェーンを構成できます。コンプライアンス監査時には以下のイベントが証跡として確認できます。

4-4. 多層防御設計

保護レイヤーの組み合わせ

logically air-gapped vault・Vault Lock compliance mode・Organizations多者承認は、それぞれが独立した保護メカニズムとして機能しながら、組み合わせることで多層防御を実現します。

攻撃シナリオ別の対応能力

3層の保護がどの攻撃シナリオに対して機能するかを整理します。

内部不正のシナリオ: バックアップ管理権限を持つ担当者がリカバリーポイントを削除しようとした場合、Vault Lock compliance modeによってAPIが拒否されます。保持期間の短縮変更を試みても同様に拒否されます。多者承認の設定があれば、管理操作の試みがすべて証跡として記録されます。

外部からの侵害シナリオ: ソースアカウントが侵害され、バックアップ保管庫への書き込み権限が悪用された場合でも、logically air-gapped vaultへの書き込みは一方向のみが許可されています。既存のリカバリーポイントへの上書きや削除はアカウント分離の仕組みによって制限されます。

サプライチェーン攻撃のシナリオ: AWS Backup自体やその周辺サービスのコンポーネントを経由した侵害が試みられた場合でも、Organizations多者承認は承認者アカウントの独立した判断を必要とします。複数の独立したアカウントを同時に侵害することは、単一コンポーネントの侵害と比較して格段に困難です。

いずれのシナリオでも、CloudTrailの証跡が改ざん不能な形で保存されていれば、インシデント後の調査と要因特定が可能です。バックアップの完全性と証跡の完全性を組み合わせた設計が、サイバーレジリエンスの要となります。

5. 対応リソースの拡大

AWS Backupのサイバーレジリエンス機能は、対応リソースを継続的に拡大しています。2026年3月にはEKS（Amazon Elastic Kubernetes Service）が、2025年にはFSx各種が、2026年2月にはクロスリージョンデータベーススナップショットコピーのair-gapped vault転送がそれぞれGAとなりました。東京リージョン（ap-northeast-1）でもこれらの保護機能を利用できます。

本セクションでは、EKS・FSx・RDS/Aurora・EC2/EBS・DynamoDB・S3の各リソースに対してlogically air-gapped vaultを組み合わせたサイバーレジリエンス設計を解説します。

5-1. EKS対応（2026-03 GA）

2026年3月のGA以降、EKSクラスターをlogically air-gapped vaultで保護できるようになりました。コンテナ化されたワークロードに対しても、Vault Lock compliance modeによる削除不可保護が適用可能です。

AWS Backup for EKSのインストールと設定

EKSクラスターでAWS Backupを利用するには、クラスターへのAWS Backup for EKSエージェントの有効化が必要です。エージェントはEKSアドオン経由で管理されており、AWS Management ConsoleまたはCLIから追加できます。

インストール手順の概要を以下に示します。

aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name aws-efs-csi-driver \
  --region ap-northeast-1

エージェントが有効化されると、AWS BackupはKubernetesのAPIサーバーと連携してリソースをバックアップします。etcd直接ダンプではなく、KubernetesリソースのAPI取得によるバックアップのため、Namespace・PVC・ConfigMap・Deployment・ServiceAccountなどの構造を維持したバックアップが取得されます。

保護対象リソース詳細

AWS Backup for EKSが保護する対象リソースは以下のとおりです。

• Namespace全体: 指定Namespace配下のすべてのKubernetesリソースをまとめてバックアップします。マルチテナント環境では、テナント単位のNamespaceごとにバックアッププランを分けることができます
• PersistentVolumeClaim（PVC）: EBSボリュームにバインドされたPVCのデータを保護します。PVCのメタデータとEBSスナップショットがペアで保存されます
• ConfigMapとSecret: アプリケーション設定や接続情報を含むConfigMap・Secretリソースも保護対象に含められます
• EKSクラスター設定: RBAC設定・Namespace構成・リソースクォータなどクラスターレベルの設定情報も含みます

air-gapped vaultへのバックアップ設定

EKSのバックアップをlogically air-gapped vaultに転送するには、バックアッププランのターゲットVaultとしてair-gapped vault ARNを指定します。

{
  "BackupPlanName": "eks-airgapped-plan",
  "Rules": [
 {
"RuleName": "eks-daily",
"TargetBackupVaultName": "logically-airgapped-vault",
"ScheduleExpression": "cron(0 2 * * ? *)",
"Lifecycle": {
  "DeleteAfterDays": 90
}
 }
  ]
}

air-gapped vaultに格納されたEKSバックアップには、Vault Lock compliance modeの不変性保護が自動適用されます。保護期間中は管理者アカウントからもバックアップを削除できません。

EKSクラスターの不正変更対策設計

コンテナ基盤への不正アクセスシナリオとして、etcdデータの改ざん・PVCデータの暗号化・Secretの窃取などが想定されます。以下の設計原則で対策します。

• etcd保護: EKSマネージドコントロールプレーンのetcdはAWSが管理しますが、KubernetesリソースのAPI取得バックアップを通じて設定の復元が可能です
• PVCデータ保護: バックアップをair-gapped vaultに保管することで、PVCデータへの不正削除・暗号化が発生した場合の復元が可能です
• 定期的な復元テスト: restore testingをスケジュール設定し、EKSクラスターからの復元手順と所要時間を定期検証します
• 最小権限のIAM設計: バックアップエージェントのIAMロールには必要最小限の権限のみを付与します

Kubernetes対応バージョンとサポートライフサイクル

AWS Backup for EKSは、EKSがサポートするKubernetesバージョンの範囲内で動作します。EOL（End of Life）バージョンのクラスターへのエージェント動作は保証対象外となるため、定期的なバージョンアップ計画が必要です。バージョンアップ前にバックアップを取得しておくことを強く推奨します。

東京リージョン（ap-northeast-1）でのEKS対応は2026-03 GAと同時に利用可能です。クロスリージョンコピーと組み合わせることで、東京→大阪（ap-northeast-3）の国内DR構成も実現できます。

5-2. FSxとファイルサーバーのサイバーレジリエンス（2025 GA）

2025年のGAにより、FSx for Lustre・FSx for Windows File Server・FSx for OpenZFSがlogically air-gapped vaultによる保護に対応しました。ファイルサーバーやHPCストレージへのサイバーレジリエンス設計が可能になっています。

FSx for Lustreのair-gapped vault保護

FSx for LustreはHPC・機械学習向けの高性能並列ファイルシステムです。大規模な計算データや学習データを保護するには、air-gapped vaultへのバックアップが有効です。

設定の基本手順は以下のとおりです。

1. AWS Backupコンソールで対象FSx for Lustreファイルシステムをリソースに追加します
2. バックアッププランのターゲットにlogically air-gapped vault ARNを指定します
3. スケジュールと保存期間を設定します（Vault Lock compliance modeの最低保存期間以上の値が必要です）

FSx for Lustreのバックアップはファイルシステム全体のポイントインタイムスナップショットとして取得され、リストア時は新規ファイルシステムとして復元されます。大量データの並列処理環境では、バックアップ頻度とコストのバランスを考慮してスケジュールを設定します。

FSx for Windows File Serverのサイバーレジリエンス設計

FSx for Windows File ServerはActive Directory統合のSMBファイル共有です。業務ファイルサーバーとして広く利用されており、ファイル暗号化型不正プログラムの主要ターゲットでもあります。以下の多層防御設計が推奨されます。

• シャドウコピーとの補完: FSxネイティブのWindowsシャドウコピー（短期・高頻度）とAWS Backupのair-gapped vault保護（長期・不変）を組み合わせます
• 2層バックアップ構成: 通常のS3バックアップ（オペレーショナル用途）とair-gapped vault（論理分離・不変保管）を2層で運用します
• Active Directory整合性: AD認証設定を含むシステム状態も保護対象に含めることで、復元後のAD再統合を迅速化できます
• 東京リージョン対応: ap-northeast-1でのFSx for Windows File Server保護はGA済みです

FSx for OpenZFSの保護設定

FSx for OpenZFSはZFSの豊富なスナップショット機能を持ちますが、AWS BackupのPolicyベース管理とair-gapped vault保護を追加することで、ZFSスナップショット単体では実現できない長期不変保管が可能になります。

設定手順はFSx for Lustreと同様です。バックアッププランへのリソース追加時に、リソースタイプとしてFSx for OpenZFSを選択します。ZFSのスナップショット粒度とAWS Backupのスケジュールを組み合わせることで、細かい時点への復元と長期保管を両立できます。

5-3. データベーススナップショットのair-gapped vault対応（2026-02）

2026年2月の機能追加により、クロスリージョンデータベーススナップショットコピーがair-gapped vaultへの転送に対応しました。これにより、RDS・Auroraのスナップショットを別リージョンの論理分離保管庫に長期保存できます。

RDS・Auroraのair-gapped vault保護設定

設定の基本フローは以下のとおりです。

1. バックアッププランの作成: 対象RDS・Auroraインスタンスをバックアッププランに追加します
2. クロスリージョンコピー設定: プランのコピーアクションで、転送先リージョンとair-gapped vault ARNを指定します
3. 保存期間設定: Vault Lock compliance modeで設定した最低保存期間以上の値を指定します（期間内はコピーの削除が不可になります）

東京リージョン（ap-northeast-1）でバックアップを取得し、大阪リージョン（ap-northeast-3）のair-gapped vaultへクロスリージョンコピーする構成が国内DR設計の定番パターンです。コピー先のスナップショットはVault Lock保護下に置かれるため、コピー元で削除が発生しても保護期間内のスナップショットは維持されます。

対応範囲と注意点

• RDS対応エンジン: MySQL・PostgreSQL・Oracle・SQL Server・MariaDBの各エンジンが対応しています
• Auroraクラスター: Aurora MySQL・Aurora PostgreSQLのクラスタースナップショットも対応しています
• Multi-AZ構成との棲み分け: Multi-AZはフェイルオーバー（可用性）目的であり、論理削除やデータ不正変更への対策はair-gapped vaultが担います
• 暗号化キー: CMK（カスタマー管理キー）で暗号化されたスナップショットをクロスリージョンコピーする場合は、コピー先リージョンでも対応するCMKが必要です
• ストレージコスト: air-gapped vaultへのコピーはコピー先リージョンでのストレージ料金が発生します。保存期間と取得頻度の設計時に考慮してください

5-4. その他リソースのサイバーレジリエンス設計

EKS・FSx・データベース以外のリソースについても、air-gapped vaultを組み合わせた保護設計を整理します。

EC2・EBSのair-gapped vault保護

EC2インスタンスとEBSボリュームは、AWS Backupにおける最も基本的な保護対象です。air-gapped vault活用の設計ポイントを以下に示します。

• AMIバックアップ: EC2インスタンスの完全なAMI（EBSスナップショット群を含む）をair-gapped vaultに保存します。OS・ミドルウェア・設定を含む完全な状態からの復元が可能です
• 増分スナップショット: EBSは変更差分のみを転送するため、初回以降のバックアップコストと時間を大幅に抑えられます
• クロスリージョン保護: 東京（ap-northeast-1）でAMIをバックアップし、大阪（ap-northeast-3）のair-gapped vaultに転送する構成が本番運用で広く採用されています
• タグベースの自動選択: AWS Backupプランのタグ条件を使ってEC2インスタンスを動的に保護対象へ追加できます。新規インスタンス作成時にタグを付与するだけで自動的にバックアップ対象に含まれます

DynamoDBの継続的バックアップとair-gapped vault

DynamoDBのPITR（ポイントインタイムリカバリ）はオペレーショナルなリカバリに最適ですが、保存期間は35日間が上限です。長期保存や論理分離保護には、以下の組み合わせ設計が有効です。

• PITR有効化: テーブル単位でPITRを有効化し、35日以内の誤操作・論理障害に対応します
• 月次オンデマンドバックアップ: AWS Backupでオンデマンドバックアップを定期取得し、air-gapped vaultに保管します
• Organizations全体適用: OrganizationsのバックアップポリシーでDynamoDBバックアップを組織全体に強制適用します

DynamoDBのバックアップはAWSフルマネージドで管理され、テーブルパフォーマンスへの影響なく取得できます。大規模テーブルでもバックアップ所要時間はほぼ一定です。

S3のBackup保護とVault Lock活用

S3オブジェクトの保護にはS3ネイティブのObject Lock（WORM）が強力ですが、AWS Backupとの組み合わせで多層保護を実現できます。

• S3バックアップ: AWS BackupはS3バケット全体をバックアップし、オブジェクト削除・バケット削除・設定変更からの復元に対応します
• S3 Object Lock＋air-gapped vault: S3 Object Lockがオブジェクトレベルの不変性を担保し、air-gapped vaultがバックアップコピー自体の不変性を担保する2層保護です
• バージョニング必須: AWS Backup for S3はバージョニングが有効なバケットのみ対応しています。バックアッププラン設定前にバージョニングの有効化を確認してください
• クロスアカウント保護: S3バックアップをair-gapped vaultに保管することで、ソースアカウントが侵害された場合でもバックアップを保護できます

5-5. 東京リージョン（ap-northeast-1）での各リソース保護例

東京リージョン（ap-northeast-1）は、AWS Backupのサイバーレジリエンス機能に対応した主要リージョンです。以下に東京リージョンを起点とした各リソースの推奨保護パターンをまとめます。

リソース種別ごとに対応状況・機能範囲が異なるため、バックアッププラン設計前にAWS公式の対応リソースリストを確認することを推奨します。新リソース対応はAWSリリースノートで随時告知されます。

6. 運用・監査・コスト管理

6-1. 組織バックアップポリシー（AWS Organizations + SCPs）

AWS OrganizationsのBackup policyを使うと、組織内の複数アカウントに対してバックアッププランを一元管理できます。管理アカウントからポリシーを定義し、OUや個別アカウントに継承させることで、各アカウントのバックアップ設定を組織標準に準拠させます。

Backup policyの適用範囲

Backup policyはOrganizations管理コンソールまたはAWS CLIから定義します。ポリシーに記述したバックアッププランは、対象アカウントにJSON形式で自動的にデプロイされます。以下は簡略化した構造例です。

{
  "plans": {
 "daily-encrypted-backup": {
"rules": {
  "daily-rule": {
 "schedule_expression": {"@@assign": "cron(0 5 ? * * *)"},
 "start_backup_window_minutes": {"@@assign": "60"},
 "target_backup_vault_name": {"@@assign": "Default"},
 "lifecycle": {
"delete_after_days": {"@@assign": "35"}
 }
  }
}
 }
  }
}

SCPによる保護の強化

Service Control Policies（SCPs）を組み合わせることで、組織メンバーアカウントがバックアップポリシーを削除したり、バックアップ保管庫のVault Lockを解除したりする操作を禁止できます。以下はVault Lock解除禁止の例です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Deny",
"Action": [
  "backup:DeleteBackupVaultLockConfiguration",
  "backup:DeleteBackupVault"
],
"Resource": "*"
 }
  ]
}

SCPはメンバーアカウントの管理者権限をも制限できるため、組織レベルの一貫したポリシー適用に有効です。ただし、管理アカウント自身にはSCPが適用されないため、管理アカウントのアクセス制御は別途IAMポリシーとCloudTrailで厳重に管理してください。

バックアップポリシーの設計原則

組織全体のバックアップポリシーを設計する際は、以下の原則を参考にしてください。

• タグベースのバックアップ割り当て：リソースに backup=enabled などのタグを付け、タグセレクタで対象を動的に管理する
• 保持期間の標準化：業務重要度に応じた保持期間ティアを定義し、ポリシーで強制する
• 暗号化の一元管理：AWS KMSカスタマー管理キーを組織で管理し、バックアップデータの暗号化を統一する
• クロスアカウント共有の制限：保管庫の共有先を承認済みアカウントのみに限定する

6-2. AWS Backup Audit Manager連携

AWS Backup Audit Managerは、バックアップ活動のコンプライアンス状態を継続的に評価し、レポートとして出力する機能です。コンプライアンスフレームワークを定義し、評価結果を自動レポート化することで、監査対応の工数を大幅に削減できます。

コンプライアンスコントロールの定義

Audit Managerでは、以下のようなマネージドコントロールを利用できます。

• BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK：バックアッププランの最小頻度と保持期間を確認
• BACKUP_RECOVERY_POINT_ENCRYPTED：復旧ポイントが暗号化されていることを確認
• BACKUP_RESOURCES_PROTECTED_BY_BACKUP_VAULT_LOCK：リソースがVault Lock保護下にあることを確認
• BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK：復旧ポイントの最小保持期間を確認

これらのマネージドコントロールに加え、カスタムコントロールを定義して、組織固有の要件も検証できます。

コンプライアンスレポートの自動生成

Audit Managerはフレームワーク評価結果を、設定したスケジュールでS3バケットに自動出力します。レポートはCSV形式またはJSON形式で出力され、評価対象リソース・コントロール・評価結果・非準拠の詳細が含まれます。定期的なコンプライアンスレポートは、内部監査や規制当局への証拠提出に直接活用できます。

restore testingとの連携

restore testingの実行結果もAudit Managerのコンプライアンスレポートに反映されます。「このバックアップは実際に復旧テストを通過した」という証跡が自動記録されるため、RTOの達成可能性を定量的に証明できます。金融・医療・公共機関など、バックアップ復旧能力の実証が規制要件となっているケースで特に有効です。

6-3. バックアップコンプライアンスフレームワークの設定と評価

コンプライアンスフレームワークはAWS CLIまたはマネジメントコンソールから作成します。以下はCLIでフレームワークを作成する手順の概要です。

aws backup create-framework \
  --framework-name "CyberResilienceFramework" \
  --framework-controls '[
 {
"ControlName": "BACKUP_RESOURCES_PROTECTED_BY_BACKUP_VAULT_LOCK",
"ControlInputParameters": []
 },
 {
"ControlName": "BACKUP_RECOVERY_POINT_ENCRYPTED",
"ControlInputParameters": []
 }
  ]'

作成後、フレームワークはコンプライアンス状態を継続的に評価し、コンソールで確認できます。評価結果は COMPLIANT または NON_COMPLIANT で示され、非準拠リソースの詳細が表示されます。

非準拠リソースへの対応フロー

Audit Managerで非準拠が検出された場合の対応フローは以下のとおりです。

1. コンプライアンスダッシュボードで非準拠リソースを特定する
2. 対象リソースのバックアップ設定を確認し、不足しているコントロールを特定する
3. バックアッププランまたはバックアップポリシーを修正し、再評価を待つ
4. 次回のレポートで準拠状態に変化したことを確認し、証跡として保存する

EventBridgeルールを設定して、コンプライアンス状態の変化をSNS通知に連携させることも可能です。

6-4. logically air-gapped vault + restore testingのコスト構造

コスト構造の詳細は変動があるため、最新の情報はAWS Backup公式料金ページを参照してください。以下は料金体系の考え方を整理したものです。

logically air-gapped vaultのストレージコスト

logically air-gapped vaultに保存されたバックアップデータは、通常のAWS Backupストレージとは異なる料金体系が適用されます。保存容量（GB/月）に基づく課金で、リージョンや保存データ量によって変動します。Vault Lock有効期間のデータにも、通常のvaultとは異なる料金体系が適用されます。

restore testingの運転コスト

restore testingは、テスト復旧先のリソース（EC2インスタンス、RDSインスタンス等）の稼働コストが主なコストになります。テスト復旧したリソースは、validation windowの終了時またはテスト完了時点で自動削除されます。ただし、稼働していた時間分の費用は発生します。テスト頻度とvalidation window（デフォルト1時間）の設定が、コストに直結します。

コスト見積もりの考え方

• logically air-gapped vaultへの保存量はCloudWatchメトリクスで把握し、公式料金ページの単価で見積もる
• restore testingのコストは「(テスト対象リソース稼働費) × テスト頻度 × validation window時間」で概算できる
• Cost Explorerのサービス別コスト表示で「AWS Backup」の月次コストを定期的に確認する

6-5. コスト最適化パターン

ライフサイクルポリシーによるcold tier移行

AWS Backupのライフサイクルポリシーを使うと、バックアップを一定期間後にwarm storageからcold storageへ自動移行できます。cold storageは低コストで利用できる反面、復旧時間は長くなる傾向があります。RPO/RTOの要件と照らし合わせて、cold移行の適用可否を判断してください。

cold tier移行の一般的な設定パターンとして、バックアップ後30日でcold storageへ移行し、移行から365日後に削除する構成がよく利用されます。logically air-gapped vaultのVault Lock保持期間と、ライフサイクルポリシーの削除期間が矛盾しないよう、注意してください。Vault Lockの保持期間が優先されるため、保持期間より短い削除ポリシーを設定しても削除は実行されません。

不要なバックアップの削除管理

保持期間が切れた復旧ポイントの自動削除は、バックアッププランのライフサイクル設定で制御できます。組織全体でどのリソースのバックアップをいつ削除するかを標準化し、不要な保存コストを削減します。

定期的にAWS Backupコンソールまたは以下のCLIコマンドで、古い復旧ポイントを確認することをお勧めします。

aws backup list-recovery-points-by-vault \
  --backup-vault-name Default \
  --by-created-before "2025-01-01T00:00:00Z" \
  --query "RecoveryPoints[*].{ID:RecoveryPointArn,Created:CreationDate,Status:Status}"

組織全体のコスト可視化

AWS Cost Explorerのサービス別フィルタとアカウント別フィルタを組み合わせることで、組織全体のバックアップコストを部門別に可視化できます。コスト配分タグ（cost allocation tag）を設定すると、アプリケーション単位やプロジェクト単位のバックアップコストを把握しやすくなります。

restore testingの頻度最適化

restore testingの対象リソースが多い場合、すべてを頻繁にテストするとコストが積み上がります。重要度に応じてテスト頻度を差別化する設計が有効です。重要システムは週次テスト、それ以外は月次テストとする階層化が一般的な最適化パターンです。validation windowを最小限（1時間）に設定することも、テストコスト削減の有効な手段です。

6-6. 監査レポートの活用

コンプライアンス証跡の自動収集

Audit Managerが出力するコンプライアンスレポートは、以下の監査目的に活用できます。

• 定期監査のエビデンス：監査担当者への証拠提出を自動化し、手動収集の工数を削減する
• 規制対応：ISMS・SOC 2・PCI DSSなど、バックアップポリシーの遵守を証明する
• 内部統制の強化：経営層への定期報告に、コンプライアンス準拠率を定量データとして提示する

インシデント対応後の復旧証明

サイバーインシデントからの復旧後、「どのバックアップから何を復旧したか」を証明するために、以下の情報をAudit Managerのレポートと組み合わせて整理します。

• 復旧に使用したRecovery Point ID
• restore testingで直近に合格した復旧ポイントの証跡
• 復旧先リソースの稼働確認記録（CloudTrailのAPI履歴）

これらの情報を事前に体系的に管理することで、インシデント発生後の証跡収集作業を最小化できます。業界によっては、復旧完了後の第三者検証が求められるケースもあり、証跡の整備は早めに着手することを推奨します。

レポートのS3保存とアクセス制御

Audit Managerのレポートは、指定したS3バケットに自動保存されます。バケットポリシーでレポートへのアクセスを制限し、S3 Object Lockと組み合わせることで、コンプライアンスレポート自体の改ざんを防ぐことができます。保存先バケットの暗号化にはSSE-KMSを使用し、KMSキーポリシーでアクセス対象を限定することをお勧めします。

CloudWatchアラームとの連携

Audit Managerのコンプライアンス評価結果はEventBridgeイベントとして発行されます。EventBridgeルールを使って、非準拠リソースが検出された際にSNS経由でアラートを受け取ることができます。運用チームへの即時通知と、コンプライアンスダッシュボードでの継続的な可視化を組み合わせることで、ポリシー違反の放置を防げます。

7. 実戦統合パターン

7-1. リージョン間DRとサイバーレジリエンスの使い分けマトリクス

リージョン間DRとサイバーレジリエンスは、目的が異なる2つの保護レイヤーです。どちらか一方で十分ということはなく、障害の性質に応じて適切な方を選択し、理想的には両方を実装した多層防御を構築します。

障害の性質による使い分け

リージョン間DRが有効なシナリオ

リージョン間DRは可用性を確保するためのアプローチです。AWSリージョン全体が利用不可になる事態や、物理的なデータセンター障害に対して有効です。クロスリージョンコピーされたバックアップから、別リージョンで素早くシステムを復旧させることが目的です。

バックアップ自体は完全性が保たれているという前提の下で機能するため、バックアップが意図的に標的にされる状況では十分ではありません。

サイバーレジリエンスが有効なシナリオ

本記事で解説するサイバーレジリエンスのアプローチは、バックアップ自体を標的とする脅威に対応します。悪意ある操作は本番データだけでなく、アクセス可能なバックアップも対象にします。logically air-gapped vaultは別アカウント管理下の保護空間にバックアップを保存し、本番アカウントの管理者権限が奪われた場合でもバックアップへのアクセスを遮断します。

使い分け判断のフロー

障害発生時、最初に確認すべき点は「バックアップ自体が安全かどうか」です。バックアップが安全であれば、リージョン間DRの手順に従い、正常なバックアップから別リージョンに復旧します。バックアップが侵害または消去されている疑いがある場合は、logically air-gapped vaultのバックアップを参照し、サイバーレジリエンスの手順に従います。

7-2. インシデント復旧のエンドツーエンド設計

インシデント被害からの復旧は、単なるデータ復元以上のプロセスです。原因の全体像を把握し、侵入経路を封鎖した上でシステムを復旧しないと、復旧直後に再び被害を受けるリスクがあります。

フェーズ1: 検知

Amazon GuardDutyが異常な行動パターン(異常なAPIコール、マルウェアシグネチャ)を検知します。Security HubはGuardDutyの知見を集約し、重要度に応じてアラートを発報します。

ユーザーやシステムからの異常報告(ファイルが開けない、拡張子が変わっているなど)も重要な検知シグナルです。複数のシグナルを組み合わせて、被害の可能性を判断します。

フェーズ2: 隔離

被害が疑われるシステムを即座にネットワークから隔離します。EC2インスタンスのセキュリティグループをすべての通信を拒否する設定に変更し、他のシステムへの横展開を防ぎます。

aws ec2 modify-instance-attribute \
  --instance-id i-INSTANCEID \
  --groups sg-ISOLATION_SG_ID \
  --region ap-northeast-1

RDSの場合は、セキュリティグループの変更とパブリックアクセスの無効化を組み合わせて隔離します。

フェーズ3: 被害範囲の特定

隔離が完了した後、被害範囲を特定します。CloudTrailで異常なAPIコールの開始時刻を特定し、その時点以降に変更されたリソースを洗い出します。

Amazon Detectiveを活用することで、GuardDutyの発見事項を起点に、関連するリソースや通信パターンを視覚的に調査できます。被害の開始時点を正確に特定することが、安全なバックアップポイントの選択に直結します。

フェーズ4: air-gapped vaultからの復旧

被害開始時点の直前のバックアップポイントをlogically air-gapped vaultから選択します。RAM経由でテスト済みの復旧手順に従い、隔離された復旧用環境にシステムを展開します。

restore testingで事前検証済みの手順を使用することで、緊急時の復旧速度と確実性が高まります。復旧環境での動作確認が完了した後、本番環境への切り替えを実施します。Route 53やALBのルーティング変更によって、最小限のダウンタイムで本番復帰できます。

フェーズ5: 本番復帰と事後対応

本番復帰後、侵入経路となった脆弱性を修正します。パッチ適用、認証情報のローテーション、不要な権限の削除を実施します。

インシデントのタイムラインを記録し、事後レビュー文書を作成します。次回のインシデント対応改善に活用するとともに、コンプライアンス監査の証跡として保管します。

7-3. 多層防御アーキテクチャの組み合わせ設計

リージョン間DRとサイバーレジリエンスを組み合わせることで、可用性脅威と悪意ある操作の両方に対応できる多層防御アーキテクチャを構築できます。

アーキテクチャの全体像

Layer 1(可用性保護): 標準的なAWS Backupによるクロスリージョンコピー。リージョン障害やハードウェア故障に対応します。

Layer 2(サイバー保護): logically air-gapped vaultへの保存。内部不正や侵害を伴う操作に対応します。

Layer 3(復旧検証): restore testingによる定期的な復旧演習。RTO/RPO目標値の継続的な検証を担います。

バックアップ階層の設計

通常のバックアップはLayer 1としてメインのバックアップボールトに保存します。同時に、logically air-gapped vaultにも並行してバックアップを取得し、Layer 2の保護を確保します。

保存コストを最適化するために、Layer 1のバックアップは短い保存期間(例: 30日)、Layer 2のair-gapped vaultのバックアップは長い保存期間(例: 1年)に設定することを推奨します。

復旧優先度の設定

複数システムが同時に被害を受けた場合、復旧の優先度設定が重要です。事業継続性への影響度(ビジネスインパクト分析)に基づき、システムの優先度をティア分けします。

ティア1(最優先): 事業継続に直接影響するコアシステム(基幹業務システム、決済システムなど)。RTOは4時間以内を目標とします。

ティア2(次優先): 事業に影響はあるが代替手段がある業務支援システム。RTOは24時間以内を目標とします。

ティア3(低優先): 開発・テスト環境など。事業継続性への直接影響は小さいです。RTOは72時間以内を目標とします。

7-4. RTO/RPO要件に基づくvault tier選択

復旧時間目標(RTO)と復旧時点目標(RPO)の要件によって、適切なバックアップ方針が変わります。

RPO要件とバックアップ頻度の対応

RPOが1時間以内の場合、バックアップ頻度を1時間ごとに設定する必要があります。logically air-gapped vaultへの直接書き込み(primary backup target)を使用することで、バックアップジョブ完了と同時に保護が完成します。

RPOが24時間以内の場合は、日次バックアップで対応できます。業務システムの多くはこのRPO水準で許容される場合が多く、コストとのバランスを取りやすい設定です。

RTO要件とrestore testingの関係

restore testingで実測されたrestore時間がRTO目標を超過している場合は、以下の対策を検討します。

EBSスナップショットの高速スナップショット復元(Fast Snapshot Restore)を有効にすることで、EC2のrestore時間を短縮できます。ただし、Fast Snapshot Restoreは追加コストが発生します。RTO要件と追加コストのトレードオフを評価して適用するリソースを選定します。

RDSの場合は、インスタンスクラスが大きいほどrestore速度が向上します。RTO要件を満たせない場合は、本番と同等またはそれ以上のインスタンスクラスを復旧先に指定することを検討します。

7-5. 業種別インシデント対応シナリオ

実際のインシデント対応では、業種ごとの規制要件や業務特性によって対応手順が異なります。

金融機関のシナリオ

金融機関では、監督官庁へのシステム障害報告要件に基づき、インシデント検知から一定時間以内に当局への報告義務があります。この報告期限を意識した対応タイムラインの設計が必要です。

顧客データの保護とトランザクションの整合性が最優先事項です。バックアップからの復旧において、トランザクションの不整合が生じないよう、トランザクションログを含めた一貫性のある復旧ポイントを選択します。

コンプライアンス証跡として、restore testingの結果とインシデント対応ログをAudit Managerで自動収集し、監査要求に備えます。

医療機関のシナリオ

医療機関では、電子カルテシステムが停止すると患者の安全に影響します。そのため、最短のRTOを目標とした復旧計画が必要です。

電子カルテシステムのrestore testingでは、実際の患者データを使用せず、匿名化されたテストデータを使用します。また、復旧後のシステムが正確な情報を表示できるかの検証を、実際の業務フローに即したシナリオで実施します。

個人情報保護の観点から、restore testingの復旧環境にもアクセス制御と暗号化を徹底します。

製造業のシナリオ

製造業では、生産ラインを制御するOT(オペレーショナルテクノロジー)システムへの影響が懸念されます。ITシステムとOTシステムを分離したネットワーク設計を前提とした復旧計画を策定します。

生産計画データや品質管理データの完全性を優先し、復旧後のデータ検証を生産再開前に必ず実施するフローを標準化します。サプライチェーンへの影響を最小化するため、部分復旧(最重要データから順次復旧)の手順も事前に準備します。

7-6. 継続的な改善サイクル

サイバーレジリエンスは一度構築して終わりではなく、継続的な改善が必要です。

定期復旧演習の設計

年に1回以上、実際の被害シナリオを想定した復旧演習を実施します。机上演習(机上のシミュレーション)と実際のシステム復旧演習を組み合わせることで、手順の有効性と担当者のスキルを両面から検証します。

演習の結果はインシデント対応計画に反映し、改善したポイントを次の演習で確認します。この継続的な改善サイクルが、実際のインシデント時の対応力を高めます。

KPIの設定と追跡

サイバーレジリエンスの成熟度を測るKPIを設定し、定期的に追跡します。

主要KPIの例として、restore testing成功率(目標: 99%以上)、RTO達成率(目標: 100%)、バックアップカバレッジ(全対象リソースのカバー率)、復旧演習実施頻度(年2回以上)が挙げられます。

KPIが目標値を下回った場合は、根本原因分析を実施し、改善策を講じます。サイバーレジリエンスの継続的な向上が、組織全体のセキュリティ態勢強化につながります。定期的な見直しの場として、年次のクラウドセキュリティレビューにバックアップ保護の評価を組み込むことを推奨します。

8. 詰まりポイント・アンチパターン・まとめ

8-1. よくある詰まりポイントと解決策

logically air-gapped vaultをはじめとするAWS Backupサイバーレジリエンス機能の本番運用で遭遇しやすい詰まりポイントを解説します。

詰まり1: compliance mode設定後の保持期間変更不可エラー

症状

保管庫のVault Lock compliance modeを設定した後、保持期間を短縮しようとするとエラーが発生します。

原因

compliance modeは設定後の変更・解除が設計上不可能です。保持期間の短縮も含め、いかなる変更も受け付けません。

解決策

保管庫を作成し直す必要があります。既存の保管庫は変更できないため、新しい保管庫を適切な保持期間で作成し、バックアッププランのターゲットを切り替えます。compliance mode設定前の十分な検討が重要です。

対処手順:
1. 新しい保管庫を適切なMinRetentionDays/MaxRetentionDaysで作成
2. バックアッププランのTargetBackupVaultNameを新保管庫に更新
3. 旧保管庫は保持期間満了後に自動削除

詰まり2: logically air-gapped vault作成時のリージョン制限エラー

症状

一部のリージョンでlogically air-gapped vaultを作成しようとするとエラーになります。

原因

logically air-gapped vaultはすべてのAWSリージョンで利用できるわけではありません。サポートリージョン以外では作成コマンド自体が失敗します。

解決策

東京リージョン(ap-northeast-1)は正式サポートリージョンに含まれます。利用前に対象リージョンのサポート状況を公式ドキュメントで確認してください。

詰まり3: RAM共有の権限設定漏れによるリストア失敗

症状

logically air-gapped vaultからのリストアを試みると、権限エラーで失敗します。

原因

Resource Access Manager(RAM)による保管庫共有が正しく設定されていない場合、または共有の受諾が完了していない場合に発生します。RAM共有は「共有作成」と「共有受諾」の両方が必要です。

解決策

確認手順:
1. 共有元アカウント: RAM共有が「Accepted」ステータスであることを確認
2. 共有先アカウント: RAM共有招待を受諾済みであることを確認
3. IAMポリシー: backup:StartRestoreJob権限が付与されていることを確認
4. テストリストアを定期的に実行して疎通確認

詰まり4: Lifecycle設定とMinRetentionDaysの不整合

症状

logically air-gapped vaultをターゲットとするバックアッププランでバックアップジョブが失敗します。エラーメッセージに保持期間に関する内容が含まれます。

原因

バックアッププランのLifecycle.DeleteAfterDaysがVault LockのMinRetentionDaysより小さい値に設定されています。compliance modeのロック期間よりも短い期間でのライフサイクル削除は許可されません。

解決策

DeleteAfterDays >= MinRetentionDaysとなるようにバックアッププランを修正します。MinRetentionDays=7であれば、DeleteAfterDays=30は適切です。

詰まり5: restore testingのIAMロール設定ミス

症状

restore testingジョブが「Access Denied」などの権限エラーで失敗します。

原因

restore testingを実行するIAMロールに、リストア対象リソース(EC2、RDS等)の起動・作成権限が不足しています。また、リストア後のリソース削除権限がない場合、クリーンアップステップも失敗します。

解決策

restore testing用IAMロールに必要な権限:
- 対象リソースの作成権限
  例: ec2:RunInstances, rds:RestoreDBInstanceFromDBSnapshot
- AWSBackupServiceRolePolicyForRestores (AWS管理ポリシー)
- テスト後リソース削除権限(クリーンアップ用)

詰まり6: Multi-party approval承認者不在時のデッドロック

症状

保管庫に対する特定の操作が、承認者の不在により長時間ペンディング状態になります。緊急時でも保護された操作を完了できない状態になります。

原因

Organizations Multi-party approvalが設定されている場合、指定した承認者が承認しないと操作が完了しません。承認者が退職・異動した場合や、緊急対応中に承認者へ連絡が取れない場合は問題になります。

解決策

承認者を複数名(最低2名以上)設定し、不在時のエスカレーションフローを事前に設計します。承認期限を設定し、期限切れ時の代替承認者を明確にしておくことが重要です。

詰まり7: 標準vaultとlogically air-gapped vault混在による保護範囲の誤解

症状

バックアッププランでlogically air-gapped vaultと標準vaultの両方をターゲットに設定しているが、不変性保護の範囲を誤解している状態で運用が続く。

原因

標準vault側のバックアップには不変性保護がありません。logically air-gapped vaultへのコピーが完了した後でも、標準vault側のバックアップは削除可能です。

解決策

保護対象のバックアップを明確に分類し、不変性保護が必要なものはlogically air-gapped vaultのみをターゲットとするバックアッププランを作成します。リカバリポイントがどちらの保管庫に存在するかをタグや命名規則で識別できるようにします。

詰まり8: カスタマー管理KMSキーの誤削除による復元不能

症状

カスタマー管理KMSキーを使用してバックアップを作成後、そのキーが削除または無効化されたため、バックアップにアクセスできなくなります。

原因

logically air-gapped vaultでカスタマー管理KMSキーを指定した場合、そのキーなしにはバックアップデータを復号できません。キーが失われた場合、バックアップは永続的にアクセス不能になります。

解決策

KMS CMK管理のベストプラクティス:
1. キー削除スケジュール: 最低30日の待機期間を設定
2. キーの使用状況をCloudTrailで監査
3. キー無効化の操作をIAMポリシーで制限(MFAデバイス必須等)
4. キーローテーションを有効化

8-2. アンチパターンと正解

logically air-gapped vaultの運用で陥りやすいアンチパターンと、その正解を示します。

アンチパターン1: governance modeで十分と判断する

NG例

governance modeの標準vaultでバックアップを保護しているため、サイバーレジリエンスは十分に確保されていると判断してしまう。

正解

governance modeはロック設定を持つ管理者権限で変更できます。本番アカウントの管理者権限が奪われた場合、vaultロックを解除してバックアップを削除できます。重要データのサイバーレジリエンス強化にはlogically air-gapped vaultのcompliance modeが必要です。

アンチパターン2: バックアップを同一アカウントのみに保存する

NG例

本番アカウントの標準vaultに全バックアップを保存し、同アカウント内でリストアできる設計にする。

正解

同一アカウント内にのみバックアップを保存する設計では、アカウント侵害時にバックアップも影響を受けます。logically air-gapped vaultを使用して、AWSマネージドの分離アカウントにバックアップを格納します。またはクロスアカウントバックアップを併用して、別アカウントへのコピーを作成します。

アンチパターン3: restore testingを未実施のまま運用する

NG例

バックアップジョブが毎日成功しているため、restore testingは実施しなくて良いと判断する。バックアップが「存在する」ことをもって復旧可能と見なす。

正解

バックアップの存在は、復元の成功を保証しません。定期的なrestore testingを実施して、実際に復元が完了すること、および復元所要時間がRTO内に収まることを継続的に検証します。AWS Backupのrestore testing機能を使うと、スケジュールに基づく自動リストアと結果レポートが可能です。

アンチパターン4: 保持期間を短く設定して後から変更できると誤解する

NG例

compliance modeの保持期間を7日間に設定し、後から必要に応じて短縮・変更できると想定して設計する。

正解

compliance modeの保持期間は設定後に短縮できません。ビジネス要件と規制要件を事前に確認し、十分な保持期間を設定します。実運用前にgovernance modeで検証し、保持期間の妥当性を確認してからcompliance modeに移行することを推奨します。

アンチパターン5: RAM共有をインシデント後に設定しようとする

NG例

インシデント発生時にRAM共有設定を行ってからリストアを開始する。平常時はRAM共有を設定しておかなくてよいと考える。

正解

インシデント発生後の混乱状態でRAM共有設定を行うと、手順ミスや設定遅延でRTOが大幅に超過するリスクがあります。平常時にRAM共有設定を完了させ、restore testingで疎通確認まで済ませておきます。インシデント対応フローとして、RAM共有が既に完了しているという前提で手順を設計します。

アンチパターン6: EKSバックアップでVault Lockを考慮しない

NG例

EKSクラスターはステートレスなコンテナが中心なので、保護層の高いlogically air-gapped vaultは不要と判断して標準vaultのみに保存する。

正解

EKSクラスターのPersistent Volume(EBS/EFSバックエンド)、etcdスナップショット、Kubernetesリソース設定などは、インシデント時の復元に必要です。ステートレスなコンテナでも、設定データや永続ストレージの保護は重要です。EKSバックアップもlogically air-gapped vaultをターゲットに設定し、不変性を確保します。

8-3. まとめ

本記事では、logically air-gapped vaultを中心としたAWS Backupのサイバーレジリエンス機能を解説しました。

本記事のポイント整理

• logically air-gapped vaultの本質: バックアップをAWSマネージドの分離アカウントに格納することで、本番アカウントが侵害されてもバックアップを保護する設計
• Vault Lock compliance mode内蔵: 一度設定した保持期間は短縮・解除不可。設計段階での十分な検討が必須
• RAM共有によるRTO最適化: 復旧専用アカウントへのRAM共有を事前設定することで、インシデント時の迅速な復元が可能
• 東京リージョン対応: ap-northeast-1は正式サポートリージョンとして確定済み
• compliance mode vs governance mode: 本番のサイバーレジリエンスにはcompliance mode、開発・検証にはgovernance modeという使い分けが基本

本番運用へのネクストステップ

1. 要件定義: 保持期間(MinRetentionDays/MaxRetentionDays)の決定
2. 段階的導入: governance mode標準vaultで動作確認 → logically air-gapped vaultへ移行
3. restore testingの自動化: スケジュールベースのリストア検証を設定
4. RAM共有設定: 復旧アカウントへの事前共有と疎通確認
5. Multi-party approvalの設計: 承認者複数名・エスカレーションフローの整備
6. 監査体制: CloudTrailとAWS Backup監査レポートによる継続的な保護状況の可視化

可用性を目的としたリージョン間DRと、サイバーレジリエンスを目的としたlogically air-gapped vaultは、互いを補完する関係にあります。両方を組み合わせた多層保護が、現代のクラウド環境における信頼性の高いバックアップ基盤を形成します。

8-4. 関連記事