はじめに

2026 年 6 月 18 日、AWS は Amazon ECS のサービスオートスケーリングの高速化を発表しました。高解像度メトリクス（20 秒間隔）のサポートとメトリクス公開処理の最適化により、負荷の変化を検知してからスケールアウトが完了するまでの時間が大幅に短縮されています。

ECS でサービスを運用している方の中には、突発的なトラフィックの急増に対してスケールアウトが間に合わず、遅延やエラーが発生した経験がある方もいるのではないでしょうか。あるいは、「いつ来るかわからないスパイクに備えて」ベースライン容量を高めに設定し続けており、コストが気になっていた方もいるかもしれません。今回のアップデートは、その課題に直接応えるものです。

本記事では、何が変わったのか、どのようなワークロードにとって意味のあるアップデートなのか、そしてどう設定すればよいのかを中心に解説します。ECS でサービスを運用するインフラ・バックエンドエンジニアの方や、コスト最適化・スケーリング戦略の見直しを検討している方を想定読者としています。

何が変わったのか

ECS のサービスオートスケーリングは、Amazon CloudWatch に送信されたメトリクスをもとにスケーリングポリシーを評価し、タスク数を増減させる仕組みです。従来はこのメトリクスの評価間隔が 60 秒固定であったため、負荷が急増してからスケールアウトが完了するまでに 6 分以上かかるケースがありました。

今回のアップデートにより、20 秒間隔の高解像度メトリクスが新たにサポートされ、メトリクス公開処理の内部最適化も合わせて実施されました。AWS のベンチマークテストでは、以下のような改善が確認されています。

項目	変更前	変更後
メトリクス解像度	60 秒（標準）	20 秒（高解像度）を新たに選択可能
スケールアウトトリガーまでの時間	約 363 秒（約 6 分）	約 86 秒（約 1.4 分）、76% 短縮（4.2 倍）
タスク起動完了までの総時間	約 386 秒（約 6.4 分）	約 109 秒（約 1.8 分）、72% 短縮（3.5 倍）

なぜ速くなったのか

改善の要因は大きく 2 つです。

1 つ目は、メトリクスの評価間隔の短縮です。ECS が CPU・メモリ使用率を CloudWatch へ送信する間隔が 60 秒から 20 秒になったことで、Application Auto Scaling がスケーリング判断を下すタイミングが 3 倍細かくなりました。

2 つ目は、メトリクス公開処理の内部最適化です。メトリクスが CloudWatch に書き込まれてからスケーリングポリシーに反映されるまでの遅延が、ECS 側の処理改善によって短縮されています。この 2 つが組み合わさることで、ベンチマーク上の数値以上の体感差が出るケースもあります。

高解像度メトリクスを利用すると、ターゲットトラッキングポリシーで選択できる定義済みメトリクスとして、以下の 2 つが追加されます。

PredefinedMetricType	説明
`ECSServiceAverageCPUUtilizationHighResolution`	20 秒解像度の平均 CPU 使用率
`ECSServiceAverageMemoryUtilizationHighResolution`	20 秒解像度の平均メモリ使用率

既存の 60 秒解像度のメトリクスは引き続き利用可能で、高解像度メトリクスはオプトイン方式のため、既存サービスへの影響はありません。

どんなワークロードに効果があるか

効果の大きさはワークロードの特性によって異なります。すべての ECS サービスに一律で適用するのではなく、自分たちのサービスの特性を踏まえて判断することが重要です。

効果が大きいケース

特に恩恵が大きいのは、トラフィックの変動が急激かつ予測困難なサービスです。EC サイトのフラッシュセールやゲームのイベント開始時のように、数分以内にリクエスト数が急増するケースでは、従来の 6 分超のスケールアウトでは対応が遅れることがありました。タスクの起動完了までの総時間が約 109 秒（約 1.8 分）に短縮されたことで、エンドユーザーへの影響を抑えやすくなります。

