LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

開発・検証環境のコストが無駄になりやすい理由：常時起動の課金構造

開発・検証環境の自動停止とは、夜間や休日など実際には使われない時間帯にAWSのEC2インスタンスやRDSインスタンス等を自動的に停止し、使う時間帯だけ起動するオンデマンドな運用に切り替えることで、クラウドコストを圧縮する取り組みです。

AWSのオンデマンド料金は、EC2やRDSのインスタンスが稼働している時間に応じて発生します。本番環境は24時間365日の可用性が求められますが、開発・検証環境はエンジニアが実際に作業する時間帯以外は使われないことが大半です。それでも常時起動のままにしておくと、夜間や休日の未使用時間にも課金が積み上がります。

たとえば平日の日中8時間だけ使う環境を24時間起動のままにしておくと、使われていない16時間分（平日）と48時間（土日）が毎週丸々課金されます。年間を通じると、実際の利用時間に対して大きな割合のコストが無駄になっている計算になります。

開発・検証環境はチームの規模が拡大するほど台数も増えやすく、「とりあえず停止し忘れていた」「誰も管理していなかった」というケースが積み重なると、AWS利用料の中で見落とされやすい節約余地になります。

本番環境との違い：管理の緩みがコスト増を招く

本番環境はサービス停止が直接的な損失につながるため、インフラ担当者の目が届きやすい環境です。一方、開発・検証環境はプロジェクト単位や個人単位で起動されることも多く、使用状況や台数の全体把握が難しくなりがちです。

プロジェクト終了後も残ったまま誰も使っていないインスタンス、検証が終わっても削除されていないRDS、ステージング環境として立ち上げたまま長期間そのままになっているEC2など、こうした「放置インスタンス」がコスト増の温床になります。自動停止・起動の仕組みを整備することは、コスト削減だけでなく環境の棚卸しと管理の起点にもなります。

自動停止の基本：止まる課金と止まらない課金の整理

自動停止でコスト削減の効果を正確に見積もるには、停止によって課金が止まる費用と、停止中も継続して発生する費用を区別しておく必要があります。

停止で課金が止まる費用

EC2インスタンスを停止（Stop）すると、インスタンスの実行に対するオンデマンド料金（vCPU・メモリ等のコンピュート費用）は発生しなくなります。インスタンスが「stopped」状態にある間は、コンピュート課金はゼロです。

RDSインスタンスも停止するとインスタンスの実行費用（コンピュート料金）が止まります。ElastiCacheやECSのサービスについても、設定によっては停止・スケールダウンでコンピュート費用を抑えられます。

停止中も課金が続く費用

一方、以下の費用は停止中も継続して発生します。この点を把握せずに削減効果を断定することは避けるべきです。

• EBSボリュームの費用：EC2インスタンスを停止してもアタッチされているEBS（Elastic Block Store）のストレージ費用はそのまま発生し続けます。
• RDSのストレージ費用：RDSインスタンスのストレージ（gp2/gp3等）の費用は停止中も課金されます。
• Elastic IP（EIP）の費用：EC2インスタンスに関連付けられているElastic IPは、インスタンスが停止中は「未使用のEIP」として課金対象になります。
• その他の付随リソース：NAT Gatewayやロードバランサー等、関連するリソースの費用は独立して発生します。

またRDSには「停止から7日後に自動的に再起動される」仕様があります^*1。これはRDSがメンテナンスや自動バックアップ等のために設けている仕様です。夜間・休日のみ停止する運用であれば自動再起動は通常問題になりませんが、長期連休中の扱いは事前に確認しておく必要があります。

削減効果の試算方法

自動停止による削減効果の目安を出す際は、「停止時間の割合×コンピュート課金の現在額」で概算します。平日夜間（18時〜翌9時の15時間）と土日祝の停止を組み合わせると、稼働時間は週の合計168時間のうち約45時間程度（平日9時〜18時の5日分）になります。単純計算では常時起動時の約25〜30%程度の時間しか課金されない試算になり、開発・検証環境のコンピュート費用を大きく削減できる余地があります。

ただしこれはあくまで試算の枠組みであり、実際の削減額はストレージ費用の割合・インスタンスタイプ・環境の台数によって異なります。AWS Cost Explorerで現在のEC2・RDS等のコンピュート費用を確認してから、対象インスタンスの割合を掛けて見積もることが大切です。

AWSでの実装方式3選：EventBridge Scheduler / Quick Setup / Instance Scheduler の比較と選び方

AWSで開発・検証環境の自動停止・起動を実装する方式は、用途と規模に応じて主に3つあります。AWS公式ドキュメントおよびAWSソリューション「Instance Scheduler on AWS」のドキュメントに基づき、それぞれの特徴と使い分けを整理します^*2。

（1）Amazon EventBridge Scheduler：シンプル・小規模向き

