AWS App Mesh（AWSが提供していたサービスメッシュ製品。マイクロサービス間の通信を制御する基盤）を使ってKubernetesクラスタを運用しているなら、この記事は無関係ではありません。AWSはApp Meshのサポートを2026年9月に終了すると発表しています。移行の判断を先送りできる猶予は、思ったより残っていません。
本稿は、App Meshからの移行を迫られたときに何が起きるか、なぜ厄介なのかを整理し、自分のプロジェクトが対象かどうかの確認手順と、移行の進め方を示すものです。実際に40のマイクロサービスを本番影響なしで移行した事例をもとに、アーキテクチャ判断の観点から解説します。
何が起きるか：サポート終了は「サイドカーの終わり」でもある
App Meshは各Pod（Kubernetesにおけるコンテナの実行単位）にEnvoy（プロキシソフトウェア）のサイドカーを注入し、サービス間通信のmTLS（相互TLS認証。通信の両端が互いに証明書で身元を確認する方式）や通信ルールを管理する仕組みでした。
サポート終了後は新規機能もセキュリティパッチも提供されなくなります。放置すれば、CVE（既知の脆弱性情報）が出ても塞がらないEnvoyバージョンを使い続けることになりかねません。
さらに見落とされがちな点があります。App Meshは実は2つの役割を1製品で担っていました。1つはクラスタ内部のサービス間通信を守る「メッシュ」の役割、もう1つは外部トラフィックをAPI Gatewayからサービスへ届ける「ゲートウェイ」の役割です。この2つが1つの製品に同居していたため、代替製品を1つ選べば済む話にはなりません。
なぜ起きるか：製品の統合設計が移行を難しくする
原因を段階的に分解すると、問題は技術選定そのものより「アーキテクチャの結合度」にあります。
1つ目の要因は、メッシュとゲートウェイが疎結合ではなかったことです。App Meshを丸ごと置き換えようとすると、内部通信の仕組みと外部公開の仕組みを同時に変える羽目になり、変更範囲とリスクが跳ね上がります。
2つ目の要因は、サイドカー方式そのものの構造的コストです。Pod単位でEnvoyコンテナを持つ設計は、CPU・メモリの重複消費や、サイドカーのライフサイクル管理（起動順序やJob終了時の挙動など）の問題を抱えていました。これはApp Mesh固有の欠点ではなく、Istio（オープンソースのサービスメッシュ）のサイドカーモードでも共通する課題です。
3つ目の要因は、移行中に新旧2つのメッシュが同居する期間が発生することです。40サービスを一度に切り替えるのは非現実的なので、段階移行中はApp MeshとIstioが並存し、その境界でのトラフィック制御が設計上の難所になります。
自分のプロジェクトが該当するか確認する
影響範囲を判断するには、まずクラスタの構成を洗い出す必要があります。
# App Meshコントローラーがクラスタに存在するか確認
kubectl get pods -n appmesh-system
# App Meshの仮想サービス・仮想ノードの定義を確認
kubectl get virtualservices,virtualnodes,virtualgateways --all-namespaces
# Envoyサイドカーが注入されているPodの棚卸し
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"
"}{end}' | xargs -I{} echo {}これらのコマンドでvirtualgatewayやvirtualnodeのリソースが返ってくるなら、App Meshに依存した構成です。あわせて確認したい点は次のとおりです。
- 外部トラフィックがAPI Gateway → VPC Link → NLB → App Mesh Virtual Gatewayという経路を通っていないか
- サービス発見（サービス名からIPを解決する仕組み）にCloud Map（AWSのサービスディスカバリ機能）を使っていないか
- mTLS証明書がサイドカーにファイルとしてマウントされていないか
- AWSマネジメントコンソールのApp Mesh画面で、稼働中のメッシュ数とサービス数を確認する
該当する項目が1つでもあれば、2026年9月までに何らかの移行判断が必要です。
対策の手順：フェーズを分けてリスクを局所化する
移行を安全に進める鍵は、メッシュとゲートウェイを別々の問題として切り分けることです。1つの巨大な移行プロジェクトにせず、フェーズを分けます。
フェーズ1: ゲートウェイの切り替え
App Meshの仮想ゲートウェイから、Gateway API（Kubernetes標準の新しいIngress管理仕様）に対応したゲートウェイへ外部トラフィックの入口だけを移します。サービス間通信のサイドカーには一切手を触れません。
問題が起きても、Ingressの向き先を元に戻すだけで復旧できるため、ロールバックコストが低いのが利点です。
フェーズ2: メッシュの移行
サービスをApp Meshのサイドカーから、Istio Ambient Mesh（サイドカーを使わない新方式のIstio運用モード）へ1サービスずつ、波状に移していきます。Ambientモードはノードごとに1つの共有プロキシ（ztunnelと呼ばれる）を配置し、そのノード上の全Podのmटls処理を肩代わりします。これによりPodごとのEnvoyコンテナが不要になり、CPU・メモリの重複が減ります。
移行順序を決める前に、次を文書化しておくことが実務上の分かれ目になります。
- どのサービスをどの順番で移すか、その理由
- 最初のサービスを移す前に何が準備完了している必要があるか
- 1サービス分の移行手順を、誰が読んでも再現できる粒度で書く
- 各ステップでのロールバック方法
- どのステップが「後戻りできない一線」か
計画段階で見つかる問題は紙の上で直せますが、本番で見つかると障害対応コストがかかります。40サービス・複数環境・複数リージョンという規模では、この差が結果を左右します。
移行判断のためのアーキテクチャ整理
技術選定はAWS App Mesh廃止という制約の中でも、評価基準を明文化して比較すると納得感が高まります。候補を並べ、重視する基準（性能・運用負荷・標準準拠・移行コスト等）に重みを付けてスコアリングし、絞り込んだ候補でPoC（概念実証）を組む進め方です。
| 観点 | App Mesh（現行） | Istio Ambient Mesh |
|---|---|---|
| データプレーン方式 | Pod単位のサイドカー | ノード単位の共有プロキシ |
| ゲートウェイ機能 | メッシュと一体 | Gateway APIとして分離可能 |
| 設定の可搬性 | AWS独自形式 | Kubernetes標準仕様 |
| サポート状況 | 2026年9月に終了 | CNCF傘下で継続開発 |
メッシュとゲートウェイを分離する設計にしておくと、今後どちらか一方だけを差し替えたくなった場合にも、他方に影響を与えずに済みます。これは技術的負債を抱え込まないための構造的な備えといえます。
まとめ
AWS App Meshに依存したクラスタを運用しているなら、まずはkubectl get virtualservices,virtualnodes,virtualgateways --all-namespacesで依存範囲を洗い出すところから始めてみてください。
判断の軸は3つです。第一に、メッシュとゲートウェイの役割を切り分けて考えること。第二に、移行計画を文書化しチームレビューを通すこと。第三に、フェーズを分けて各段階でロールバック手段を確保することです。
2026年9月まで時間はありますが、40サービス規模の移行には数か月単位の検証期間が必要になる可能性があります。早めの棚卸しと計画策定が、本番障害を避ける最も現実的な備えです。