はじめに

Amazon VPC Lattice の Resource Gateway を使うと、Amazon VPC Peering（以下、VPC ピアリング）や AWS Transit Gateway を使わずに、アカウントをまたいでプライベートなリソースにアクセスできるようになります。

本ブログでは、

Aアカウントに配置した Amazon Aurora へ、Bアカウントから Resource Gateway 経由で接続する構成を試してみた結果
その過程で気になった DNS 解決の挙動、カスタムドメイン名まわりの考慮事項について調べてみた結果

についてまとめています。

今回の接続構成

今回試した構成は以下です。

【Bアカウント（クライアント側）】              【Aアカウント（リソース側）】
  Amazon EC2                                  Aurora クラスター
       |                                            |
  Resource VPC Endpoint  ─────────────→  Resource Gateway
                                               |
                                         Resource Configuration
                                         (Reader Endpoint を登録)

Aアカウント: Aurora クラスターを持つアカウント。
Resource Gateway と Resource Configuration を作成し、AWS Resource Access Manager（以下、AWS RAM）でBアカウントに共有。
Bアカウント: AWS RAM 経由で共有された Resource Configuration に対して Resource VPC Endpoint を作成し、Aurora にアクセス。

クロスアカウントのユースケースとして「参照系の処理のみを別アカウントへ提供したい」というシナリオを想定したかったので、Reader Endpoint を登録する形にしています。Reader Endpoint に限定して共有することで、書き込みは Aアカウント内に閉じたまま、Bアカウントには読み取り専用のアクセスだけを提供する形となります。

設定手順

設定手順は大きく Aアカウント（リソース提供側）での作業 と Bアカウント（クライアント側）での作業 に分かれます。順番に見ていきます。

Aアカウントでの作業

Aアカウントでは、共有するリソース（Aurora）の周辺に Resource Gateway / Resource Configuration を作成し、AWS RAM でBアカウントに共有する、までを一通り行います。具体的には以下の4ステップです。

セキュリティグループの作成・追加
Resource Gateway の作成
Resource Configuration の作成
AWS RAM で Resource Configuration を共有

A-1. セキュリティグループの作成・追加

まずは Resource Gateway および Aurora それぞれに適用するセキュリティグループの作成・追加を行います。

Resource Gateway 用セキュリティグループの作成

Resource Gateway のセキュリティグループは、Gateway からバックエンドリソースへのアウトバウンドトラフィックを制御するものとなります。以下のアウトバウンドルールを設定します。

方向	プロトコル	ポート	送信先
アウトバウンド	TCP	3306	Aurora のセキュリティグループ（または CIDR）

なお、インバウンド側（クライアントから Resource Gateway への通信）は AWS 内部のネットワークを経由するため、セキュリティグループへのインバウンドルールの追加は不要です。

Aurora 用セキュリティグループへのルール追加

Aurora 側の既存のセキュリティグループに、Resource Gateway からのインバウンドを許可するルールを追加します。

方向	プロトコル	ポート	送信元
インバウンド	TCP	3306	Resource Gateway 用セキュリティグループ

A-2. Resource Gateway の作成

セキュリティグループの準備ができたら、AアカウントのVPC内に Resource Gateway を作成します。

設定のポイントは以下の通りです。

IPアドレスタイプ: IPv4 / IPv6 / Dualstack から選択。Resource Gateway のサブネットと、対象リソース（Aurora）の IP アドレスタイプに合わせる必要がある。今回は IPv4 を選択。
リソース設定 DNS 解決タイプ: ターゲットの名前解決方式として パブリック か VPC内 を選択。今回はパブリックを選択。元々はパブリックのみであったが、VPC内 の選択肢が最近のアップデートで追加された。
VPC / サブネット: Aurora が配置されている VPC 内のサブネットを指定。Aurora と同じサブネットである必要はないが、Aurora のリソースが存在する AZ には Resource Gateway も存在している必要がある。
セキュリティグループ: A-1 で作成した Resource Gateway 用セキュリティグループを指定

