---
title: appmeshを供養する
tags:  #aws #jaws-ug  
author: [Akifumi Niida](https://docswell.com/user/nid)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/YJ9P8P1W73.jpg?width=480
description: JAWS-UG横浜 #102 AWSサ終供養LT会 登壇資料
published: July 17, 26
canonical: https://docswell.com/s/nid/Z4N9PW-2026-07-17-193151
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/YJ9P8P1W73.jpg)

AppMeshを供養する
until EOL
2026-09-30
JBCC株式会社 新居田晃史 - JAWS-UG横浜 #102 AWSサ終供養LT会 2026.7.17


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GJ8D8D4RJD.jpg)



# Page. 3

![Page Image](https://bcdn.docswell.com/page/LJLMRM62ER.jpg)

ハンズオン過去にやりましたね（コロナ禍の２０２１年）


# Page. 4

![Page Image](https://bcdn.docswell.com/page/47MYRY597W.jpg)

WHY SERVICE MESH — 2012-2019
背景：マイクロサービスによる通信の複雑さ
マイクロサービス化で、あらゆる関数呼び出しがネットワーク越しのRPC/RESTになり、ネットワークの信頼性がシステ
ムの信頼性に大きく関わるようになった
リトライ・タイムアウト・CB
呼び出し先が落ちたらどうするか
サービスディスカバリ
呼び出し先のIPはオートスケールで常に変わる
トラフィック制御
新バージョンに10%だけ流したい
暗号化と認証
ゼロトラストでは「同じVPC内」は信頼の根拠にならない
可観測性
リクエストがどのサービスを通り、どこで遅延したか
対応方法の変遷 — 各世代は前世代の「残った課題」から生まれた：
第1世代：ライブラリ内蔵 2012〜
Netflix OSS（Hystrix等）
→ 言語ロックイン・再デプロイ地獄
第2世代：サイドカー 2016〜
→ Envoy（Lyft）/ Linkerd
→ 数千プロキシへの設定配布（xDS）
第3世代：コントロールプレーン 2017〜
→ Istio / App Mesh（2019 GA）
→ 抽象化の複雑さ＝本編へ


# Page. 5

![Page Image](https://bcdn.docswell.com/page/P7R9R939E9.jpg)

THE VISION — GA: 2019-03-27
App Meshが見た夢
“AWSで動かすならネットワークインフラの管理に悩むべきではない。それはアプリケーション認識型ネッ
トワークが担う。App Meshはその旅路の第一歩だ”
— Werner Vogels (CTO), GA発表ブログより要旨
① 論理と物理の分離
② コンピュート横断メッシュ
③ 通信三大関心事のインフラ化
Virtual Service＝論理名、Virtual Node＝
ECS / EKS / Fargate / EC2 / AWS上のセ
信頼性（retry/CB）・可観測性（Envoy統
実体。Routeの重み書き換えだけで、アプ
ルフマネージドK8sを単一メッシュで。サ
一メトリクス+X-Ray）・セキュリティ
リにもDNSにも触れずカナリア完結。IF
イドカー型メッシュとしてこれを実現し
（TLS/mTLS）を、宣言的設定のプロパテ
と実装の分離をネットワーク層で。
たAWSネイティブはApp Meshだけ。
ィにする。
※ ただしGA時点で使えたのは加重ルーティングまで。リトライ・CB等は「将来提供」（Call Back は2020年11月）


# Page. 6

![Page Image](https://bcdn.docswell.com/page/PJXQRQ437X.jpg)

THE REALITY — LEAKY ABSTRACTION
夢破れる！？ App Meshの複雑さ
「serviceA → serviceB」を表現するための層：
① 覚えることが多すぎる
たった1本の通信のために4種類の「仮想」リソースを作る。画面に実物は映らな
Virtual Service
論理サービス名（DNS解決可能が必須）
いので、頭の中で組み立てないと理解できない。
↓
Virtual Router
② 作る順番・消す順番に決まりがある
トラフィック分散の器
↓
Route
「先にこれを作らないとエラー」「参照中は消せない」。正しい順番を覚えてい
ないと、作ることも消すこともできない。
match条件・重み・retryPolicyはここだけ
↓
Virtual Node
実体へのポインタ（listener/backend/SD）
↓
③ 設定する場所が直感と食い違う
「リトライ設定はRouteに書く」など、どこに何を書くかが分かりにくい。置き
場所を間違えると本番でエラー（503）になる。
Envoy Sidecar
proxyConfig・複数のIAM設定・バージョン追従
↓
④ 隠したはずのEnvoyが結局見えてくる
Cloud Map
proxy設定・複数のIAM設定・バージョン追従・DNS名・mTLS証明書の配布…。
サービスディスカバリ登録
「難しさを隠す」約束が、最後まで守られなかった。


# Page. 7

![Page Image](https://bcdn.docswell.com/page/3JK9R9ZNJD.jpg)

END OF LIFE
AppMeshの夢は2つのサービスへ
2018-11
2019-03-27
2022-11
2024-09-24
2026-09-30
Preview発表
GA
後継登場
EOL発表
完全終了
re:Invent'18（Hystrixメンテモード
Vogels「旅路の第一歩」
Service Connect発表 / Lattice
同日から新規停止。終了日26-09-30
リソース全停止
preview（GAは23-03）
を告知
と同月）
読み解き（※私見です。AWSは「分割した」とは言っていない）
App Mesh の遺産
クラスタ内 → ECS Service Connect： Envoyを完全隠蔽。設定は「名前とポート」だ
けに
単一の万能メッシュ
という設計
→
境界越え → VPC Lattice： サイドカー自体を廃止。リンクローカル経由のマネージド
データプレーン（顧客IPを消費しない）


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LE3W8WDZE5.jpg)

M I G R AT I O N PAT H S
移行3択：こういう場合は、これ
ECSクラスタ内で完結する通信なら
→
ECS Service Connect
・Service Connectが自動でEnvoyを管理
・名前とポートだけで設定完了
・制約：L7ルーティング不可・mTLS不可
VPC・アカウントをまたぐ通信なら
→
Amazon VPC Lattice
・サイドカーレス・IAM Auth Policyで認可
・2024-11〜ECSネイティブ統合・TCPも対応
・注意：リージョン跨ぎ不可・ECS統合はローリングデプロイのみ
mTLS必須＋高度なL7制御が要るなら
→
Istio on EKS
・Ambient Modeでサイドカーレス化
・mTLSはデフォルト有効・自動ローテ
・主戦場はK8s。ECSネイティブ統合はなし


# Page. 9

![Page Image](https://bcdn.docswell.com/page/8EDKMKP47G.jpg)

F E A T U R E G A P A N A LY S I S
高度機能の行き先：埋まらない穴はどこか
App Mesh機能
Service Connect
VPC Lattice
Istio
weightedTargets（加重カナリア）
△ ALB加重TG / ECS canary(25-10)
○ Listener Rule加重
○ VS weight
HTTPヘッダーmatch（A/B）
✗ 完全に喪失
○ HTTPRoute HeaderMatch
○ match.headers
Outlier Detection / Conn Pool
△ 内蔵・チューニング不可
✗ TG healthcheckのみ
○ DR outlierDetection
✗ TLSのみ（PCA短命証明書）
△ IAM AuthPolicyで代替
gRPC L7ルーティング
△ 通信可・L7ルーティング不可
○ HTTPS Listener(ALPN)
○ フル対応
クロスVPC/アカウント
△ 25-09〜NS共有(同Region)
○ RAM共有ネイティブ
△ multi-cluster要構成
mTLS（File/SDSのみ。ACM PCAクライアント証明書は未
対応のままEOL）
○ PeerAuth・自動ロー
テ
mTLS＋ヘッダーA/B の両立はAWSマネージドでは埋まらない → Istio Ambient（またはアプリ層実装）が現実解


# Page. 10

![Page Image](https://bcdn.docswell.com/page/V7PKRKNVJ8.jpg)

M I G R AT I O N P I T FA L L S
移行時の注意点
01
App MeshとService Connectは同時に使えない
→ 全サービスを作り直す必要がある
1つのECSサービスが、両方に同時に所属することはできない。少しずつ更新するのではなく、新規に作り直してBlue/Green（新旧を並行稼働させ、徐々にトラフ
ィックを移す方式）で切り替える。海外の移行事例では「初回4〜6時間・以降1〜2時間/サービス」との報告がある（ALB直結への移行例）。
02
移行の途中は、新環境と旧環境が互いに通信できない
App Mesh側のサービスとService Connect側のサービスは、名前の解決の仕組みが別物のため、互いを呼び出せない。呼び出し合う一連のサービス（例：フロント
エンドとその先のAPI群）は、まとめて同じタイミングで切り替える設計が必要。
03
Service Connectの名前は、Route 53（DNS）に登録されない
App Meshは名前をRoute 53で公開できたが、Service Connectの名前解決はECSクラスタ内部だけで完結する。クラスタの外にあるEC2やLambdaがRoute 53経由
でサービス名を参照していた場合、その方法が使えなくなる。
04
外向き通信の「見えない特別扱い」が変わる
App MeshのEnvoyは、外部SaaSやAWSの内部情報を取得する通信（メタデータエンドポイント等）を特別に素通しする設定を持っていた。Service Connectでは
この挙動が変わるため、外向き通信を厳しく制限する運用をしていた場合はセキュリティ設定の見直しが必要。


# Page. 11

![Page Image](https://bcdn.docswell.com/page/2JVVRVKRJQ.jpg)

App Mesh、
使ってなくても、学びはある
App Meshを使っていた人は少数派。でも「1つのサービスの一生」を
追いかけると、ITの変遷そのものが見える。
2012
ありがとう。
ネットワーク抽象化の夢は続く
ライブラリ内蔵の時代
2016
サイドカーの発明
2019
App Mesh誕生（夢）
2024
EOL・2つに分割相続
サービスの生死を追うのが、一番のITトレンド学習
法
→ 「なぜ生まれたか」を見ると、当時の技術的課題がわかる
→ 「なぜ終わるか」を見ると、次の設計思想が見える
→ App Mesh→Service Connect/Latticeの構図は、業界全体の「サイドカ
ーからサイドカーレスへ」という潮流の縮図