Istio アーキテクチャを AWS にマッピングして考える
- ※ 待合室で暇があったので素案を書きました。帰宅後修正していきます。
- (多少バージョンズレやIstioやAwsとか知らないしの皆様に説明がちょいたりない、ただしクラウド＆コンテナの思想の学びにはなるかもなな記載にもれむらがあるのでご迷惑おかけします)
はじめに
マイクロサービスやサービスメッシュを導入したい、という話になると、現場では決まって以下のような議論が立ち上がります。
- マイクロサービスの 3つの設計思想(独立デプロイ・独立データ・独立障害境界)、サービス分割粒度、Git ブランチ戦略、フィーチャーフラグ運用 —— 何から決めるのか?
- 「いやモジュラーモノリスでいいでしょ」「いや段階移行だ」という マウント合戦
- デプロイしたら終わり、という思考停止。バージョニング、リリース計画、運用中の 監視 / 予測 / カイゼン が抜け落ちる
- IaC と CI/CD を入れただけで「SREやってます」と言ってしまう "雰囲気SRE"(本来 DevOps と SRE は並列概念で、IaC/CI/CD は SRE を構成する一要素にすぎないはず)
これらは個別に語られがちですが、本質的にはすべて 「サービス間通信」「ライフサイクル管理」「観測可能性」を、アプリ実装から剥がしてプラットフォーム層に寄せる という同じ思想に収束します。
そして、その思想を最も純度高く体現しているのが Istio (Service Mesh) です。
私は Istio のアーキテクチャ図を初めて見たとき、こう思いました。
これ、AWS で本気のシステムを組むときの VPC / ECS Service Connect / VPC Lattice / CloudWatch / X-Ray / ACM Private CA の縮図そのものじゃないか?
本記事では、
- Istio アーキテクチャを簡潔に整理し
- 各要素を AWS のリソースにマッピングし
- 冒頭で挙げた「現場のあるある課題」への回答を、思想ベースで提案する
という構成で進めます。AWS Ambassador / JAWS-UG コミュニティ運営者という立場から、「ツール論」ではなく「思想論」として読んでいただきたい記事です。
1. Istio アーキテクチャ — 過去図と現行図
冒頭に添付した図は Istio 1.4 までの旧アーキテクチャで、これがいちばんわかりやすかったので起点にします。
旧構成(〜Istio 1.4)
- Data Plane: 各サービスに Envoy Proxy をサイドカーとして注入
- Control Plane: Pilot(設定配布)、Citadel(証明書/ID管理)、Galley(設定検証) が 独立プロセス
- すべての通信は Envoy が横取り(intercept)して、ポリシー適用 / mTLS / メトリクス収集を行う
現行構成(Istio 1.5 〜 / 2026年時点)
公式ドキュメント(Istio Architecture)に整理されているとおり、現在は 3コンポーネントが istiod という単一バイナリに統合されています。
| 役割 | 旧 | 現行 |
|---|---|---|
| サービスディスカバリ / 設定配布 | Pilot | istiod |
| ID / 証明書管理 (CA) | Citadel | istiod |
| 設定検証 / Webhook | Galley | istiod |
| データプレーン(従来) | Envoy sidecar | Envoy sidecar |
| データプレーン(Ambient Mode, 1.24+ Stable) | — | ztunnel + waypoint proxy |
特に Ambient Mode はサイドカーレス構成で、L4 を ztunnel(Rust製)、L7 を waypoint proxy が分担する設計です。「全Pod に Envoy をくっつける」モデルから、「ノード単位の薄いL4プロキシ + 必要時のL7プロキシ」へという、運用コスト低減を狙った進化形です。
思想的に重要なのは「Control Plane と Data Plane の分離」が一貫して保たれていることです。AWS にマッピングする時もこの軸を崩さないのがコツになります。
2. Istio 要素 → AWS リソースのマッピング
2-1. データプレーン: Envoy Sidecar → ECS Service Connect / VPC Lattice
| Istio | AWS |
|---|---|
| Envoy Sidecar Proxy | ECS Service Connect の Envoy(マネージド) / VPC Lattice Service |
| Sidecar Injection (Mutating Webhook) | ECS Service Connect の Task Definition 自動付与 |
| Mesh 境界 | VPC Lattice Service Network |
AWS App Mesh は 2026年9月30日で終了します。新規オンボードは 2024年9月24日に停止済み。
本記事では現行推奨である ECS Service Connect(ECS向け)、VPC Lattice(EKS / クロスVPC)を前提にしています。
ここで効いてくる思想
Envoy が「アプリケーションの代わりに通信を横取りする」ことで、
- リトライ・タイムアウト・サーキットブレイカ
- カナリアリリース / トラフィックシフト
- mTLS
これらが すべてアプリのコード外で実現されます。VPC Lattice + Route 53 加重ルーティングで Blue/Green を組む設計はまさに、「アプリは新旧バージョンの存在を知らなくていい」という Istio 的思想の AWS 版実装です。
[Client]
│
▼
[VPC Lattice Service] ← 「Envoy の役割」
│ weight: 90% → v1 (旧)
│ weight: 10% → v2 (新)
▼
[ECS Service v1] [ECS Service v2]
2-2. サービスディスカバリ: istiod (Pilot) → Cloud Map / RDS Proxy / Aurora Endpoint
ここが今回いちばん書きたかったポイントです。
Istio のサービスディスカバリの本質は、「DBやサービスへの参照系/更新系アクセスを、アプリ実装ではなく Envoy が横取りしてルーティングする」 という発想です。これにより、
- Read replica と Primary の振り分け をアプリから隠蔽できる
- CQRS 的にデータソースを後から分割しても、アプリは無変更で済む
- マルチDB(MySQL / Aurora / DynamoDB) へのフェデレーション的アクセスも、プロキシ層で吸収可能
AWSは「選択肢」を与えてくれる
ここで強調したいのが、AWS は一つの正解を押し付けず、複数の選択肢を提示してくれるということです。これは設計者の心理的安全性にとって極めて重要で、Westrum の組織類型論で言う Generative Culture(生成的文化) —— 失敗を学習に変え、選択を尊重する文化 —— と相性がいい設計思想です。
DB のRead/Write分離一つとっても、AWS には 段階的に選べる選択肢があります。
| アプローチ | 実装 | 適性 |
|---|---|---|
| A. アプリ側で接続先を切り替える | Aurora の Reader Endpoint / Writer Endpoint をアプリから直接指定 | シンプル。フレームワーク(例: Spring の @Transactional(readOnly=true))で読み書き判定が明確な場合 |
| B. プロキシ層で透過的に振り分ける | RDS Proxy + Aurora Endpoint | アプリは1つのエンドポイントだけ知っていればよい。コネクションプーリング・フェイルオーバー高速化も同時に得られる |
| C. ネットワーク層で完全に隠蔽する | VPC Lattice + Cloud Map で論理サービス名で抽象化 | サービス間通信そのものをメッシュ化したい場合(Istio 的思想に最も近い) |
どれが正解、ではなく、組織の成熟度とユースケースに応じて選べばいい。 この「選択の自由」こそが、AWS が単なるインフラベンダーを超えて「設計のためのプラットフォーム」になれている理由だと、私は理解しています。
サービスエンドポイントの抽象化全体で見ると、組み合わせは以下のようになります。
| 「横取り」したいもの | AWSでの実装 |
|---|---|
| サービスエンドポイント解決 | AWS Cloud Map / Route 53 Private Hosted Zone |
| DB の Read/Write 分離 | A/B/C のいずれか(上表) |
| サービス間ルーティング(L7) | VPC Lattice Listener + Rule |
| クロスアカウント/リージョンの抽象化 | VPC Lattice Service Network(複数アカウントから参照可) |
つまり、**「アプリは論理名だけ知っていればいい」**という Istio の思想は、AWS では Cloud Map + (RDS Proxy or Aurora Endpoint) + VPC Lattice の組み合わせで等価に実現できる、というのが私の解釈です。
# アプリのコード(理想形)
db = connect("orders.local") # ← 論理名のみ
result = db.read("SELECT ...") # ← 内部で reader endpoint へ
db.write("UPDATE ...") # ← 内部で writer endpoint へ
アプリは orders.local しか知らない。実際にどこにルーティングされるかは、Envoy(= RDS Proxy / Aurora Endpoint / VPC Lattice)が決める。これが「データプレーン横取り」の本懐です。
2-3. オブザーバビリティ: Mesh 境界 → VPC / Namespace の縮図
Istio の Mesh 境界を理解するときに、Kubernetes の Namespace を思い浮かべるとスッキリします。そして、Namespace = AWS の VPC(あるいは Account 境界) とアナロジーをかけると、AWS 設計者の脳内モデルにスッと馴染みます。
| Istio / k8s | AWS |
|---|---|
| Pod | ENI を持つ ECS Task / Lambda |
| Namespace | VPC / アカウント境界 |
| Service | Cloud Map Service / VPC Lattice Service |
| Mesh | VPC Lattice Service Network / Transit Gateway 圏 |
| NetworkPolicy | Security Group + NACL |
そして観測の三本柱(Logs / Metrics / Traces)は以下にマップされます。
| 観測の柱 | Istio | AWS |
|---|---|---|
| Logs | Envoy access log | CloudWatch Logs |
| Metrics | Prometheus (istio-proxy metrics) | CloudWatch Metrics / Container Insights |
| Traces | OpenTelemetry / Jaeger / Zipkin / SkyWalking | AWS X-Ray / OpenTelemetry (ADOT) |
2-4. トレーシング: 「ログ・メトリクスに加わる第3の柱」
Logs と Metrics は古くからある観点ですが、マイクロサービス時代に決定的に重要になったのが 分散トレーシングです。因果関係(causality) を扱える唯一の柱、と言ってもいいでしょう。
Istio がサポートするトレーシングバックエンド
公式の Distributed Tracing タスク を見ると、現行 Istio(1.29 系)は 以下4つのバックエンドを公式サポートしています。
- OpenTelemetry(推奨。Telemetry API は 1.22 で Stable)
- Jaeger
- Zipkin
- Apache SkyWalking
これは大事なポイントで、Zipkin / Jaeger も「現役」です。歴史的にこれらが先行していて、現在は OpenTelemetry が標準の OTel エコシステムに統合する役割を担っている、という関係性です。
Istio → AWS X-Ray を繋ぐパターン
ここで実用上のキーになるのが、AWS 公式ブログで紹介されている 「Istio → OpenTelemetry Collector → AWS X-Ray」のパイプラインです。
📖 AWS X-Ray を使った Istio 仮想サービスのトレースの可視化(AWS公式ブログ)
ここで紹介されている構成を私なりに整理すると、こうなります。
[Istio Envoy Sidecar]
│ Zipkin / OpenTelemetry フォーマットで span を発行
▼
[OpenTelemetry Collector] ← レシーバ + プロセッサ + エクスポータ
│ ・zipkin receiver
│ ・awsxrayexporter (Contrib モジュール)
▼
[AWS X-Ray] ← マネージドなトレースバックエンド
│
▼
[Service Map / Trace Details] ← 可視化
ポイントは OpenTelemetry Collector が "翻訳機" として機能し、Istio が出す span を AWS X-Ray のセグメントドキュメントに変換してくれること。これにより、
- アプリは何も変更不要(コンテキスト伝播は Envoy 任せ)
- バックエンドだけ X-Ray に差し替えられる(マネージドになる)
- メトリクス・ログも同じ Collector で扱える(CNCF OpenTelemetry プロジェクトの真骨頂)
という、まさに 「分散トレーシングの重労働を AWS にオフロードする」 設計が成立します。
ここでも「選択肢」がある
トレーシングのバックエンドも一択ではありません。
| バックエンド | 適性 |
|---|---|
| Jaeger / Zipkin (Self-hosted) | k8s完結。OSS文化に親和的なチーム |
| AWS X-Ray | フルマネージド。AWS リソース(Lambda, API Gateway 等)とのトレース連携 |
| OpenTelemetry + Datadog / NewRelic | 商用APMで開発者体験(DX)を最大化したい場合 |
| OpenTelemetry + Tempo (Grafana stack) | Grafana 一極化 |
AWS X-Ray を選ぶことは、Jaeger を否定することではありません。 「マネージドという選択肢を取る」だけのことです。これも 2-2 で書いた Generative Culture の話と同じ思想で、Werner Vogels さん流に言えば "You build it, you run it. But you don't have to build everything yourself." ですね。
2-5. セキュリティ: istiod (Citadel) → ACM Private CA + IAM
Istio の Citadel(現 istiod の CA機能)は、Pod ごとに短命な x.509 証明書を発行して mTLS を実現します。SPIFFE ID という形式です。
AWS では:
| Istio | AWS |
|---|---|
| Citadel (CA) | AWS Private CA (ACM PCA) |
| SPIFFE ID | IAM Role / IAM Roles Anywhere |
| AuthorizationPolicy | IAM Policy / VPC Lattice Auth Policy (SigV4) |
| mTLS | ACM PCA + ALB / NLB の mutual TLS |
「サービスのIDを、IPアドレスではなく証明書(=暗号学的アイデンティティ)で表現する」 という Zero Trust の発想は、Istio の世界では既にデフォルトです。AWS でも VPC Lattice の Auth Policy + IAM Roles Anywhere で同じ世界が構築可能になっています。
3. 全体マッピング(早見表)
| 観点 | Istio | AWS |
|---|---|---|
| Data Plane | Envoy / ztunnel | ECS Service Connect / VPC Lattice |
| Control Plane | istiod | VPC Lattice Service Network 管理面 / Cloud Map |
| Service Discovery | Pilot | Cloud Map + Route 53 Private |
| DB Read/Write 分離 | Envoy ルーティング | Aurora Endpoint / RDS Proxy / VPC Lattice |
| 通信制御(L7) | VirtualService / DestinationRule | VPC Lattice Listener Rule |
| mTLS / ID | Citadel (SPIFFE) | ACM Private CA + IAM Roles Anywhere |
| Logs | Envoy access log | CloudWatch Logs |
| Metrics | Prometheus | CloudWatch / Container Insights |
| Traces | OpenTelemetry / Jaeger / Zipkin / SkyWalking | AWS X-Ray + ADOT (OTel Collector) |
| Mesh境界 | k8s Namespace / Mesh | VPC / Account |
| ポリシー | AuthorizationPolicy | IAM Policy / SCP / VPC Lattice Auth Policy |
4. 考察 — 冒頭の「現場のあるある課題」に答える
ここで最初の問いに戻ります。
「マイクロサービスは設計思想3つやどう分割し…」
→ 答え:分割の正解はない。代わりに "横取りできる層" を先に作れ。
ECS Service Connect / VPC Lattice を先に整備すれば、後から分割粒度を変えてもアプリは無変更で済む。設計を凍結せず、進化可能にする のが Istio 的回答。
「モジュラーモノリスとの議論で結局どうしたら…」
→ 答え:モノリスでも構わない。ただし境界に Envoy 的な "横取り層" を置け。
DB 接続を直書きでなく Aurora Endpoint や RDS Proxy 経由にする、サービス内通信を Cloud Map 経由にする、それだけで「いつでも切り出せるモノリス」になる。これが本当の意味でのモジュラーモノリス。
「デプロイしたらおしまいで監視・カイゼンが抜ける」
→ 答え:三本柱(Logs / Metrics / Traces)が揃ってから初めて運用が始まる。
特に Traces を最初から入れること。OpenTelemetry Collector + X-Ray は後付けがしんどいので、初日から traceparent を流す設計を。
「IaC / CI/CD 入れただけで雰囲気SRE」
→ 答え:SRE の核は SLO / Error Budget / Toil削減。IaC は手段にすぎない。
Istio が教えてくれるのは、「プラットフォーム層がアプリの信頼性を肩代わりする」という分業の設計思想。サーキットブレイカ、リトライ、トラフィックシフトをアプリに書かせている時点で、それは SRE ではなく "雰囲気" です。
つまり、Istio の思想を AWS にマッピングして実装するという行為は、進化的アーキテクチャを物理的に成立させる ということに他なりません。
おわりに 〜BroadenTsuyoshi として〜
2025年の re:Invent、Werner Vogels さんの最終キーノートで提示された "The Renaissance Developer" フレームワーク。その中で最も強く心に残ったのが、
"Broaden your T."
〜 一つの専門の深さを保ったまま、隣接領域への幅を広げよ 〜
という言葉でした。T字型エンジニアの「T」を、もっと広くせよ、と。
私はずっと、AWS の設計と、Kubernetes / Istio の世界と、Java / Spring エコシステムの深掘りと、コミュニティ運営と、AI/ML の啓蒙書と、それぞれを別の軸として走ってきましたが、Werner さんの言葉を聞いて、
「これらは全部つながっている。つなぐのが私の仕事だ。」
と腹落ちしました。本記事もまさにその試みで、Istio という一見 Kubernetes ローカルな話題を、AWS の VPC Lattice / RDS Proxy / X-Ray / ACM PCA に結び直して、最後に SRE / 進化的アーキテクチャという思想に着地させました。
私の名前は Tsuyoshi です。なので、Werner さんの "Broaden your T" を、私はこれから自分のシリーズタイトルとして名乗ろうと思います。
BroadenTsuyoshi
〜 深さを失わずに、Tを広げ続けるエンジニアリング・ブログ 〜
次回以降、本シリーズでは「Istio思想 × AWS実装」をさらに深掘りしながら、Java / Spring エコシステム、コミュニティ、AI/ML、組織論、進化的アーキテクチャまで、横断的に書いていきます。
Werner さん、14年間のキーノート、本当にお疲れさまでした。
そして、深く、広く、続きを書いていくのは私たちの番です。
Tsuyoshi, out. 🛫