【実録】Auroraクラスタの料金が急増 → EventBridgeで夜間自動停止してコスト削減した話
初めに
業務で使用している客先の環境からBilling and Cost Management を参照したところ、RDSの料金がかなり跳ね上がってしまっていました。
そこで、使用しない時間帯でRDSの停止と起動の設定をしようと思います。
結論
いきなり結論を書きますが、Event Bridge のスケジュールから設定することが正解でした。
冒頭に失敗してしまった出来事を書いている関係で若干長くなっているのでご了承ください。
やることリスト
-
EventBridgeから、RDS停止と起動のルールを新規作成 -
RDS停止起動用のIAMロールとポリシーを作成
IAMロールとポリシーを作成
Classmethodさんが素晴らしい記事を公開されておりましたので、こちらを参考にして作成しましたので手順は割愛させていただきます。
IAMポリシーについては、作成当初下記のように作成していました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"rds:StartDBCluster",
"rds:StopDBCluster"
],
"Resource": "arn:aws:rds:ap-northeast-1:アカウント番号:cluster:RDSクラスター"
}
]
}
調べてみましたところ、どうやらこれだけでは不足しているみたいでした。
EventBridge で Aurora DB インスタンスを停止や起動を実行するには、
rds:DescribeDBClusters ・rds:StopDBCluster ・rds:StartDBCluster
の3セットが必要みたいです。
DescribeDBClusters は、対象のクラスター情報を取得するために必要です。
これがないと、EventBridgeが対象のクラスターを特定できず、実行時にエラーになります。
それぞれの役割についてはAWS公式ドキュメントを参照ください。
また、IAMポリシーに Systems Manager（SSM）関連の権限が不足していたため、Automationドキュメントの実行に失敗する可能性が高いため権限を与える必要があります。
AWS Systems Manager Automation 実行に必要なIAM権限の詳細はこちら：
最終的に作成したIAMポリシーは以下のようになりました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"rds:StartDBCluster",
"rds:StopDBCluster",
"rds:DescribeDBClusters"
],
"Resource": "arn:aws:rds:ap-northeast-1:アカウント番号:cluster:RDSクラスター"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"ssm:*"
],
"Resource": "*"
}
]
}
※ ssm:"*" は広範囲な権限を許可するため、必要なアクションに絞ることが推奨されます。
本件は検証環境のため、Resourceは"*"で指定しています。
推奨されるSSM権限（最小構成）は、以下が望ましいとされています。
{
"Effect": "Allow",
"Action": [
"ssm:StartAutomationExecution",
"ssm:GetAutomationExecution",
"ssm:DescribeAutomationExecutions",
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "*"
}
| アクション名 | 役割・説明 |
|---|---|
| ssm:StartAutomationExecution | Automationドキュメントを実行するための権限。EventBridgeからAutomationを起動する際に必須。 |
| ssm:GetAutomationExecution | 実行されたAutomationの詳細情報（ステータスや出力など）を取得するための権限。 |
| ssm:DescribeAutomationExecutions | 過去に実行されたAutomationの一覧を取得するための権限。監視やトラブルシュートに使用。 |
| ssm:GetDocument | Automationドキュメントの内容を取得するための権限。ドキュメントのパラメータや構成を確認する際に必要。 |
| ssm:DescribeDocument | Automationドキュメントのメタ情報（名前、タイプ、バージョンなど）を取得するための権限。 |
EventBridgeルール作成
(2025年7月時点の画面構成です)
-
Amazon EventBridge>ルールへ遷移 - ルールの画面から
ルールを作成を押下
- ルールの詳細から、名前を定義(説明 - オプションは任意)
- イベントバスはdefault
- ルールタイプはスケジュールを選択して「続行してルールを作成する」を押下
-
スケジュールパターンから「特定の時刻～」を選択した状態でcron式で停止(または起動)させたい日時を設定
※cron式の詳細は下記を参照
https://qiita.com/koheki/items/ab4e86e448cee259aba3 -
ターゲットを選択の項目で、以下のように選択する(変更が必要な箇所のみ記載)
- ターゲットタイプ：AWS のサービス
- ターゲットを選択：System Manager オートメーション
- ドキュメント：AWS-StartStopAuroraCluster
- ClusterName：停止・起動対象のRDSクラスター名
- Action - オプション：Start or Stop
- 実行ロール：既存のロールを使用
- ロール名：前段で作成したロールを指定
- タグの設定は任意で設定する
- 最後に全体を確認して問題無ければページ下部の作成を押下
停止起動確認
客先での出来事なのでスクショなどを公開することはできませんが、確認しましたところ夜間停止・朝方起動されていることを確認できました。
得ることができたこと
- イベント設定で自動停止・起動の設定手順が身についた
- IAMポリシーの設定に関する理解が深まった
翌日の確認
後日メトリクスでルールが適用されたか確認したところ、Auroraの停止すら実行されていませんでした。
EventBridgeルールが機能しなかった背景と原因
当初は、AWS EventBridge のルールを使って Aurora クラスターの起動・停止を自動化していましたが、期待通りに停止処理が実行されない問題が発生しました。
問題の内容
- 平日 23:00 に Aurora を停止するルールを設定していたが、実際には停止されていなかった
- CloudWatch メトリクスや Systems Manager Automation の実行履歴を確認しても、該当時間に処理が実行されていない
原因の特定
EventBridgeルールのスケジュールが UTC ベースで動作していた
- ルール作成時にローカルタイム（JST）で設定したつもりだったが、内部的には UTC で解釈されていた
- その結果、意図した時間にトリガーされていなかった可能性が高い
対応方針
これらの課題を踏まえ、より柔軟でタイムゾーン対応が可能な EventBridge Scheduler を使って、Aurora の起動・停止を再構築することにしました。
旧構成（EventBridgeルール）
- 起動：平日 08:00 JST
- 停止：平日 23:00 JST
-
ターゲット：Systems Manager Automation（
AWS-StartStopAuroraCluster） -
課題：
- UTCベースでのCron式管理が煩雑
- タイムゾーン指定不可
- 再試行やDLQの設定が柔軟でない
そこで、2022年にリリースされた EventBridge Scheduler を活用し、Aurora の起動・停止をより安定的に制御する構成に移行しました。
新構成（EventBridge Scheduler）
スケジュール設定（例：Aurora起動）
-
Cron式：
0 8 * * MON-FRI -
タイムゾーン：
Asia/Tokyo -
ターゲットAPI：
RDS_StartDBCluster
以下の設定を実施しました。
- Cron式で08:00に起動するように設定
- かつ、曜日は月曜日から金曜日までの平日設定
- ターゲットAPIは
Aurora RDS StartDBClusterを指定し、以下のようにクラスターのフィルターを指定する
startdbcluster
{
"DbClusterIdentifier": "RDSクラスター名"
}
スケジュール設定（例：Aurora停止）
-
Cron式：
0 23 * * MON-FRI -
タイムゾーン：
Asia/Tokyo -
ターゲットAPI：
RDS_StopDBCluster
起動設定と同じように、以下の設定を実施しました。
- Cron式で23:00に停止するように設定
- かつ、曜日は月曜日から金曜日までの平日設定(土日は起動させない)
- ターゲットAPIは
Aurora RDS StopDBClusterを指定し、以下のようにクラスターのフィルターを指定する
stopdbcluster
{
"DbClusterIdentifier": "RDSクラスター名"
}
見直し後のIAMロールのポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"rds:StartDBCluster",
"rds:StopDBCluster",
"rds:DescribeDBClusters"
],
"Resource": "arn:aws:rds:ap-northeast-1:アカウント番号:cluster:RDSクラスター名"
}
]
}
見直し後の信頼されたエンティティ（トラストポリシー）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "scheduler.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
再試行ポリシーとDLQ設定
- 再試行回数：185回(Max)
- 最大経過時間：1日（hour(s): 24, minute(s): 0）
- DLQ：未設定（必要に応じて設定可能）
移行時の注意点
EventBridgeルールはSchedulerの動作確認が完了するまで「無効化」して残しておくのが安全です。
最終的な構成のメリット
- JSTベースでのスケジュール管理が可能
- 柔軟な再試行・DLQ設定
- 将来的なスケジュール管理の一元化にも対応しやすい
翌日の再確認
スケジュールで組み直してAuroraのメトリクスを確認したところ、昨晩23:00で停止しており、8:00に起動していることを確認しました。
反省点
- EventBridgeのルールとスケジュールの違いやメリット・デメリットを比較せず対応してしまったため、対応に手戻りが生じてしまった
- 作業着手前には、まずは類似サービスなどを比較してしっかり選定することから始めていくようにする
まとめ
EventBridge Scheduler を使うことで、Aurora の起動・停止をより安定的かつ柔軟に制御できるようになりました。
既存のEventBridgeルールからの移行もスムーズに行えるため、同様の課題を抱えている方にはぜひおすすめしたい構成となっております。
【8/1追記】RDS使用量の減少率計算（6月 → 7月）
6月の使用量: $254.09
7月の使用量: $137.79
減少率の計算式
減少率（％） = ((254.09 - 137.79) / 254.09) × 100
= (116.30 / 254.09) × 100
≒ 45.77%
| 数値 | 意味 |
|---|---|
| 254.09 | 6月のRDS使用量（ドル）。比較の基準となる月のコスト。 |
| 137.79 | 7月のRDS使用量（ドル）。減少した後の月のコスト。 |
| 254.09 - 137.79 = 116.30 | 使用量の減少額（ドル）。6月と7月の差額。 |
| 116.30 / 254.09 | 減少額が6月の使用量に対してどれだけの割合かを示す。 |
| × 100 | 割合をパーセント（％）に変換するための操作。 |
| ≒ 45.77% | 最終的な減少率。6月と比べて7月の使用量が約45.77%減ったことを示す。 |
結果：RDSの使用量は約 45.77% 減少しました。
参考
Discussion