AWS App Meshとは？サービスメッシュの仕組みと2026年9月終了・移行先の選び方【2026年版】

AWS App Meshは、マイクロサービス間の通信を各サービスの外側に置いたプロキシで一元的に制御する、マネージド型のサービスメッシュです。アプリのコードを書き換えずに、トラフィックのルーティング・リトライ・可観測性・暗号化をインフラ側へ寄せられる点が特徴でした。ただしAWSはApp Meshのサービス終了を公表しており、2026年9月30日をもって停止する予定です。この記事では、App Meshが何をどう実現していたのかをEnvoyプロキシと構成要素の目線で整理したうえで、終了スケジュールとECS Service Connect・VPC Lattice・Istioという移行先の選び分けを、実装者が採否を決められる形で判断します。前提となるサービスメッシュという仕組みそのものを押さえてから読み進めると、移行先の比較が理解しやすくなります。

まとめ：App Meshは「Envoyで通信を制御するメッシュ」だが2026年9月で終了する

App Meshの本質は、各マイクロサービスの隣にEnvoyプロキシをサイドカーとして配置し、サービス間の全通信をそのプロキシに通すことで、通信制御をアプリから切り離す点にあります。重み付けルーティングやリトライ、タイムアウト、外れ値検出、Envoy間のmTLS暗号化、CloudWatchやX-Rayへの可観測性データ送出を、コード変更なしに設定で実現できました。

一方で運用上の最大の論点は、機能ではなく製品のライフサイクルです。AWSは2024年9月24日に新規顧客のオンボードを停止し、2026年9月30日にApp Mesh自体を終了すると公表しています。したがって、これから新規に採用する選択肢からは外れ、既存利用者は終了前に移行を完了させる作業が必要になります。

判断の軸は明快です。新規構築ならApp Meshは選ばず、ECSならService Connect、複数VPC・複数アカウント間の通信ならVPC Lattice、EKSで高度なトラフィック制御が要るならIstioやLinkerdを選びます。既存のApp Mesh利用者は、稼働環境がECSかEKSか、通信要件がどこまで高度かで移行先を振り分け、2026年9月30日から逆算して計画を立てます。

AWS App Meshの定義とEnvoyで通信を制御する仕組み

まず、App Meshが「何を」「どうやって」制御していたのかを、サービスメッシュの考え方からデータプレーンの実体まで順に見ていきます。

マイクロサービス間通信をアプリの外側で制御するサービスメッシュの定義

サービスメッシュは、マイクロサービス同士の通信を担う専用のインフラ層です。各サービスにサイドカープロキシを添え、サービス本体の代わりにプロキシ同士が通信することで、ルーティングや再送、暗号化、計測といった横断的な処理をアプリのコードから分離します。App Meshは、この仕組みをAWSがマネージドで提供するサービスでした。メッシュの考え方そのものはサービスメッシュの解説記事で体系立てて整理しています。

App Meshが動く場所は幅広く、Amazon ECS、AWS Fargate、Amazon EKS、EC2上のKubernetes、EC2上のアプリのいずれにも対応していました。Kubernetesで組んだ環境でも、ECSで組んだ環境でも、同じメッシュの抽象で通信を扱える点が導入時の訴求でした。

コントロールプレーンとデータプレーンという2層構造とEnvoyサイドカー

App Meshは、設定を管理する「コントロールプレーン」と、実際に通信を運ぶ「データプレーン」の2層で構成されます。コントロールプレーンはAWSがマネージドで運用し、利用者はメッシュの構成要素を定義するだけで済みました。データプレーンの実体は、各サービスの隣で動くEnvoyプロキシです。

Envoyは、CNCFがホストするオープンソースの高機能プロキシで、サービスメッシュのデータプレーンとして広く採用されています。App Meshでは、利用者が定義した構成をAWSがEnvoyの設定へ変換し、各サイドカーへ配布する形をとりました。アプリはローカルのEnvoyに向けて通信を出すだけで、相手の発見・再送・暗号化はEnvoyが肩代わりします。この分離によって、通信ポリシーの変更をアプリのリリースから切り離せた点が価値でした。

App Meshの構成要素とVirtual Node・Routerの関係

