Amazon VPC Latticeとは？サービスネットワークの仕組みと構成要素・使い分けを実装目線で解説【2026年版】

Amazon VPC Latticeは、複数のVPCや複数のAWSアカウントにまたがるサービス間の通信を、接続・保護・監視の3点でまとめて扱うフルマネージド型のアプリケーションネットワークサービスです。VPCピアリングやTransit Gatewayがネットワーク層（IPの到達性）を束ねるのに対し、VPC Latticeはアプリケーション層でサービスそのものを抽象化し、認証・ルーティング・可観測性をインフラ側へ寄せられる点が違いになります。この記事では、中心概念であるサービスネットワークから、サービス・リスナー・ターゲットグループ・認証ポリシーという構成要素までを実装目線で整理し、そのうえでVPCピアリング・Transit Gateway・PrivateLink・App Meshとの使い分けを、実装者が採否を決められる形で判断します。前提となるマイクロサービスという分割の考え方を押さえておくと、なぜサービス単位の接続が要るのかが理解しやすくなるはずです。

まとめ：VPC Latticeは複数VPC・アカウントを横断する「サービス単位のネットワーク」

VPC Latticeの本質は、IPアドレスやサブネットではなく「サービス」を接続の単位に置き換える点にあります。サービスネットワークという論理境界を1つ作り、そこにVPCとサービスを関連付けるだけで、境界内のクライアントは相手のIPやルートテーブルを意識せずにサービス名で通信できます。重複するCIDRを持つVPC同士でも接続でき、AWS Resource Access Manager（RAM）を使えばアカウントをまたいだ共有も可能です。

この抽象の上に、通信を細かく制御する仕組みが載ります。リスナーが受けたリクエストを、ルールの条件に従ってターゲットグループへ振り分け、IAMベースの認証ポリシーで誰がどのサービスを呼べるかをきめ細かく制御する仕組みです。通信のメトリクスとログはリクエスト単位で取得でき、CloudWatchやS3へ出力できます。

判断の軸は明快です。複数VPC・複数アカウントに散ったサービス群を、ネットワーク設定を都度組まずにサービス名でつなぎたいならVPC Latticeが向きます。単純なIP到達性の集約が目的ならTransit GatewayやVPCピアリングで足り、特定のエンドポイント1つへ安全に届けたいだけならPrivateLinkで十分です。役割が重ならないため、既存のネットワーク構成に足す形で導入できます。

Amazon VPC Latticeの定義と従来のVPC接続との違い

まず、VPC Latticeが「何を」「どのレイヤーで」解決するのかを、従来のVPC間接続と対比しながら押さえます。ここを取り違えると、Transit Gatewayと機能が重複すると誤解しがちです。

アプリケーション層でサービス間通信を扱うフルマネージドサービス

VPC Latticeは、アプリケーションのサービスやリソースを、接続・保護・監視するためのアプリケーションネットワークサービスです。従来のVPC間接続がIPパケットの到達性を扱うのに対し、VPC LatticeはHTTP／HTTPS／gRPCといったアプリケーション層のプロトコルを解釈し、サービスという単位で通信を仲介します。クライアントは相手サービスに割り当てられたFQDNへリクエストを送るだけでよく、サービスネットワークがその名前解決とルーティングを引き受けます。

コントロールプレーンとデータプレーンをAWSがマネージドで運用するため、利用者はサイドカープロキシの配布やコントロールプレーンの運用を自分で抱えずに済みます。マイクロサービスのようにサービスが増えるほど、この「サービス名でつながる」抽象が接続の設計を単純にします。

VPCピアリング・Transit Gatewayとのレイヤーの違い

VPC間の接続手段は複数あり、それぞれ担うレイヤーが異なります。VPC Latticeは、既存のネットワーク層の接続を置き換えるものではなく、その上に載る補完的な位置づけです。

VPCピアリングやTransit Gatewayは、CIDRが重ならないことを前提にIPで経路を張ります。多数のVPCを束ねるハブとしてはTransit Gatewayが受け皿になりますが、扱うのはあくまでIPの到達性で、どのサービスが誰を呼べるかというアプリケーション層の制御は別途必要です。一方でVPC Latticeは重複するCIDRを持つVPC間でも接続でき、サービス単位の認証・ルーティングまで内包します。CIDR設計の制約から解放される点は、既存環境へ後付けする際の実務上の利点です。

