本記事は、CyberAgent Group SRE Advent Calendar 2024の25日目の記事になります。

本記事では、ECSサービス間通信の選択肢である ALB、VPC Lattice、ECS Service Discovery、ECS Service Connect、App Mesh(終了予定) の5点を比較します。

App Mesh終了告知やre:Invent 2024でのVPC Lattice強化(ECSネイティブ統合,TCPをサポート)を受け、今後のECSサービス間通信の在り方が気になったため整理しました。

※ 本記事の内容は、2024/12/18時点での仕様に基づいています。

先にまとめ

	ALB	VPC Lattice	ECS Service Discovery	ECS Service Connect	App Mesh（終了予定）
一言で	安定&汎用的	なんでも繋ぐALBの進化系	シンプル名前解決	ECS特化で簡単&多機能	複雑&多機能メッシュ
登場(GA)	2016年	2023年	2018年	2022年	2019年
構築・管理の容易さ	中程度	中程度	👍👍簡単	👍簡単め	👿👿複雑
💰費用	時間+LCU	時間+通信量+リクエスト数	👍👍激安	サイドカー	サイドカー
🔭ログ・メトリクス	👍対応	👍対応	👿なし	👍対応	👍対応
🔭トレース	👿なし	👿なし	👿なし	👿なし	👍対応
🛡️ヘルスチェック	👍対応	👍対応	👍対応(コンテナレベル)	👍一応対応^[1]	👍対応
🛡️自動リトライ	👿なし	👿なし	👿なし	👍対応	👍対応
🛡️サーキットブレーカー	👿なし	👿なし	👿なし	一部 (外れ値検出)	👍対応
🚢対応デプロイタイプ	👍全て	一応全て	👍全て	👿`ECS`のみ	👍全て
🚢Canaryのやりやすさ	👍容易	👍容易	👿どうにか	👿不可	👍容易
🐙ECS以外からの名前解決	👍可能	👍可能	👍可能	👿不可	👍可能
🐙VPC間通信	👍可能(要VPC Peering等)	👍👍得意	~~👿不可~~ 👍可能(要VPC Peering等)	👍可能	👍可能
🐙アカウント間通信	👍可能(要VPC Peering等)	👍👍得意	~~👿不可~~ 👍可能(要VPC Peering等)	👿不可	👍可能

選定基準の一例を示します。

「それなりに機能揃ってて、使い慣れてて、今後も消えないのがいい」
-> ALB
「ECS以外にもEKSやLambda等色々使ってて、かつ多くのVPC/アカウント同士を繋げたい」
-> VPC Lattice
「シンプルに名前解決できればOK。信頼性・可観測性は不要or自前実装する」
-> Service Discovery
「ECS間を信頼性・可観測性高く繋げたい。ECS以外との通信は少ないから別途考える」
-> Service Connect
「マイクロサービスの数が多く、信頼性・可観測性へのこだわりが強い。ECS以外も繋ぐ」
-> App Mesh （終了予定なので、VPC Latticeか、Service Connect+αか...）

そもそもECSのサービス間通信とは

ECSサービス->ECSサービスの通信を指します。

ECSサービス間通信

単に「アクセス先をどう見つけるか」だけでなく、「アクセス先が落ちていたらどうするか」「通信の可観測性はどうか」など、様々な考慮事項があります。

実際にはLambdaやEC2からECSにアクセスする場合もあるので、本記事では比較観点の一つとして触れます。

各通信方法の概要

1. ALB

ALBはL7のLBで、ECS以外との接続にも利用可能です。
最も"枯れて"いて情報量が多い点と、「ALBがサービス終了することはないだろう」という安心感が強みだと思います。

接続方法

サービス間通信用のALBを構築し、そのドメイン名でアクセスします。

ALBでのサービス間通信

ALBにパスベースでルーティングルールを複数設定すれば、ALBを大量に作らずに済みます。

例）　/web なら service-webへ、 /app なら service-appへ

2. VPC Lattice

VPC LatticeはALBを抽象化したようなアプリケーション接続サービスで、2023年3月にGAしました。
EC2、EKS、Lambdaも接続でき、VPCまたぎやアカウントまたぎが強みです。

接続方法

Lattice Serviceのドメイン名+ポートでアクセスし、
Listenerで定義されたLattice Target Groupに紐づくECSサービスにアクセスします。

VPC LatticeによるECSサービス間連携

Lattice Service Network: Lattice Serviceの論理的な集合
Lattice Service: 「ALB一つ」に近く、ドメイン名や複数のListenerを持てる
Lattice Target Group: ELBのターゲットグループとほぼ同じだが、互換性はない