App Meshは、通信の論理構造を次の抽象で表現します。それぞれが何を指すのかを押さえると、設定の全体像がつかめます。

たとえば「注文サービスから決済サービスを呼ぶ」通信は、決済のVirtual Serviceを宛先に指定し、その裏でVirtual Routerが本番版と新版のVirtual Nodeへ重みを付けて振り分ける、という組み立てになります。カナリアリリースやブルーグリーンを、アプリを触らずルート定義だけで表現できたわけです。

App Meshが提供したトラフィック制御・可観測性・mTLS暗号化

App Meshの機能は、大きく「通信の制御」「通信の可視化」「通信の保護」の3つに分かれます。いずれもEnvoyの機能をAWSの抽象でまとめたものです。

重み付けルーティング・リトライ・タイムアウト・外れ値検出という通信制御

App Meshは、宛先ごとにトラフィックの扱いを細かく定義できました。RouteでVirtual Node間の重みを指定すればカナリア配分ができ、HTTPやgRPCのパス・ヘッダー条件でルーティングを分けることも可能です。呼び出しが失敗したときのリトライ回数と条件、応答を待つタイムアウトも宛先単位で設定できます。

加えて、応答エラーが続くインスタンスを一時的に振り分け先から外す外れ値検出（アウトライアーディテクション）を備え、障害の連鎖を抑える回路遮断に近い挙動を実現しました。これらはすべてEnvoyが実行し、アプリ側にリトライやサーキットブレーカーのライブラリを持ち込まずに済む設計です。

CloudWatch・X-Rayへ送るメトリクスとトレースの可観測性

サイドカーが全通信を経由するため、App Meshは通信のメトリクス・ログ・分散トレースを一貫した粒度で収集できました。Envoyが出力する統計はAmazon CloudWatchやPrometheus形式で受け取れ、リクエストの経路はAWS X-Rayで分散トレースとして追えます。

マイクロサービスでは、遅延やエラーがどのサービス間で起きているかの切り分けが難しくなりがちです。メッシュ層で計測点をそろえておくと、アプリの実装差に左右されずにサービス間の健全性を横並びで観測できます。App Meshはこの計測を、コードへの計装を増やさずに提供する点で運用の負荷を下げました。

Envoy間の相互TLS（mTLS）でサービス間通信を暗号化する保護

App Meshは、Envoy同士の通信を相互TLS（mTLS）で暗号化できました。証明書はAWS Private CAやファイルベースで供給し、サービス間の通信路をアプリのコード変更なしに暗号化・相互認証できます。ゼロトラストの文脈で求められる「内部通信も暗号化する」要件を、メッシュ層でまとめて満たせる構成でした。ロードバランサーでの終端とは別に、サービス間の東西トラフィックを保護できる点が、単なるロードバランサーとの違いです。

App Meshの2026年9月終了スケジュールと移行先の選び方

ここからが本題の判断です。App Meshは機能面では成熟していましたが、製品としては終了が決まっています。採否と移行先は、この事実から逆算して決めます。

2024年9月に新規停止・2026年9月30日に終了という終了スケジュール

AWSの公表によれば、App Meshは2024年9月24日をもって新規顧客のオンボードを停止しました。既存の利用者は移行期間中も通常どおり利用でき、CLIやCloudFormationでのリソース作成、セキュリティと可用性の重要な更新は継続されますが、サービス自体は2026年9月30日に終了する予定です。日付は一次情報で変わり得るため、移行計画を組む際はAWSの最新の告知を確認してください。ここで示すのは2026年7月時点で公表されている区切りです。

この前提に立つと、選択は2つに分かれます。新規に構築する場合はApp Meshを採用せず、後述の代替へ最初から切り替えるのが前提です。既存でApp Meshを運用している場合は、終了日から逆算して移行を計画・実行します。どちらも「App Meshを使い続ける」という選択肢は残りません。

ECS Service Connect・VPC Lattice・Istioの選び分け

AWSはApp Meshの後継として、ECS Service ConnectとVPC Lattice、そしてALBへの直接ルーティングを案内しています。EKSで高度な制御が要る場合は、オープンソースのIstioやLinkerdを自前で運用する道もあります。稼働環境と要件に応じて振り分けるのが判断の起点です。

