次にターゲットの選択を行います。
「すべての API」を選択し、「RDS」で検索をかけます。
「Amazon RDS」を選択し、次はrebootで検索をかけます。
今回はDBインスタンスの再起動になるので「RebootDBInstance」を選択しました。
(「RebootDBCluster」もありますが、aurora-postgresqlではサポートしていないとの事… )
(「RebootDBCluster」もありますが、aurora-postgresqlではサポートしていないとの事… )
以下のように対象DB名を記載しましょう。
スケジュール完了後のアクションではNONE、再試行ポリシーとデッドレターキュー (DLQ)はなしとしています。
最後にこのイベントルールを動作させる為にIAMロールが必要となります。
まずはIAMポリシーを作成しましょう。
今回はクラスターの再起動を行うので以下で設定しました。
1{2 "Version": "2012-10-17",3 "Statement": [4 {5 "Sid": "VisualEditor0",6 "Effect": "Allow",7 "Action": "rds:RebootDBInstance",8 "Resource": "*"9 }10 ]11}次にIAMロールを作成します。
EventBridgeで実行できるように信頼されたエンティティで以下のように設定しておきましょう。
エンティティを設定したら、上で作成したポリシー(RDS再起動する権限のやつ)も付与しておきます。
1{2 "Version": "2012-10-17",3 "Statement": [4 {5 "Effect": "Allow",6 "Principal": {7 "Service": "scheduler.amazonaws.com"8 },9 "Action": "sts:AssumeRole"10 }11 ]12}上記、作成したロールを「アクセス許可」で指定し、設定を最終確認後、スケジュールを作成してください。
実際に動作したかはauroraの「ログとイベント」より確認できます。
■Auroraの再起動について
ちなみに、ライターとリーダーで構成されているAuroraの再起動は以下のように動作します。
・ライターを再起動した場合
ライターとリーダーが再起動される
・リーダーを再起動した場合
再起動されるのは選択したリーダーのみ
参考:
ライター DB インスタンスを再起動すると、クラスター内の各リーダー DB インスタンスの再起動も開始されます。
これにより、クラスター全体のパラメータの変更がすべての DB インスタンスに同時に適用されます。
ただし、すべての DB インスタンスの再起動により、クラスターのための短時間の停止が発生します。
リーダー DB インスタンスは、ライター DB インスタンスの再起動が完了して利用可能になるまで利用できません。
■最後に
EventBridge Schedulerは導入が簡単であり、様々な動作をスケジュールできます。
もちろんRDS再起動以外でもターゲットAPIは豊富にありますので、色んな使い方を模索してみたいと思います。