Amazon EventBridge Scheduler（アマゾン・イベントブリッジ・スケジューラ）は、cron式で指定した時刻にAWS APIを呼び出せるフルマネージドのスケジューラです^*3。EC2の「StartInstances」「StopInstances」APIやRDSの「StartDBInstance」「StopDBInstance」APIをターゲットに指定することで、インスタンスの定時停止・起動を実現できます。

設定はAWSマネジメントコンソールから行え、Lambda等の中間リソースを用意しなくても直接APIを呼び出せる点が特徴です。小規模・単純なスケジュールであれば追加の管理コストを抑えながら導入できます。ただしタイムゾーンはデフォルトがUTCのため、日本時間（JST=UTC+9）で設定する際は時刻のずれに注意が必要です。

（2）AWS Systems Manager Quick Setup リソーススケジューラ：タグ運用で素早く展開

AWS Systems Manager（システムズマネージャー）のQuick Setup機能には、EC2インスタンスのスケジュール管理を簡単に設定できる「ホスト管理」が含まれています^*4。タグを付与したインスタンスに対してまとめてスケジュールを適用できるため、管理対象が多い場合に管理の手間を減らせます。

開発環境のEC2に「Schedule: devstop」のようなタグを付けて、そのタグが付いたインスタンス全体に同一のスケジュールを適用する運用が典型的な使い方です。プロジェクトやチームの単位でタグを分けることで、異なるスケジュールを柔軟に使い分けられます。

（3）Instance Scheduler on AWS：大規模・本格運用向き

Instance Scheduler on AWS（インスタンス・スケジューラ・オン・AWS）はAWSが公式に提供するソリューションで、CloudFormationテンプレートで展開します^*2。EC2とRDSを対象に、複数のAWSアカウントや複数リージョンをまたいで一元的にスケジュール管理できます。

DynamoDBにスケジュール定義を保存し、Lambdaで定期的に評価・制御する構成です。特定の日付や曜日のみ停止しない例外ルール、環境ごとに異なる複数のスケジュール定義、スケジューラのログ管理といった本格的な運用機能を備えています。大規模・複雑な管理が必要な環境での採用に向いており、解説はAWS公式のソリューションページで確認できます。

導入の進め方：棚卸し→タグ設計→スケジュール定義→例外運用→効果測定

自動停止・起動の仕組みは「設定すれば終わり」ではなく、対象の整理と運用ルールの設計を先に行うことで安定して機能します。以下の順序で進めることが実務的な進め方です。

ステップ1：対象インスタンスの棚卸しと依存関係の確認

自動停止の導入で最初に行うべきは、停止対象となるインスタンスの一覧化です。AWS Cost ExplorerやAWS Trusted Advisorを使って起動中のEC2・RDS等を確認し、どのインスタンスが開発・検証用途かを整理します。

この際に重要なのが依存関係の確認です。複数のインスタンスが連携している環境では、停止の順序を誤るとサービスの起動失敗につながります。たとえばアプリケーションサーバーとデータベースサーバーが連携している場合、起動時はDBを先に起動してからアプリを起動する順序を設計する必要があります。棚卸し段階で依存関係をマップとして整理しておくことが、後工程のトラブル防止になります。

ステップ2：タグ設計とタグ付与ルールの策定

Systems ManagerやInstance Scheduler on AWSを使う場合、インスタンスの識別にタグを活用します。タグ設計は「どの粒度でスケジュールを管理するか」を定義する作業です。

チーム別・プロジェクト別・環境種別（dev/stg等）を軸にタグを設計し、新しくインスタンスを立ち上げる際にタグを付与するルールを徹底することで、管理漏れを防げます。IAMポリシーで特定のタグなしのインスタンス起動を制限する設計も、タグ付けルールの徹底に有効です。

ステップ3：スケジュール定義と動作テスト

停止・起動のスケジュールを定義します。平日夜間・土日祝の停止が基本パターンになりますが、チームの就業時間やリリースサイクルに合わせて調整します。EventBridge SchedulerではJST（UTC+9）を意識したcron式の記述が必要です。

本番への適用前に、まず1〜2台のインスタンスで動作テストを行うことが大切です。スケジュール通りに停止・起動されるか、起動後にアプリケーションやデータベースが正常に動作するかを確認してから対象を広げる手順が、トラブルを防ぐ観点で適切です。

ステップ4：例外運用ルールと通知設計

自動停止を運用する上で必要なのが例外運用の設計です。「深夜にリリース作業がある」「連休前に特定環境を起動し続けたい」といったケースに対応するため、一時的に自動停止を解除できる運用フローを用意しておきます。

また、停止・起動の実行結果をAmazon SNS（シンプル・ノーティフィケーション・サービス）等でSlackやメールに通知する設計を入れておくと、意図しない停止が発生した際に早期に気づけます。エラーが発生して起動に失敗した場合の検知・対応フローも事前に定めておくことが大切です。

ステップ5：導入後の効果測定と継続改善

