はじめに
VPC Latticeという名前は何度も目にしていたのですが、正直「EKSとかECSとか、コンテナと一緒に使うやつ」というイメージをずっと持っていました。
ある日のイベント(AWS Summit Japan 2026)や様々な方のお話をお聞きし、コンテナ文脈だけじゃない活用シーンが出てきて、「あれ、これVPCの問題を解決してくれるやつじゃね？？」と気づきました。
この記事では「VPC Latticeってこういうサービスだよ」という基礎的な説明と、実は「コンテナ以外でもこんなに使えるんだよ」というユースケースを4つ紹介していきます。
VPC Lattice
VPC Latticeとは
Amazon VPC Lattice は、フルマネージド型のアプリケーションネットワーキングサービスです。
複数のVPC・アカウントにまたがったサービス間通信(ここ重要)を、ネットワーク設定の複雑さを意識せずに実現するためのサービスで、接続・保護・モニタリングを一元管理できます。
「アプリケーションネットワーキング」とは、レイヤー7（HTTP/HTTPS、gRPC）レベルでサービス間をつなぐ仕組みを指しています。単純なネットワーク接続（Transit GatewayやVPCピアリング）とは異なり、ルーティングルール・認証・ロギングなどアプリケーションレベルの内容をセットで扱えます。
gRPC（gRPC Remote Procedure Call）は、Googleが開発したオープンソースのRPCフレームワークです。双方向ストリーミング通信にも対応しているため、マイクロサービス間の内部通信でよく採用されています。
主要コンポーネント
VPC Latticeは3つの主要コンポーネントで構成されています。
| コンポーネント | 役割 |
|---|---|
| サービスネットワーク | VPCとサービスをまとめる論理グループ。VPCはここに関連付けることで、ネットワーク内のサービスへアクセスできるようになります。 |
| サービス | クライアントからのリクエストを受け付ける論理エンドポイント。ALBと同様にリスナー・ルール・ターゲットグループを持ちます。 |
| ターゲットグループ | 実際にリクエストを処理するリソースのグループ。EC2、Lambda、ALB、IPアドレスを登録できます。 |
加えて最近はリソース設定（Resource Configuration）という概念も追加されています。RDSやカスタムIPなど、HTTPベース以外のTCPリソースへのアクセスをLattice経由で実現するための仕組みです（後述）。
コンテナ文脈での使われ方
VPC Latticeがよくコンテナと一緒に語られるのは、ECSやEKSを使ったマイクロサービスアーキテクチャとの相性の良さからきています。
例えば、複数のECSクラスターにまたがるサービス間通信を、統一したDNS名・IAM認証・一元ログという仕組みで管理できるのは、マイクロサービスが増えてきたタイミングで特に効いてきます。
他のVPC間接続サービスとの比較
もちろん、VPC間接続の手段はVPC Latticeだけではありません。それぞれの最適なユースケースも整理しておきます。
| 接続方式 | 最適なユースケース | CIDRの重複 | プロトコル |
|---|---|---|---|
| VPCピアリング | 少数VPC間のシンプルな接続 | 不可 | TCP/UDP |
| Transit Gateway | VPC・オンプレをハブアンドスポークで集約 | 不可 | TCP/UDP |
| AWS PrivateLink | VPC間・SaaSとのポイントツーポイント接続 | 可 | TCP/UDP |
| Amazon VPC Lattice | 多数アカウント・VPCに分散したサービス間通信 | 可 | HTTP/gRPC/TCP |
VPC LatticeはSSH・RDPなどの管理/運用通信には向いていません。あくまでアプリケーション間通信をターゲットにしたサービスです。踏み台サーバ経由のログインや監視通信はTransit GatewayやVPCピアリングの管轄になります。
コンテナだけじゃない！VPC Latticeが活きる4つのシーン
ここからがこのブログ記事のメインです。
実際のユースケースを4つ紹介します。
シーン1：クロスVPC / クロスアカウント接続
課題：VPCが増えるたびに設定が増える地獄
複数のVPCをまたいでサービス通信させようとすると、従来はVPCピアリングやTransit Gatewayが必要でした。
VPCピアリングはシンプルですが、VPC数が増えるとフルメッシュ状態になって管理が辛くなります。Transit Gatewayで集約できますが、アタッチメントを追加するたびにルートテーブルをポチポチ更新する必要がありますし、CIDRが重複していたら設計からやり直し……ということが何度かありました。
また、マルチアカウント構成で、別アカウントのVPCと通信しようとすると、さらに設定が増えて辛かったりします。
解決策：サービスネットワークに関連付けるだけ
VPC LatticeではVPCをサービスネットワークに関連付けるだけで、そのVPC内のリソースがサービスネットワーク内のサービスへアクセスできるようになります。
ルートテーブルは自動で設定されます。手動でルートを追加する必要はありません。
そして何より、CIDRが重複していても問題ありません。VPC Latticeはリンクローカルアドレス（169.254.x.x）を使ってサービスを公開するため、クライアント側のIPアドレス空間に依存しないんですね。
クロスアカウントでのサービス共有はAWS RAMを使います。サービスネットワークをRAMで共有するだけで、別アカウントのVPCからでもアクセスできるようになります。
シーン2：VPC Endpoint（PrivateLink）の代替
課題：リソースごとにエンドポイントを1個ずつ作る
AWS内の内部サービスやSaaSにプライベートでアクセスする定番手段としてPrivateLink（Interface型VPC Endpoint）があります。
ただ、リソースごとにエンドポイントを1つ作成する必要があります。RDS、内部API、ベンダー提供のサービス……とエンドポイントが増えていくと管理が煩雑になってきます。加えて、エンドポイントはサブネットにENIを作成する仕組みなのでサブネットのIPを消費します。VPCのIPアドレス設計が手狭になってくると地味に痛い……という経験はあるのではないでしょうか。
解決策：リソース設定で複数リソースをまとめて管理
VPC Latticeにはリソース設定（Resource Configuration）という機能があります。
RDSエンドポイントやドメイン名、IPアドレスなどTCPベースのリソースをリソース設定として登録し、サービスネットワーク経由でアクセスさせることができます。これをAWS RAMで共有すれば、別アカウントからもプライベートにアクセスできます。
1つのサービスネットワークに複数のリソース設定をぶら下げることができるので、エンドポイントを乱立させなくて済みます。ENI消費の問題も緩和されます。
シーン3：EC2 / Lambda / ECS が混在する環境での統一的な通信
課題：コンピュートタイプごとに接続方法がバラバラ
EC2上のサービスからLambdaを呼び出す場合、以下のような選択肢になります。
- API GatewayのエンドポイントURLを叩く - LambdaをAPI Gateway経由でHTTPエンドポイントとして公開し、HTTPリクエストで呼び出す方法です
- SDK経由でInvokeする - Pythonなら
boto3.client('lambda').invoke()、Node.jsならLambdaClientのように、AWS SDKが提供するAPIを使ってAWS固有のプロトコルでLambdaを直接呼び出す方法です。同期・非同期の制御はできますが、呼び出し元がAWS SDKを組み込んでいることが前提になります
ECSのタスクからEC2のサービスを呼ぶ場合はALBを介すか、内部ドメインを設定するか……という話になります。
コンピュートタイプの組み合わせが増えるほど接続パターンが増えて、認証・ログの一元管理も難しくなっていきます。
解決策：コンピュートタイプを問わずターゲットグループに登録
VPC Latticeのターゲットグループは、以下を混在して登録できます。
- EC2インスタンス
- Lambda関数（VPC Lambdaでも非VPC Lambdaでも可）
- IPアドレス（ECSタスクのIPなども）
- ALB（内部ALBをターゲットにすることも可能）
呼び出し側からは統一されたDNS名（サービスに自動で払い出される）でアクセスするだけでよく、バックエンドが何で動いているかを意識しなくてよくなります。
認証はIAMポリシーをサービスネットワーク・サービス単位で設定でき、アクセスログはCloudWatch Logs・S3・Firehoseへ一元出力できます。インフラ構成を変えても認証・ログの仕組みをそのまま維持できるのは嬉しいですね。
シーン4：カナリア / ブルーグリーンデプロイ
課題：ALBの重み付けターゲットグループを設定・管理
段階的なデプロイをALBで実現しようとすると、ターゲットグループを複数作って重みを設定して、デプロイが完了したら切り替えて……という作業が必要になります。
別VPCやアカウントのリソースをターゲットに含めたい場合はさらに工夫が必要で、そのままでは実現できないケースも出てきます。
解決策：サービスの重み付けルーティングで手軽に実現
VPC Latticeのサービスでは、ルールに対して複数のターゲットグループを重み付きで設定できます。
しかもこのターゲットグループ、別々のVPCに存在するリソースを混在させてもOKです。Kubernetesのクラスターアップグレード時に新旧クラスターへのトラフィックを重み付けで制御することも、同じ仕組みで実現できます。
おわりに
最初は「コンテナのやつ」だと思っていたVPC Latticeが、実際には意外とよく困る、ネットワーク設計の課題をかなりカバーしてくれると分かりました。
Endpointを代替できる点と、コンピュートタイプを問わず統一的に管理できる点が個人的にはいいなぁと思っています。
AWSのドキュメントとBlackBelt資料がよくまとまっているので、ぜひそちらを読んでみるところから始めてみてください！！！