はじめに
2026 年 7 月 1 日、AWS は Amazon ECS Service Connect に対して Zone-Aware Routing を発表しました。サービス間通信において同一 AZ 内のエンドポイントを優先する、新しいルーティング機能です。
マルチ AZ 構成で ECS Service Connect を運用している方の中には、可用性のために複数 AZ にタスクを分散させた結果、意図せずクロス AZ 通信が増え、データ転送コストがじわじわと膨らんでいた、という経験がある方も多いのではないでしょうか。今回のアップデートは、その課題に応えるものです。
ECS Service Connect を運用しているインフラ・SRE エンジニアの方や、クラウドコストの最適化に関心のあるマネジメント層の方に向けて、仕組みと有効化の手順、効果の測定方法をまとめます。
何が変わったのか
| 項目 | 従来（Zone-Aware Routing 適用前） | Zone-Aware Routing 適用後 |
|---|---|---|
| ルーティング方式 | AZ を考慮せず、エンドポイントへ均等に振り分け | 同一 AZ 内のエンドポイントを優先的に選択 |
| クロス AZ 通信 | AZ をまたぐ通信が高頻度で発生 | 同一 AZ 内で完結する通信が大半を占める |
| コストと可用性の関係 | マルチ AZ 構成にするほどクロス AZ 転送コストが増加するトレードオフ | 同一 AZ 優先でコストを抑えつつ、マルチ AZ の可用性も維持 |
| 有効化に必要な作業 | ー | 新規サービスはデフォルトで有効、既存サービスは一度の再デプロイのみ |
従来の課題
ECS Service Connect はこれまで、リクエスト元のタスクがどの AZ にあるかを考慮せず、宛先サービスのエンドポイントへ均等にトラフィックを振り分けていました。そのため、可用性を高めるために各サービスをマルチ AZ に分散配置するほど、AZ をまたぐ通信が増え、クロス AZ データ転送コストが積み上がっていくという構造がありました。
AWS のクロス AZ データ転送料金は片道 0.01 USD/GB、往復で 0.02 USD/GB が目安です。1 回あたりは小さな金額でも、マイクロサービス間の呼び出しが多いアーキテクチャでは通信量が膨大になり、月単位で見ると無視できないコストになります。つまりこれまでは、高可用性のためのマルチ AZ 構成と、コスト最適化が両立しづらいトレードオフの関係にありました。
Zone-Aware Routing は、このトレードオフの解消を狙ったアップデートです。
仕組み
Zone-Aware Routing は、Service Connect のプロキシに組み込まれた Envoy の zone-aware routing 機能を利用して、エンドポイントの所在 AZ に基づいたルーティングを行っています。処理の流れは大きく 4 つのステップに分かれます。
1. エンドポイントの検出
プロキシが宛先サービスの利用可能なエンドポイントと、それぞれの配置 AZ を検出します。
2. 同一 AZ の優先
リクエスト元（クライアント）と宛先（サーバー）の AZ ごとのエンドポイント分布比率に基づいて、同一 AZ 内にとどめられるトラフィックの割合を計算します。エンドポイントが各 AZ に均等に分散している場合、同一 AZ 内のトラフィックは 80 % を超えるのが一般的です。
3. 残余キャパシティに応じたクロス AZ 分散
同一 AZ 内で処理しきれないトラフィックは、他の AZ の残余キャパシティに応じて振り分けられます。プロキシは各ゾーンの残余キャパシティを計算し、正の残余キャパシティを持つゾーンにクロス AZ トラフィックを比例配分します。エンドポイントのスケールアウト・スケールインに応じて、ルーティングウェイトはリアルタイムに再計算されます。
4. 過負荷防止とフォールバック
特定の AZ への過負荷を防ぐため、宛先サービスには AZ 数の 2 倍以上のエンドポイント数が必要です。たとえば 3 AZ のリージョンであれば、最低 6 エンドポイントが目安になります。この閾値を下回ると Zone-Aware Routing は一時的に無効化され、トラフィックは通常のラウンドロビン方式で均等に分散されます。エンドポイント数が閾値を超えると、ルーティングは自動的に再度有効化されます。また、同一 AZ 内のエンドポイントが利用不可になった場合も、他の AZ へトラフィックが再分散され、可用性が維持されます。
この一連の処理はすべて Envoy サイドカープロキシ側で完結しており、アプリケーションコードの変更や追加のインフラ構築は必要ありません。
有効化と効果測定
有効化
Zone-Aware Routing は、Service Connect を利用する新規サービスではデフォルトで有効になっています。既存サービスの場合は、クライアント・サーバー双方のサービスを一度だけ再デプロイすることで有効化されます。追加の設定変更やアプリケーションコードの修正は不要です。
aws ecs update-service \
--cluster <cluster-name> \
--service <service-name> \
--force-new-deployment
初回の再デプロイ以降は、エンドポイントの増減に応じてルーティングが動的に調整されるため、再デプロイを繰り返す必要はありません。
動作確認
確認方法は、コンテナランタイムによって異なります。
Amazon EC2 ＋ Docker ランタイムの場合
Service Connect エージェントコンテナ内の Envoy プロキシの統計情報を確認することで、Zone-Aware Routing が機能しているかを確認できます。
-
AWS Systems Manager Session Manager でコンテナインスタンスに接続します。
aws ssm start-session --target <instance-id> -
Service Connect エージェントコンテナ内でシェルを開きます。
sudo docker exec -it $(sudo docker ps --filter "name=ecs-service-connect" -q | head -1) /bin/sh -
Envoy の管理インターフェースからゾーンルーティングの統計を取得します。
curl --unix-socket /tmp/envoy_admin.sock http://unix/stats | grep "lb_zone"
Zone-Aware Routing が正しく機能していれば、次のように lb_zone_routing_cross_zone が 0 になります。
cluster.<my-service>.lb_zone_routing_cross_zone: 0
cluster.<my-service>.lb_zone_cluster_too_small: 0
| メトリクス | 意味 |
|---|---|
| lb_zone_routing_cross_zone | 別 AZ のエンドポイントへルーティングされたリクエスト数。0 が継続していれば、すべての通信が同一 AZ 内に収まっていることを示す |
| lb_zone_cluster_too_small | エンドポイント数が閾値を下回り、Zone-Aware Routing がバイパスされた回数。デプロイ直後に 0 でないのは想定内で、エンドポイントが安定すれば 0 に収束する |
AWS Fargate ／ containerd ランタイムの場合
これらの環境では Envoy の統計情報に直接アクセスできないため、後述の VPC Flow Logs でルーティング挙動を確認します。
効果測定
有効化の効果は、Amazon VPC Flow Logs と AWS Cost Explorer を組み合わせて確認できます。VPC Flow Logs は az-id フィールドを使うことで、各トラフィックがどの AZ から発生し、どの AZ で終端しているかをネットワークレベルで確認でき、同一 AZ 内通信とクロス AZ 通信の比率を測定できます。さらに AWS Cost Explorer で Zone-Aware Routing 有効化前後のクロス AZ データ転送料金を比較すれば、コスト削減効果を金額として定量的に確認できます。
再デプロイ直後に一度確認するだけでなく、サービスのスケールイン・スケールアウトが発生した後にも同様の確認を行うと、動的なルーティング調整が意図通りに機能しているかを継続的に把握できます。
活用シーン
効果が大きい構成
Zone-Aware Routing は Service Connect を使っていれば自動的に恩恵を受けられる機能ですが、特に効果が大きく現れるのは、商品検索・在庫確認・決済処理のように 1 つのリクエストの中で複数のサービスを連鎖的に呼び出すマイクロサービス構成です。各サービスを各 AZ に均等に配置しておけば、リクエストチェーンが同一 AZ 内で完結しやすくなり、クロス AZ 転送コストとレイテンシの両方を同時に抑えられます。呼び出し回数が多いシステムほど、1 リクエストあたりのわずかな削減が積み重なって効果が大きくなります。
同様の理由で、取引処理のようにレスポンスタイムが重要な処理、多数のテナントがバックエンドを横断してアクセスするマルチテナント SaaS、複数ステージを順番に処理するデータパイプラインなども、サービス間通信量が多い構成として効果を実感しやすい部類に入ります。
効果が限定的なケース
サービス間の呼び出し回数が少ない構成や、単一 AZ 運用に近い構成では、そもそもクロス AZ 通信自体が少ないため、コスト削減効果は限定的です。マルチ AZ で Service Connect を使っている場合は、まず有効化してみて、効果を測定してみるとよいでしょう。
まとめ
Zone-Aware Routing は、ECS Service Connect のサービス間通信において同一 AZ 内のエンドポイントを自動的に優先し、クロス AZ データ転送コストとレイテンシを削減する機能です。
AZ をまたぐ通信のコストと可用性のトレードオフは ECS 固有の課題ではなく、AWS の他サービスでも AZ を意識したルーティングが広がりつつある流れの一つです。その中でも、アプリケーション側の変更なしに同一 AZ 優先と自動フェイルオーバーを両立させている点が、今回のアップデートの特徴です。
マルチ AZ で ECS Service Connect を運用している場合は、まず既存サービスを再デプロイし、効果を確認してみることをおすすめします。