A-3. Resource Configuration の作成

続いて、Resource Configuration で共有したいリソースを登録していきます。

Resource Configuration を作成する際、まず大きく以下の 設定タイプ を選択します。

設定タイプ	概要
リソース	単独のリソース設定。単独で AWS RAM 共有が可能
リソースグループ	複数の子リソース設定をまとめたグループ。グループ単位で AWS RAM 共有が可能

「リソース」を選択した場合は、さらに以下の タイプ を選択します。

タイプ	概要
単一（Single resource configuration）	単独のリソース設定として作成
子（Child resource configuration）	リソースグループに属する子のリソース設定として作成。子単独では AWS RAM 共有はできず、所属するグループ単位での共有のみ可能。
ARN（ARN resource configuration）	AWS が提供するサービスのリソースを ARN で直接指定する形式。現状サポートされているのは Amazon RDS データベースのみ。子リソース設定（Writer / Reader 各ノードなど）は AWS 側で自動的に管理される。

タイプとして「単一」「子」を選択した場合は、さらにターゲットとして指定する リソースタイプ を選択します。

リソースタイプ	概要
IP アドレス	プライベート IP アドレスを直接指定。VPC 内のプライベート IP アドレス範囲（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、100.64.0.0/10）から指定可能で、パブリック IP は指定不可。
ドメイン名	FQDN（ドメイン名）を指定。Aurora の Cluster Endpoint や Reader Endpoint など、DNS 名で表現されるリソースに利用。

Aurora の場合、タイプとして ARN を選択しクラスターを指定することも可能ですが、その場合は Writer / Reader の各ノードを含む形で子リソースが自動構成されます。今回は Reader Endpoint のみに絞って共有したかったため、「単一 × ドメイン名」で Reader Endpoint のドメイン名を直接指定する形としました。

また、リソースタイプにドメイン名を指定する場合、Resource Gateway による名前解決が行われます。今回は Aurora の Reader Endpoint がパブリック DNS で名前解決できるため特別な設定は不要でしたが、この挙動の詳細については後述のセクションで触れます。

今回の設定は以下です。

設定タイプ: リソース
タイプ: 単一
リソースタイプ: ドメイン名
ドメイン名: Aurora の Reader Endpoint（例: mydb.cluster-ro-xxxx.ap-northeast-1.rds.amazonaws.com）
ポート: 3306
Resource Gateway: A-2 で作成したもの

A-4. AWS RAM で Resource Configuration を共有

作成した Resource Configuration を AWS RAM でBアカウントに共有します。

共有先にはBアカウントのアカウントID、もしくは AWS Organizations の OU を指定する形となります。

ここまでで、Aアカウント側の作業は完了です。続いてBアカウント側に切り替えて作業していきます。

Bアカウントでの作業

Bアカウントでは、Aアカウントから共有された Resource Configuration を承諾し、それに紐付ける形で Resource VPC Endpoint を作成します。具体的には以下の3ステップです。

RAM 招待の承諾
セキュリティグループの作成・追加
Resource VPC Endpoint の作成

B-1. RAM 招待の承諾

まずは AWS RAM で、Aアカウントから共有された Resource Configuration の招待を承諾します。

B-2. セキュリティグループの作成・追加

続いて、Resource VPC Endpoint およびクライアント（EC2）それぞれのセキュリティグループを設定します。

Resource VPC Endpoint 用セキュリティグループの作成

Resource VPC Endpoint のセキュリティグループは、クライアントから Endpoint へのインバウンドトラフィックを制御します。

方向	プロトコル	ポート	送信元
インバウンド	TCP	3306	クライアント用セキュリティグループ（または CIDR）

なお、Endpoint からバックエンド（Resource Gateway）方向の通信は AWS 内部のネットワークで処理されるため、アウトバウンドルールの設定は不要です。

クライアント用セキュリティグループへのルール追加

