はじめに

先日4/11(金)に、以下VPC LatticeとPrivateLinkのAWS公式勉強会に参加しましたので、そこで学んだことをざっくり整理しています
- AWS Application Networking Roadshow Japan 2025
個人的にはVPC Latticeって何がうれしいの？PrivateLinkと何が違うの？？となっていたので、それが整理できたよい機会だったなと感じています。

VPC Latticeとは

Private Link and Lattice
AWSのVPC内の アプリケーションを簡素に接続するためのサービス
VPC間を接続するAWS サービスの関連性(ざっくりしたイメージです)

	1対1	1対多もしくは多対1 もしくは多対多
VPCを接続	VPC Peering	Transit Gateway
アプリケーションを接続	PrivateLink	VPC Lattice

VPC Latticeの主要コンポーネント
- (VPC Latticeの)ターゲットグループ
  - アプリケーションを指す
  - ターゲットの種類
    - インスタンス
      - 特定の VPC 内にあるインスタンスがサポート
    - IP アドレス
      - VPC リソースへのトラフィックをサポート
      - マイクロサービスベースのアーキテクチャによる柔軟性を提供して、アプリケーション間の通信を簡素化し、コンテナ化されたアプリケーション用に Amazon ECS および Amazon EKS と統合
    - Lambda 関数
      - 単一の Lambda 関数へのルーティングを容易にする
    - Application Load Balancer
      - 単一の Application Load Balancer へのルーティングを容易にする
- サービス(Latticeサービス)
  - ターゲットグループの集合
  - HTTPのメソッドやパス、ヘッダー条件などでリクエストを制御可能
- サービスネットワーク
  - サービスの集合体
  - サービス間の接続を制御するルーター的な役割
  - ここを接続したいVPCに紐づける
  - VPCへの紐づけ方
    - リソース設定の関連付け
      - Gateway Endpointのように、そのVPCに設定しているCIDRとは異なるIPを用いて通信を行う
      - そのVPCの中からの通信でのみ利用可能
    - VPCの関連付け
      - 指定したVPC/subnetに1つもしくは複数のENIを作成し、そのENIを用いて通信を行う
        
        そのsubnetに1つのIPを使用するため、最低"/28"のCIDRが必要
      - PrivateLinkのように、別のVPCからも推移的に利用が可能
- 認証タイプ
  - IAMロールを用いて通信を制御
    - Network ACLやSGは使用しない
  - PortやHTTP Request(Get/Postなど)を基に制御が可能
  - 詳細は以下も参照
    - Amazon VPC LatticeでIAM認証を使って通信元を制限してみた

参加した勉強会の概要

セッション概要

現代のアプリケーションは、EC2インスタンス、EKS、ECS、Fargate、Lambdaなど、様々な実行環境を活用しています。それぞれの環境で、安全で効率的なネットワーキングソリューションが必要とされています。
本セッションでは、以下の内容をご紹介します：
・VPC LatticeやPrivateLinkなど、AWSによるアプリケーションネットワーキングの簡素化
・セキュリティ、信頼性、スケーラビリティに関する最新の取り組み
・AWSネットワーキングポートフォリオにおける最新のイノベーション
・複雑さを軽減し、パフォーマンスを向上させた高度なアプリケーションアーキテクチャの構築方法
これらのサービスがどのように連携し、お客様のアプリケーション開発をサポートするのか、実践的な内容でお伝えいたします。

午前中は、AWS NWの歴史とVPC Latticeが登場してきた背景、VPC Lattice/PrivateLinkの新機能、及びECS/EKSでサービスメッシュとしてVPC Latticeを使う方法について解説がありました。
午後は以下のワークショップを実施し、VPC Latticeを中心としてどういった設定を行うかを学びました。
- Amazon VPC Lattice ワークショップ

講演内容(午前)

今回の講演内容は以下の通り大人の事情で資料公開がないとのことです。
そのため、私がとったメモをメインに記載しているため、抜け漏れや不正確な内容となっている可能性があります。
その場合は温かく見守っていただけますと幸いです。

https://x.com/twtko/status/1910612777418580299

大人な事情で本日の資料は公開されないようですが、直近のBlack Beltでの PrivateLink and Lattice 資料が公開されていますし、Workshop Studioも英語は公開済ですので、ご参考下さいませ。

PDF
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2025_AmazonVPCLattice_0122_v1.pdf

YouTube
https://youtu.be/6_s_KuKkahY

Workshop Studio
https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US

キーノート

なぜAWSでNWサービスを提供し始めたのか
- ワークロードセキュリティ、及びパフォーマンスと信頼性を担保するため
なぜVPC Latticeのようなアプリケーションを接続するサービスが出てきたか
- 従来のモノリシックなアプリケーションはLoad Balancer(LB)で問題なかった
  - なぜなら、モノリシックなアプリケーションは1つのサーバだけで運用されてきた
- しかし、コンテナが出てきたことで、アプリケーションが従来以上に分散され、LBだけでは不十分になってきた
  - コンテナは、基本的に複数のサーバに分散され運用されているため
