Amazon VPC Lattice で CIDR 重複・ピアリングなしの 3 VPC 構成を試してみた

はじめに

最近、AWS Application Networking Demonstrated の microcredential を取得しました。

その中で、Amazon VPC Lattice についての出題があったのですが、実際に触ったことがなかったので少し動作確認してみることにします。

今回は VPC Lattice を使って、CIDR が重複した 3 つの別 VPC をピアリングなしで繋ぐハンズオンを実施してみます。

この記事で学べること

• VPC Lattice の基本的な仕組み（サービスネットワーク・サービス・リソース設定）
• CIDR が重複した 3 つの VPC をピアリングなしで繋ぐ構成と手順
• VPC Lattice のおおよその料金（東京リージョン）

前提知識・条件

• 検証日: 2026 年 6 月 4 日 / リージョン: 東京（ap-northeast-1）
• EC2 や Aurora　などは AWS CDK（TypeScript）を使って事前に準備しておきます

VPC Lattice とは

Amazon VPC Lattice は、VPC やアカウントをまたいだアプリケーション間の通信を接続・保護・監視できるフルマネージドのアプリケーションネットワーキングサービスです。

従来は VPC ピアリング / PrivateLink などを自分で組み合わせる必要がありました。

VPC Lattice はこれらを「サービスネットワーク」という論理的なまとまりに抽象化してくれるようですね。

うれしいポイントをざっくりまとめるとこんな感じです。

• CIDR が重複していても OK（VPC のアドレス設計に縛られない）
• ピアリング不要（サービスネットワークに繋ぐだけで通信できる）
• 負荷分散つき（複数ターゲットを登録するだけでラウンドロビン分散）

といった感じです。今回はこの恩恵を実際に確認していきます！

やってみた

具体的な仕組みなどは実際にやってみながら確認します。

構成

今回は以下の構成で動作確認してみます。

        VPC-1                    VPC-2                      VPC-3
   ┌─────────────┐         ┌──────────────────┐     ┌──────────────┐
   │  Lambda     │         │  EC2 #1 (AZ-a)   │     │  Aurora      │
   │ (クライアント)│         │  EC2 #2 (AZ-c)   │     │ (リソース)     │
   └──────┬──────┘         │  = EC2 サービス   │     └──────▲───────┘
          │                └─────────▲────────┘             │
          │ VPC アソシエーション        │ サービス関連付け        │ リソース設定+RGW関連付け
          └───────────┬──────────────┴───────────┬──────────┘
                      ▼                           ▼
              ┌─────────────────────────────────────┐
              │        サービスネットワーク             │
              └─────────────────────────────────────┘
                      ▲
        (Function URL 経由で Internet からクライアント Lambda へ)

3 つの VPC はすべて CIDR を 10.0.0.0/16 で重複させています。「ピアリングなし・CIDR 重複でも通信できる」ことを体感するための設計です。

リクエストの流れは「Internet → (Function URL) → クライアント Lambda →（1）EC2 サービス /（2）Aurora(リソース)」です。

ポイントは、3 つの VPC がピアリングもアドレス設計の調整もなしに「サービスネットワーク」を介して繋がるところです。

図中の用語（サービス関連付け、リソース設定、VPC アソシエーションなど）は、このあと手順の中で 1 つずつ説明します。

なお、VPC Lattice のサービスはインターネットから直接叩けないプライベート専用の仕組みなので、今回は一番手軽なクライアント Lambda の Function URL を使います。

準備

各コンポーネントの理解が目的なので、土台は CDK で作成し、VPC Lattice の設定はコンソールで手動作成してみます。

以下、CDK の構成です。

スタック	内容
Vpc1Stack（クライアント）	VPC-1、クライアント Lambda（VPC アタッチ、Function URL）、クライアント用 SG
Vpc2Stack（EC2 サービス）	VPC-2、EC2 ×2（httpd、別 AZ）、ターゲット用 SG
Vpc3Stack（リソース）	VPC-3、Aurora PostgreSQL（Serverless v2）、Aurora 用 SG

ソースは以下の通りです。

今回 Lambda を VPC 内に配置しています。これは VPC Lattice を利用するためには下記の通り、VPC 内にリソースがある必要があるからです。

クライアントは、同じサービスネットワークに接続されている VPC 内にある場合にのみ、サービスネットワークに関連付けられたサービスとリソースにリクエストを送信できます。

セキュリティグループ

なお、VPC Lattice に関連したセキュリティグループのみは先行して、CDK で作っておきました。

