この記事はNHN テコラス Advent Calendar 2025 の 2 日目の記事です。

概要

こんにちは！
今年もいよいよ残り 1 ヶ月を切り、お財布事情が厳しくなる時期になりました。
AWS においても予算管理者から利用額を来年からは削減するようにと要請されることもあるかと思います。
そんなみなさんのために、今回はコスト削減のために EC2 や RDS を自動起動/停止する方法についてメリットやデメリットを比較したいと思います。

前提

というわけで今回は EC2 や RDS を自動起動/停止する方法についてお話ししますが、内容を理解するにあたって必要となる前提知識がありますので簡単に説明します。
特に必要ないよという方は読み飛ばしていただければと思います。

EC2 や RDS を自動起動/停止して何が嬉しいの？

EC2 や RDS は起動時間に応じた従量課金制のため、夜間や土日など使わない時間帯に停止しておくことでコストを削減することができます。
例えば、r8g.large のインスタンスタイプの EC2 1 台を対象に、平日 8:00 ~ 20:00 以外の時間帯に停止しておくようにすると月額約 64.81 USD (約 63%) もの料金を削減することができます。

• 平日 8:00 ~ 20:00 以外の時間帯に停止している場合の EC2 の月額料金
  • 0.14212 [USD/Hour] × 12 [Hour] × 22 [Day/Month] ≒ 37.52 USD/Month
• 常に起動している場合の EC2 の月額料金
  • 0.14212 [USD/Hour] × 24 [Hour] × 30 [Day/Month] ≒ 102.33 USD/Month

※ 2025/11/27 時点での東京リージョンの EC2 料金を元に試算
※ 1 ヶ月 = 30 日で試算
※ 土日 8 日間を休日として試算
参考: オンデマンドインスタンスの料金 – Amazon EC2 (仮想サーバー) | AWS

社内検証環境などでは業務時間外にこれらのリソースを起動しておく必要のないケースが多く、自動起動/停止機能を活用しているユーザも多くいるかと思います。
反対に、本番環境など常にリソースを起動し続けなければならない環境では Reserved Instance や Savings Plans を活用するのが良いですね。

どうやって EC2 や RDS を自動起動/停止するの？

そんな検証環境のコスト削減の役に立つリソース自動起動/停止機能ですが、どのような方法で実現できるのでしょうか。
私の主観とはなりますが、以下の 3 つの方法が代表的なものになります。

1. EventBridge + SSM Document
2. ステートマネージャー + SSM Document + Change Calendar
3. Instance Scheduler

各方法について簡単に説明します。

1. EventBridge + SSM Document

こちらは EC2 を停止するコマンドを実行するスクリプトである SSM Document を EventBridge によって定期的にトリガーする構成です。
数ある構成の中でも恐らく最も一般的な方法かと思います。
この Tech blog でも過去紹介されている記事がありますので、興味があればご参照ください。

2. ステートマネージャー + SSM Document + Change Calendar

こちらは先ほどと同じ SSM Document をステートマネージャーによって定期的にトリガーする構成です。
これだけ聞くと EventBridge を用いた方法と変わらないじゃないかと思うかもしれませんが、Change Calendar など他の Systems Manager と連携することで様々な便利機能を追加することができます。

参考: AWS Systems Manager State Manager – AWS Systems Manager

3. Instance Scheduler

こちらは AWS が提供するソリューションの 1 つとなります。
構成としては EventBridge や Lambda、DynamoBD などを組み合わることによって、タグ付けによる対象リソースの制御など柔軟に自動起動/停止機能を用いることができます。
構成が複雑に見えるためセットアップが大変そうに見えますが、CloudFormation のテンプレートが提供されているため簡単に実装することができます。

参考: Instance Scheduler on AWS | AWS Solutions | AWS Solutions Library

比較

概要比較

今回のようなソリューションを導入するにあたってまず気になる要素を比較します。

方法	導入の手間	管理の手間	料金
EventBridge + SSM Document	小	小	極小
ステートマネージャー + SSM Document + Change Calendar	大	大	極小
Instance Scheduler	小	大	極小

前提として、対象リソース数が 1 ~ 10 台程度の比較的小規模な環境を想定しています。

「EventBridge + SSM Document」については、使用するサービス数が少なく、また EventBridge がマネージドサービスであることからかなり導入や管理の手間を少なくすることができます。
そのため、なるべく手間をかけずにリソース自動起動/停止機能を使いたいケースでオススメです！
また、料金面では EventBridge の実行回数に応じての課金となりますが、実行回数が少ないため月額 1 USD 未満となる可能性が高いです。

