Amazon Auroraのクロスアカウントクローン作成を自動化する

2021.06.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは。大阪オフィスの林です。

Amazon Auroraでクロスアカウントクローン作成の自動化を検証する機会がありましたので手順をまとめておきます。ただし、自動化については現状標準機能では対応していないのでLambdaとEventBridgeを組み合わせてスケジュール実行させることで実現させています。下記がザックリやることイメージです。

なお、Auroraクローン作成はAWSリージョン間で作成することができなかったり、幾つか制約もありますので他の制約やクローン作成についての公式ドキュメントは下記を参照頂ければと思います。

Auroraのクローンについては下記ブログも併せて参照頂ければより理解も深めて頂けるかと思います。

やってみた

事前準備(RAMの設定)

まずはAWSアカウント間でAuroraDBクラスターを共有する必要がありますので、ソースとなるAuroraDBクラスターを保有するAWSアカウントのマネージメントコンソールにログインし、AWS Resource Access Manager(以下、RAMという)からAuroraDBクラスターのリソースを共有していきます。
RAMのダッシュボードから「自分が共有」-「リソースの共有」-「リソースの共有の作成」を選択します。

任意の名前を入力して「リソースタイプ」で「Aurora DB クラスター」を選択し、共有するクラスターのDB識別子(画像は「database-1」)を選択します。

プリンシパルで「外部アカウントの許可」にチェックが入っている状態でリソース共有する先のAWSアカウントID(12桁)を入力し選択します。その後「リソース共有の作成」を選択します。

共有元からリソース共有する設定が完了しました。

次にリソース共有先のAWSマネージメントコンソールにログインし、RAMのダッシュボードから「自分と共有」-「リソースの共有」を選択します。共有元から正しく共有されていれば「1 招待」というアイコンが付きます。

本手順はじめのリソース共有の作成で指定した共有名を選択します。

「リソースの共有を承認」を選択します。

確認のウィンドウで「OK」を選択します。

承認後「共有リソース」に共有されているリソースが表示されます。

再度、共有元のAWSマネージメントコンソールにログインし、RAMのダッシュボードから「共有リソース」および「共有プリンシパル」のステータスがAssociatedとなっていることを確認します。

以上で事前準備は完了です。次工程以降でクローンを作成するLambdaの作成およびEventBridgeでのトリガーの設定をしていきます。

クローン作成用Lambdaの準備

以下のコードをLambdaで準備します。本検証ではPython3.8を使用しています。 コード内SourceDBClusterIdentifierにはクローン作成元のAurora DB クラスターのARNを指定します。※本手順では最低限のパラメータで検証しているので必要に応じてリファレンスを参照しながらパラメータを付け足してください。

import boto3
client = boto3.client('rds')

def lambda_handler(event, context):
    response = client.restore_db_cluster_to_point_in_time(
        DBClusterIdentifier='test-clone1', #任意のクラスタ名を指定
        RestoreType='copy-on-write', 
        SourceDBClusterIdentifier="arn:aws:rds:ap-northeast-1:123456789012:cluster:database-1", #ソースのクラスタのARN指定
        UseLatestRestorableTime= True
),
    response = client.create_db_instance(
        DBClusterIdentifier='test-clone1', #クローン作成したクラスタ名を指定
        Engine='aurora-mysql', #ソースと同じエンジンを指定
        DBInstanceIdentifier='instance-1', #任意のインスタンス名を指定
        DBInstanceClass='db.t3.small' #任意のインスタンスサイズを指定
),
    response = client.create_db_instance(
        DBClusterIdentifier='test-clone1', #クローン作成したクラスタ名を指定
        Engine='aurora-mysql', #ソースと同じエンジンを指定
        DBInstanceIdentifier='instance-2', #任意のインスタンス名を指定
        DBInstanceClass='db.t3.small' #任意のインスタンスサイズを指定
)

Lambdaに付与されているロールにRDSの操作権限を付与しておきます。
「設定」-「アクセス権」から割り当てられているロールを選択します。

本検証ではAmazonRDSFullAccessのポリシーをアタッチします。

次にトリガーを設定していきます。「設定」-「トリガー」-「トリガーを追加」を選択します。

トリガーのサービスに「EventBridge」を選択して任意の名前をスケジュールを設定し「追加」を選択します。

トリガーが追加されました。

設定したスケジュールになるとクローンが作成されました。

下記コマンドの実行結果で"CrossAccountClone": true,となっていることを確認し本当にクローンされたクラスターなのか念のため確認しておきます。

[cloudshell-user@ip-10-0-173-94 ~]$ aws rds describe-db-clusters --db-cluster-identifier test-clone1
{
    "DBClusters": [
        {
            ~(省略)~
            "CrossAccountClone": true,
            ~(省略)~
        }
    ]
}

クローン削除用Lambdaの準備

以下のコードをLambdaで準備します。本検証ではPython3.8を使用しています。
本手順内「クローン作成用Lambdaの準備」と同じ手順でLambdaに付与されているロールにRDSの操作権限を付与し、削除も自動化する場合はトリガーを設定してください。 ※クローン作成を定時実行する場合、同名のAurora DB クラスターが存在しているとクローンの作成に失敗しますので、作業が終わって不要になったクローン環境は削除しておいてください。

import boto3
client = boto3.client('rds')

def lambda_handler(event, context):
    response = client.delete_db_instance(
        DBInstanceIdentifier='instance-2', #インスタンス名
        SkipFinalSnapshot=True
),
    response = client.delete_db_instance(
        DBInstanceIdentifier='instance-1', #インスタンス名
        SkipFinalSnapshot=True
),
    response = client.delete_db_cluster(
        DBClusterIdentifier='test-clone1', #作成したクラスタ名
        SkipFinalSnapshot=True
)

まとめ

運用業務において「決まったタイミングでAuroraDBのクローンが欲しい!」という方の参考になれば幸いです!

以上、大阪オフィスの林がお送りしました!