🦉

【基礎編】VPC Lattice/VPCエンドポイントで異なるVPCのリソースに接続する方法3選

に公開
AWS
aurora
VPC
エンドポイント
lattice
tech

はじめに

VPC Latticeの蓋をようやく開けるときが来ました。ある日のこと,「このVPCのAuroraへに接続したいんだけど,VPCピアリングとTransit Gatewayどっちがいいかな？」と質問されました。確かVPC Latticeを使えばもっと簡単かつ最低限の穴あけだけで実現できるような。。。確信がもてない。。。てなことあったので今回は基礎編として実際にハンズオンしてみました。

実現したいこと

実現したいことは「異なるVPCにあるAuroraに接続する」になります。事前にVPC,サブネット,Aurora等のリソースを作成しました。動作確認はCloudShell VPC Environmentを使用します。psqlを実行してAuroraに接続できることを確認します。3つのパターンで接続できたので,それぞれのアーキテクチャ,必要なリソース,アクセス制御について紹介します。以降では,CloudShellを配置したVPCを「コンシューマーVPC」,Auroraを配置したVPCをプロバイダーVPCと呼びます。

Resource型VPCエンドポイント

1つ目はResource型VPCエンドポイントを使った方式です。VPC LatticeのResource Configuration,Resource Gateway（RGW）を利用します。

手順（Resource型VPCエンドポイント）

作成したリソースと作成順序は下記の通りです。

  1. RGW
  2. Resource Configuration
  3. Resource型VPCエンドポイント
    • DNS名を有効化：はい

SGのインバウンドルールは下記の通り設定しました。アウトバウンドルールはデフォルトのままなので割愛します。RGWのインバウンドルールは不要です。Resource型VPCエンドポイントのSGはどこからも参照されません。

タイプ プロトコル ポート範囲 ソース
Resource型VPCエンドポイント PostgreSQL TCP 5432 Cloud Shell SG
RGW - - - -
Aurora PostgreSQL TCP 5432 RGW SG

疎通確認（Resource型VPCエンドポイント）

接続できました！

# ホスト名にライターエンドポイントを指定
$psql -U postgres -p 5432 -h zenn-aurora-serverless-dev.cluster-cne2k6gawkmf.ap-northeast-1.rds.amazonaws.com
Password for user postgres:
psql (15.14, server 16.6)
WARNING: psql major version 15, server major version 16.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=>

Service Network型VPCエンドポイント

2つ目はService Network型VPCエンドポイントを使った方式です。

手順（Service Network型VPCエンドポイント）

  1. RGW

  2. Resource Configuration

  3. Service Network

  4. Service Network型VPCエンドポイント

    • 作成が完了するとService Networkの「エンドポイント関連付け」に自動反映されます

  5. 関連付け

    • Service NetworkにResource Configurationを関連付けると同じく画面に反映されます

SGのインバウンドルールは下記の通り設定しました。アーキ図ではService NetworkのSGが省略されているためご注意ください（どこに書くのが適切なんだろう？？）。アウトバウンドルールはデフォルトのままなので割愛します。RGWのインバウンドルールは不要です。Service Network型VPCエンドポイントのSGはどこからも参照されません。

タイプ プロトコル ポート範囲 ソース
Service Network型VPCエンドポイント PostgreSQL TCP 5432 Cloud Shell SG
Service Network PostgreSQL TCP 5432 CloudShell SG
RGW - - - -
Aurora PostgreSQL TCP 5432 RGW SG

疎通確認（Service Network型VPCエンドポイント）

疎通できました！

# ホスト名にライターエンドポイントを指定
$psql -U postgres -p 5432 -h zenn-aurora-serverless-dev.cluster-cne2k6gawkmf.ap-northeast-1.rds.amazonaws.com
Password for user postgres:
psql (15.14, server 16.6)
WARNING: psql major version 15, server major version 16.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=>

VPC関連付け

3つ目はLattice Service Networkに直接コンシューマーVPCを関連付けてAuroraにアクセスする方式です。2つ目の方式ではVPCにService Network型VPCエンドポイントが関連付けられ,Service Network型VPCエンドポイントにService Networkが関連付けられていました。

手順（VPC関連付け）

  1. RGW

  2. Resource Configuration

  3. Service Network

  4. 関連付け

    • Resource ConfigurationとコンシューマーVPCをService Networkに関連付けます

疎通確認（VPC関連付け）

この構成の場合はAuroraのエンドポイントに直接アクセスすることはできません。Resource Configuration > リソース設定の関連付け から払い出される「DNSエントリ：ドメイン」からアクセスします。ライターとリーダーの各エンドポイントに対応するDNSエントリが発行されます。当初,Auroraのエンドポイントに直接アクセスしていたため接続することができず,苦労しました。コンソールからDNSエントリを探し出すのにも時間を要しました。サービスネットワークの画面の「リソース設定の関連付け」タブを押下→リソース設定名が「rcfg-」から始まる関連付けIDを押下（リソース設定名は押下しない）→DNSエントリ,の順でたどり着くことができます。