- 更にアプリケーション同士の通信を制御するため、ゼロトラストを担保することが大変になってきた
- このマイクロサービス化してきた中、アプリケーション間の通信を簡素化し、セキュリティを担保するためにVPC Latticeが登場してきた
VPC Latticeのポイント
- subnetやIPv4/IPv6を意識することなく利用可能
- Routing Tableを作成する必要がない
  - これがTransit GWとの大きな違い(筆者イメージ)
VPC LatticeとPrivateLinkの新機能
- VPC Lattice
  - ECSをネイティブにサポートするようになった
    - 従来はVPC LatticeとECSを接続するために、間にLBを介さないといけなくなった
    - これが直接VPC LatticeとECSを接続できるようになったということ
    - これがネイティブ、ということ
  - TCPをサポート
    - 今まではhttp/httpsだけだった
    - これによりDBなどの通信もVPC Latticeを介してできるようになった
  - オンプレミスをサポートするようになった
- PrivateLink
  - UDPをサポート
    - IPv6通信のみで利用可能
  - NBLを介さず、VPC内の複数サービスを接続できるようになった
    - この 複数サービス の部分に、内部的にVPC Latticeが使われている
  - クロスリージョンでPrivateLinkが使えるようになった
QA
- TransitGateWayとVPC Latticeの違いは何か
  - レイテンシは同程度か、VPC Latticeの方がよいくらい
  - LBとTransitGatewayの組合せに比べて、VPC Latticeの方がコストメリットよい

VPC Lattice and PrivateLinkの新機能紹介

概要
- 従来は難しかったワークロードの共有が可能になった
- VPC Lattice
  - HTTP/HTTPS以外のTCP通信が可能になった
    - 例えばDBの通信
- PrivateLink
  - LBが不要なワークロードに対応できるようになった
    - 例えば単一のデータベース
VPC LatticeとPrivateLinkの設定方法
- 詳細はハンズオン等でお試しください(ここが説明のメインだったのですが、、)

Top Use-Cases and Architectures with EKS/ECS/Fargate

Containerへ入っていく(Inbound)通信の制御リソース

従来からある、Kubernetesネイティブなルーティングリソース
- Service
  - L4 LoadBalancer
- Ingress
  - L7 LoadBalancer
  - HTTP/HTTPS
- Gateway
  - L4 or L7 LoadBalancer
  - HTTP/GRPC/TLSをしゃべる
上記をAWS ネイティブにすると
- Service
  - CLB/NLB
- Ingress
  - ALB
- Gateway
  - VPC Lattice
AWSで上記を使う=プロビジョニングするために
- CLB
  - AWS Cloud Provider Load Balancer Controller
  - ※レガシーとなっているため、基本は後続のAWS Load Balancer ControllerでALBかNLBを使用しましょう
- ALB/NLB
  - AWS Load Balancer Controller
- VPC Lattice
  - AWS Gateway API Controller

VPC Lattice と Kubernetes の関係

- VPC Latticeにおいては異なるレベルの制御に関連する異なるペルソナが存在します。
- Kubernetes Gateway APIの構文を使用してゲートウェイ、HTTPRoute、サービスを作成しますが、KubernetesはVPC Latticeからそれらの項目の詳細を取得します：
  - インフラストラクチャプロバイダー
    - Kubernetes GatewayClassを作成し、VPC LatticeをGatewayClassとして識別します。
  - クラスタオペレーター
    - Kubernetes Gatewayを作成します。これはService Gatewayとサービスネットワーク、およびそれらに関連するService Policiesに関する情報をVPC Latticeから取得します。
  - アプリケーション開発者
    - Kubernetesサービスを指すHTTPRouteオブジェクトを作成します。このサービスは、この場合、特定のポッドに向けられます。