SQS キューと組み合わせたバッチ処理やジョブキューのコンシューマーも、恩恵を受けやすいケースです。キュー深度の急増に対してコンシューマータスクを素早く増やせるため、処理遅延の蓄積を抑えられます。

「スパイクに備えてベースライン容量を高めに保っている」サービスにとっても、このアップデートは直接的なコスト削減につながります。スケールアウトが速くなることで、余剰バッファとして確保していたタスクを減らせます。

効果が限定的なケース

トラフィックパターンが曜日・時間帯によって規則的に変動するサービスは、Predictive Scaling や Scheduled Scaling の方が効果的な場合があります。需要を事前に予測してプロアクティブに容量を確保する戦略の方が、レイテンシへの影響を抑えやすいためです。

負荷が安定していてスパイクがほとんど発生しないサービスや、スケーリングのボトルネックがメトリクス評価の遅延ではなくタスクの起動時間にあるケースでは、本機能単体での改善幅は小さくなります。

コストとのトレードオフ

標準解像度（60 秒）の ECS メトリクスは CloudWatch への送信が無料ですが、高解像度メトリクス（20 秒）は追加の CloudWatch 料金が発生します。機能自体に追加コストはないものの、メトリクスのデータポイント数が 3 倍になることで CloudWatch のメトリクス費用が増加します。詳細は Amazon CloudWatch 料金ページを参照してください。

「スケーリング高速化によって削減できるコンピューティングコスト」と「増加する CloudWatch コスト」のトレードオフで考えるのが基本です。スパイクへの対応のためにベースライン容量を多めに確保しているサービスほど、削減効果が大きくトレードオフがプラスに働きやすくなります。まずはトラフィック変動が顕著なサービスから段階的に適用し、効果を確認してから展開範囲を広げるアプローチが現実的です。

スケーリング戦略の選び方

ECS のサービスオートスケーリングには複数のポリシータイプがあり、それぞれ得意なシナリオが異なります。今回のアップデートでターゲットトラッキングの応答性が向上したことで、これらの組み合わせ方を改めて考える機会にもなります。

ポリシータイプ	向いているシナリオ	特徴
Predictive Scaling	毎朝 9 時の業務開始、週末の利用増など繰り返しパターンがある	過去の負荷データを ML で分析し、需要が増える前にプロアクティブにスケール
Scheduled Scaling	セール・リリース・バッチ処理など日時が決まっているイベント	指定した日時にタスク数を変更。計画済みの負荷に確実に備えられる
Target Tracking（高解像度）	突発的・予測困難なトラフィックスパイク	今回のアップデートの中心。リアルタイムに近い精度でリアクティブにスケール

それぞれの役割を理解する

Predictive Scaling と Scheduled Scaling はいずれも「先手を打つ」プロアクティブなアプローチです。Predictive Scaling は設定不要で自動的にパターンを学習しますが、学習データが蓄積されるまで精度が上がらないため、サービスの立ち上げ直後には効果が限定的です。Scheduled Scaling は確実性が高い一方、想定外のタイミングで発生するスパイクには対応できません。

ターゲットトラッキングは実際のメトリクスに基づいてリアクティブにスケールするため、予測できない負荷変動に強いポリシーです。従来の 60 秒解像度では応答が遅く、急激なスパイクへの対応に課題がありましたが、今回の高解像度メトリクス対応でこの点が改善されています。

組み合わせて使うのが現実解

日次のトラフィックパターンには Predictive Scaling を、キャンペーンなど計画済みイベントには Scheduled Scaling を当て、それでもカバーしきれない想定外のスパイクをターゲットトラッキング（高解像度）で受け止める構成が考えられます。プロアクティブとリアクティブを使い分けることで、それぞれの弱点を補い合えます。

ステップスケーリングからの移行も選択肢に

