AWS BackupでRDS(Aurora)を別アカウントへ集約管理する：KMS再暗号化(2段階コピー)と命名規約のベストプラクティス

RDS（Aurora）のバックアップを別アカウントに集約して管理したい場合、以下の2つの壁にぶつかります。

1. デフォルトキーの壁: aws/rds（AWS管理キー）で暗号化されたスナップショットは、そのままでは別アカウントにコピーできない。（ここが最大のハマりポイントです！）
2. 権限管理の壁: 別アカウントにコピーするためには、一度自アカウント内でカスタマー管理型のキー（CMK）に再暗号化してから転送する必要がある。

本記事では、この「2段階のコピー処理」を Lambda で自動化しつつ、運用しやすい命名規約で管理する方法と、よくある権限エラーの解決策を解説します。

前提：AWS Organizations と機能の有効化

手順に入る前に、AWS Backup のクロスアカウントコピーには外せない前提が 2 つあります。

1 つ目は、コピー元とコピー先の両アカウントが同じ AWS Organizations の組織に属していること。

組織に属していないアカウント同士では、そもそもクロスアカウントコピーができません。

2 つ目は、組織の管理アカウントでクロスアカウントバックアップを有効化しておくこと。

AWS Backup コンソールの「設定」から有効にするか、UpdateGlobalSettings API で切り替えます。

この操作は管理アカウントの認証情報でしか実行できないので、メンバーアカウント側でいくら設定しても解決しません。

構成図（正しい2段階コピーのアーキテクチャ）

RDS/Aurora の場合、クロスアカウントコピーを成功させるには以下のステップを踏む必要があります。

1. STEP1 (自動): Backup Plan により、自アカウントの Vault に aws/rds キーでバックアップが作成される。
2. STEP2 (1段階目のコピー): 完了イベントを検知した Lambda が、「自アカウントの CMK」 を使って再暗号化し、同じアカウント内の Vault へコピーする。
3. STEP3 (2段階目のコピー): STEP2 の完了を検知した Lambda が、今度は 「別アカウント（管理側）の Vault ARN と CMK」 を指定して、クロスアカウントコピーを実行する。

KMS CMK の作成と共有設定の勘所

この構成では、バックアップ元（自アカウント）とバックアップ先（管理アカウント）の両方に CMK が必要になります。

• キー管理者 (STEP3): 万が一のロックアウトを防ぐため、AdministratorAccess を持つロールを指定。
• キーユーザー (STEP4):
  • 自アカウント側の CMK：AWS Backup のサービスロール（AWSBackupDefaultServiceRole）が使えるように設定。
  • 管理アカウント側の CMK：共有設定の「他のAWSアカウント」に、バックアップ元の 12 桁のアカウント ID を追加する。

運用を支える「命名規約」の決定

AWS Backup のリソース名には 50文字制限 があります。クラスタ名が長い場合を考慮し、以下の規約を採用しました。

Lambda による 2 段階コピーの自動化

Lambda (EventBridgeトリガー) で start_copy_job を発行します。状態（State: COMPLETED）と、暗号化キーの種類を判別してジョブを出し分けます。

• 1段階目（ローカルでの CMK 化）
  • コピー元：aws/rds 復元ポイント
  • コピー先：自アカウントの rds-backup-vault
  • 使用キー：自アカウントの CMK ARN
• 2段階目（クロスアカウント転送）
  • コピー元：1段階目で作成した CMK 復元ポイント
  • コピー先：管理アカウントの rds-backup-vault (ARN指定)
  • 使用キー：管理アカウントの CMK ARN

【超重要】よくあるエラー：IAMロールの権限不足

検証中、最も引っかかりやすいのが以下のエラーです。

【解決策】 エラー文面が no resource-based policy と言っているとおり、まず疑うべきは IAM ではなく KMS のキーポリシーです。

AWS Backup の公式ドキュメントでは、キーポリシーに最低限 kms:CreateGrant・kms:GenerateDataKey・kms:Decrypt が必要とされています。

とくに kms:CreateGrant は、公式が次のように条件付きで付ける例を示しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "KmsCreateGrantPermissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::[アカウントID]:root"
            },
            "Action": [
                "kms:CreateGrant"
            ],
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "kms:EncryptionContextKeys": "aws:backup:backup-vault"
                },
                "Bool": {
                    "kms:GrantIsForAWSResource": true
                },
                "StringLike": {
                    "kms:ViaService": "backup.*.amazonaws.com"
                }
            }
        }
    ]
}

kms:ViaService と kms:GrantIsForAWSResource で AWS Backup 経由の呼び出しに限定しているので、素の kms:CreateGrant 全開放より安全です。

そのうえで、コピーを実行する IAM ロール（AWSBackupDefaultServiceRole など）側にも同じ権限を持たせます。

キーポリシーと IAM ポリシーは「両方そろって初めて許可される」と考えるのが正解です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowKMSForBackupCopy",
            "Effect": "Allow",
            "Action": [
                "kms:CreateGrant",
                "kms:Decrypt",
                "kms:Encrypt",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "[使用する CMK の ARN]"
        }
    ]
}

管理アカウント側の「受け皿」設定

管理アカウントの Backup Vault には、外部からのコピーを許可するポリシーを忘れずに設定します。

これはコピー先の vault に付けるリソースベースポリシーです。

{
    "Sid": "AllowCopyFromOtherAccounts",
    "Effect": "Allow",
    "Principal": { "AWS": ["arn:aws:iam::[アカウントA]:root", "..."] },
    "Action": "backup:CopyIntoBackupVault",
    "Resource": "*"
}

見落としやすい「コピー元」側の IAM 権限

受け皿さえ作れば動くと思いがちですが、コピー元アカウントの IAM ロールにも 2 つの権限が必要です。

• backup:CopyFromBackupVault：コピー元の復元ポイントを読み出す許可。
• backup:CopyIntoBackupVault：コピー先の vault へ書き込む許可。

ポイントは 2 つ目で、backup:CopyIntoBackupVault はコピー先 vault のリソースベースポリシーと、コピー元ロールのアイデンティティベースポリシーの両方に必要です。

クロスアカウントの呼び出しなので、片方だけでは通りません。

AWS マネージドポリシーの AWSBackupServiceRolePolicyForBackup には両方含まれているので、カスタムロールを自作している場合だけ気をつければ大丈夫です。

まとめ

• RDS/Aurora は 2段階コピー必須: aws/rds キーのままでは別アカウントに飛べない。
• 権限管理: エラーが出たら、IAM ロール側に kms:CreateGrant の権限が正しく付与されているか疑う。
• 命名規約: 50文字制限を逆算して rds- プレフィックスを活用する。

参考(出典)

• Creating backup copies across AWS accounts(AWS Backup)
• Encryption for backups in AWS Backup
• Default key policy(AWS KMS)

saratoga

フリーランスエンジニア

XYouTube

仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。