クライアント（EC2）の既存のセキュリティグループに、Resource VPC Endpoint へのアウトバウンドを許可するルールを追加します。

方向	プロトコル	ポート	送信先
アウトバウンド	TCP	3306	Resource VPC Endpoint 用セキュリティグループ（または CIDR）

B-3. Resource VPC Endpoint の作成

BアカウントのVPC内に Resource VPC Endpoint を作成し、共有された Resource Configuration に紐付けます。

タイプ、リソース設定: 共有された Resource Configuration を選択
VPC、サブネット: クライアントが存在するVPC、サブネット（Resource Gateway との間でAZが最低1つ重複している必要あり）
セキュリティグループ: B-2 で作成した Resource VPC Endpoint 用セキュリティグループを指定

疎通確認

BアカウントのEC2から、Resource VPC Endpoint の DNS 名を使って Aurora の Reader Endpoint に接続します。

無事に Aurora の Reader Endpoint への接続が確認できました。

関連知見

Resource Gateway の DNS 解決タイプについて

ここまでで、クロスアカウントでの Aurora 接続自体は確認できました。続いて、設定中で軽く触れた DNS 解決の挙動について少し掘り下げてみます。

DNS解決タイプ「パブリック」とは？

Resource Configuration に DNS 名（ドメイン名）を登録すると、Resource Gateway がその名前解決を行います。ここで気になるのが、Resource Gateway のデフォルトの DNS 解決方式が「パブリック」 となっている点です。「パブリック」と聞くと、グローバル IP アドレスが設定されているリソースが対象なのでは？と思った方もいるかもしれません。

ここでいう「パブリック」とは、パブリック DNS リゾルバーで名前解決を行うという意味であり、解決結果として返る IP アドレスがパブリックかプライベートかは問いません。つまり、「パブリック DNS で名前解決できる = パブリック IP アドレスに解決されるではない」ということです。

Aurora のエンドポイントは、パブリック DNS に登録されています（つまりインターネット上で名前解決ができる）が、解決結果として返ってくるのは プライベート IP アドレスとなります。Resource Gateway はそのプライベート IP アドレスへ VPC 内から直接通信するため、Aurora がパブリックに公開されているわけではない、ということになります。

【DNS 解決の流れ（デフォルト: パブリックモード）】

Resource Gateway
  → パブリック DNS リゾルバーで Reader Endpoint を名前解決
  → 解決結果: プライベート IP アドレス（例: 10.0.x.x）
  → そのプライベート IP アドレスへ VPC 内から直接通信

今回の構成でも特別な設定は不要で、そのまま動作しました。一方で、Route 53 プライベートホストゾーンや社内 DNS で管理しているドメイン名の場合は、パブリック DNS では解決できないため、DNS解決タイプ「IN VPC（VPC内）」の利用が必要になります。

DNS解決タイプ「IN VPC（VPC内）」について

Resource Gateway の DNS 解決モードに VPC内 が選択肢として追加されたのは2026年5月4日のアップデートで、それまではパブリックのみでした。これにより、パブリック DNS で名前解決できないドメイン（Route 53 プライベートホストゾーンや社内 DNS で管理しているドメイン名）も Resource Configuration のターゲットとして利用できるようになっています。（今回は未検証のため以下はドキュメントレベルの情報）

参考：Amazon VPC Lattice のリソース設定でプライベートなドメイン名ターゲットのサポートを開始（What's New）

Resource Gateway の DNS 解決タイプは作成時に パブリック か VPC内 を選択する形となっており、この設定は後から変更ができません。

モード	概要	用途
パブリック（デフォルト）	パブリック DNS リゾルバーで解決	Aurora などパブリック DNS で名前解決できるリソース
VPC内	VPC の DHCP オプションセットで設定された DNS サーバーで解決	Route 53 プライベートホストゾーン、社内 DNS など

