AWS Control Tower ランディングゾーンで実現する AWS Backup 統合管理：導入から有事のリストアまで徹底解説

前回のブログ「AWS Control Towerとは？マルチアカウント管理を自動化する仕組み」では、AWS Control Tower を使ったマルチアカウント環境の管理についてお伝えしました。

今回は、ランディングゾーンのバージョン4.0 展開時にオプションで有効化できる AWS Backup 統合管理 を徹底解説します。

自動作成されるリソースの仕組みや、 Vault ポリシーによるデータ保護に加え、「万が一の際、中央アカウントからどうやってデータを戻すのか」という具体的なリストア手順までお伝えします。

これからマルチアカウントのバックアップ運用を始める方はもちろん、導入後のリカバリプランに不安を感じている方にも最適な内容です。

AWSの利用規模が拡大し、マルチアカウント運用（Landing Zone）が必要になると、バックアップ運用において以下のような課題が浮上します。

• 設定漏れ：各アカウントの設定が担当に委ねられており、バックアッププランの設定漏れが発生する。
• 統制の欠如：コンプライアンスで定められた保存期間が、アカウントごとにバラバラ（例：ある部署は30日、別の部署は1年など）。
• 監査・監視コスト：「全アカウントでジョブが成功したか」を確認するために、個々のアカウントにログインして回る必要があり、膨大な時間がかかる。

2024年末のAWS Control Towerのアップデートにより、これらを AWS Control Tower の標準機能として一元管理できるようになりました。

AWS Control Tower の設定画面からAWS Backup 統合管理機能を有効化すると、Security OU 内に以下の2つの共有アカウントが自動で追加（または指定）され、役割が明確に分離されます。

Backup administrator では、組織全体の運用監視と監査レポート生成を担当します。主に以下の機能を利用することができます。

• クロスアカウントモニタリング：全メンバーアカウントのジョブ（バックアップ・コピー・復元） の状態を、この管理者アカウントから一画面で監視できます。
• S3 レポート出力：全アカウントのジョブ（バックアップ・コピー・復元）の実行結果を、監査証跡として S3 バケットに自動集約します
• バックアップポリシー：メンバーアカウントにバックアッププランを配布します。

Central backupでは、全組織のバックアップデータを集約して保管（二次保管）することができます。主に以下の役割を担っています。

• 二次保管の集約：各アカウントで取得したバックアップのコピーをこのアカウントに集約します。
• バックアップの改ざん防止：万が一、個別のメンバーアカウントが侵害（不正アクセス等）されデータが改ざんされたとしても、二次バックアップとして別アカウントに隔離されているため、復旧が可能になります。また、バックアップボールトと呼ばれるバックアップデータの保管庫では、データの削除を禁止するvault ポリシーが設定されています。

AWS Backup 統合管理機能を有効化すると、あらかじめ定義されたバックアッププランが自動生成されます。利用者は、バックアップしたいリソース（Amazon EC2やAmazon RDSなど）に、以下の特定のタグを付与するだけで、自動的にバックアップを取得できます。

※1 各メンバーアカウント内に作成されるバックアップボールト（バックアップデータ保管庫）でのデータ保持期間のこと
※2 中央バックアップアカウント（Central backup）内に作成されるバックアップボールトでのデータ保持期間のこと

「バックアップが正しく取れているか」の証跡管理も自動化されます。

バックアップ管理者アカウント内に Backup Audit Manager のレポートプランが自動作成され、組織全体の実行履歴が S3 バケットへ定期的に出力されます。

■ 用意される S3 バケットの種類
セキュリティと監査の妥当性を担保するため、2種類のバケットが用意されます。

• レポート用バケット：実際のジョブ実行結果が格納されます。
• アクセスログ用バケット：上記バケットへのアクセス履歴を記録します（「レポートが改ざんされていないか」の証明になります）。

■ レポート用バケット内のフォルダ構成
レポート用バケットの中には、ジョブの種類に応じて3種類のフォルダが作成されます。

• backup-reports/：バックアップジョブの成功・失敗ログ
• copy-reports/：コピーなどの転送ログ
• restore-reports/：復元ジョブの実行ログ