ECSワークロードの多くは、Service Connectがそのまま受け皿になります。サービス発見と通信の信頼性・計測という、App Meshで得ていた価値の中核を、サイドカー設定を自分で組まずに置き換えられるためです。VPC境界やアカウントをまたぐ連携を主眼にしていたなら、VPC Latticeの方が到達範囲の面で合います。Amazon EKSで重み付けや詳細なポリシーを使い込んでいた場合は、同等の表現力を持つIstioやLinkerdへ移すのが自然ですが、コントロールプレーンの運用を自分で背負う点は織り込む必要があります。

新規構築では採用せず、既存利用者は環境別に移行先を選ぶという判断

採否は、次のように条件付きで言い切れます。新規構築なら、終了が決まっているApp Meshは選ばず、ECSならService Connect、クロスVPC連携ならVPC Lattice、EKSで高度な制御が要るならIstio／Linkerdを最初から選びます。サービス数がまだ少ない段階であれば、メッシュを導入せずロードバランサーとサービス発見で足りることも多く、無理にメッシュを持つ必要はありません。

一方で既存のApp Mesh利用者は、2026年9月30日を締切として、稼働環境がECSならService Connect、EKSならIstioかVPC Lattice、というように現在の構成に近い移行先を選び、段階的に切り替えます。移行には通信経路の再設計とEnvoy依存の棚卸しが伴うため、終了間際ではなく余裕を持った着手が現実的です。AWS上のアーキテクチャ再設計と移行を設計から任せたい場合は、AWSのインフラ構築・移行支援で要件整理から実装・運用まで一貫して支援できます。

AWS App Meshの採用可否と移行先の選定でよくある質問

App Meshの採否と移行でよく挙がる論点を、実装の観点で簡潔に答えます。

AWS App Meshはいつ終了しますか？

AWSの公表では、2024年9月24日に新規顧客のオンボードを停止し、サービス自体は2026年9月30日に終了する予定です。移行期間中は既存利用者が通常どおり利用でき、セキュリティと可用性の更新も継続されます。正確な日付は変更され得るため、移行計画時にAWSの最新告知を確認してください。

App Meshから何へ移行すればよいですか？

稼働環境で選びます。ECSやFargateならAmazon ECS Service Connect、複数VPC・複数アカウント間の連携ならAmazon VPC Lattice、サービス数が少なくL7振り分けで足りるならALBへの直接ルーティングが候補です。EKSで細かなトラフィック制御が要るなら、IstioやLinkerdといったオープンソースのメッシュを自前で運用する選択もあります。

App MeshとECS Service Connectは何が違いますか？

App MeshはEnvoyの設定を抽象化して幅広い環境で使える汎用メッシュでしたが、その分ユーザーが構成要素を細かく定義する必要がありました。ECS Service Connectは、ECSに統合された仕組みで、サービス発見と通信の計測を、Envoy設定を自分で管理せずに実現します。ECSワークロードの多くは、Service Connectで移行先の中核を賄えます。

そもそもサービスメッシュは必要ですか？

サービス数が多く、サービス間のルーティング・再送・暗号化・可観測性を横断的に統制したい規模になって初めて、メッシュの価値が出ます。数個のサービスであれば、ロードバランサーとサービス発見、アプリ側の軽いリトライで足りることが多く、メッシュの運用コストが上回ります。規模と統制要件で導入可否を判断してください。

App Meshに料金はかかりましたか？

App Mesh自体の制御機能に追加料金はなく、費用はサイドカーのEnvoyが消費するコンピューティングリソース（ECSタスクやEC2の増分）に対して発生する形でした。移行先でもサイドカーやゲートウェイの分のリソースが必要になるため、移行時はコンピューティングの増減を見積もりに含めると精度が上がります。

関連記事

• サービスメッシュとは：App Meshの上位概念。メッシュの仕組みとサイドカーの考え方を基礎から整理。
• Amazon EKSとは：EKSでメッシュを運用する場合の土台。Istio移行の前提知識に。
• ロードバランサーとは：サービス数が少ない場合の移行先候補。ALB直接ルーティングの基礎。
• Kubernetesとは：コンテナオーケストレーションの全体像。App Meshが動く実行基盤の理解に。