Route 53 プライベートホストゾーンで管理しているドメイン名を Resource Configuration に使いたい場合は、Resource Gateway を DNS解決タイプ「IN VPC（VPC内）」で作成する必要があります。既存の Gateway の変更はできないため、設計の段階で意識しておく必要があります。

なお、VPC内モードには以下の制約もあります。

IPv6 のみのサブネットには使用不可
ARN で定義された Resource Configuration はアタッチ不可

カスタムドメイン名の利用について

VPC Lattice では、Resource Configuration に対してカスタムドメイン名（任意の FQDN）を割り当てることも可能です（今回は未検証）。カスタムドメイン名を利用するケースとしては、大きく分けて以下の2つがあるかなと思います。

① 接続先を抽象化したい場合

アプリケーション側の接続先を任意の FQDN（例: db.example.com）に統一しておくことで、Aurora のエンドポイントが将来変更になってもアプリケーションの接続設定を変えずに済む、というメリットが得られます。

このパターンでは、カスタムドメイン名は AWS 提供のドメインとは別の任意の名前（自社で所有するドメインなど）を使うことが一般的です。なお、自社所有ドメインを使う場合はドメイン検証（TXT レコードによる所有権確認）が必要となります。

② SSL/TLS でホスト名検証付きの接続を行いたい場合

ホスト名検証付きの SSL/TLS 接続（PostgreSQL の sslmode=verify-full や、HTTPS クライアントが行う一般的な証明書検証など）では、サーバー証明書のホスト名（CN/SAN）とクライアントが接続に使うホスト名が一致している必要があります。Resource Configuration のカスタムドメイン名と、サーバー証明書のホスト名が一致しないと、証明書検証エラーになります。

このケースは、リソース側でどのように証明書が用意されるかによって、考え方が少し変わります。

パターン1: AWS 側でサーバー証明書が提供されるリソース（Aurora など）

Aurora のように AWS 側でサーバー証明書が提供されており、クライアントが任意の証明書を持ち込めないリソースの場合、サーバー証明書に記載されているホスト名（= Aurora 本来のエンドポイント名）をそのままカスタムドメイン名として Resource Configuration に設定することで、ホスト名検証を通すことができます。

※PostgreSQLのsslmode=verify-caのように証明書の CA のみ検証し、ホスト名は検証しないケースでは、①のパターンで任意のカスタムドメイン名を使うことができます。

パターン2: 自前で証明書を用意するリソース（EC2 上の Web サーバーなど）

例えば EC2 上で動かしている Web サーバーや独自サービスのように、ユーザー側でサーバー証明書を用意できるケースでは、自分で発行する証明書のホスト名と一致するカスタムドメイン名を Resource Configuration に設定する形となります。Resource Configuration のカスタムドメイン名（例: service.example.com）に対応する証明書をリソース側にセットしておくことで、クライアントは service.example.com を使って接続でき、ホスト名検証も通るようになります。

いずれのパターンも考え方は共通で、「クライアントが指定するホスト名」「カスタムドメイン名」「サーバー証明書のホスト名」を一致させる、という形になります。

参考情報

Resource Gateway とカスタムドメイン名を組み合わせる際の考慮事項（ドメイン検証、プライベートホストゾーンの管理など）については、以下のドキュメントおよびブログ記事が参考になります。

おわりに

AWS Resource Gateway（VPC Lattice）を使ったクロスアカウントでの Aurora 接続を試しつつ、Resource Gateway を扱う上で押さえておきたい名前解決、カスタムドメインまわりの話についても整理してみました。

VPC ピアリングや Transit Gateway を使わずにシンプルな構成でプライベートなリソースへのアクセスを実現できるのは、なかなか使い勝手がよさそうだなというのが個人的な感触です。一方で、DNS 解決タイプの選択や、カスタムドメイン名と SSL/TLS の組み合わせ方など、構成を考える前段で意識しておきたいポイントもあるなと感じました。今回未検証だった範囲もいずれ試してみたいと思います。

参考リンク