ECSとのネイティブ統合前

従来はECSの前段にALBが必要でしたが、2024/11/18のアップデートにより不要になりました。

従来: ECSの前段にALBが必要だった

複数のECSサービスを紐付ける

各ListenerにはALB同様に複数のListenerRuleを設定できます。
パスベースのルーティングを設定することで、1つのLattice Serviceに複数のECSサービスを紐づけられます。

1つのLattice Serviceに複数のECSサービスを紐づける

これにより管理性向上に加えてコスト低下が見込めます。
後述しますが、Lattice Service1つ毎に時間課金が発生するためです。

その他の特徴

IAM認証によって通信元を制限することも可能です。
- https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html
TCP対応したので、DBなどにもアクセスできます。（ただし高価）
- https://aws.amazon.com/jp/about-aws/whats-new/2024/12/vpc-lattice-tcp-vpc-resources/

3. ECS Service Discovery

ECS Service Discovery(サービス検出)は、簡単な名前解決機構を提供します。
信頼性や可観測性関連がほとんどないかわりに、シンプルかつ安価で済みます。

接続方法

クライアント側が<サービスのnamespace>.<hosted-zone名>で名前解決し、バックエンドのTaskのIPアドレスを取得する
そのIPアドレスを使ってアクセスする

Service Discoveryの概観

他の方法と異なり、コンテナが対向サービスに対して直接通信できます。

4. ECS Service Connect

Service Connectは、ELB + Service Discovery + App Meshの折衷として2022年11月に登場しました。
ECS->ECSに特化している点と、簡単な設定で信頼性・可観測性周りを整備できる点が特徴です。

詳細はこちらをご覧ください。

接続方法

Envoyベースのサイドカーコンテナ（Service Connect Agent）が通信を代行します。
Cloud Mapへの登録、Cloud Mapを介したアクセス先の検出、アクセスを自動でやってくれます。

Service Connectの概観

余談）LambdaやVPC Latticeとの統合

Service ConnectとLambdaと統合したりVPC Latticeと統合するリクエストが上がっています。
思想や仕組み的に困難な可能性もありますが、実現されるとService Connectの可能性が一気に広がると思います。

5. App Mesh （サービス終了予定）

App Meshは多機能なサービスメッシュを提供するサービスで、
[1]Envoyのマネージドコントロールプレーンと[2]Envoyサイドカーコンテナからなります。

2026/09/30をもってサービス終了することがアナウンスされています。移行先として以下の2つが推奨されていそうです。

接続方法

Service Connect同様、サイドカーが色々やってくれます。
サービス終了予定のため、仕組みの詳細は割愛します。

App Meshの概観

観点ごとに比較

ここからは基本的にApp Meshには触れません。
サービス終了予定である上に、複雑性以外では概ね強力だからです。

費用💰

	ALB	VPC Lattice	👑ECS Service Discovery	ECS Service Connect	App Mesh
費用	時間+LCU	時間+通信量+リクエスト数	👍👍激安	サイドカー	サイドカー

Service Discoveryはサイドカーなども存在しないので、圧倒的に安いです
ALBはLCU単位の複雑な費用計算が必要です
VPC LatticeはLattice Service毎に時間課金があります
- 時間課金のみで1Service月額約¥3.5kかかります（$0.0325/h x 24 x 30 x ¥150/$）
- ECSサービス毎にLattice Serviceを作るのではなく、複数のECSサービスを1つのLattice Serviceに紐づけるのが費用面では良さそうです（ALBと同様）
Service Connectはサイドカーのリソースに課金されます
- サイドカーの最低推奨スペックをx86のFargateで動かすと、1タスクあたり月額約¥1.4kかかります ($0.05056/h x 0.25 x 24 x 30 x ¥150/$)^[2]
- もちろん、トラフィックによってはより大きなサイズが必要になりえます
- タスク数が多い場合、費用的に不利かもしれません

可観測性🔭

	ALB	VPC Lattice	ECS Service Discovery	ECS Service Connect	App Mesh
ログ・メトリクス	👍対応	👍対応	👿なし	👍対応	👍対応
トレース	👿なし(IDは付与される)	👿なし	👿なし	👿なし	👍対応

Service Discoveryは思想的に可観測性を削っていて、今後も対応はないと思います
トレースはApp Meshの独擅場で、EnvoyサイドカーによってX-RayやDatadog等にデータを送信できました
Service ConnectもEnvoyベースなので、今後トレースが対応される可能性もあると思います
- リクエストも上がっています
  https://github.com/aws/containers-roadmap/issues/2369