VPC Latticeの構成要素とサービスネットワークの仕組み

VPC Latticeは、いくつかの論理オブジェクトを組み合わせて通信を表現します。それぞれの役割を押さえると、設定の全体像がつかめます。

VPC Latticeの中心概念であるサービスネットワークとサービス

サービスネットワークは、サービスとクライアントを束ねる論理的な境界です。ここにVPCを関連付けると、そのVPC内のクライアントは境界内のサービスへ接続できるようになります。サービスは、特定の機能を提供する独立してデプロイ可能な単位で、注文サービスや決済サービスといった業務上のまとまりに対応する概念です。1つのサービスは複数のサービスネットワークに参加でき、逆に1つのサービスネットワークは多数のサービスを収容します。

このモデルの利点は、ネットワーク管理者とアプリケーション開発者の責任を分けられる点です。ネットワーク管理者がサービスネットワークを作成・共有し、開発者が自分のサービスをそこへ登録する、という分担で運用でき、分散した開発組織でも接続の統制を保てます。

リスナー・ターゲットグループ・ルールによるリクエストのルーティング

サービスの内部は、リクエストを受けて振り分けるための3つの部品で構成されます。ロードバランサーを扱ったことがあれば、構造はよく似ています。

リスナーはHTTP／HTTPS／gRPCとポートを指定して接続を受け付け、パスやヘッダーの条件を持つルールが、リクエストをどのターゲットグループへ送るかを決めます。ターゲットグループには、EC2インスタンス、ECS／EKS上のコンテナ、Lambda関数、Application Load Balancer、IPアドレスといった実体を登録可能です。この構造はロードバランサーのリスナーとターゲットグループの関係とよく似ており、重み付けによるカナリア配分もルールで表現できます。

IAM認証ポリシーとセキュリティグループを重ねた多層防御の保護

VPC Latticeのアクセス制御は、複数の層を重ねる設計です。第1に、VPCやサービスをサービスネットワークへ関連付けるかどうかで到達範囲を絞ります。第2に、VPCとサービスネットワークの関連付けにセキュリティグループを適用する形です。第3・第4に、サービスネットワーク単位とサービス単位で、IAMベースの認証ポリシーを適用し、どのプリンシパルがどのサービスを呼べるかをきめ細かく制御します。

サービス間の通信はAWSのネットワークインフラ内で完結し、インターネットを経由しません。IAMの認可とネットワーク層の分離を組み合わせることで、内部通信にもゼロトラストに近い統制をかけられます。個々のサービスにアクセス制御のコードを書き込むのではなく、ネットワーク側で誰が誰を呼べるかを宣言的に定義できる点が、マイクロサービスの認可設計を単純にします。

VPC Latticeが向く場面と料金・他サービスとの使い分け

ここからが採否の判断です。対応する実行環境と料金の考え方を押さえたうえで、隣接するサービスとの棲み分けを条件付きで言い切ります。

対応コンピュートと重複CIDR・クロスアカウントという適用範囲

ターゲットには、EC2、ECS、EKS、Fargate、Lambda、ALB、IPアドレスと幅広く登録でき、コンテナからサーバーレスまで同じサービスの抽象で束ねられます。加えて、可用性ゾーンをまたぐデータ転送では、クライアントと同じAZのサービスIPを優先的に返す仕組みを備え、AZ間のデータ転送料金を抑えつつ、AZ障害時には自動でフェイルオーバーする挙動です。重複CIDRを許容し、RAMでクロスアカウント共有できるため、事業部ごとにアカウントとVPCが分かれた大規模組織でも、サービス群を1つのネットワークとして扱えます。

処理したデータ量とサービスの稼働時間で決まる従量制の料金体系

VPC Latticeの費用は、大きく分けて「サービスやリソースのプロビジョニング時間」「処理したデータ量」「リクエスト数」に応じて発生します。サービス所有者はサービスの稼働時間・データ転送・リクエストに対して課金され、サービスネットワーク所有者はリソース設定の時間に対して課金される、という役割ごとの分担になっています。正確な単価は変わり得るため、見積もり時にはAWSの料金ページで対象リージョンの最新の単価を確認してください。ここで示すのは2026年7月時点の課金の考え方です。従量制であるため、常時稼働のサービス数と通信量を見積もると費用感がつかめます。