VPC を跨いだ通信は全て、マネージドプレフィックスリスト（com.amazonaws.ap-northeast-1.vpc-lattice）経由で通信が来るところが特徴です。

• EC2（ターゲット）の SG: VPC Lattice プレフィックスリストからのインバウンド 80（HTTP）を許可
• Aurora の SG: リソースゲートウェイ（同一 VPC）からのインバウンド 5432 を許可
• VPC アソシエーションの SG（クライアント VPC 側）: VPC CIDR からのインバウンドに、アクセス先のポート（EC2 サービス用に 80、Aurora 用に 5432）を許可

マネージドプレフィックスリスト（com.amazonaws.ap-northeast-1.vpc-lattice）は確認してみると、以下２つのアドレスを持ってるみたいですね。

では、作成していきます。

手順 1: サービスネットワークを作成

サービスネットワークは後述するサービスとリソースをまとめ、通信を許可しあうグループの単位のようなものです。ここに VPC を関連付けると各 VPC 間で通信できるようになります。

VPC Lattice → サービスネットワーク →「サービスネットワークを作成」から作成可能です。

今回は一番シンプルに作ってみました。

• 名前: lattice-demo-sn
• 共有（RAM）:「共有しない」
• 認証: なし

手順 2: EC2 サービスを作成して関連付け

サービスは、マイクロサービスにおける 1 サービスのような論理的な単位です。

その実体となる EC2 などを「ターゲットグループ」に登録し、リスナーが受けたリクエストをそこに振り分けます。

ここでは、2 台の EC2 がある VPC を EC2 サービスとして登録し、サービスネットワークに関連付けます。

VPC Lattice → サービス →「サービスを作成」で作成します。

サービスもシンプルに作ります。

• 名前: ec2-service
• 認証タイプ: なし

次にリスナー、ターゲットグループを作っていきます。

ALB のリスナー、ターゲットグループとほぼ同じようなものです。

設定内容は以下の通りです。

• リスナー: プロトコル HTTP / ポート 80
• ターゲットグループを作成
  • 名前: service-a-ec2-tg
  • ターゲットタイプ: インスタンス
  • VPC: lattice-vpc2-service
  • プロトコル/ポート: HTTP / 80
  • ヘルスチェック: HTTP / パス /
  • ターゲット登録: EC2 2 台

そして最後にサービスをサービスネットワーク lattice-demo-sn に関連付けます。

手順 3: リソース（Aurora）を作成して関連付け

リソースとは、EC2 や Lambda のような「アプリ本体」ではなく、DB やキャッシュのように「別 VPC から直接つなぎたいエンドポイント」を共有する仕組みです。

仕組みとしては、リソースゲートウェイ（リソースがある VPC への入り口）とリソース設定（リソースの論理定義）の 2 つを作ります。

まず、VPC Lattice → リソースゲートウェイ →「リソースゲートウェイを作成」からリソースゲートウェイを作成します。

設定内容は以下の通りです。

• 名前: aurora-resource-gw
• VPC: lattice-vpc3-resource
• サブネット: ap-northeast-1a と ap-northeast-1c（DB サブネットグループと同じ）
• SG: AuroraSg
• リソース設定 DNS 解決タイプ: IN_VPC（Aurora のプライベート DNS をこの VPC 内で解決するため）

次に VPC Lattice → リソース設定 →「リソース設定を作成」からリソース設定を作成します。

設定内容は以下の通りです。

• 名前: aurora-postgres-rc
• 設定タイプ: リソース
• リソースタイプ: DNS リソース
• ドメイン名: Aurora クラスターエンドポイント
• IP アドレスタイプ: IPv4、ポート範囲: 5432-5432
• リソースゲートウェイ: aurora-resource-gw

最後にリソース設定をサービスネットワーク lattice-demo-sn に関連付けしておきます。

手順 4: クライアント VPC（Lambda）を関連付け

VPC Lattice における「クライアント」とは、サービスやリソースに対してリクエストを送る側のことです。今回は Lambda をクライアントにします。

また、このクライアント Lambda は「入り口兼クライアント」の二役で、Function URL でインターネットから受けつつ、VPC アタッチ + VPC 関連付けで Lattice 経由の通信もできるようにします。

VPC アソシエーション（関連づけ）は「この VPC 内のクライアントがサービスネットワーク上のサービス/リソースにアクセスできる権利」を与える操作です。

では設定します。

サービスネットワーク lattice-demo-sn から「VPC の関連付け」を行います。

設定内容は以下の通りです。

