はじめに
- 先日4/11(金)に、以下VPC LatticeとPrivateLinkのAWS公式勉強会に参加しましたので、そこで学んだことをざっくり整理しています
- 個人的には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からも推移的に利用が可能
- 指定したVPC/subnetに1つもしくは複数のENIを作成し、そのENIを用いて通信を行う
- リソース設定の関連付け
- 認証タイプ
- IAMロールを用いて通信を制御
- Network ACLやSGは使用しない
- PortやHTTP Request(Get/Postなど)を基に制御が可能
- 詳細は以下も参照
- IAMロールを用いて通信を制御
- (VPC Latticeの)ターゲットグループ
参加した勉強会の概要
- セッション概要
現代のアプリケーションは、EC2インスタンス、EKS、ECS、Fargate、Lambdaなど、様々な実行環境を活用しています。それぞれの環境で、安全で効率的なネットワーキングソリューションが必要とされています。
本セッションでは、以下の内容をご紹介します：
・VPC LatticeやPrivateLinkなど、AWSによるアプリケーションネットワーキングの簡素化
・セキュリティ、信頼性、スケーラビリティに関する最新の取り組み
・AWSネットワーキングポートフォリオにおける最新のイノベーション
・複雑さを軽減し、パフォーマンスを向上させた高度なアプリケーションアーキテクチャの構築方法
これらのサービスがどのように連携し、お客様のアプリケーション開発をサポートするのか、実践的な内容でお伝えいたします。
- 午前中は、AWS NWの歴史とVPC Latticeが登場してきた背景、VPC Lattice/PrivateLinkの新機能、及びECS/EKSでサービスメッシュとしてVPC Latticeを使う方法について解説がありました。
- 午後は以下のワークショップを実施し、VPC Latticeを中心としてどういった設定を行うかを学びました。
講演内容(午前)
今回の講演内容は以下の通り大人の事情で資料公開がないとのことです。
そのため、私がとったメモをメインに記載しているため、抜け漏れや不正確な内容となっている可能性があります。
その場合は温かく見守っていただけますと幸いです。
大人な事情で本日の資料は公開されないようですが、直近の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が登場してきた
- 従来のモノリシックなアプリケーションはLoad Balancer(LB)で問題なかった
- 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を介してできるようになった
- オンプレミスをサポートするようになった
- ECSをネイティブにサポートするようになった
- PrivateLink
- UDPをサポート
- IPv6通信のみで利用可能
- NBLを介さず、VPC内の複数サービスを接続できるようになった
- この 複数サービス の部分に、内部的にVPC Latticeが使われている
- クロスリージョンでPrivateLinkが使えるようになった
- UDPをサポート
- VPC Lattice
- QA
- TransitGateWayとVPC Latticeの違いは何か
- レイテンシは同程度か、VPC Latticeの方がよいくらい
- LBとTransitGatewayの組合せに比べて、VPC Latticeの方がコストメリットよい
- TransitGateWayとVPC Latticeの違いは何か
VPC Lattice and PrivateLinkの新機能紹介
- 概要
- 従来は難しかったワークロードの共有が可能になった
- VPC Lattice
- HTTP/HTTPS以外のTCP通信が可能になった
- 例えばDBの通信
- HTTP/HTTPS以外のTCP通信が可能になった
- PrivateLink
- LBが不要なワークロードに対応できるようになった
- 例えば単一のデータベース
- 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をしゃべる
- Service
- 上記をAWS ネイティブにすると
- Service
- CLB/NLB
- Ingress
- ALB
- Gateway
- VPC Lattice
- Service
- AWSで上記を使う=プロビジョニングするために
- CLB
- AWS Cloud Provider Load Balancer Controller
- ※レガシーとなっているため、基本は後続のAWS Load Balancer ControllerでALBかNLBを使用しましょう
- ALB/NLB
- VPC Lattice
- CLB
-
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オブジェクトを作成します。このサービスは、この場合、特定のポッドに向けられます。 
EKSでVPC Latticeを使うユースケース
- kube-proxyのサイドカーとしてアプリケーション間の連携に変わる形で使用
- マルチクラスタもシングルクラスタもどちらでも利用可能
- pod間の通信を制御
- VPC Latticeの場合、Network Policyを用いて制御が必須
- Network Policyがない場合、VPC Latticeで認証認可をしていても、Kubernetes ServiceのFQDNでバイパスができてしまい、通信ができてしまう
- VPC Latticeの場合、Network Policyを用いて制御が必須
- 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 ワークショップ
- 紙面で共有された構成図
-
ラボの中で以下高度なラボも紹介されてました
勉強会を通じた疑問
講師の方に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 Latticeについて、知見者の支援を受けつつハンズオン等をやってみたいという興味を持たれた方、以下のCommpassグループに登録してお待ちいただくのがいいかもしれません
- かつてAWSの中の人だった亀田さん主催の勉強会にて、今後VPC Latticeのハンズオン勉強会を企画されているという話をお聞きしておりますので、勉強会が登録されましたら速攻で申し込みましょう！！
- 予定では6月開催といわれていたような？？