Transit Gateway・PrivateLink・App Meshとの使い分け

採否は、目的とレイヤーで次のように振り分けられます。複数VPC・複数アカウントのサービス群をサービス名でつなぎ、認証とルーティングまでインフラ側に寄せたいならVPC Latticeが向きます。単にVPC間のIP到達性を集約したいだけなら、ハブとして働くTransit GatewayやVPCピアリングで足り、アプリケーション層の制御は要りません。

特定のサービス1つへ、消費側から安全に届けたいだけなら、PrivateLink（VPCエンドポイント）の方が構成が軽く済みます。逆に、サイドカープロキシによる詳細なトラフィック制御やmTLSを東西通信に効かせたい場合は、サービスメッシュの領域です。終了が予定されているAWS App Meshの移行先としても、VPC Latticeは複数VPC・アカウント間連携を主眼にするケースの受け皿になります。どのサービスを選ぶべきか、既存構成を踏まえた設計から任せたい場合は、AWSのインフラ構築・移行支援で要件整理から実装・運用まで一貫して支援できます。

Amazon VPC Latticeの採用と設計でよくある質問

VPC Latticeの採否と設計でよく挙がる論点を、実装の観点で簡潔に答えます。

VPC LatticeとTransit Gatewayはどう違いますか？

扱うレイヤーが異なります。Transit Gatewayはネットワーク層で多数のVPCのIP到達性を集約するハブで、CIDRの重複を許しません。VPC Latticeはアプリケーション層でサービスを単位に接続し、重複CIDRを許容したうえで認証・ルーティング・可観測性まで内包します。両者は競合せず、IP集約はTransit Gateway、サービス接続はVPC Latticeと役割で分けて併用できます。

重複するCIDRのVPC同士でも接続できますか？

接続できます。VPC Latticeはサービスを論理的な名前で抽象化するため、VPC間のIPアドレス空間が重なっていても通信を成立させられる点が特徴です。VPCピアリングやTransit Gatewayでは重複CIDRが接続の妨げになるため、統合対象のVPCでアドレスが衝突している環境ほど、VPC Latticeの利点が効きます。

どのコンピュートリソースをターゲットにできますか？

EC2インスタンス、ECSやEKS上のコンテナ、Fargate、Lambda関数、Application Load Balancer、IPアドレスをターゲットグループに登録できます。コンテナとサーバーレスを同一のサービスの抽象で束ねられるため、混在するマイクロサービス環境でも接続方法を統一できます。

クロスアカウントでサービスを共有できますか？

できます。AWS Resource Access Manager（RAM）を使ってサービスネットワークやサービスを他アカウントへ共有すれば、アカウントをまたいだサービス間通信を構成する形です。事業部ごとにアカウントが分かれた組織で、共通サービスを複数アカウントから呼ぶといった構成に向きます。

通信の監視やログはどう取得しますか？

サービスネットワークを経由するリクエストとレスポンスごとに、メトリクスとアクセスログを生成できます。出力先はAmazon CloudWatchのロググループ、Amazon Data Firehose、Amazon S3から選べ、サービス所有者・リソース所有者・サービスネットワーク所有者がそれぞれの粒度でログ記録を設定する形です。サービス間の遅延やエラーの切り分けに使えます。

関連記事

• サービスメッシュとは：サイドカー方式で東西通信を制御する上位概念。VPC Latticeとの守備範囲の違いを整理。
• AWS Transit Gatewayとは：ネットワーク層でVPCを集約するハブ。VPC Latticeと併用する際の土台。
• AWS VPCエンドポイント（PrivateLink）とは：単一エンドポイントへ安全に届ける軽量な代替。使い分けの比較対象。
• ロードバランサーとは：リスナーとターゲットグループの基礎。VPC Latticeのルーティング理解の前提。
• モノリスとマイクロサービスの違い：サービス分割の考え方。なぜサービス単位の接続が要るかの背景。