「ステートマネージャー + SSM Document + Change Calendar」については使用するサービス数が多いことから導入や管理の手間は比較的大きくなります。
しかし、詳細は後述しますが、Change Calendar を利用することでリソース自動起動/停止機能のスケジューリングの手間を大幅に下げることができるため、リソース自動起動/停止機能の稼働・停止を頻繁に操作したいケースでオススメです！
料金面でも「EventBridge + SSM Document」と同じく月額 1 USD 未満となる可能性が高いです。

「Instance Scheduler」については、導入は CloudFormation で楽に実施できるものの、作成されるリソース数が多く、ランタイムの更新など Lambda の管理が必要であることから管理の手間は大きいです。
しかし、Lambda など複数のサービスを組み合わせていることから推測できる通り豊富な便利機能を備えているため、導入の手間を上げずに便利な機能を使いたいケースでオススメです！
料金面でも他 2 つの方法と同じく月額 1 USD 未満となる可能性が高いです。

詳細比較

リソース自動起動/停止機能を利用してからでないと気付きにくい運用を元に各方法を比較します。

• 対象リソースを追加したい
• 一時的に機能を無効化したい
• 祝日や年末年始は範囲外としたい

対象リソースを追加したい

「新しく EC2 を作ったので自動的に停止するようにしたい！」といったようなケースで、リソース自動起動/停止機能をデプロイした後に対象リソースを追加することもあるかと思います。
このように対象リソースを追加する場合は「ステートマネージャー + SSM Document + Change Calendar」あるいは「Instance Scheduler」がオススメです。

これら 2 つの方法では、対象リソースをタグで制御することができます。
例えば、リソースに “Automation: True” というタグが付いている場合に自動起動/停止機能の対象とする、といったような設定が可能です。
この場合、新しく対象リソースを追加する場合はそのリソースに “Automation: True” タグを付けるだけで追加されます。
そのため、運用負荷を上げることなく対象の追加が可能なためオススメとなっています。

参考: State Manager 関連付けのターゲットとレート制御について – AWS Systems Manager
参考: サンプルスケジュール – AWS での Instance Scheduler

一方で「EventBridge + SSM Document」の場合は、EventBridge とリソースが一対一の関係となっています。
そのため、対象リソースを新たに追加するためには EventBridge のルールあるいはスケジューラーを 1 つ作成する必要があります。
そうなると対象リソースの増加とともに EventBridge の数も増えるため作業や管理の手間も上がってしまい、前述の 2 つの方法と比較するとオススメできません。

一時的に機能を無効化したい

「長時間かかるテストを実施したいから今日から 3 日間は EC2 を止めたくない！」といったようなケースで、リソース自動起動/停止機能を一時的に無効化することもあるかと思います。
このように一時的に無効化する場合は「ステートマネージャー + SSM Document + Change Calendar」がオススメです。

この方法では Change Calendar を用いることで事前に期間を指定してリソース自動起動/停止機能の有効/無効を管理します。
そのため、「機能の対象に戻し忘れて夜間に EC2 が止まるはずが止まっていなかった…」といったような事態を防止することができます。

一方で、他 2 つの方法ではリソース自動起動/停止機能の有効/無効を切り替える際には明示的に操作する必要があります。
そのため、上述のような設定戻し忘れが発生する可能性があり、比較的オススメできません。

祝日や年末年始は範囲外としたい

「祝日や年末年始は業務時間外なので自動起動させたくない」といったようなケースで、特定の日付のみリソース自動起動/停止機能を無効化することもあるかと思います。
年末年始の休業期間と年間の祝日を合計すると 20 日程度ありますので、祝日や年末年始にリソース自動起動/停止機能を無効化することができれば更にコストを 10% 程度削減することができます。
このように特定の日付のみ無効化する場合は「ステートマネージャー + SSM Document + Change Calendar」がオススメです。

上述の通りこの方法では Change Calendar でリソース自動起動/停止機能の有効あるいは無効を管理します。
この際に Change Calendar に ics ファイルをインポートすることで、その isc ファイルで指定されている期間は自動起動を無効化することができます。
祝日のカレンダーは Google カレンダーなどから ics ファイルでエクスポートすることができますので、事前に直近 5 年間の祝日で機能を無効化しておくことができます。

参考: サードパーティーのカレンダーからのイベントのインポートと管理 – AWS Systems Manager

一方で、他 2 つの方法では事前に祝日や年末年始の機能無効化に対応することはできません。
祝日が迫ったその都度有効あるいは無効を明示的に操作する必要があります。
そのため、運用負荷が高くなり比較的オススメできません。

まとめ

コスト削減手段としては有名なリソース自動起動/停止機能ですが、実現方法についてはそこまで広まっていないなと感じてこの記事を書いてみました。
個人的には、詳細比較でご紹介した運用が多く出てくることから「ステートマネージャー + SSM Document + Change Calendar」の方法が好みです。
みなさんもこれを機に今の方法がご自身の環境や運用に適切なものかどうか今一度検討してみてはどうでしょうか。

NHN テコラスの採用情報はこちら