はじめに
みなさんこんにちは！
EC2インスタンスは便利ですが、ずっと動かしっぱなしにしていると意外とコストが積み上がります。
FinOpsの観点からも、開発・検証環境などで利用していないEC2インスタンスの停止はコスト最適化の基本です。
しかし、「平日の日中だけ動かしたい」「検証環境は夜間に止めたい」と思っても、手動運用だと漏れやすく結局回らなくなることが多いです。
そこで今回はEC2の起動停止を仕組みとして自動化する方法を検討しましたのでご紹介します。
本記事で紹介すること
- 検討した方法と概要
- その中でAWS公式ソリューションであるInstance Schedulerを採用した理由
本記事で紹介しないこと
- Instance Schedulerの詳細な実装方法
詳細はInstance Scheduler on AWSを確認ください。CloudFormationテンプレートが用意されていますので、簡単に実装できます。
候補
今回の候補は次の3つでした。
- Instance Scheduler：AWS公式ソリューションを使う方法
- EventBridgeスケジューラー：直接Stop/Start APIを呼ぶ方法
- EventBridge + SSM Automation（またはLambda）：スクリプトを作成しEventBridgeで呼ぶ方法
結論としては Instance Scheduler を採用しました。理由については後半のInstance Schedulerを採用した理由にて説明します。
各候補の特徴
各候補について簡単にまとめると以下のようになります。以降でそれぞれの特徴について説明します。
| # | 候補 | 向いているケース |
|---|---|---|
| 1 | Instance Scheduler | 複数アカウント/リージョン、大規模、スケジュール一元管理したい場合 |
| 2 | EventBridgeスケジューラー | 小規模・シンプルな要件、まず小さく始めたい場合 |
| 3 | EventBridge + SSM/Lambda | 前後処理や外部連携など、複雑な制御を行いたい場合 |
1. Instance Scheduler
AWS Solutionsの「Instance Scheduler on AWS」を利用する方式です。
特徴は以下の通りです。
- 特徴：任意のタグベースでスケジュールを一元管理。複数アカウント/リージョン対応。
- 向いているケース：組織全体で運用を統一したい、数百〜数千台規模のインスタンスが対象。
- メリット：CloudFormationテンプレートとして仕組みが整備済みのため導入が簡単。スケジュール対象をタグで判別するため設定がシンプル。
- 注意点：構成がやや複雑。DynamoDB/CloudFormation/Lambdaなどの構成が含まれる。EventBridgeが定期的にリソースを確認するため他の候補よりコストがかかる。
構成図は以下の通りです。リソースが多く複雑ですが、大きく①～③に分けられます。
それぞれ別々のCFnテンプレートを使ってリソースを作成することができます。
- ①スケジュール管理
新規リソースのDynamoDBへの登録、EventBridgeを使った既存リソースの確認を定期的に行う。 - ②スケジュール実行
③のスケジュールに基づき対象リソースの起動停止を行う。 - ③スケジュール作成
起動停止のスケジュールを定義する。CFnテンプレートはもちろん、CLIやコンソール上でDynamoDBテーブルを直接編集することで定義可能。
構成図はArchitecture diagramより引用したものを編集
EC2インスタンス以外に以下リソースも対応しています。
- Amazon EC2 Auto Scaling グループ
- Amazon RDS
- Amazon Aurora クラスター
- Amazon DocumentDB
- Amazon Neptune
2. EventBridgeスケジューラー
EventBridgeスケジューラーからEC2のStart/Stop APIを直接呼び出す方式です。
特徴、構成図は以下の通りです。
- 特徴：最小構成でシンプル。単一アカウント/単一リージョン向き。
- 向いているケース：数十台までの小規模、要件が単純。
- メリット：実装が短く、運用コストが低い。
- 注意点：スケジュールが増えると管理が煩雑になりがち。例外対応に弱い。
3. EventBridge + SSM Automation（またはLambda）
EventBridgeのルールからSSM Automationを起動し、そこで起動停止を行う方式です。Lambdaを挟む構成も同じ考え方です。
SSM AutomationはRunbookとして実行フローを管理でき、Lambdaはコードで柔軟に制御したい場合に向いています。
特徴、構成図は以下の通りです。
- 特徴：フローを柔軟に組める。条件分岐や通知がしやすい。単一アカウント/単一リージョン向き。
- 向いているケース：前後処理、外部連携、複雑な制御が必要。
- メリット：制御の自由度が高く、他システムとの統合も可能。
- 注意点：設計が複雑になりがち。運用者がSSM/Lambdaに慣れている必要がある。
Instance Scheduler を採用した理由
今回は以下の理由により、Instance Scheduler を採用しました。
-
短期間で導入できる
Instance Schedulerは、AWS Solutionsの1つとしてCFnテンプレートが公式に提供されています。アーキテクチャーの設計やコードの実装が不要で、テンプレートをデプロイしてスケジュールを定義するだけで動作します。もちろんCFnテンプレートで作成するリソースや動作について理解する必要はありますが、ゼロからスクラッチで開発するよりも大幅に短い期間で導入できました。 -
スケジュールの管理による運用負荷を低減できる
複数アカウント/複数リージョンを前提にした運用を想定していました。そのため、起動停止のスケジュールはアカウント/リージョンで個別に作成するのではなく、1つのアカウントで一元的に管理したいと考えていました。Instance Schedulerではスケジュール管理用と実行用でCFnテンプレートが分かれており、アカウントをまたいで連携することができました。 -
スケジュール対象の増減による運用負荷を低減できる
Instance Schedulerでは特定のタグが付いているリソースをスケジュールの対象とするため、インスタンス追加時にタグを付けるといった比較的簡単な運用で対象リソースの管理をすることができました。 -
柔軟なスケジュールを設定できる
Instance Schedulerでは月/日/時間単位で細かなスケジュールを設定でき、ゴールデンウイーク/夏休みなど変則的なスケジュールに対応することができました。
おわりに
今回はEC2インスタンスの起動停止を自動化するにあたり、3つの候補を比較した上でInstance Schedulerを採用した経緯をご紹介しました。
みなさんも検証環境の夜間停止から始めてみてはいかがでしょうか。
この記事が参考になりましたら、「いいね」や「記事のストック」をしていただけると嬉しいです！
- AWS は、米国その他の諸国における Amazon.com, Inc. またはその関連会社の商標です。
- その他、記載されている会社名および商品・製品・サービス名は、各社の商標または登録商標です。