ECS Expressモードで高解像度（20秒）オートスケーリングは使えるのか検証してみた
こんにちは。サービス開発部の武田です。
2026年6月、Amazon ECSのサービスオートスケーリングが高解像度（20秒）メトリクスに対応しました。これまでの60秒解像度に加えて20秒解像度を選べるようになり、負荷の変化を早めに検知してスケールアウトできます。
AWSのベンチマークでは、スケールアウトの開始までが363秒から86秒（76%短縮）、新しいタスクの起動完了までを含めても386秒から109秒（72%短縮）になったとされています。ベースラインのタスク数を下げてコストを抑えつつ、急な負荷にも追従しやすくなるアップデートです。
標準のECSサービスでこの機能を有効化し、スケールアウトが実際に速くなるかは、弊社の別記事で検証しています。
本記事では、3つだけの設定でWebアプリを公開できるECS Expressモードでもこの高解像度オートスケーリングが使えるのか、という点を検証します。Expressモードはコンテナイメージ・実行ロール・インフラロールを渡すだけで、ALBやオートスケーリングまで自動で構成してくれる簡易デプロイ機能です。その自動構成に20秒解像度を載せられるのかを確かめます。
検証はboto3 1.43.33（2026年6月18日リリース）で行いました。今回扱うmonitoringやHighResolution付きメトリクスは、機能リリースと同時にSDK/CLIへ追加されています。AWS CLIで試す場合も、これらに対応したバージョンが必要です。
先に結論
- 高解像度オートスケーリングは「サービス側で20秒解像度メトリクスを有効化」「ターゲット追跡ポリシーで高解像度版の定義済みメトリクスを指定」の2点セットで有効にする。標準ECSサービスではこの構成が通った
- Expressモードを操作するAPIには、解像度を指定するフィールドがない
- Expressが自動生成する裏側のサービスは、デフォルトの60秒解像度だった
- 裏側の標準サービスを直接書き換えて20秒化すると、一時的には高解像度ポリシーが通る。ただしExpressの管理（canaryデプロイやreconcile）で60秒に戻され、安定して維持できなかった
- 現状、高解像度オートスケーリングを使いたいなら標準のECSサービスを選ぶことになる
まず標準ECSでの有効化方法を確認する
Expressモードを見る前に、高解像度オートスケーリングを素のECSサービスでどう有効化するのかを整理します。有効化は2つの設定がセットになっています。
サービス側で20秒解像度メトリクスを有効化する
CreateService/UpdateServiceにmonitoringが追加されました。ここでCPUUtilization/MemoryUtilizationの収集解像度を指定します。
{
"monitoring": {
"metricConfigurations": [
{
"metricNames": ["CPUUtilization", "MemoryUtilization"],
"resolutionSeconds": 20
}
]
}
}
resolutionSecondsに指定できるのは20か60で、未指定なら従来どおり60秒です。高解像度メトリクスには通常のCloudWatch料金がかかります。
ターゲット追跡ポリシーで高解像度の定義済みメトリクスを使う
Application Auto Scalingに、高解像度版の定義済みメトリクスが追加されました。
ECSServiceAverageCPUUtilizationHighResolutionECSServiceAverageMemoryUtilizationHighResolution
従来のECSServiceAverageCPUUtilizationが60秒版、HighResolution付きが20秒版という関係です。ターゲット追跡ポリシーでこのHighResolution付きを指定します。
2つには順序の依存がある
この2つには順序の依存があります。サービス側で20秒解像度を有効化していない状態で高解像度ポリシーを作ろうとすると拒否されます。
ValidationException: High-resolution metrics are not fully enabled on the ECS service.
しかも、monitoringを有効化してから高解像度ポリシーが受理されるまでには伝播時間を要しました。メトリクスが流れ始めるまでのラグで、筆者の環境では約60秒です。有効化した直後にポリシーを作ると上のエラーになり、しばらく待つと通る、という挙動でした。
標準サービスでは構成できた
標準のFargateサービスをmonitoringの20秒設定付きで作りました。そこへECSServiceAverageCPUUtilizationHighResolutionを使うターゲット追跡ポリシーを登録します。結果はポリシーが受理され、CloudWatchアラームも生成されました。標準ECSでは、この2点セットで高解像度オートスケーリングを構成できます。
なお今回はスケールアウトの実時間を測るのが目的ではありません。標準サービスでの実測は先に挙げたDevIOの記事に譲り、本記事では構成が通るところまでの確認にとどめます。
Expressモードで検証する
ここからが本題です。Expressモードのオートスケーリングに20秒解像度を載せられるか、3つの角度で確認しました。
Express APIに解像度を指定する口がない
Expressモードを操作するのはCreateExpressGatewayServiceとUpdateExpressGatewayServiceです。オートスケーリングはscalingTargetという構造で指定し、中身はこの4項目だけでした。
minTaskCountmaxTaskCountautoScalingMetric（AVERAGE_CPU/AVERAGE_MEMORY/REQUEST_COUNT_PER_TARGET）autoScalingTargetValue
標準サービスにあったmonitoringやresolutionSecondsに相当するフィールドはありません。Expressモードを操作するAPIからは、そもそも20秒解像度を指定する手段が用意されていないということです。
Expressが作る裏側はデフォルトの60秒解像度
Expressモードは、実体として標準のECSサービスとApplication Auto Scalingのポリシーを自動生成します。生成された裏側を確認すると、サービスのmonitoring設定はありませんでした（＝デフォルトの60秒解像度）。ターゲット追跡ポリシーも60秒版のECSServiceAverageCPUUtilizationです。Expressモードはデフォルトで60秒解像度の構成になっています。
裏側を直接書き換えても、Expressが60秒に戻す
Expressモードの売りは「裏側のリソースにも直接アクセスできる」点です。それなら、裏側の標準サービスに直接UpdateServiceで20秒のmonitoringを入れ、高解像度ポリシーに差し替えればいけるのでは、と考えて試しました。
結果はこうです。
UpdateServiceで20秒のmonitoringを適用すると、伝播後（約60秒後）には高解像度ポリシーが通った- ところがしばらくすると設定が元に戻り、高解像度ポリシーがまた拒否されるようになる
- Expressモード側の更新やcanaryデプロイが進行している間は、
monitoringを入れ直しても受理されない時間帯があった
Expressモードはサービスの状態を管理し続けています。canaryデプロイやreconcile（あるべき状態への収束）の過程で、こちらが入れたmonitoring設定を上書きし、60秒解像度に戻してしまいます。一瞬は適用できても、安定して維持できませんでした。
切り分けのため、同じUpdateServiceでの20秒化を素の標準サービスに対して行うと、伝播後に高解像度ポリシーは問題なく受理され、その後も維持されました。手順自体は正しく、Expressモードが管理機構によって設定を戻している、という整理になります。
最後に
ECSの高解像度（20秒）オートスケーリングをExpressモードで使えるか検証しました。
標準ECSサービスなら、monitoringの20秒設定とHighResolution付き定義済みメトリクスの2点セットで構成できます。一方Expressモードは、操作APIに解像度を指定するフィールドがなく、デフォルトは60秒解像度。裏側の標準サービスを直接書き換えても、Expressの管理機構で元に戻されて安定しませんでした。
高解像度オートスケーリングをきちんと使いたいなら、いまは標準のECSサービスを選ぶことになります。Expressモードは少ない設定で手早くデプロイできる代わりに、こうした細かいチューニングの余地は持たない、という割り切りが見える結果でした。今後Expressモードのスケーリング設定に解像度の指定が追加されれば、この状況も変わるでしょう。
