技術記事 2026/8/9

ECS Service ConnectのAZ優先ルーティングがデフォルト化 — エンドポイントがAZ数の2倍を割ると静かに均等配信へ戻る

2026年7月23日、Amazon ECS Service Connectがゾーン意識ルーティングに対応し、新規・既存の全サービスでデフォルト有効になりました。同一AZ優先と残余容量による按分の仕組み、そして閾値割れで自動的に無効化される挙動と監視方法を公式仕様に沿って解説します。

#Amazon ECS
#Service Connect
#AWS Fargate
#コスト最適化
#SRE

Amazon ECSでサービスを複数のアベイラビリティゾーン（AZ、障害の切り分け単位となるデータセンター群）に分散させると可用性は上がりますが、サービス間の通信がAZをまたぐたびにデータ転送料金とレイテンシ（応答にかかる時間）が発生します。2026年7月23日、AWSはAmazon ECS Service Connectに**ゾーン意識ルーティング（zone-aware routing）**を追加し、新規・既存のすべてのサービスでデフォルト有効にしました。本記事では、このルーティングが何を基準にトラフィックを振り分けるのか、そして運用で見落としやすい「エンドポイント数が閾値を割ると警告なく無効化される」挙動をどう監視するかを、公式仕様に沿って解説します。対象読者は、ECS／Fargateでサービス間通信を設計するSRE・プラットフォームエンジニアです。

Service Connectとは — サービス間通信を「ECSの設定」として持つ

すでにService Connectを本番で使っている方は、この節を読み飛ばしても差し支えありません。

Amazon ECS Service Connectは、サービス間通信の管理をECSの設定として扱う機能です。公式ドキュメントの表現では、サービスディスカバリ（相手のサービスの居場所を見つける仕組み）とサービスメッシュ（通信の制御・可観測性をアプリの外側で担う層）の両方をECS内に構築します。

仕組みの中心はプロキシコンテナです。Service Connectを有効にしたサービスでは、各タスクの中にプロキシコンテナが1つ追加され、アプリケーションからの通信をこのプロキシが受け取って相手サービスのプロキシへ中継します。呼び出し側は mysql や checkout といった短い名前で相手を指定するだけでよく、VPCのDNS設定に依存しません。名前空間の実体にはAWS Cloud Mapが使われ、同じ名前空間に属するサービス同士だけが相互に接続されます。

このプロキシは従来、ラウンドロビン（相手のエンドポイントを順番に一巡する方式）と、過去の失敗情報にもとづく外れ値検出を組み合わせて接続先を選んでいました。つまり、接続先がどのAZにあるかは考慮していませんでした。

料金面では、Service Connect自体に追加料金はなく、Cloud Mapの利用分も無料です。ただしプロキシエージェントはタスクの内部で動くため、その分のvCPU・メモリはタスクのリソースとして消費されます。

クロスAZ通信で何が起きているか

可用性のためにサービスを複数AZへ分散させるのは定石ですが、そのときサービス間通信は自動的にAZをまたぎます。ここには2つのコストがかかります。

1つはデータ転送料金です。AWSではAZをまたぐデータ転送に追加料金が発生します。サービス間で大量のデータをやり取りするワークロードほど、この積み上がりが効いてきます。

もう1つはレイテンシです。AWS公式ブログによれば、同一AZ内の通信は300〜400マイクロ秒（μs）程度まで下がる一方、クロスAZの呼び出しは1.5ミリ秒以上になります。1回あたりの差は小さく見えますが、1リクエストの処理で内部サービスを何度も呼ぶ構成では、この差が積算されて応答時間に現れます。

従来のラウンドロビンは接続先のAZを区別しないため、エンドポイントがAZ間で均等に散っている3AZ構成であれば、単純計算で約3分の2の通信がAZ境界をまたぐことになります。ゾーン意識ルーティングは、この割合を引き下げるための機能です。

何が変わったか — 同一AZ優先がデフォルトになった

2026年7月23日の発表で、Service Connectのプロキシは接続先のAZを考慮するようになりました。公式ドキュメントによれば、実装にはEnvoyプロキシが持つゾーン意識ルーティング機能が使われています。

まず押さえておきたいのは適用範囲です。この挙動は新規・既存を問わずService Connectを使うすべてのサービスでデフォルトで有効であり、インフラやアプリケーションコードの変更は不要です。追加コストもかかりません。提供範囲は、Service Connectがサポートされる全AWS商用リージョンおよびAWS GovCloud (US) リージョンです。すべての起動タイプで動作し、AWS Resource Access Manager（RAM）で共有したクロスアカウントの名前空間とも互換性があります。

ルーティングの判断は、次の4ステップで行われます。

3つのAZに送信元と宛先のタスクが分散する図。各AZ内で同一AZ優先に通信し、宛先の割合が送信元を上回るAZ-cが残余容量として越境分を吸収する。判断の4ステップ（エンドポイント検出／同一AZ優先／残余容量ルーティング／オーバーロード保護とフォールバック）も併記 — 図1: 同一AZ優先と、残余容量を持つAZへの越境分の按分

