Aurora の クラスター復元時、AssociatedRoles指定でIAMロールを紐付けてみた

はじめに

AWS CLI v2.36.2 で、Aurora のクラスター作成・復元系 API に AssociatedRoles パラメータが追加されました。対象は CreateDBCluster、RestoreDBClusterFromSnapshot、RestoreDBClusterToPointInTime、RestoreDBClusterFromS3 の4つです。

2.36.2
api-change:rds: Adds the AssociatedRoles parameter to CreateDBCluster, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, and RestoreDBClusterFromS3, letting customers associate IAM roles with an Aurora DB cluster at create or restore time instead of calling AddRoleToDBCluster afterward.
https://github.com/aws/aws-cli/blob/v2/CHANGELOG.rst

このパラメータを使うと、新規作成・スナップショット復元・PITR いずれの場面でも IAM ロールを永続的に紐付けられるため、従来必要だった AddRoleToDBCluster の別途実行が不要になります。

本記事では4つの API のうち RestoreDBClusterFromS3 を検証対象としました。他の3 API には S3 インポート用の一時ロール指定がなく、一時ロールと永続ロールの共存を検証できるのはこの API のみです。

• --s3-ingestion-role-arn: リストア処理中に S3 からバックアップを読み取るための一時的なロール指定です。クラスターの AssociatedRoles には残りません。
• --associated-roles: クラスターに永続的に残るロール指定です（AssociatedRoles に登録される）。

検証内容

検証環境

今回は EC2 上の MySQL から Percona XtraBackup で取得したバックアップを S3 にアップロードし、それをソースとして利用しました。

restore-db-cluster-from-s3 の実行

--s3-ingestion-role-arn と --associated-roles を同時に指定してクラスターを復元します。--associated-roles は RoleArn をキーに持つオブジェクトの JSON 配列で指定します。

aws rds restore-db-cluster-from-s3 \
  --db-cluster-identifier test-aurora-from-s3-0719 \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.12.0 \
  --master-username admin \
  --master-user-password '***' \
  --db-subnet-group-name test-dbsubnet-0719 \
  --s3-bucket-name test-aurora-xtrabackup-20260719 \
  --s3-prefix backup/ \
  --s3-ingestion-role-arn arn:aws:iam::123456789012:role/test-ingestion-role-0719 \
  --source-engine mysql \
  --source-engine-version 8.0.40 \
  --associated-roles '[{"RoleArn":"arn:aws:iam::123456789012:role/test-associated-role-0719"}]' \
  --region ap-northeast-1

--source-engine-version は Aurora が受理可能な最大値 8.0.40 を指定しています（実際のソース MySQL は 8.0.46 のため、後述の migration-failed の原因になります）。

クラスター作成とロール紐付けは成功しましたが、データ移行は後述のバージョン不整合により migration-failed となりました。

AssociatedRoles が ACTIVE になることの確認

クラスター作成後、describe-db-clusters で AssociatedRoles を確認しました。

"AssociatedRoles": [
    {
        "RoleArn": "arn:aws:iam::123456789012:role/test-associated-role-0719",
        "Status": "ACTIVE"
    }
]

--associated-roles で指定したロールが、クラスター作成時点で ACTIVE ステータスとして紐付いていました。

CloudTrail で API コールの中身を確認

CloudTrail から RestoreDBClusterFromS3 の requestParameters を抜粋します。

{
  "s3IngestionRoleArn": "arn:aws:iam::123456789012:role/test-ingestion-role-0719",
  "associatedRoles": [
    {
      "roleArn": "arn:aws:iam::123456789012:role/test-associated-role-0719"
    }
  ]
}

s3IngestionRoleArn と associatedRoles が同一の API コール内に両方含まれています。両者は排他ではなく、S3 インポート用の一時ロールと永続紐付けロールを同時に指定できました。

RestoreDBClusterFromS3 実行後、クラスターが available になるまでの10分間の管理イベントを確認したところ、AddRoleToDBCluster イベントは記録されていませんでした。ロールの紐付けは RestoreDBClusterFromS3 のコール内で完結しています。

migration-failed でもロール紐付けは成功する

データ移行はバージョン不整合で migration-failed となりましたが、ロール紐付けのステータスに影響はありませんでした。

今回のリストアでは、MySQL 8.0.46 で取得したバックアップを Aurora MySQL 3.12.0（MySQL 8.0.44 互換）へ復元しました。ソースバージョン（8.0.46）が Aurora 互換バージョン（8.0.44）より新しいため、migration-failed となっています。

まとめ

RestoreDBClusterFromS3 の --s3-ingestion-role-arn は、リストア中に S3 上のバックアップを読み取るための一時的なロールです。一方、今回追加された --associated-roles は、Aurora クラスターに IAM ロールを永続的に関連付けるためのパラメータであり、作成・復元後に AddRoleToDBCluster で行っていた関連付けをリクエスト時に指定できます。

今回の検証では、両方のロールを同時に指定できることを確認しました。Aurora MySQL から Lambda 関数を呼び出す構成などでは、クラスターの作成・復元直後から必要な IAM ロールが関連付いた状態で利用できます。