こんにちは。株式会社NTTデータ九州の山下です。
株式会社NTTデータ九州は、福岡市博多区に本社を構えるシステムインテグレーター（SIer）です。
公共・金融・法人分野を中心にシステム開発やインフラ構築を行っており、九州を拠点に全国規模のプロジェクトを手掛けています。
私は Amazon Web Services（AWS） を中心に、クラウドアーキテクチャの設計・構築や運用支援を担当しています。
本記事では、Instance Scheduler on AWS（以下、Instance Scheduler） を利用したAmazon EC2 および Amazon RDS の自動起動・停止の仕組みと、運用の中で見えてきた設定上の課題について紹介します。
本環境では既に Instance Scheduler v1.3.x が導入されており、運用改善の一環として挙動を調査する機会がありました。
前提条件
- AWS 上で Amazon EC2 または Amazon RDS の運用経験があること
- タグによるリソース管理の基本を理解していること
本記事の対象読者
- コスト最適化を検討している方
- Instance Scheduler の導入または運用改善を検討している方
この記事でわかること
- Instance Scheduler の設定値による運用上の違いを理解できる
- コスト最適化と障害対応の運用トレードオフを把握できる
※本記事は 2026 年 7 月時点の情報をもとに、検証および実運用経験に基づき作成しています。
※記載している構成や設定値は一般的な例であり、実際の挙動は環境やバージョンにより異なる場合があります。
Instance Scheduler とは？
Amazon EC2 および Amazon RDS をスケジュールに従って自動起動・停止するためのソリューションです。
小規模な環境であれば Amazon EventBridge でも十分運用できますが、管理対象のインスタンスやAWSアカウントが増えると、スケジュール管理や設定の統一が課題になります。
Instance Scheduler は、そのような運用課題を解決するためにAWS が提供するソリューション実装です。
Instance Scheduler のアーキテクチャ
Instance Scheduler の全体像は以下の通りです。
※図は筆者作成
定期的に EventBridge が AWS Lambda を起動し、AWS Lambda が Amazon DynamoDB（以下、DynamoDB） に保存されたスケジュール情報を参照して、対象インスタンスの起動・停止を制御します。
Instance Scheduler では、標準的にタグベースのスケジュール管理が可能です。
対象インスタンスへタグを付与するだけで運用できるため、管理対象が増えるほど効果を実感しやすくなります。
DynamoDB による設定管理
Instance Scheduler では、スケジュール情報を DynamoDB テーブルで管理します。
例えばスケジュール名やタイムゾーン、曜日ごとの起動・停止時間などを定義し、そのスケジュール名をインスタンスのタグに設定します。
Key: Schedule
Value: office-hours
インスタンスに対してこのようにタグを付与すると、Instance Scheduler が DynamoDB から office-hours スケジュールを参照し、自動的に起動・停止を実施します。
Schedule と Period の関係
Instance Scheduler の設定は、Schedule と Period の2つの概念で構成されています。
-
Schedule
- インスタンスに付与するタグの値を定義
- 利用する Period や動作設定を保持
-
Period
- 実際の起動・停止時刻を定義
図のように、Schedule 定義が参照され、関連付けられた Period に従って起動・停止が行われます。
例えば office-hours スケジュールでは、平日の 8:00 に起動し、18:00 に停止する設定となります。
※図は筆者作成
運用の中で考慮すべき課題
事象
Instance Scheduler で管理しているものの、24時間無停止になっているインスタンスが発見されました。
調査したところ、以下の設定となっており、スケジュール時間外に手動起動したインスタンスが起動状態のまま維持されていました。
enforced=false
retain_running=true
そこで、停止漏れによるコスト増加を防ぐため、以下の設定へ変更しました。
enforced=true
retain_running=false
これにより、停止漏れによるコスト増加は防げそうでしたが、別の問題が発生しました。
少なくとも本環境での確認では、スケジュール時間外に手動起動したインスタンスも自動停止の対象となりました。
例えば夜間の障害調査やメンテナンスのために手動起動した場合でも、AWS Lambda の定期実行時にスケジュール時間外と判定されると、自動停止されることを確認しました。
図のように、設定値によって「手動起動を維持するか」「強制停止するか」の挙動が変わります。
※図は筆者作成
このように、
- retain_running=true は運用の柔軟性が高い
- enforced=true は停止漏れを防止できる
という特徴がある一方で、それぞれ異なる運用上の課題があります。
改めて整理
Instance Scheduler は、「Schedule タグが付与されたインスタンスを、スケジュールどおりに起動・停止する」ことに忠実な特性を持つようです。
| 構成 | メリット | デメリット |
|---|---|---|
| enforced=false, retain_running=true | 手動起動しやすい | 停止忘れが発生すると起動し続ける |
| enforced=false, retain_running=false | 停止漏れが発生しにくい | 手動起動してもすぐに停止される |
| enforced=true, retain_running=* | 停止漏れが発生しにくい | 手動起動してもすぐに停止される |
現時点での考え
Instance Scheduler を使う場合、
- 通常時は、強制停止によるコスト最適化を優先する
- 緊急時は、一時的にタグを解除して運用対処で解決する
もしくは、
- 手動起動可能とし、手動停止漏れのインスタンスは発見的統制で検知する
という運用が現実的ではないかと考えています。
ただし、本件については現在も調査中であり、コスト最適化と運用の柔軟性を両立できる方法がないか引き続き検討しています。
まとめ
Instance Scheduler は Amazon EC2 および Amazon RDS の自動起動・停止を実現する便利なソリューションです。
ただし、ケースによっては運用性に大きく影響するため、導入時にシミュレーションすることをおすすめします。
本記事が、Instance Scheduler を運用している方の参考になれば幸いです。
免責事項
本記事は筆者個人の見解に基づくものであり、所属組織の公式見解ではありません。
また、本記事の内容を利用したことによって生じたいかなる損害についても、筆者は責任を負いかねます。