自動停止の導入後は、AWS Cost ExplorerでEC2・RDS等のコンピュート費用の推移を確認します。導入前後の月次費用を比較することで、実際の削減額と削減率を把握できます。

定期的に対象インスタンスの棚卸しも継続することが大切です。新規プロジェクトの発足でインスタンスが増えたり、スケジュール外の利用が増えたりと、環境は変化します。スケジューラの設定も合わせて見直す習慣を持つことで、効果を維持できます。

外注の使いどころ：スケジューラ基盤構築・タグ運用設計・コスト診断の委託判断軸

自動停止の設定は、AWSの操作経験があるエンジニアであれば小規模な環境では内製で進めることも可能です。一方、以下のような状況では外注によって効率よく進められます。

外注が有効な3つのシナリオ

第一は、AWSの知識や運用経験が社内に不十分な場合です。EventBridge SchedulerのcronやIAMロールの設定は、AWSに不慣れな担当者にとっては判断事項が多く、設定ミスによる意図しない停止（本番環境を誤って止めてしまう等）のリスクがあります。初期設計から設定・テストまでを外注することで、リスクを抑えながら短期間で導入できます。

第二は、対象インスタンスが多数にわたる場合や、複数アカウント・複数リージョンを横断して管理する必要がある場合です。Instance Scheduler on AWSの展開・設定・タグ運用設計には、CloudFormationやDynamoDB、Lambdaの知識が求められます。社内担当者の工数と知識が不足する場合、外注によって体系的な設計を短期間で完成させられます。

第三は、AWSコスト全体の診断とセットで取り組みたい場合です。開発・検証環境の自動停止以外にも、Savings PlansやReserved Instancesの活用、不要なリソースの整理など、他のコスト最適化の余地がないかを合わせて診断してもらうことで、トータルの削減効果が高まります。

内製で進める場合の必要スキルと工数の目安

内製でEventBridge Schedulerによる停止・起動を設定する場合、IAMロールの作成（EC2/RDSの操作権限付与）とcron式の理解、タイムゾーン設定の確認、対象インスタンスの棚卸し、テストと動作確認の知識が求められます。

小規模な環境（対象10台程度・単純なスケジュール）であれば、担当者1名が1〜3営業日程度で設定を完了できることがあります。一方、Instance Scheduler on AWSの展開・タグ運用設計・複数アカウント対応まで含めると、AWSの専門知識を持つエンジニアが数日〜数週間の工数を要するケースもあります。こうした工数を他の開発・運用業務から確保するコストと外注費用を比較して判断することが現実的なアプローチです。

外注先選定の判断軸

外注先を選ぶ際は、AWS環境での運用実績・IAM・EventBridge・Systems Manager等の設定経験に加えて、既存環境の棚卸しと依存関係分析を行える体制があるかどうかを確認することが大切です。設定後の監視・通知設計まで一貫して担えるか、設定内容のドキュメント化と内製化支援を提供できるかも選定の判断軸になります。

まとめ：開発・検証環境の自動停止導入で押さえる3つの判断軸

本稿では、開発・検証環境を夜間・休日に自動停止してAWSのクラウドコストを削減する方法について整理しました。常時起動による無駄なコンピュート課金の構造、停止で止まる費用と止まらない費用の違い、EventBridge Scheduler・Systems Manager Quick Setup・Instance Scheduler on AWSの3方式の比較、導入の5ステップ、外注の使いどころを解説しています。要点を3つにまとめます。

第一に、自動停止の削減効果はコンピュート費用のみで、EBSやRDSのストレージ費用は停止中も継続課金されます。削減効果の試算はAWS Cost Explorerで現在の費用構造を確認してから行うことが大切です。

第二に、実装方式は規模と複雑さで使い分けることが合理的です。数台程度の単純なスケジュールであればEventBridge Scheduler、タグ一括管理が必要な場合はSystems Manager Quick Setup、複数アカウント・複数リージョンの大規模管理にはInstance Scheduler on AWSが適しています。

第三に、導入は棚卸し・タグ設計・スケジュール定義・例外運用・効果測定の5ステップで進めます。AWSの知識や工数が不足する場合は、外注によるスケジューラ基盤構築やコスト診断の活用が現実的な選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Amazon RDS DB インスタンスの停止」 — https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_StopInstance.html（2024年）
2. *2　出典：Amazon Web Services「Instance Scheduler on AWS」（AWSソリューション） — https://aws.amazon.com/jp/solutions/implementations/instance-scheduler-on-aws/（2024年）
3. *3　出典：Amazon Web Services「Amazon EventBridge Scheduler ユーザーガイド」 — https://docs.aws.amazon.com/ja_jp/scheduler/latest/UserGuide/what-is-scheduler.html（2024年）
4. *4　出典：Amazon Web Services「AWS Systems Manager Quick Setup」 — https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/quick-setup-scheduler.html（2024年）

Tweet