# ホスト名にライターエンドポイントに対応するDNSエントリを指定
$psql -U postgres -p 5432 -h snra-0258ae5ca1fffbb4a.rcfg-01158845410b9f395.4232ccc.vpc-lattice-rsc.ap-northeast-1.on.aws
Password for user postgres:
psql (15.14, server 16.6)
WARNING: psql major version 15, server major version 16.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=> \q
# ホスト名にリーダーエンドポイントに対応するDNSエントリを指定
~ $psql -U postgres -p 5432 -h snra-0293fb8b823d3c65c.rcfg-0ba7ebc5ff6368de5.4232ccc.vpc-lattice-rsc.ap-northeast-1.on.aws
Password for user postgres:
psql (15.14, server 16.6)
WARNING: psql major version 15, server major version 16.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=> \q
# ホスト名にライターエンドポイントを指定：接続不可
~ $psql -U postgres -p 5432 -h zenn-aurora-serverless-dev.cluster-cne2k6gawkmf.ap-northeast-1.rds.amazonaws.com
psql: error: connection to server at "zenn-aurora-serverless-dev.cluster-cne2k6gawkmf.ap-northeast-1.rds.amazonaws.com" (10.0.143.144), port 5432 failed: Connection timed out
        Is the server running on that host and accepting TCP/IP connections?


SGのインバウンドルールは下記の通り設定しました。アーキ図ではService NetworkのSGが省略されているためご注意ください。アウトバウンドルールはデフォルトのままなので割愛します。RGWのインバウンドルールは不要です。

タイプ プロトコル ポート範囲 ソース
Service Network PostgreSQL TCP 5432 CloudShell SG
RGW - - - -
Aurora PostgreSQL TCP 5432 RGW SG

番外編

せっかくなのでLattice Serviceも使ってみます。3つ目の方式にLattice Serviceを導入します。Lattice ServiceにはLattice専用のターゲットグループが必要なので事前に作成します（ターゲットをなぜ"VPC"Lambdaにしたのかは謎）。

手順（Lattice Service）

  1. ターゲット（Lambda）

  2. ターゲットグループ

  3. Lattice Service

  4. 関連付け

    • 先ほどのService NetworkにLattice Serviceを関連付けます

SGのインバウンドルールは下記の通り設定を追加しました。

タイプ プロトコル ポート範囲 ソース
Service Network HTTPS TCP 443 CloudShell SG
Lambda - - - -

動作確認（Lattice Service）

無事Lambdaからレスポンスが返ってきました！

$curl  https://zenn-vpc-lattice-service-dev-0a836c24f4bc2c8ea.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
"Hello from Lambda!"
$curl  https://zenn-vpc-lattice-service-dev-0a836c24f4bc2c8ea.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws -I
HTTP/2 200
date: Thu, 25 Sep 2025 15:29:47 GMT
content-type: application/json
content-length: 20
x-amzn-requestid: cf71b252-7284-4460-ac17-ed299d1c8f36
x-amzn-remapped-content-length: 0
x-amz-executed-version: $LATEST
x-amzn-trace-id: Root=1-68d55feb-1001fff6679a96f4502a5f1f;Parent=071dcbb02b9ece44;Sampled=0;Lineage=1:e42985b8:0

用語解説メモ

  • Resource Gateway
    • プロバイダーVPCに関連付ける
    • 他のVPCからアクセスするために入口になる
    • 実態はENIなのでSGでアクセス制御する
  • Resource Configuration
    • RGWの指定が必須
    • 複数のResource Configurationを同一のRGWに関連付け可能
    • プロバイダーVPC側のリソース指定方法は,プライベートIPアドレス/DNS名/ARN（RDSのみ対応）の3パターン※1
    • プロトコルはTCPのみサポート
  • Resource型VPCエンドポイント
    • 実態はENIなのでSGでアクセス制御する
    • エンドポイントポリシー非対応
  • Service Network型VPCエンドポイント
    • 実態はENIなのでSGでアクセス制御する
    • エンドポイントポリシー非対応
  • Service Network
    • VPCの関連付けでSGを設定しない場合,SGによる通信制御は行われない
    • VPCの関連付けはコンシューマーVPCを指定する
    • 1つのService Networkに複数のVPCを関連付け可能
    • VPCに関連付けられるService Networkは1つだけ
    • IAM認証をサポート（リソースベースポリシーを付与できる）
    • 「サービスの関連付け」はレイヤー7をサポート（HTTP/HTTPS）
    • 「Rsource Configurationの関連付け」はレイヤー4をサポート（TCP）
  • Lattice Service
    • カスタムドメイン,IAM認証をサポート
    • あるターゲットグループは1つのLattice Service（リスナー）に関連付けられる（複数のリスナーに関連付けることは不可）

※1：AuroraのIPは変動するため「ARN」を採用した

Amazon Aurora はVPC 内にDBクラスターを作成する際に、DB サブネットグループの IP アドレスを使用して DBクラスターにネットワークインターフェースを割り当てます。ただし、DBクラスターへの接続にはドメインネームシステム (DNS) 名を使用することを強くお勧めします。これは、フェイルオーバー時に基盤となる IP アドレスが変更されるためです。

さいごに

今回はVPC Latticeを用いて異なるVPCのリソースにアクセスする方式を3つ提案しました。アクセス制御について,IAM認証は実装しませんでしたが,SGでアクセス元をかなり限定してセキュアな設定を実現できたと思います。番外編では1つのService Networkに複数のサービス（Lattice ServiceとResource Configuration）を関連付けることでLatticeのうま味を体験できました。Latticeによって取り得る構成が大幅に増えた一方,使い分けが難しく,学習コストも高いと感じました。今後はLatticeに関連付けられるプロバイダー側リソースについて整理しつつ,VPCエンドポイントとの使い分けを学んでいきます。

参考

Discussion