技術系(Tips)
PR

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

saratogax
記事内に商品プロモーションを含む場合があります

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

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

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

構成図(正しい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文字制限 があります。クラスタ名が長い場合を考慮し、以下の規約を採用しました。

リソース命名テンプレート理由
Backup Vaultrds-backup-vault全アカウント共通でシンプルに管理するため。
Backup Planrds-plan-{クラスタ名}どのクラスタのバックアップ計画か一目で判別するため。
Backup Rulerds-backup-rule-{クラスタ名}Planに紐づくスケジュールやライフサイクルルールを明確にするため。
Backup Resourcerds-backup-resource-{クラスタ名}resource をフルスペルで残し視認性を確保しつつ、50文字制限をクリアするため。
※表は横スクロールできます

rds-backup-resource- (20文字) + クラスタ名 が 50 文字を超えないよう設計するのがコツです。

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

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

AWS BackupでRDS(Aurora)を別アカウントへ集約管理する:KMS再暗号化(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ロールの権限不足

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

because no resource-based policy allows the kms:CreateGrant action

【解決策】 KMS のキーポリシーをいじるよりも、コピーを実行する IAM ロール(AWSBackupDefaultServiceRole など)に対して、直接インラインポリシーで以下の権限を付与するのが最も確実な解決策です。

{
    "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 には、外部からのコピーを許可するポリシーを忘れずに設定します。

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

まとめ

  • RDS/Aurora は 2段階コピー必須: aws/rds キーのままでは別アカウントに飛べない。
  • 権限管理: エラーが出たら、IAM ロール側に kms:CreateGrant の権限が正しく付与されているか疑う。
  • 命名規約: 50文字制限を逆算して rds- プレフィックスを活用する。
ABOUT ME
saratoga
saratoga
フリーランスエンジニア
仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。
記事URLをコピーしました