![VPC Lattice と Kubernetes の関係](https://www.gateway-api-controller.eks.aws.dev/latest/images/fundamentals-mapping.png)

EKSでVPC Latticeを使うユースケース

kube-proxyのサイドカーとしてアプリケーション間の連携に変わる形で使用
- マルチクラスタもシングルクラスタもどちらでも利用可能
pod間の通信を制御
- VPC Latticeの場合、Network Policyを用いて制御が必須
  - Network Policyがない場合、VPC Latticeで認証認可をしていても、Kubernetes ServiceのFQDNでバイパスができてしまい、通信ができてしまう
LBのように通信の重みづけが可能
- 利用可能な制御方法
  - Blue/Green
  - Canary
- ユースケース
  - VMからContainer(EKS/ECS)への移行
  - クラスタ/ECSサービスのバージョンアップ

サービスメッシュ

サービスメッシュとは何ですか?

サービスメッシュは、アプリケーション内のサービス間のすべての通信を処理するソフトウェアレイヤーです。
このレイヤーは、コンテナ化されたマイクロサービスで構成されています。
アプリケーションがスケールし、マイクロサービスの数が増えるにつれて、サービスのパフォーマンスをモニタリングすることは困難になります。
サービス間の接続を管理するために、サービスメッシュでは、モニタリング、ログ記録、トレース、トラフィックコントロールなどの新機能を使用できます。
各サービスのコードに依存しないため、ネットワークの境界を越えて複数のサービス管理システムと連携できます。

サービスメッシュとVPC Latticeは異なるため、併用が可能
- サービスメッシュは、あくまでクラスタ内のアプリケーションがターゲット
- VPC Latticeはクラスタ間にも対応している点が違う
- 従来
  - サービスメッシュでクラスタ内を通信制御
  - クラスタ間はTransit Gateway
- これから
  - サービスメッシュでクラスタ内を通信制御　←これは変わらず
  - クラスタ間はVPC Latticeを用いる
サービスメッシュの実現方法
- サイドカー　←デファクトスタンダード
  - 1つのpodに、Applicationのコンテナとサービスメッシュ用のコンテナを配置する
  - 通信はすべてサイドカーのコンテナを経由する
- Ambient Mode
  - 中央集権的なProxyを配置する

QA

Service EndPointを使用するパターンはデータセンターなどのオンプレ環境とも接続できるなどメリットが多いように感じるが、VPC関連付けを用いることのメリットは何か
- VPC関連付けはsubnetのCIDRとは異なる、特殊なIPが割り当てられ、それが通信に使用される
- すなわち、既存NWに影響を与えずに利用可能な点がメリット
- コスト的には、Service Endpointの利用料はかからないため差異なし

ハンズオン(午後)

実施したハンズオン(再掲)
- Amazon VPC Lattice ワークショップ
- 紙面で共有された構成図
ラボの中で以下高度なラボも紹介されてました
- AWS Gateway コントローラと Amazon VPC Lattice を使用した EKS
- Amazon VPC Lattice を使用した IAM 認証、TLS、カスタムドメイン、マルチクラスター接続の実装

勉強会を通じた疑問

講師の方にQAしたり、自身の中で自己解決した疑問を整理しています

VPC Latticeサービスネットワークのログモニタリングとして設定できる「サービスアクセスログ」と「リソースアクセスログ」は何がちがうか
- サービスアクセスログは、サービスやサービスネットワークを通る通信のログ
- リソースアクセスログは、サービスの中のリソースにIn/Outする通信のログ
- 参考
VPC LatticeがLBの機能を持つということは、例えばALBが提供している機能、具体的にはTLS終端機能なんかも提供しているのだろうか
- 調べては無いが、おそらく提供していない
- なぜなら、アプリケーション間の通信でLBにおいてTLSを終端する意味がないから
- 一般的に、サーバ間の通信を暗号化して盗み見ができないようにすることがTLS暗号化
- それをLBで終端するのは、アプリケーションを提供しているサーバに負荷を与えないようにすることが目的の一つ
- そうしたとき、アプリケーション間の通信においてアプリケーションを提供しているサーバに負荷を与えたくないのであれば、端からTLS暗号化をしなければよいだけであり、アプリケーション間の通信も盗み見されたくないのであれば負荷をかけてでも全通信をTLS暗号化すればよいだけ
- VPC Latticeが仮にTLS終端機能を提供している場合
  - 例えば
  - アプリケーションA ⇒ VPC Lattice ⇒ アプリケーションB　の通信の中で
  - アプリケーションA ⇒ VPC Lattice　はTLS暗号化
  - VPC Lattice ⇒ アプリケーションB　は非TLS暗号化
  - ということになるが、、それならTLS暗号化/非TLS暗号化に寄せた方がシンプル
AWSサービスの接続において作成しなければいけないVPC EndPointがまとめられるのか？
- 例：セッションマネージャ用のEndPointとしてSSMとSSMMessagesの2つのエンドポイントが必要になるが、これがまとめられるようにならないか？
- 結論まとめられない
- これは、VPC Endpointには2025.4時点で7つのタイプが存在しており、AWSサービスに紐づくのは【AWSのサービス】というカテゴリであり、VPC LatticeやPrivate Linkに関連するのは【リソースやサービスネットワーク】であるから
- 別件ですが、AWS re:Invent2025でリリースされた新機能の「次世代のSageMaker」を起動すると、27個のVPC Endopointが作成されるそうで、これが地味にコストにはねて辛いという話を聞いたことがあります。なんとかまとめられるとうれしいなぁ...
  - VPCスタックで作成されるリソース

おまけ

完全余談ですが、、
VPC Latticeについて、知見者の支援を受けつつハンズオン等をやってみたいという興味を持たれた方、以下のCommpassグループに登録してお待ちいただくのがいいかもしれません
- 流しのエバンジェリストシリーズ　AWSを中心として色んなサービスの基礎を学ぼう
かつてAWSの中の人だった亀田さん主催の勉強会にて、今後VPC Latticeのハンズオン勉強会を企画されているという話をお聞きしておりますので、勉強会が登録されましたら速攻で申し込みましょう！！
- 予定では6月開催といわれていたような？？

参考