ECS Service Connect 完全攻略：コンテナポート名から通信の裏側まで徹底解説

AWS

ECSでのサービス間通信において、今や標準的な選択肢となった ECS Service Connect。 一見するとサイドカーコンテナが勝手にやってくれる便利な機能ですが、その裏側ではEnvoyプロキシとCloud Map、そしてLinuxのネットワーク機構が緻密に連携しています。

下記構成図をベースに、エンジニアが「裏側で何が起きているか」を把握できるレベルまで深掘りして解説していきます。



主要概念と使用されている技術の解説

用語を「情報の持ち主（Cloud Map）」と「情報の利用者（Service Connect）」に分けて整理します。

■ AWS Cloud Map：リソース情報の「台帳」

サービスの名前解決と稼働中のECSタスクのIPアドレス（ENI）を管理する基盤です。

  • Namespace（名前空間）
    Cloud Mapの基本単位です。サービスを論理的にグループ化する「区画」であり、Service Connectはこの区画を利用してサービスを識別します（例：local）。

  • Services（サービス） もしくは Discovery Name（検出名）
    台帳に登録されるサービス名です（例：backend-app-sc）。
    もう少し詳しく説明すると、Cloud Mapの階層構造におけるServices（サービス）の名前のことです。ECS Service Connectでは、この名前をキーにして通信先のタスク（サービスインスタンス）を探し出すため、Discovery Name（検出）と呼ばれます。

  • サービスインスタンス (Service Instance)
    台帳に載る「実際の宛先（IPアドレス）」です。ECSでは個々の「ECSタスク」に付与されるENIがこれに該当します。

  • ECSによるIPアドレスの自動登録・削除（情報の更新）
    ECSのコントロールプレーンが、ECSタスクのライフサイクル（起動・停止）を常に監視しています。
    • タスク起動時：即座にそのECSタスクのENI（プライベートIP）をCloud Mapへ登録。
    • タスク停止時：接続が切れる前に、Cloud MapからそのIPを削除。 これにより、「台帳」が常に最新の状態に保たれます。

■ ECS Service Connect：通信の「実行役」

Cloud Mapの台帳情報を読み取り、実際にパケットを正しく送り届ける仕組みです。

  • Service Connect プロキシ（Envoy）
    各タスクにサイドカーコンテナとして常駐するプロキシです。Cloud Mapの最新情報をリアルタイムで同期しており、存在しないIP（台帳から消えたIP）へのリクエストを物理的に防ぐ役割を担います。

  • DNS名（エンドポイント）
    FrontAppがリクエストを送る際の宛先です（例：backend.app.local）。 裏側では、そのリクエストをタスク内のEnvoyプロキシが取得（インターセプト）し、DNS名をDiscovery名へと変換して、実際の通信先を特定します。

  • 変換テーブル
    送信側のEnvoy（Frontend側）が持つ内部マップです。「アプリが叩くDNS名」を「Cloud Map上のServices（Discovery名）」に翻訳し、最新のIPリストと照らし合わせます。

  • コンテナポート名
    タスク定義で設定する識別子。受信側のEnvoy（Backend側）が「コンテナポート名からコンテナのどのポート」にパケットを届けるかを決定するための最終的なキーとなります。


通信の裏側

図の番号に沿って、パケットがFrontAppからBackAppへ届くまでの詳細に追っていきます。

①アプリケーションによるリクエスト発行
FrontApp コンテナ内で動くアプリケーションが、http://backend.app.local:8081 に対してHTTPリクエストを投げます。この時、アプリケーション自体は「相手がどのIPアドレスにいるか」を一切気にする必要はありません。

② Envoyによる通信のインターセプト（横取り）
リクエストがタスクの外に出ようとする瞬間、タスク内の Envoyプロキシ（サイドカー） がこのパケットを捕捉します。これはiptablesによって自動的に行われます。

③ Discovery名への変換とCloud Mapへの問い合わせ
Envoyは自身が持つ「変換テーブル」を参照し、リクエスト先の backend.app.local がどのDiscovery名（backend-app-sc）に対応するかを特定します。
その後、バックエンドとして稼働しているタスクの情報を取得するため、AWS Cloud Map に対して問い合わせを行います。