• VPC: lattice-vpc1-client
• SG: ClientSg
• DNS 名を有効にする: チェックを入れる
• プライベート DNS の詳細設定: 検証済みドメインのみ

手順 5: Lambda の設定

動作確認の前にクライアント Lambda の処理を紹介しておきます。

やっていることはシンプルで、1 リクエストで「EC2 サービスへの HTTP 呼び出し」と「Aurora への接続クエリ」を並行して実行し、両方の結果を JSON で返すだけです。

// 1. EC2 サービスを VPC Lattice 経由で HTTP 呼び出し
async function callServiceA(): Promise<StepResult> {
  const res = await fetch(SERVICE_A_ENDPOINT, { signal: AbortSignal.timeout(5000) });
  const body = (await res.text()).trim();
  return { ok: res.ok, detail: body };
}

// 2. Aurora にリソース設定の DNS 名経由で接続してクエリ
async function queryAurora(): Promise<StepResult> {
  // DB 認証情報は Secrets Manager から取得
  const secretValue = await secrets.send(new GetSecretValueCommand({ SecretId: DB_SECRET_ARN }));
  const { username, password } = JSON.parse(secretValue.SecretString ?? '{}');

  const client = new Client({ host: DB_HOST, port: DB_PORT, database: DB_NAME, user: username, password,
    connectionTimeoutMillis: 5000, ssl: { rejectUnauthorized: false } });
  await client.connect();
  const result = await client.query('SELECT inet_server_addr() AS server_ip, version() AS version');
  // ...
}

export const handler = async () => {
  const [serviceA, db] = await Promise.all([callServiceA(), queryAurora()]);
  return { statusCode: 200, /* ... */ body: JSON.stringify({ service_a: serviceA, db }) };
};

接続先（SERVICE_A_ENDPOINT / DB_HOST）は全て VPC Lattice の専用のドメイン名を指定するところが特徴ですね。

環境変数	値
SERVICE_A_ENDPOINT	http://ec2-service-0cb1ddad97a823683.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
DB_HOST	snra-095fd955e556b01e5.rcfg-04080adc42ca26ee3.4232ccc.vpc-lattice-rsc.ap-northeast-1.on.aws

手順 6: 動作確認

最後にクライアント Lambda の関数 URL を使って curl で叩いてみます。

curl <ClientFunctionUrl>

成功すると以下のような JSON が返ってきます！

{
  "message": "VPC Lattice 経由でサービス A とリソース(Aurora)にアクセスした結果",
  "service_a": {
    "ok": true,
    "detail": "Hello from Service A | instance=i-032a4aeab634f20f3 | az=ap-northeast-1c"
  },
  "db": {
    "ok": true,
    "detail": "server_ip=10.0.0.163, version=PostgreSQL 16.11 on aarch64-unknown-linux-gnu"
  }
}

これで 3 つの別 VPC がピアリングなし・CIDR 重複（すべて 10.0.0.0/16）で通信できることを実際に確認できました。

何度か叩くと instance= の値が i-032a4aeab634f20f3（AZ-c）と i-0a866c7b64512ec89（AZ-a）で交互に切り替わります。ラウンドロビン分散の確認できます。

料金

最後に料金を確認しておきます。

VPC Lattice の課金は「（1）サービス数（時間）（2）データ処理（GB）（3）リクエスト数」です。リソースは別体系（時間 + データ処理）になっています。

下表は東京リージョン（ap-northeast-1）の料金です（2026 年 6 月時点）。

項目	単価	備考
VPC Lattice サービス	$0.0325/時	サービス 1 つあたり
VPC Lattice データ処理	$0.0325/GB	サービスへの送受信合計
VPC Lattice リクエスト	$0.13/100 万リクエスト	1 時間あたり最初の 300,000 件は無料(Always Free Tier)
VPC Lattice リソース	$0.14/時	サービスネットワークに追加する VPC リソース 1 つあたり

まとめ

今回は VPC Lattice を使って、CIDR が重複した 3 つの VPC をピアリングなしで繋ぎ、EC2 サービスへのラウンドロビン分散と Aurora への接続を 1 本のリクエストで確認しました。

VPC Lattice 専用の用語が多く、構築に複雑さはあるものの、構築後はドメインで VPC 間を意識せず接続できるのは体験が良さそうです。

サービス（呼ばれる側）とリソース（DB 等）が別系統になっている点や、クライアントが VPC 内にいることが前提という点は、最初に押さえておくと構成設計で迷いにくくなると思います。

今回は基本的な機能の紹介ですが、私が経験した microcredential で出題された内容をカバーできる内容ですので、誰かのお役に立てると幸いです！