サーバー専門のフリーランスエンジニアです。クラウドサーバー環境を利用してWebサイト、ITシステムのサーバー全体構成やサーバー内部構成をデザインします。EC2インスタンスのバックアップのため、スナップショットを作成するLambda関数を紹介しました。今回はRDSインスタンスのMulti-AZの有効、無効(Muti-AZとSingle-AZ)を切り替えるLambda関数を紹介します。今回のLambda関数は、以下の記事で公開されていた関数を参考にさせていただきました。Developers.IOhttps://dev.classmethod.jp/cloud/note_when_use_waiter_of_rds_in_boto3/ユースケースLambda関数を紹介する前に、どういった場面でこの関数が必要となるかを考えてみます。RDSは、Multi-AZを有効にすることで、可用性が高くなります。万一RDSインスタンスに何らかの障害が発生した場合に、異なるアベイラビリティゾーンで起動しているスタンバイインスタンスにフェイルオーバーすることで、1分~3分程度のダウンタイムでRDBサーバーを自動復旧させることができます。AWSによるメンテナンスやアップグレード、インスタンスタイプの変更の際も、ダウンタイムはフェイルオーバーにかかる時間のみの短時間となります。便利な機能ですが、常に2つのインスタンスを起動していますから、RDSの料金がMulti-AZ無効(Single-AZ)のときの2倍となります。このため、Multi-AZを有効にする時間帯を限定することで、ある程度料金を削減することができます。夜間や休日はMulti-AZを無効(Single-AZ)とするような運用方法が考えられます。逆に「平日の障害発生時はサポート要員がいて人手で復旧できる(このとき、復旧に多少時間がかかってもよい、という前提)。平日営業時間帯はMulti-AZを無効(Single-AZ)夜間や休日はMulti-AZを有効という運用方法が考えられます。このような場合に今回のLambda関数を使うと、Multi-AZの有効無効を、曜日や時間を指定してスケジューリングできます。DBインスタンスのMulti-AZを無効(または有効)にする。DBインスタンスのステータスが「available」以外のときや、すでにMulti-AZが無効(または有効)となっているときは何もしない(ステータスが「available」以外のときは、DBインスタンス情報の変更ができない)。Multi-AZを無効、有効にする関数はそれぞれ別に作成する(変数で工夫してひとつにまとめてもよいでしょう)。対象となるDBインスタンス名は、Lambdaの環境変数で指定する。DBインスタンスと同じリージョンでLambda関数を作成します。Lambda関数の環境変数で以下を設定する。指定したRDSインスタンスのMulti-AZを有効にする。Lambda関数の環境変数で以下を設定する。EOF実行ロールLambda関数に付与するIAMロールのカスタムポリシーは以下のようにします。Logsのログ書き出しと、RDSインスタンスの情報取得、変更アクションを付与しています。対象とするRDSインスタンスは、Lambda関数の環境変数で指定します。<DBインスタンス名>基本設定メモリはデフォルトの128MBのままでOKです。Eventを指定して、スケジュールのルールを設定します。以下は「日本時間の月-金の22時」に関数を実行する設定例です。「スケジュール式」の時刻はUTCで指定することに注意します。Multi-AZの有効チェック設定ミスや、Lambda関数の実行エラーなど、何らかの原因で、必要なときにMulti-AZが有効になっていない可能性もゼロではありません。SNSで通知するLambda関数も用意してみました。ステータスが「available」以外のときも通知します。Multi-AZの有効無効を切り替えるLambda関数と同様に、対象となるDBインスタンス名は、Lambdaの環境変数で指定します。SNSトピックは、あらかじめRDSインスタンスと同じリージョンで作成し、通知先(SNSやWebhookなど)のサブスクリプションを設定しておきます。このときのSNSトピックのARN(arn:aws:sns:ap-northeast-1:~)はのちに必要となるので、メモしておきます。DBインスタンスと同じリージョンでLambda関数を作成します。指定したRDSインスタンスのMulti-AZが有効となっているかチェックする。有効になっていなければ、SNSでアラート通知する。