第1にエンドポイント検出で、宛先サービスの全エンドポイントとそのAZ配置を把握します。第2に同一AZ優先で、送信元（クライアント側）と宛先（サーバ側）のエンドポイント分布の比率から、同一AZに留める割合を算出します。第3に残余容量ルーティングです。ここが単純な同一AZ固定と異なる点で、同一AZに収まらないトラフィックは、各AZの「残余容量」に応じて按分されます。宛先側のエンドポイント割合が送信元側を上回るAZは正の残余容量を持ち、その余力がほかのAZからの越境トラフィックを引き受けます。エンドポイントが増減すると、プロキシはこの重みをリアルタイムに再計算します。第4にオーバーロード保護とフォールバックです。単一AZへの負荷集中を防ぐしくみで、閾値を下回ると自動的にラウンドロビンの均等配信へ切り替わります（具体的な閾値と運用上の注意点は次節で扱います）。同一AZのエンドポイントが利用不能になった場合も、この保護によってほかのAZへ自動的に再分配され、可用性が保たれます。

効果の目安として、AWSはエンドポイントがAZ間でバランスしている場合に80%超のトラフィックが同一AZ内に留まり、マルチAZ構成における中央値のネットワークレイテンシが約24%削減されると公表しています。これらはAWS公式ブログおよびドキュメントに記載された値であり、エンドポイントの偏りやワークロードの性質によって変動するため、自環境で同じ数値が保証されるものではありません。

なお、既存サービスについては注意点があります。クライアント側・サーバ側の両方で1回限りの再デプロイが必要で、これを行うまで新しいルーティング挙動は有効になりません。初回の再デプロイさえ済ませれば、以降はエンドポイントの増減に応じて自動で調整され、追加の再デプロイは不要です。

実務で使うときの注意点 — 閾値割れは警告なしに起きる

この機能で最も見落としやすいのが、有効化の条件です。

閾値による切り替わりを示す図。3AZ構成で宛先が6タスク以上なら有効、5タスク以下ならエラーなくラウンドロビンの均等配信へ戻る。監視手段としてEnvoy統計・VPC Flow Logs・Cost Explorerを併記 — 図2: 閾値を割ると自動でラウンドロビンへ戻る。監視の手段は3つ

単一AZへの負荷集中を防ぐため、プロキシは宛先サービスに少なくともAZ数の2倍のエンドポイントがあることを要求します。3AZのリージョンであれば最低6エンドポイントです。この閾値を下回るとゾーン意識ルーティングは自動的に無効化され、トラフィックはラウンドロビンで全AZへ均等に配信されます。閾値はEnvoyプロキシの内部で強制されており、利用者が設定で変更することはできません。エンドポイント数が閾値を超えれば自動的に再び有効化されます。

運用上やっかいなのは、この切り替わりがエラーにならない点です。可用性は保たれたまま、コスト削減とレイテンシ改善の効果だけが静かに失われます。オートスケーリングの縮退や、夜間・休日の最小タスク数への収束で閾値を割った場合、何も気づかないままクロスAZ転送料金が元に戻っている状況が起こり得ます。設計としては、宛先サービスの最小タスク数をAZ数の2倍以上に設定しておくのが素直な対処です。

有効に働いているかは、次の3つで確認できます。

手段	対象	見るもの
Envoyプロキシの統計	EC2上のDockerランタイム	`lb_zone_routing_cross_zone` と `lb_zone_cluster_too_small`
VPC Flow Logs	Fargate・containerdを含む全構成	`az-id` フィールドで同一AZとクロスAZの比率を測る
AWS Cost Explorer	全構成	再デプロイ前後のクロスAZデータ転送料金の推移

EC2でDockerランタイムを使っている場合は、Systems Manager Session Managerでコンテナインスタンスに接続し、エージェントコンテナ内からEnvoyの管理インターフェースに問い合わせて統計を取得します。健全な状態では両方がゼロです。

cluster.my-service.lb_zone_routing_cross_zone: 0
cluster.my-service.lb_zone_cluster_too_small: 0

lb_zone_cluster_too_small は閾値を下回ってバイパスされた回数なので、継続的に非ゼロなら閾値割れが常態化していると判断できます。デプロイ直後に非ゼロになるのは想定内で、エンドポイントが健全になるにつれて解消します。Fargateやcontainerdを使う構成ではエージェントコンテナへシェルで入れないため、VPC Flow Logsの az-id フィールドを使う方法が公式に案内されています。

まとめ

本記事のポイントを3つに整理します。

ゾーン意識ルーティングは新規・既存の全サービスでデフォルト有効になりました。 追加コストはありませんが、既存サービスはクライアント・サーバ双方で1回限りの再デプロイが必要です。
仕組みは単純な同一AZ固定ではなく、分布比にもとづく按分です。 収まらない分は宛先側の割合が送信元を上回るAZ（残余容量）へ振り分けられます。効果の目安は同一AZ内80%超・中央値レイテンシ約24%削減（AWS公表値）です。
宛先のエンドポイント数がAZ数の2倍を割ると自動的に無効化されます。 エラーは出ないため、最小タスク数を閾値以上に設定し、Envoy統計やVPC Flow Logsで実際の同一AZ比率を確認しておく必要があります。