[アップデート] Control Tower ランディングゾーンがAWS Backup の統合管理をサポートしたので使ってみた

あしざわです。

先日、AWS Control Tower のランディングゾーンにAWS Backupの管理機能が追加されました。

https://aws.amazon.com/jp/about-aws/whats-new/2024/11/aws-control-tower-prescriptive-backup-plans-landing-zone/

本ブログでは、前半で機能の概要を確認し、後半で検証用のControl Tower 環境を使った機能を有効化を試してみます。

概要

Control Tower ランディングゾーンでAWS Backup を有効化すると、CT管理下のAWSアカウントでAWS Backup を使ってバックアップを取得する基盤がマネージドに構築できます。

機能の有効化によって作成されるリソースを含む、全体の構成はこちらです。

構成の特徴をまとめたものがこちらです。

• ランディングゾーンでAWS Backupを有効化すると、Security OU の共有AWSアカウントが新規に2つ追加される
  • 中央バックアップアカウント：組織の集約用バックアップボールトを管理
  • バックアップ管理者アカウント：Backup Audit Manager を管理
• OU 単位でオプトインすると、その他のAWSアカウントにAWS Backup を使ったローカルバックアップリソースが作成される

これまでControl Tower のSecurity OU が管理する共有AWSアカウントは、監査アカウント(Audit)、ログアーカイブアカウント(LogArchive)の2つでした。

今回の新機能をランディングゾーンで有効化すると、新しく 中央バックアップアカウント(Central Backup)、バックアップ管理者アカウント(Backup Administrator) の2つが追加され、共有AWSアカウントは 4つ になります。

ランディングゾーンでの有効化後、OU単位で機能をオプトインすることで管理下のAWSアカウントにAWS Backup関連のリソースがデプロイされます。メンバーアカウントの利用者は、AWS リソースに指定のタグを付与するだけで任意の周期で定期的にバックアップが取得できる、タグの付与によるバックアップ機能 が利用できます。

組織全体でバックアップを取るための仕組みはControl Tower が管理するため、構築・運用のための管理者の負荷を低減 できます。

事前準備

検証の前提として、Control Tower ランディングゾーンが有効化されているOrganizations 組織を準備してください。

また今回有効化するAWS Backup 管理機能を有効する前提として以下のアカウント・リソースが必要になります。

• 中央バックアップアカウントとなる、Control Tower に登録されていないAWS アカウント
• バックアップ管理者アカウントとなる、Control Tower に登録されていないAWS アカウント
• キーポリシー要件を満たしたマルチリージョンKMS キー(管理リージョンのレプリカキーの複製も含む)

やってみた

有効化方法はこちらのドキュメントに記載があります。

https://docs.aws.amazon.com/controltower/latest/userguide/enable-backup.html

全体の流れはこちらです。

• 管理アカウントのランディングゾーン設定からAWS Backup を有効化する
• OU の設定でAWS Backup オプションを有効化する

ランディングゾーンの更新

はじめに、Control Tower の管理アカウントのランディングゾーン設定を変更し、AWS Backupを有効化します。

Control Towerのマネジメントコンソール、ランディングゾーン設定タブの設定を変更するをクリックしてください。
今回の検証で使うControl Tower 環境のランディングゾーンバージョンは3.3です。

ステップ 3 設定を更新まで設定画面を進め、AWS Backup を有効にする にチェック入れて の項目を入力します。

組織を参照をクリックすると、Orgnaizationsの組織構造画面を表示できました。ここで対象のアカウントを選択すると、アカウントIDがそのまま入力されました。

このように必要情報を入力してから、次へをクリックします。

ステップ4の確認画面で入力した情報を確認して、ランディングゾーンの更新をクリックします。

更新に成功しました。

Control Tower コンソールのランディングゾーン設定から、AWS Backupが有効になっていること、各アカウントやリソースの設定状態が確認できました。

OU 単位のAWS Backup オプションの有効化

続いて管理アカウントのControl Tower のOU 設定から、バックアップを取得したいAWSアカウントが所属するOU でAWS Backup オプションを有効化します。

Control Tower マネジメントコンソールの組織タブからOUの詳細情報画面に遷移します。

詳細画面の下の方に、 この OU での AWS Backup - オプション という枠があるので、Enable AWS Backup on OUから有効化していきます。

しばらく待つとステータスが有効に変わりました。

AWS Backup を有効化したOU 配下のアカウント上のリソースを確認します。

aws-controltower-local-backupvault-<AWSアカウントID>というバックアップボールトが作成されています。

また、以下の4種類のバックアッププランが作成されていました。各プランの仕様のサマリがこちら。

• aws-controltower-monthly-backup-plan
  • 1 時間ごとのバックアップ = ローカル ボールトに 2 週間保存、中央バックアップ ボールトにコピーなし
