2022/12/21 最新の情報に更新しました。また一部の文章を修正・更新しています。
こんにちは！
BFT名古屋支店の佐野です。
前回の記事ではEC2インスタンスを自動起動および自動停止させる方法についてお送りしましたが、今回はAmazon Auroraで構築したDBクラスターを自動起動・自動停止させる方法についてお話しします。
AuroraもEC2インスタンスと同じく、起動している間に料金が発生し続ける課金方式であり、かつその料金はEC2と比べたらずっと割高！
しかもAurora DBクラスターは一度停止しても、7日後に自動的に立ち上がってしまうという仕様があります。
開発環境に置いておきたくて、基本的に停止しているAurora。それがこの仕様によって知らぬ間に起動していて、気づいたら料金がすごいことに…というのは割と見られる話です。
このためAuroraでは、自動起動・自動停止を実装してスケジュールに則った稼働時間とすることは、EC2以上に重要であると言えます。
その実装方法の流れは、前回お送りしたこちらの記事とほぼ同じ。
対応するIAMロールを作り、そのIAMロールをEventBridgeに与え、起動あるいは停止のイベントを実行させるだけです。
EC2の時と大きく違うのは、ポリシーをユーザーが用意するところ。
関わるAWSサービスのフルアクセスポリシーを全て与えてもよいのですが、セキュリティの観点からある程度権限を絞ったものを作っていきます。
はじめに：Aurora DBクラスターの自動起動・自動停止の前提条件
今回のAuroraの自動起動・自動停止でも、EC2での場合と同じくSystem ManagerとEventBridgeを使用していきます。
ほぼ前記事の繰り返しとなりますが、Auroraの状態を制御するのに必要なものは以下の３つです。
- EventBridgeからSystems Managerを使ってRDSを操作する権限を設定したIAMポリシー
- 1.で作成したポリシーを含んだIAMロール
- 指定時刻にSystems Managerの機能を動かすためのEventBridgeルール
またプライベートサブネット内にあるAurora DBクラスターに関しても、やはりSystems Managerエンドポイントは不要になります。
Auroraの自動起動・自動停止を行なえるポリシーを作成
まずは今回作成するIAMロールに付与する専用のポリシーを作成していきます。
内容としては、以下のサービスとアクションに対応する権限を付与していくことになります。
- RDS
- DescribeDBCluster
- StartDBCluster
- StopDBCluster
- IAM
- PassRole
- SNS
- アクセスレベル“書き込み”のアクション(19種)
- System Manager
- すべての Systems Manager アクション (ssm:*)
ではこれらの権限を持つポリシーを作成していきましょう。
まずはIAMコンソールに入り、左ペインからポリシーを選択、ポリシー一覧画面右側の「ポリシーを作成」を選択します。
ポリシーの作成画面に入ったら、ビジュアルエディタで先に挙げた権限を設定していきます。
サービスの欄に“RDS”と入力して検索をかけ、出てきた〈RDS〉を選択します。
次に許可するアクションを設定していきます。 アクションの検索欄に各アクション名を入力することで候補が表示されるため、RDSの場合はDescribeDBCluster、StartDBCluster、StopDBClusterそれぞれを入力して、そのチェックボックスにチェックを入れていきましょう。 例えばDescribeDBClusterの場合は以下のようになります。
RDSに必要なアクション３つにチェックを入れたら、アクションの項目が赤枠図のようになるかと思います。
こののち、リソース項目で〈指定〉ラジオボタンを選択し、cluster項目の右側にある〈このアカウント内のいずれか〉にチェックを入れます。
これでRDS、つまりAuroraの権限は設定できましたので、「さらにアクセス許可を追加する」を選択して新たなアクション設定枠を出していきます。
次はIAMのアクション権限を設定します。
RDSの時と同じように、サービスとアクション、リソースの設定を行ないます。
リソースもRDSと同じように〈指定〉ラジオボタンを選択し、role項目右側の〈このアカウント内のいずれか〉にチェックを入れましょう。
正しく設定できれば以下のような表示となりますので、設定できたらまた「さらにアクセス許可を追加する」を選択して新たなアクション設定枠を出しましょう。
次はSNSですが、こちらは先のRDSやIAMとは少し設定方法が異なります。
サービスの設定までは同様に“SNS”と検索をかけて、出てきた〈SNS〉を選択しますが、アクションではアクセスレベル配下の〈書き込み〉にチェックを入れます。
これをチェックすることで、以下画像にあるような19の項目にチェックが入ります。
（〈書き込み〉左側の三角マークをクリックして展開すると見えるようになります）
その後はまたリソースの〈指定〉ラジオボタンを選択し、topic項目右側の〈このアカウント内のいずれか〉にチェックを入れます。
以下のような設定にできたら、また「さらにアクセス許可を追加する」を選択して新たなアクション設定枠を出します。
最後にSystems Managerのアクション権限ですが、まずは以下の画像の通り、サービスを設定後、手動のアクション配下の〈すべてのSystems Manager アクション (ssm.*)〉にチェックを入れます。
そしてリソースでは〈すべてのリソース〉を選択します。
ここで他と同じように〈指定〉としてしまうと、Systems Managerの権限が足りず、起動・停止を行なう処理にたどり着けなくなってしまうためです。
筆者はこの設定を誤り、結構な時間ハマってしまいました…
ここまで設定し終えたら、下部の「次のステップ：タブ」を選択して次の画面に進みます。
「タグを追加(オプション)」画面では、任意のタグを追加することができます。
筆者は以下のようにNameタグを設定し、値を“testclusterstopstart”としていますが、こちらは必須ではありません。
タグの設定が不要な場合はそのまま「次のステップ：確認」を選択して次に進みます。
「ポリシーの確認」画面となったら、〈名前〉に任意のポリシー名を入力します。
今回の例では、“testclusterstopstart”としました。
そして概要欄で、以下画像のように権限を設定したサービスが並んでいることを確認したら、「ポリシーの作成」を選択します。
この後、ポリシーの一覧画面に作成したポリシーが表示されていれば、ポリシーの作成は完了となります。
EventBridge用のIAMロールを作成
ここからは以前の記事とほぼ同じ流れです。
「はじめに」の2.で述べた、先までに作成したポリシーを含むIAMロールを作成していきます。
まずは例によってIAMコンソールの左ペインからロールを選び、さらにロールの一覧画面右側の「ロールの作成」を選びます。
「信頼されたエンティティを選択」画面となったら、〈他のAWSサービスのユースケース〉リストからSystems Managerを選びます。
その後、リストの下に出てくる〈Systems Manager〉ラジオボタンを選択し、「次へ」をクリックして進みます。
ここまでは前記事と同じです。
「許可を追加」画面となったら、このIAMロールに割り当てるポリシー、つまり先に作成したポリシーを選択していきます。
作成したポリシーの名前もしくはその一部を検索欄に入力してフィルタをかけ、作成したポリシーのチェックボックスにチェックを入れます。
入れたら「次へ」をクリックして進みましょう。
「名前、確認、および作成」画面となったら、〈ロール名〉に作成するロールの任意の名前を入力します。
今回の例では“testclusterstopstart_role”としています。
その後、「ロールを作成」クリックします。
ロールの一覧画面に戻り、「ロール〈ロール名〉が作成されました」と表示されれば、ロールの作成は完了です。
ただ例によって、作成したロールはSystems Managerにしか関連付けられないため、EventBridgeが利用できるよう信頼関係を編集していきます。
EventBridge用のIAMロールの信頼関係を変更
前記事で作成したロールと同じように、今回も信頼関係の変更を行なっていきます。
仔細については、前記事にある同名の項目をご覧ください。
手順としては、ロールの一覧画面から作成したIAMロールを選択し、以下のように信頼関係タブを選択、
その後「信頼ポリシーを編集」を選択します。
「信頼ポリシーの編集」画面となり、json形式でポリシーの信頼関係を編集することができます。
ここで内容が以下の通りになるように変更しましょう。
（具体的には"Service"の部分を編集します）
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com", "ssm.amazonaws.com", "events.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }
変更したら「ポリシーの変更」をクリックして変更を適用します。
これでAurora DBクラスターの起動・停止が可能なEventBridge用IAMロールができあがりました。
次はEventBridgeで自動停止、自動起動のルールを作成します。
Aurora DBクラスターを指定時刻に自動起動（自動停止）するルールを作成
EventBridgeコンソールに入り、左ペインより「ルール」を選択します。
そしてルールの一覧画面となったら、「ルールを作成」を選択します。
「ルールの詳細」項目が出たら、まず作成するルールの名前を設定します。
画像の例では“testclusterstopstart_event”としています。
〈イベントバス〉はdefaultのままとし、〈ルールタイプ〉で「スケジュール」を選択します。
その後「続行してルールを作成する」を選択します。
（EventBridge Schedulerを選んでしまわないように注意）
次に「スケジュールパターン」項目で、作成するイベントをいつ発生するかを設定します。
今回は例として日本標準時(JST)で毎日9:00に起動するスケジュールを組んでいきます。
〈スケジュールパターン〉で「特定の時刻（毎月第1月曜日の午前8時(IPST)など）に実行されるきめ細かいスケジュール。」を選択します。
Cron式の各入力欄で、分、時間は0を、日付は?を、月と曜日と年は*を入力します。
そして〈以後 10 回のトリガー日〉リストをローカルタイムゾーンにし、発生日が意図した通りになっていることを確認します。例えば2022/12/10に以上の設定を行なった場合、以下の画像の通りになるはずです。
なおCron式の法則については以下URLを参照ください。
最後に「ターゲット」項目では、イベントで起こす処理の内容と、その処理の対象、そして使用するIAMロールを設定します。
〈ターゲットタイプ〉で「AWS のサービス」を選択し、〈ターゲットを選択〉のリストから Systems Manager オートメーションを選択します。そして〈ドキュメント〉のリストからAWS-StartStopAuroraClusterを選択します。
このAWS-StartStopAuroraClusterというのが、対象のDBを起動または停止させる処理を行ないます。
EC2の場合は起動と停止でドキュメントが別でしたが、Aurora DBクラスターの起動と停止はどちらもAWS-StartStopAuroraClusterだけで行なえます。
そして〈ClusterName〉で起動もしくは停止させる対象のDBクラスターのDB識別子を指定し、〈Action〉で起動処理を作る場合は“Start”を、停止処理を作る場合は“Stop”を指定します。
今回の例では起動処理を行なう“Start”を指定しています。
最後に〈実行ロール〉で「既存のロールを使用」を選択して、リストボックスから先ほど作成したEvent Bridge用のIAMロールを選択します。
すべて設定したら最下部の「次へ」を押下します。
その後、「タグ」項目で必要ならタグを追加し、「次へ」を押下します。
すると「レビューと作成」画面に入るため、設定した内容に間違いがないか確認して「ルールの作成」を押下すると、ルールが作成されます。
そしてルール一覧にここで作成したルールが表示されていれば、無事作成完了になります。
動作確認
あとは指定した時刻にイベントが実行され、問題なく起動・停止が行われることを確認するだけになります。
EC2の時と同じく、実際にイベントによって起動したかどうかは、CloudTrailのイベント履歴で見ることができます。
以下画面のStartAutomationExecutionというイベントが、今回作成したイベントが実行された時に発生するものです。
またその後にDBクラスターが起動するイベントもしくは停止するイベントが発生するので、これを目印に動作確認を行なってください。
以下はDBクラスターの起動時のイベントであるStartDBClusterがStartAutomationExecutionの後に発生している例になります。
さいごに
この自動起動・自動停止を実装することで、EC2以上にコストの発生を抑えることができるでしょう。
データベースであるが故、本番環境での出番はないかもしれませんが、開発環境や検証環境で利用時間以外は絶対に停止しておきたい！ という場合にはとても有効です。
ということで、今回はここまで。 また次回の記事でお会いしましょう。