④ 動的なIPリストの取得と負荷分散
Cloud Mapから、現在ヘルスチェックに合格しているBackAppタスクのIPアドレスリスト（例：10.0.0.1, 10.0.0.2, 10.0.0.3）が返却されます。
Envoyはこのリストをメモリにキャッシュし、負荷分散アルゴリズム（ラウンドロビン等） に基づいて、今回リクエストを送るべき「たった一つのIP」を決定します。

⑤ Envoy間（サイドカーコンテナ間）のセキュアな通信
送り側のEnvoyは、決定したターゲットIP（Service Back側のENI）に向けてパケットを送信します。このパケットには「どのポート名宛の通信か」というメタデータが含まれた状態で、受け手側のEnvoyへと届けられます。
ここでの通信は 「Envoy ⇔ Envoy」 の形で行われるのがポイントです。これにより、通信の統計情報（レイテンシやエラー率）を双方向のプロキシが正確に記録できるようになります。

⑥ 最終的なアプリケーションへの到達
受け手側のタスクに届いたパケットは、まずそのタスク内の受信側Envoyが受け取ります。
受信側Envoyは、自身が管理する設定を参照し、「ポート名：backend-app-container」宛の通信は、タスク内のポート「8081」で待機しているコンテナへ渡すというルールに従い、パケットを BackApp コンテナへ流し込みます。これで通信が完了します。

なぜ「ポート名」を介するのか？

このフローにおいて、ポート名は「論理的な宛先」としての役割を担っています。

  • 疎結合の実現：バックエンドコンテナのポート番号が 8081 から 9000 に変更されたとしても、タスク定義の「ポート名」さえ変わらなければ、送信側（FrontApp）の設定やEnvoyの変換ルールを一切変更せずに通信を継続できます。
  • マルチポートへの対応：1つのタスク内で複数のポート（例：Web用と管理用）を公開している場合でも、ポート名によって正確に送り先を振り分けることができます。


ECS Service Connect を導入する3つの運用メリット

この複雑な裏側の仕組みが、私たちの運用を劇的に楽にしてくれます。

A. 「可観測性（Observability）」

Envoyが全ての通信を中継するため、アプリに手を加えずに CloudWatch で詳細なメトリクスを確認できます。

  • リクエスト成功率
  • レスポンスタイム（レイテンシ）
  • 接続エラー数 「どこで通信が詰まっているか」が一目でわかるようになります。

B. 「耐障害性（Fault Tolerance）」

ネットワークの瞬断や、特定のコンテナの反応が遅い場合、Envoyが肩代わりして以下の制御を行います。

  • 自動リトライ：失敗したリクエストを別の健全なタスクへ自動で再試行。
  • アウトライヤー検出：応答が異常に遅いタスクを一時的にIPリストから除外。

C. DNSキャッシュに縛られない「堅牢なデプロイ」

DNSのTTLの影響を受けません。ECSによる即座なInstance更新と連動して、安全なトラフィック切り替えを実現します。


まとめ：これからのECS運用のスタンダード

ECS Service Connectは、単なる「サービス発見器」ではありません。
図にあるように、EnvoyとCloud Mapが密に連携することで、「可視化・保護・確実なデプロイ」を自動化する強力な武器です。

この裏側の流れを意識してインフラを設計することで、トラブルに強く、スケーラブルなマイクロサービスを構築できるようになります。

AWS ECSスケーリングの極意：Fargate/EC2の境界線と「運用を劇的に楽にする」高度な設定群
AWS ECSにおけるFargateとEC2のスケーリング管理の違いを徹底解説！「2重のスケーリング」が必要なEC2運用を劇的に楽にするCapacity Providers（Managed Scaling/Draining）の仕組みや、Service Auto Scalingの正体まで、実務に役立つ知識を網羅した完全ガイドです。
skill-for-it.com
2026.03.09


参考記事

コメント

タイトルとURLをコピーしました