• aws-controltower-hourly-backup-plan
  • 毎日のバックアップ = ローカル ボールトに 2 週間保存、中央バックアップ ボールトに 1 か月保存
• aws-controltower-weekly-backup-plan
  • 週次バックアップ = ローカル ボールトに 1 か月保存、中央ボールトに 3 か月保存
• aws-controltower-daily-backup-plan
  • 月次バックアップ = ローカル ボールトに 3 か月保存、中央バックアップ ボールトに 3 か月保存

バックアップの取得

AWS Backup がサポートする任意のAWS サービスに以下のタグを付与します。

• キー：aws-control-tower-backup<バックアップ周期>
• バリュー:true

<バックアップ周期>には、周期を表す4つの単語(※)を入れます（例：aws-control-tower-backuphourly, aws-control-tower-backupmonthly）

※hourly(1時間おき) / daily(1日おき) / weekly(1週間おき) / monthly(1ヶ月おき)

今回はすぐに結果を確認したかったので、EC2インスタンスにaws-control-tower-backuphourly : trueのタグを指定しました。

1時間〜2時間後に確認したところ、AwsBackup〜で始まる名前のAMI がおおよそ1時間おきに作成されていました。

注意点

本機能ですが、公式ドキュメントを見ていると利用にあたっていくつか注意点があるようでした。

私が気になったのは以下のあたりです。

• サービス無効化関連の注意
  • 現在、OU 単位のバックアップの無効化はコンソールからはできないため、DisableBaselineAPIの利用が必須
  • ランディングゾーン全体でバックアップを無効化する際は、事前にすべてのOUでバックアップを無効化する作業が必要
  • 参考リンク:Turn off backups - AWS Control Tower
• 監査アカウントとログアーカイブアカウントでの注意点
  • Control Tower 共有アカウントである監査アカウントとログアーカイブアカウントのバックアップを有効化するときは、Control TowerのEnableBaselineAPIを利用して設定する必要がある
  • 参考リンク:Enable backups - AWS Control Tower
• バックアップ関連のドリフト回避のための注意点
  • バックアッププランの削除や変更によってドリフト状態になることが想定されるため注意が必要
  • 共有アカウントのSecurity OUからの移動、共有AWSアカウントの削除などが含まれます
  • 参考リンク:Backup drift in AWS Control Tower - AWS Control Tower

検証の前にドキュメントをよく読んでおくことをお勧めします。

（参考）検証中にハマったこと

検証にあたってランディングゾーンの更新ができず、ハマったことがあったので参考までに紹介します。

マルチリージョンKMS キーはプライマリキーの準備だけでなく、Control Tower で管理している全リージョンのレプリカキーの複製が必須です。

公式ドキュメントのNote に以下の記載がありますが、私はこの記載を読み飛ばしてハマりました。

Your multi-region AWS KMS key must be replicated for every AWS Region that you plan to govern with AWS Control Tower.

レプリカキーを作成せずにランディングゾーンを更新するとエラーが表示されます。

AWS Control Tower はランディングゾーンを完全に設定できませんでした。AWS Control Tower failed to deploy one or more stack set instances: StackSet Id: AWSControlTowerCentralBackup:9f1ffa16-e6ef-4205-8760-81794237d138, Stack instance Id: arn:aws:cloudformation:us-east-1:123456789012:stack/StackSet-AWSControlTowerCentralBackup-cad9186c-3c28-4312-9060-a90f5336b181/1ce18090-bacc-11ef-94a6-0affcc3f1c57, Status: OUTDATED, Status Reason: ResourceLogicalId:CentralBackupVault, ResourceType:AWS::Backup::BackupVault, ResourceStatusReason:Resource handler returned message: "Insufficient privileges to create a backup vault. Creating a backup vault requires backup-storage and KMS permissions. (Service: Backup, Status Code: 403, Request ID: 4b0f1076-4d51-4a98-926e-591fe293baee)" (RequestToken: 3ecc72bc-1fea-35e5-ccc3-f20506100b9f, HandlerErrorCode: AccessDenied).

これはControl Tower が実行するCloudFormation StackSets のエラーです。

管理アカウントのStackSets のステータスを確認すると、レプリカキーを作成していなかったus-east-1リージョンでスタックインスタンスの実行に失敗していました。

レプリカキーを作成した後、ランディングゾーンの更新をすると無事更新できました。

最後に

以上、AWS Control Tower ランディングゾーンのAWS Backup管理機能の概要紹介と試してみたブログでした。

私がAWS マルチアカウント構成について考える際、AWS セキュリティリファレンスアーキテクチャをよく参考にしているのですが、本ブログ執筆時点で本アップデートに関連したバックアップ関連の追記は確認できていません。

そのうち追記されるのかなと思いながら、ないかも知れないとも思っています。これまで通り、気長にアップデートを追いたいと思います。

以上です。