ターゲットトラッキングの応答の遅さを補うために、閾値ごとに細かくスケール量を定義するステップスケーリングを使っていたチームもあるかと思います。高解像度メトリクスを使ったターゲットトラッキングは、従来ステップスケーリングのカスタム設定が必要だったような積極的なスケーリング動作をシンプルな設定で実現できます。複雑なスケーリング設定の整理を考えているチームには、見直しのタイミングになります。

設定方法

設定の流れは「新規サービスに適用する」場合と「既存サービスを更新する」場合で異なります。既存サービスへの適用は 2 ステップのプロセスになる点に注意が必要です。なお、本機能は ALB・NLB を使用するサービスで利用可能です。Classic Load Balancer（ターゲットグループなし）および CODE_DEPLOY・EXTERNAL デプロイコントローラーを使用するサービスは対応していません。

新規サービスに設定する

コンソールから設定する

サービス作成フォームの Monitoring configuration セクションで Add metric configuration を選択し、メトリクス名（CPUUtilization または MemoryUtilization）と解像度（20 秒）を設定します。続いて Service auto scaling セクションでスケーリングポリシーのタイプに Target Tracking を選択し、メトリクスタイプとして ECSServiceAverageCPUUtilizationHighResolution または ECSServiceAverageMemoryUtilizationHighResolution を指定します。

AWS CLI から設定する

まず create-service コマンドで 20 秒解像度のモニタリング設定を含めてサービスを作成します。

aws ecs create-service --region <region> \
    --cluster <cluster-name> \
    --service-name <service-name> \
    --task-definition <task-definition> \
    --desired-count <desired-count> \
    --monitoring "metricConfigurations=[{metricNames=[CPUUtilization,MemoryUtilization],resolutionSeconds=20}]"

次に、Application Auto Scaling のスケーラブルターゲットとして登録します。

aws application-autoscaling register-scalable-target \
    --service-namespace ecs \
    --resource-id service/<cluster-name>/<service-name> \
    --scalable-dimension ecs:service:DesiredCount \
    --min-capacity <min-capacity> \
    --max-capacity <max-capacity> \
    --region <region>

最後に、高解像度メトリクスを使ったターゲットトラッキングポリシーを作成します。

aws application-autoscaling put-scaling-policy \
    --service-namespace ecs \
    --resource-id service/<cluster-name>/<service-name> \
    --scalable-dimension ecs:service:DesiredCount \
    --policy-name <policy-name> \
    --policy-type TargetTrackingScaling \
    --target-tracking-scaling-policy-configuration '{
        "TargetValue": <target-value>,
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
        }
    }' \
    --region <region>

AWS CloudFormation や AWS SDK からの設定も同様にサポートされています。

既存サービスを更新する

既存サービスへの適用は 2 ステップのプロセスです。まずモニタリング設定を変更してデプロイメントを完了させ、すべてのタスクが 20 秒解像度でメトリクスを送信するようになってから、スケーリングポリシーを設定します。デプロイメントが完了する前にポリシーを設定しようとしても、コンソール上では高解像度メトリクスの選択肢がグレーアウトされているため、順序を守って進めてください。

コンソールから設定する

サービスの Update フォームを開き、Monitoring configuration セクションで 20 秒解像度のメトリクス設定を追加して更新を実行します。デプロイメントの完了後、サービス詳細画面の Service auto scaling タブからスケーリングポリシーを作成し、高解像度メトリクスを指定します。

AWS CLI から設定する

update-service コマンドでモニタリング設定を更新し、デプロイメントの完了を待ちます。

aws ecs update-service --region <region> \
    --cluster <cluster-name> \
    --service <service-name> \
    --monitoring "metricConfigurations=[{metricNames=[CPUUtilization,MemoryUtilization],resolutionSeconds=20}]"

update-service および create-service のレスポンスにはモニタリング設定の内容が含まれません。設定が正しく反映されたかどうかは、デプロイメント完了後に describe-service-revisions コマンドで確認します。まず describe-services でアクティブなサービスリビジョンの ARN を取得し、次のコマンドを実行します。

