【TypeScript版】CognitoのIDトークンのJWT検証
saratogax
サラトガ牧場
RDS(Aurora)のバックアップを別アカウントに集約して管理したい場合、以下の2つの壁にぶつかります。
aws/rds(AWS管理キー)で暗号化されたスナップショットは、そのままでは別アカウントにコピーできない。(ここが最大のハマりポイントです!)本記事では、この「2段階のコピー処理」を Lambda で自動化しつつ、運用しやすい命名規約で管理する方法と、よくある権限エラーの解決策を解説します。
RDS/Aurora の場合、クロスアカウントコピーを成功させるには以下のステップを踏む必要があります。
aws/rds キーでバックアップが作成される。この構成では、バックアップ元(自アカウント)とバックアップ先(管理アカウント)の両方に CMK が必要になります。
AdministratorAccess を持つロールを指定。AWSBackupDefaultServiceRole)が使えるように設定。AWS Backup のリソース名には 50文字制限 があります。クラスタ名が長い場合を考慮し、以下の規約を採用しました。
| リソース | 命名テンプレート | 理由 |
|---|---|---|
| Backup Vault | rds-backup-vault | 全アカウント共通でシンプルに管理するため。 |
| Backup Plan | rds-plan-{クラスタ名} | どのクラスタのバックアップ計画か一目で判別するため。 |
| Backup Rule | rds-backup-rule-{クラスタ名} | Planに紐づくスケジュールやライフサイクルルールを明確にするため。 |
| Backup Resource | rds-backup-resource-{クラスタ名} | resource をフルスペルで残し視認性を確保しつつ、50文字制限をクリアするため。 |

Lambda (EventBridgeトリガー) で start_copy_job を発行します。状態(State: COMPLETED)と、暗号化キーの種類を判別してジョブを出し分けます。
aws/rds 復元ポイントrds-backup-vaultrds-backup-vault (ARN指定)検証中、最も引っかかりやすいのが以下のエラーです。
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": "*"
}aws/rds キーのままでは別アカウントに飛べない。kms:CreateGrant の権限が正しく付与されているか疑う。rds- プレフィックスを活用する。