Organizations環境下で、管理アカウントでAWS Backupのバックアップポリシーを作成し、メンバーアカウントのバックアップを一元管理してみた

マルチアカウント環境下で、バックアップを一元管理する方法を説明します。
2023.09.29

はじめに

Organizations環境下で、管理アカウントにAWS Backupのバックアップポリシーを作成し、メンバーアカウントのバックアップを取得する手順をまとめました。

バックアップポリシーとは、どのリソースに対して、どのくらいの頻度で、いつバックアップするかなどを定義したものです

バックアップポリシーでは、具体的には以下の内容などを定義できます。

  • バックアッププラン
  • バックアップルール
  • リソースの割り当て
  • バックアッププランのタグ
  • アドバンスドバックアップ設定

Organizations内の組織単位(OU)やアカウントに対して、バックアップポリシーを割り当てることで、OUやアカウント単位でバックアップ設定を一元的に管理することができます。

この記事では、管理アカウントでバックアップポリシーを作成し、メンバーアカウント側でバックアップポリシーをもとにバックアップを取得し、一元管理できることを確認します。

管理アカウントとメンバーアカウントでは、それぞれ下記の対応を行います。

  • 管理アカウント
    • クロスアカウント管理を有効化
    • IAMロール作成
    • バックアップボールド作成
    • バックアップポリシー作成
  • メンバーアカウント
    • IAMロール作成
    • バックアップボールド作成

重要な点として、管理アカウントとメンバーアカウントで作成するIAMロールとバックアップボールドは、それぞれ同名である必要があります。

理由は、バックアップポリシーが、IAMロールとバックアップボールドの名前を指定しているためです。

名前が異なると、メンバーアカウント側でバックアップがされないため、注意しましょう。

管理アカウントでやること

管理アカウントでは、以下の順で対応します。

  1. クロスアカウント管理を有効化
  2. IAMロール作成
  3. バックアップボールド作成
  4. バックアップポリシー作成

クロスアカウント管理を有効化

AWS Backupの[設定]からバックアップポリシーとクロスアカウントモニタリングを有効化します。

IAMロール作成

AWS Backup用のIAMロールをtest-bk-roleという名前で作成します。

信頼エンティティは、下記の通りです

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "backup.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

アタッチするポリシーは、以下の2つです。

  • AWSBackupServiceRolePolicyForBackup
  • AWSBackupServiceRolePolicyForRestores

バックアップボールド作成

test-bkvaultという名前でバックアップボールドを作成します。

バックアップポリシー作成

Organizationサービスに遷移し、バックアップポリシーを有効化します。

有効化後、test-bk-policyという名前でバックアップポリシーを作成します。

バックアッププランは、test-bk-planという名前で、東京リージョンを選択します。

バックアップルールは、test-bk-ruleという名前にし、先程作成したバックアップボールド名(test-bk-vault)を記載します。

バックアップの頻度は、各自必要な頻度にします。

毎時間バックアップを取得したい場合、バックアップ頻度を毎時にし、開始時間を00:00とすると毎時間(1日24回)バックアップが取得できます。

詳しくは、こちらを参考下さい。

「リソースを割り当てる」では、リソース名をtest-bk-resourceにし、先程作成IAMロール(test-bk-role)名を入力します。

リソースタグキーとタグの値は、メンバーアカウントでバックアップしたいリソースに付与するタグのことです。

タグキーをBackup、タグ値をOnにしました。

バックアップポリシーを作成後、ターゲットでバックアップを管理したOUをターゲットにします。

Rootをターゲットにすると、全てアカウントがバックアップの対象になります。

バックアップポリシーを管理アカウントにアタッチしていない場合、管理アカウントでバックアップポリシーに準じたバックアップは、もちろんできません。

ちなみに、バックアップポリシーは、AWS Backupのコンソールからも作成できます。

メンバーアカウント

バックアップポリシーをアタッチしたOU配下のメンバーアカウントで以下を対応します。

  1. IAMロール作成
  2. バックアップボールド作成

IAMロール作成

管理アカウントと名前も含めて全く同じ設定で作成します。名前は、必ず同じにする必要があります。

AWS Backup用のIAMロールをtest-bk-roleという名前で作成します。

信頼エンティティは、下記の通りです

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "backup.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

アタッチするポリシーは、以下の2つです。

  • AWSBackupServiceRolePolicyForBackup
  • AWSBackupServiceRolePolicyForRestores

バックアップボールド作成

管理アカウントのバックアップボールドと同じ名前で作成します。

バックアップボールドで設定するKMSキーが、メンバーアカウントに共有された管理アカウントのKMSキーを利用する場合は、コンソール上ではバックアップボールドの作成ができません。

CloudShellで下記のAWS CLIコマンドで作成します。

$ aws backup create-backup-vault --backup-vault-name test-bk-vault --encryption-key-arn arn:aws:kms:ap-northeast-1:アカウントID:key/xxx-xxx-xxx-xxx-xxx
{
    "BackupVaultName": "test-bk-vault",
    "BackupVaultArn": "arn:aws:backup:ap-northeast-1:アカウントID:backup-vault:test-bk-vaults",
    "CreationDate": "2023-09-25T06:50:29.083000+00:00"
}

バックアップポリシーが反映されたメンバーアカウント内のリソース確認

バックアップポリシーがアタッチされたメンバーアカウントでは、バックアッププラン(test-bk-rule)がメンバーアカウント側で表示されますが、変更はできません。

バックアップルール(test-bk-rule)も確認できました。

test-bk-ruleに紐づいているバックアップボールド(test-bk-vault)は、リンクになっていますが、メンバーアカウントでtest-bk-vaultを事前に作成していない場合、リンク先に正しく遷移されません。

「リソースの割り当て」(test-bk-resource)も確認できました。

バックアップを試してみる

メンバーアカウント内で、EC2を起動し、タグにキーBackupと値Onを付与します。

メンバーアカウントのAWS Backupの[保護されたリソース]から、EC2のバックアップを取得したことが確認できます。

[バックアップを復元]から、ロールをtest-bk-roleに設定し、復元することもできました。

ジョブも成功しています。

管理アカウント側でも[クロスアカウントモニタリング]で、メンバーアカウントのバックアップ取得を確認できました。

バックアップルールやリソースの割り当てを追加する

バックアップルールやリソースの割り当てを追加する場合は、作成したバックアップポリシーに追加するだけです。

追加でバックアッププランを作成する

以下の条件で、別のバックアッププランを追加設定したい場合、同じバックアップボールド名でバックアップポリシーを新規作成するだけです。

  • バックアップボールドは同じ名前
  • IAMロールは同じ名前
  • バックアッププランもしくはリソースの割り当てが異なる

バックアップボールドとIAMロールは同じため、リソースアカウント側ですることは特にありません。

参考