AWS Control Tower の AWS Backup 統合機能でクロスアカウント復元してみた
こんにちは！クラウド事業本部のおつまみです。
みなさん、AWS Control Tower の AWS Backup 統合機能使ったことありますか？
この機能を使って、Organizations 配下のメンバーアカウントから中央バックアップアカウントへバックアップを集約し、別アカウントへ復元する一連のフローを検証してみました。
公式ドキュメントを読みつつ進めたのですが、実際の手順や挙動について公式ドキュメントだけではわからないハマりポイントがいくつかあったので、検証で得た知見をまとめておきます。
検証の背景
ランサムウェア対策として、AWS Organizations 配下のワークロードアカウントのバックアップを別アカウントへ集約し、侵害発生時には全く別の復旧用アカウントへ復元する、というアーキテクチャを検討していました。
AWS Control Tower の AWS Backup 統合機能を使えば、Backup Plan・中央 Backup Vault・IAM Role の配布がマネージドで実現できるため、CCoE 側の運用負荷を最小化しつつ、組織全体に統一的なバックアップ戦略を展開できます。
ただし、侵害発生時に「中央バックアップアカウントから別アカウントへ実際に復元できるのか」 を検証しないと、いざという時に動かない可能性があります。今回はその一連のフローを実検証しました。
検証構成
検証では以下の 5 アカウントを使用しました。
| アカウント | 役割 |
|---|---|
| Control Tower 管理アカウント | Control Tower の管理 |
| Central Backup Account | バックアップ集約先（Control Tower が自動作成） |
| Backup Administrator Account | バックアップポリシー管理（Control Tower が自動作成） |
| ワークロードアカウントA | バックアップ取得元（EC2 を立てる） |
| 復旧用アカウントB | 復元先（侵害時を想定した別アカウント） |
検証フェーズ
検証は以下の3フェーズで実施しました。
- フェーズA: Control Tower Backup 統合機能の有効化
- フェーズB: バックアップ取得・中央ボールトへのコピー確認
- フェーズC: 中央ボールトから復旧用アカウントへの「コピー → 復元」検証
フェーズA: Control Tower Backup 統合機能の有効化
公式ドキュメントどおりに以下の手順で有効化しました。
- マルチリージョン KMS キーの作成（管理アカウント）
- Backup Administrator Account と Central Backup Account を Account Factory で払い出し
- Control Tower のランディングゾーン設定で AWS Backup を有効化
- 対象 OU の詳細画面で「Enable AWS Backup on OU」をクリック
注意ポイント: OU 単位での有効化が必須
ランディングゾーンレベルで有効化しただけでは、メンバーアカウントにバックアップリソースが配布されません。
対象 OU ごとに「Enable AWS Backup on OU」を個別に実行する必要があります。
有効化後、ワークロードアカウントには以下が自動配布されます。
- ローカル Backup Vault（
aws-controltower-local-backupvault-xxx） - 4 種類の Backup Plan（hourly / daily / weekly / monthly）
- ローカル IAM Role（
aws-controltower-BackupRole）
全体構成は以下のようなイメージです。Security OU 配下に Central Backup と Backup Administrator の2アカウントが作成され、Workload OU 配下の各アカウントにローカル Backup Vault と Backup Plan が自動展開されます。
フェーズB: バックアップ取得・中央ボールトへのコピー
検証 EC2 にタグを付与してバックアップを取得しました。
バックアップ取得時のデータフローは以下のとおりで、利用者がタグを付与すると、Backup Plan によって自動でローカル Vault および中央 Vault に復旧ポイントが格納されます。
検証時間短縮のため hourly を採用
公式の推奨タグは aws-control-tower-backuphourly: true（「backuphourly」とハイフン無しで連結）です。最初 aws-control-tower-backup-hourly: true と書いてしまい、バックアップが走らなくて 30 分ほど悩みました。
hourly を採用したのは、daily だと検証完了まで翌日まで待つ必要があるためです。1 時間ごとにスケジュール実行されるため、検証時間を大幅に短縮できました。
ハマりポイント1: hourly は中央ボールトにコピーされない
公式ドキュメントによると、Control Tower 配布の Backup Plan の保持期間は以下のとおりです。
| プラン | ローカルボールト | 中央ボールト |
|---|---|---|
| Hourly | 2 週間 | コピーなし |
| Daily | 2 週間 | 1 ヶ月 |
| Weekly | 1 ヶ月 | 3 ヶ月 |
| Monthly | 3 ヶ月 | 3 ヶ月 |
hourly はローカルボールトのみで中央ボールトにはコピーされない仕様でした。中央ボールトへの集約検証には daily 以上が必要です。
検証では時間短縮のため、ローカルボールトから中央ボールトへ 手動コピー で集約しました。手動コピー時の IAM ロールには、ワークロードアカウントに自動配布された aws-controltower-BackupRole を指定しました。
フェーズC: クロスアカウントコピー & 復元
ここが本検証のメインで、最もハマったフェーズです。
ワークロードアカウントが侵害され、ローカルボールトのバックアップも破壊された想定で、中央ボールトから復旧用アカウントへ復元します。
AWS Backup の仕様上、別アカウントへの「直接復元」は不可なので、「コピー → 復元」の2ステップ が必要です。
ざっくりした手順は以下の図の通りです。
復旧用アカウントは Workload OU 配下である必要はなく、別 OU に新規払い出ししたアカウントでも、既存アカウントでも構いません。
アカウント発行時に StackSets や Account Factory で VPC・セキュリティ設定が自動配布される運用にしておくと、復旧用アカウントの基盤再構築の手間が省けるためおすすめです。
復旧用アカウントBの準備
- KMS キーの新規作成（対称・カスタマー管理キー）
- Backup Vault の作成（
cm-restore-target-vault） - Backup Vault のリソースベースポリシー設定（Central Backup Account からのコピー許可）
- KMS キーポリシーの調整（Central Backup Account のキー利用許可）
ハマりポイント2: Central Backup Account に AWSBackupDefaultServiceRole がないとコピーが失敗する
中央ボールトから復旧用アカウントへコピーを実行した際、以下のエラーで失敗しました。
Failed to finalize copy operation due to missing permissions.
Source recovery point might still be shared with the destination account.
Access Denied trying to call AWS Backup service
このエラーの厄介な点は、コピー先アカウントの CloudTrail には何のログも残らないことです。原因切り分けに何時間も費やしました。
最終的に、Central Backup Account に AWSBackupDefaultServiceRole が存在しなかった ことが原因でした。
なぜ起きるのか
Central Backup Account は「バックアップを保存するだけ」のアカウントなので、AWS Backup コンソールを一度も開く機会がありません。AWSBackupDefaultServiceRole は AWS Backup の初回利用時に自動作成されるため、明示的に作成していないと存在しない状態になります。
コピー操作時にこのロールを指定しても、ロールの実体がないため AssumeRole に失敗し、finalize フェーズで権限不足エラーになります。
対処方法
Central Backup Account でコピーを実行する際、IAM ロール選択欄で「デフォルトロールを作成」を選択するだけ で AWSBackupDefaultServiceRole が自動作成され、その後のコピーが成功するようになりました。
事前に CLI で存在確認したい場合は以下のコマンドで確認できます。
aws iam get-role --role-name AWSBackupDefaultServiceRole
NoSuchEntity が返ってきた場合は未作成の状態なので、AWS Backup コンソールでコピー操作時に「デフォルトロールを作成」を選択するか、コンソールを一度開いて初期化させてください。
ハマりポイント3: 元 EBS が暗号化なしでも、復元時は暗号化必須
コピーは成功したものの、今度は復元ジョブで以下のエラーが発生しました。
Cannot create unencrypted device /dev/xvda from encrypted snapshot
元の EC2 の EBS は 暗号化なし で作成していたので、最初は意味がわかりませんでした。
なぜ起きるのか
公式ドキュメントによると、AWS Backup のクロスアカウントコピーでは コピー先 Backup Vault の KMS キーで強制的に再暗号化 されます。
When you copy a backup to cross-account for the first time, AWS Backup copies the backup in full. AWS Backup re-encrypts your copy using the encryption key of your destination vault.
このため、元 EBS が暗号化なしでも、コピー後のリカバリポイントは暗号化済みになります。復元時に Encrypted: false で復元しようとすると「暗号化済みスナップショットから非暗号化デバイスは作れない」とエラーになるわけです。
対処方法
復元時のメタデータで Encrypted: true と KmsKeyId を明示指定します。コンソールの場合は「Advanced settings / Edit metadata」から JSON メタデータを編集できます。
{
"DeviceName": "/dev/xvda",
"Ebs": {
"VolumeSize": 8,
"VolumeType": "gp3",
"DeleteOnTermination": true,
"Encrypted": "true",
"KmsKeyId": "arn:aws:kms:ap-northeast-1:<account-b-id>:key/<key-id>"
}
}
これで復元が成功し、EC2が無事起動されるところまで確認できました。
まとめ
AWS Control Tower の AWS Backup 統合機能で、メンバーアカウント → 中央バックアップアカウント → 復旧用アカウントへのコピー & 復元フローを検証しました。
公式ドキュメントどおりに進めるだけでは想定外のエラーに何度か遭遇しましたが、いずれも仕組みを理解すれば事前準備で回避できるものでした。
特に AWSBackupDefaultServiceRole の事前作成 と 復元時の EBS 暗号化指定 は、知らないと本番障害時に焦るポイントなので、CCoE ガイドラインや復元手順書に明記しておくことをおすすめします。
ランサムウェア対策の観点では、Control Tower 管理外の独自 Backup Vault を介して別アカウントへ復元できることが確認できたため、十分実用に耐える構成だと感じました。Vault Lock の導入も別途検討する余地はありますが、まずは「分離・集約」を実現する第一歩として、本機能の活用は有効だと思います。
最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。
以上、おつまみ（@AWS11077）でした！