※Backup Audit Manager のレポートは、仕様としてAWS Backup によるコピー/バックアップ/リストアが実際に動作しなかった場合にも、それぞれ 24 時間ごとに自動的に S3 バケットに保存されます。

■ レポート用バケット/アクセスログ用のライフサイクルルール
「RetentionRule」というライフサイクルルールが適用され、アップロードされたオブジェクトが365日経過した後、削除されます。

また、標準でライフサイクルルール（保存期間）が設定されています。レポート自体は365日、アクセスログは3650日と、一般的なコンプライアンス要件を満たすための設定が最初から組み込まれています。

組織全体のバックアップが集約される本ボールトには、以下のポリシーが適用されています。

• 削除の禁止（不変性）： 管理者であっても、保管されたバックアップデータを手動で削除することはできません。これにより、ランサムウェア攻撃や内部不正によるデータ喪失を防ぎます。
• ポリシー変更の制限： AWS Control Tower が管理に使用する特定の IAM ロール以外、ポリシーを書き換えることはできません。「ポリシーを変更してからバックアップデータを消す」という策を実施できないように設定されています。
• 組織内コピーの許可： AWS Organizations 内の組織からのコピーのみを許可する設定となっており、メンバーアカウントからのバックアップ集約を受け入れています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCopyFromOrganization",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "backup:CopyIntoBackupVault",
      "Resource": "*",
      "Condition": { "StringEquals": { "aws:PrincipalOrgID": "<組織 ID>" } }
    },
    {
      "Sid": "DenyDeleteRecoveryPoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "backup:DeleteRecoveryPoint",
      "Resource": "*"
    },
    {
      "Sid": "DenyBackupVaultPolicyUpdates",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["backup:UpdateRecoveryPointLifecycle", "backup:PutBackupVaultAccessPolicy"],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:*:iam::<Central backup アカウントID>:role/AWSControlTowerExecution",
            "arn:*:iam::<Central backup アカウントID>:role/aws-service-role/controltower.amazonaws.com/AWSServiceRoleForAWSControlTower"
          ]
        }
      }
    }
  ]
}

中央バックアップボールトと同様に、本ボールトでも管理者を含めたデータの削除/ポリシーの書き換えが禁止されています。また、以下の2点の制御も自動設定されています。

• 中央バックアップボールトからのリストア： 万が一、ローカル側のデータが破損・改ざんされた場合に備え、中央バックアップボールトからデータを戻す権限が記述されています。
• 中央バックアップボールトへのコピー：個別のメンバーアカウントで取得したバックアップを中央バックアップボールトへコピーできるよう、クロスアカウントコピーの権限があらかじめセットされています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCopyFromCentralBackupVaultForRestores",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<Central backup アカウントID>:root"
      },
      "Action": "backup:CopyIntoBackupVault",
      "Resource": "*"
    },
    {
      "Sid": "AllowCopyToCentralBackupVaultForVaulting",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<Central backup アカウントID>:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"
      },
      "Action": "backup:CopyFromBackupVault",
      "Resource": "*"
    },
    {
      "Sid": "DenyDeleteRecoveryPoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "backup:DeleteRecoveryPoint",
      "Resource": "*"
    },
    {
      "Sid": "DenyBackupVaultPolicyUpdates",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "backup:UpdateRecoveryPointLifecycle",
        "backup:PutBackupVaultAccessPolicy"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:*:iam::<ローカル アカウントID>:role/AWSControlTowerExecution",
            "arn:*:iam::<ローカル アカウントID>:role/aws-service-role/controltower.amazonaws.com/AWSServiceRoleForAWSControlTower"
          ]
        }
      }
    }
  ]
}

ここまで、AWS Backup 統合管理を実装することで自動作成されるリソースについて解説しました。ここからは、Control Tower コンソールから数クリックで実装できるAWS Backup 統合管理の設定方法について解説します。

1. 1.ランディングゾーンの設定を更新するために、管理アカウントのAWS Control Tower コンソールのメニューから、「ランディングゾーン設定」＞「設定を変更する」をクリックします。

2. 2.「AWS Backupを有効化にする」を選択した上で、「中央バックアップアカウント」「バックアップ管理者アカウント」「バックアップのKMSキー」を指定します。指定が完了した後、「ランディングゾーンの更新」をクリックすることで設定が完了します。