ALBはリクエストヘッダーにX-Amzn-Trace-Idが付与されますが、これ単体ではリッチな分散トレーシングはできません

信頼性🛡️

	ALB	VPC Lattice	ECS Service Discovery	👑ECS Service Connect	App Mesh
ヘルスチェック	👍 対応	👍対応	👍対応 (コンテナレベル)	👍一応対応^[1:1]	👍対応
自動リトライ	👿 なし	👿なし	👿なし	👍対応	👍対応
サーキットブレーカー	👿 なし	👿なし	👿なし	一部(外れ値検出)	👍対応

ヘルスチェックは不可欠と思いますが、自動リトライやサーキットブレーカーは必須ではないと思います
Service Connectが自動リトライと外れ値検出の点で優位です
- 自動リトライでは、失敗したタスクとは別のタスクにリトライされます
App Meshのサーキットブレーカーは、[1]外れ値検出 +[2]接続プールからなるようです
- 外れ値検出(outlier detection): 実トラフィックを監視して、エラーが多いホストへのルーティングを止める
- 接続プール: 同時接続数またはリクエスト数を制限

[2025-06-23 追記] ALB の Automatic Target Weights 機能は、サーキットブレーカーに近いと思います。

デプロイ🚢

	👑ALB	VPC Lattice	ECS Service Discovery	ECS Service Connect	App Mesh
対応デプロイタイプ	👍 全て	一応全て	👍全て	👿`ECS`のみ	👍全て
Canaryのやりやすさ	👍 容易	👍容易	👿どうにか	👿不可	👍容易

※ ECSのデプロイタイプは、ECS(ローリングアップデート)、CODE_DEPLOY(Blue/Green)、EXTERNAL(外部デプロイ)の3種です。

ALBが最も扱いやすいです。ECSとよく統合されていて、制約が少ないです
VPC LatticeはListenerRuleを操作することでALB同様にCanaryが可能です
- Internal-ALBを配置する場合は、結局ALBなのですべてのデプロイタイプに対応でき、柔軟なデプロイを実現できます
- ただしECSとのネイティブ統合においてはECSデプロイタイプしか選択できません
Service Discoveryはすべてのデプロイタイプに対応しているものの、ルーティングを柔軟に制御する機構がないため、Canaryは困難です^[3]
Service ConnectはECSデプロイタイプしか使えず、デプロイの自由度は低いです。

接続相手の幅広さ🐙

	ALB	👑VPC Lattice	ECS Service Discovery	ECS Service Connect	App Mesh
ECS以外からの名前解決	👍可能	👍可能	👍可能	👿不可	👍可能
VPC間通信	👍可能(要VPC Peering等)	👍👍得意	~~👿不可~~ 👍可能(要VPC Peering等)	👍可能	👍可能
アカウント間通信	👍可能(要VPC Peering等)	👍👍得意	~~👿不可~~ 👍可能(要VPC Peering等)	👿不可	👍可能

VPC Latticeのアイデンティティであり、最も得意とする領域です
ALBは通常のVPC内リソースであり、VPCやアカウントを跨ぐ際にはVPC Peeringなどの補助が必要です
~~Service DiscoveryはVPCやアカウントを跨げませんが、それゆえにシンプルさを保てると思います~~
- [2025-06-23訂正] Service Discoveryは下記のようにすればVPCやアカウントを跨げます。
  - VPC Peering等によるVPCの疎通性確保
  - Route53のHosted ZoneをVPC関連付けする
  - 参考: https://repost.aws/ja/knowledge-center/fargate-service-discovery-cloud-map
- ただしクロスアカウントに関しては、ログ・メトリクスがないのはトラブルシューティングや監査等で困るので、あまり向いてないと思います。
Service ConnectはECS特化であり、最も限定的です
- 「外部からECSへの最初の入り口」は別の方法が必要です
- クロスアカウント通信はいずれサポートされるかもしれません
  https://github.com/aws/containers-roadmap/issues/2148

おわりに

費用面や複雑さを考慮すると、「そもそもECSサービス間通信を減らす」という選択肢もある気がします。

VPC LatticeとService Connectの成長に今後も注目したいです。

脚注

現状では「タスクがHEALTHYになる前でもルーティングされる」ケースがあるようです https://github.com/aws/containers-roadmap/issues/2334 ↩︎ ↩︎
サイドカー用にタスク毎に最低 256CPU(=0.25vCPU)と64MiB の追加が推奨されています。https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-connect-concepts-deploy.html#service-connect-concepts-proxy ↩︎
強引な方法はこちらを参照してください https://qiita.com/t-kikuc/items/69957ee2c6b490a01b6d ↩︎

Discussion