aws ecs describe-service-revisions --region <region> \
    --service-revision-arns <service-revision-arn>

レスポンスに "resolutionSeconds": 20 が含まれていれば、モニタリング設定が正しく適用されています。

デプロイメントの完了後、スケーラブルターゲットとして登録します。

aws application-autoscaling register-scalable-target \
    --service-namespace ecs \
    --resource-id service/<cluster-name>/<service-name> \
    --scalable-dimension ecs:service:DesiredCount \
    --min-capacity <min-capacity> \
    --max-capacity <max-capacity> \
    --region <region>

続けてスケーリングポリシーを作成します。

aws application-autoscaling put-scaling-policy \
    --service-namespace ecs \
    --resource-id service/<cluster-name>/<service-name> \
    --scalable-dimension ecs:service:DesiredCount \
    --policy-name <policy-name> \
    --policy-type TargetTrackingScaling \
    --target-tracking-scaling-policy-configuration '{
        "TargetValue": <target-value>,
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
        }
    }' \
    --region <region>

動作確認

設定後は、CloudWatch コンソールの Metrics → All metrics → AWS/ECS → ClusterName, ServiceName から対象サービスのメトリクスを確認し、ピリオドを 20 秒に設定してデータポイントが 20 秒間隔で記録されていることを確認します。サービス詳細画面の Service auto scaling タブで、ポリシーのメトリクスタイプが ECSServiceAverageCPUUtilizationHighResolution または ECSServiceAverageMemoryUtilizationHighResolution になっていることも合わせて確認してください。

ベストプラクティスと注意点

クールダウン期間はより慎重に設定する

20 秒間隔でスケーリング判断が行われるようになると、従来の 60 秒間隔と比べてスケールイン・スケールアウトのトリガーが頻繁に発生します。適切なクールダウン期間を設定しないと、負荷の小さな揺らぎに反応してタスク数が短時間で増減を繰り返す「フラッピング」が起きます。

スケールインのクールダウン期間は特に余裕を持って設定することを推奨します。スケールアウトは素早く、スケールインは慎重に、という非対称な設計がフラッピング防止の基本です。スケールアウトとスケールインそれぞれのクールダウン期間を独立して調整できるため、サービスの特性に合わせてチューニングしてください。

まずは検証環境で試す

モニタリング設定の変更は新しいサービスリビジョンを作成し、デプロイメントをトリガーします。本番環境に直接適用するのではなく、開発・ステージング環境でスケーリングの挙動を確認してから展開することを推奨します。

CloudWatch でスケーリングの挙動を可視化する

CloudWatch ダッシュボードに CPU・メモリ使用率とタスク数を並べて可視化することで、スケーリングのトリガーから実際のタスク増加までの流れを確認できます。クールダウン期間やターゲット値のチューニングにも活用できます。スケーリングイベントが短時間に集中して発生している場合は、フラッピングのサインとして設定を見直す目安になります。

まとめ

本記事では、Amazon ECS の高速サービスオートスケーリングについて解説しました。20 秒間隔の高解像度メトリクスとメトリクス公開処理の最適化により、スケールアウトのトリガーまでの時間が 4.2 倍、タスク起動完了までの総時間が 3.5 倍に短縮され、突発的なトラフィックスパイクへの対応力が大きく向上しています。

一方で、すべての ECS サービスに適用すべきものではありません。高解像度メトリクスには追加の CloudWatch 料金が発生するため、コスト削減効果とのトレードオフを判断した上で、トラフィック変動が顕著なサービスへ検証環境から適用することをおすすめします。

本機能は全 AWS 商用リージョンおよび AWS GovCloud（US）リージョンで、AWS Fargate・Amazon ECS Managed Instances・Amazon EC2 のすべてのコンピュートオプションに対して利用可能です。

参考リンク