※各アカウント、リソースをその場で作成することも可能ですし、事前に用意しておき、選択することも可能です。
KMSキーにおいては、Control Tower管理対象の全リージョンに複製されたマルチリージョン KMS キーが必要です。

1. 1.続いて、任意のOUに対してAWS Backupを有効化するために、管理アカウントの Control Tower コンソールから、「組織」＞「対象のOU」＞「Integrations on this OU - オプション」＞「編集」の順に選択します。

2. 2.「有効にする」を選択した上で、「確認」を選択します。

上記のステップで設定は完了です。

これにより、各メンバーアカウントには「Amazon EC2やAmazon RDSといったリソースに対して、タグを貼るだけで機能するバックアッププラン」が配布され、同時に「管理者が一元監視できる設定」と「イミュータブルなバックアップボールト」が自動的に整います。

本来であれば、監査レポート用のS3バケット準備や、クロスアカウントコピーのための複雑な権限設定には工数がかかります。しかし、この統合管理ならそれらすべてが自動で行われるため、設定ミスによる「バックアップ漏れ」の心配もありません。

ここまで、AWS Backup 統合管理について自動で設定されるリソースの解説から設定手順まで解説しました。

ただ、バックアップデータは取得するだけでなく、有事の際に復旧（リストア）できるよう手順を確立しておくことが重要です。ここからは、各アカウントに作成されるローカルバックアップボールトのデータが消失したことを想定して、中央バックアップアカウント (Central backup)に二次保管として保持しておいたデータからAmazon EC2をリストアする手順について解説します。

1. 1.中央バックアップアカウント (Central backup)にログインし、「AWS Backup」＞「ボールト」＞「中央バックアップボールト」＞「復旧ポイント」＞「対象のバックアップを選択」＞「アクション」＞「コピー」の順にクリックします。

2. 2.画面が遷移したら、「リージョン」、「別のアカウントのボールトにコピー」にチェック＞「外部ボールト ARN」にメンバーアカウントのローカルバックアップボールトのARN を入力＞「コピー」をクリックします。

3. 3.実施したコピージョブについては、ジョブメニューから現在のステータス状況などを確認できます。

1. 1.コピージョブが完了になったら、メンバーアカウントにログインし、「AWS Backup」＞「ボールト」＞「ローカルバックアップボールト」＞「復旧ポイント」＞「対象のバックアップを選択」＞「復元」＞の順にクリックします。

2. 2.「バックアップを復元」という画面が表示されます。この画面からリストアすることもできますが、NWの設定など詳細なパラメータを指定することができません。詳細な設定を実施するために「インスタンス起動ウィザード」をクリックします。

3. 3.画面が遷移したら、「名前」「インスタンスタイプ」「キーペア」「VPC」「サブネット」「セキュリティグループ」をそれぞれ指定し、「インスタンスを起動」をクリックします。

※「高度なネットワーク設定」にてIPアドレスの指定や、「ストレージを設定」にてボリュームの追加などより詳細な設定を実施することも可能です。

4. 4.緑色のバナーで「成功」と表示されれば、リストアの完了です。適宜Amazon EC2に接続していただくと、バックアップから正常に復旧されていることを確認いただけます。

本記事では、AWS Control Tower と AWS Backup の統合による一元管理のメリットと、有事を見据えた具体的なリストア方法まで解説しました。

「タグベース」の自動化で設定漏れを防ぎ、「イミュータブル」な保護でデータの不変性を担保する仕組みを導入することで、運用の手間を最小限に抑えつつ、組織全体のデータ保護を実現することができます。

ぜひAWSのバックアップ運用に活用してみてください。

執筆者・シリーズ情報

• 佐藤 寿紀

2023年に新卒入社し、現在はAWSのフィールド業務を担当。得意分野であるAWSアカウント管理をはじめ、ネットワークやEC2など、インフラ全般の構築を手掛ける。また、アシストオリジナルのAmazon Redshift研修講師も担当している。 趣味はYouTube鑑賞。最近はワイシャツのアイロンがけにもハマっており、シワのないシャツと同様に、無駄のない綺麗なクラウド環境を構築することに並々ならぬ情熱を注いでいる。...show more