Cloud Automator に、ECS サービスのタスク数や自動スケーリング設定をジョブから安全に変更できる新しいアクション「ECS: サービスのタスク数を変更」を追加しました。
このアクションを使うことで、時間帯やカレンダー（平日 / 土日・祝日）に応じて ECS サービスのスケールを自動制御し、ムダな稼働コストを削減できます。
よくある ECS 運用パターンとコストの課題
ECS ベースのシステムでは、「止められるのに止めていないリソース」が少しずつコストを押し上げていくケースが少なくありません。
例えば、次のようなパターンです。
- 平日の日中だけ利用する開発・検証環境が、夜間や土日・祝日もフル稼働している。
- 昼休みなど短時間のピークに備えて、常に多めのタスク数を維持している。
- 日本の祝日を考慮できない自作 cron によって、アクセスのない祝日にもタスクが起動している。
具体的な例として、開発環境クラスターで Fargate タスク 4 つ（1 つあたり 0.05 USD/時）を 24 時間 × 30 日 動かし続けると、次のようなコストになります。
- タスク数：4
- 単価：0.05 USD/時
- 常時稼働：4 × 0.05 × 24 × 30 ≒ 144 USD/月
これを実態に合わせて、平日 8 時間 × 20 日 に絞ると、次のようになります。
- 稼働時間：8 時間 × 20 日
- コスト：4 × 0.05 × 8 × 20 ≒ 32 USD/月
つまり、1 環境あたり 100 USD 以上の差になります。
同様の環境が複数存在し、本番環境でも「ピークの一瞬」に合わせた余裕を一日中・一年中払い続けていると、月次の AWS 利用料にとって無視できないコスト増となってしまいます。
時間帯とカレンダーに応じて「必要なときだけ動かす」
「ECS: サービスのタスク数を変更」アクションは、こうした無駄な稼働を減らすために、Cloud Automator のアクションから ECS サービスのタスク数や自動スケーリング設定を変更し、時間帯、カレンダー（平日 / 土日・祝日）に合わせて「必要なときだけリソースを動かす」状態をつくるためのアクションです。
Cloud Automator のジョブとして設定することで、
- いつ、どのサービスを、どのタスク数（またはスケール幅）にするか
- その変更がいつ実行され、成功 / 失敗したか
を履歴として確認でき、人手のミスや設定漏れを減らしながら、安全にスケール運用を自動化できます。
2 つのモードでコストを最適化
本アクションは、ECS サービスのスケールを次の 2 パターンで制御します。
タスク数（DesiredCount）の変更
Auto Scaling を使っていないサービス向けに、
update_serviceAPI を用いて DesiredCount を直接更新します。例：開発環境のタスク数を、平日朝に 2 に増やし、夜間や休日は 0 にする
※ タスク数を 0 にする場合は、バッチ処理や監視・ヘルスチェックなど、バックグラウンドでの前提処理がないかを確認してから設定することをおすすめします。
自動スケーリング（MinCapacity / MaxCapacity）の変更
Application Auto Scaling を利用しているサービス向けに、
register_scalable_targetAPI を用いてmin_capacity/max_capacityを更新します。例：本番サービスの最小タスク数を、昼前だけ一時的に増やし、夜間は小さく抑える
これにより、「常にピークに合わせる」のではなく、「必要な時間帯だけ増やし、それ以外は絞る」運用が実現できます。
対象サービスの指定方法
対象とする ECS サービスは、次のいずれかの方法で指定できます。
サービス名で 1 件を指定
特定のサービスだけをピンポイントで制御したい場合に利用します。タグ（
tag_key/tag_value）で複数サービスを一括指定
env=devやproject=campaign-2025などのタグを使い、関連サービスをまとめて制御したい場合に利用します。
タグベースで指定しておけば、あとからサービスが増えても、同じタグを付けるだけで自動的に制御対象に含められるため、運用効率も高められます。
これにより、例えば次のような運用が可能になります。
- 開発環境の ECS サービスだけ、平日夜間と土日・祝日はタスク数を 0 にします。
- 特定キャンペーン用サービス群だけ、昼休み前に一括でスケールアウトします。
代表的な利用シナリオ
1. 開発・検証環境の夜間／休日停止
- 平日 9:00 にタスク数を 2 に増やします。
- 平日 19:00 にタスク数を 0 にします。
- 土日・祝日は終日 0 のままにします。
これにより、これまで 24 時間動かしっぱなしだった開発・検証環境を、実際に利用する時間帯だけ起動する形に切り替えられます。
Aurora Serverless などと組み合わせれば、DB 側のコスト削減にもつながります。
2. 昼休み前の事前スケール
- 平日 11:45 に特定サービス群のタスク数を増やします。
- 13:15 に元のタスク数に戻します。
CloudWatch Alarm ベースの Auto Scaling だけでは追いつかない「一気に増えるトラフィック」に対して、時間指定の事前スケールで備えることで、
- レスポンス悪化やエラー増加を防ぎつつ
- それ以外の時間帯はタスク数を抑えてコストも削減
といった運用が可能になります。
3. キャンペーン期間中の一時的なキャパシティ増強
project=campaign-2025タグが付いたサービス群の Min/Max を、キャンペーン期間中だけ拡大します。- キャンペーン終了後に、Min/Max を元の値に戻します。
これにより、キャンペーン期間中はピークに耐えられるようスケール幅を広げつつ、終了後は速やかに元の設定へ戻せるため、一時的な増強に伴うコストを必要最小限に抑えることができます。
簡単なアクション作成手順
ここでは、サービスのタスク数を時間帯に応じて変更するジョブを例に、設定手順を簡潔に紹介します。
1. Cloud Automator のジョブ作成画面で、アクションとして「ECS: サービスのタスク数を変更」を選択します。
2. アクションを実行する AWS アカウントを選択します。
3. アクションのパラメーター（リージョン、クラスター、サービス／タグ、タスク数など）を設定します。
各パラメーターの詳細については、アクションのマニュアル を参照してください。
おわりに
ECS サービスのスケーリングは、「止められる時間帯に止める」「必要な時間帯にはあらかじめ増やす」というシンプルなルールを徹底できるかどうかで、コストが大きく変わります。
Cloud Automator の新アクション「ECS: サービスのタスク数を変更」は、このルールを 時間帯 と カレンダー に沿って自動化するための仕組みです。
- まずは 開発・検証環境の夜間停止 や、祝日を含む平日運用の見直し から始めてみてください。
- そのうえで、本番環境のピーク時間帯 や キャンペーン期間のスケール にも広げていくことで、無理なく段階的に ECS のコスト最適化を進めることができます。
Cloud Automator を活用して、「必要なときだけ動かす ECS」をぜひ実現してみてください。
