VPC 内のリソースを別の VPC やアカウントから安全に利用したい場面は、マルチアカウント構成が一般化した現在では珍しくありません。これまでは AWS PrivateLink のエンドポイントサービス、VPC ピアリング、Transit Gateway などを組み合わせて対応してきましたが、いずれにも制約がありました。PrivateLink のエンドポイントサービスはプロバイダー側に Network Load Balancer(NLB)を前段として置く必要があり、Amazon RDS のようなマネージドリソースをそのまま公開するには向きません。ピアリングや Transit Gateway は経路をつなげる仕組みであるため、双方の CIDR(IP アドレス空間)が重複していると素直にルーティングできないという根本的な課題を抱えていました。
AWS VPC Resource Gateways は、こうした課題に対して「リソース単位でのプライベート接続」という新しい選択肢を提供します。NLB を必須とせず、CIDR が重複する環境でも単方向のプライベート接続を確立できる点が大きな特徴です。本記事では、構成要素と仕組み、PrivateLink や VPC Lattice との違い、代表的なユースケース、設計と運用のベストプラクティスを整理します。
VPC Resource Gateways とは何か
VPC Resource Gateways は、従来の PrivateLink プロバイダー/コンシューマーモデルには馴染まないリソースへのプライベート接続を実現する仕組みです。PrivateLink のエンドポイントサービスは、サービス提供者が NLB を前段に配置することを前提としたモデルでした。しかし、Amazon RDS のようにエンドポイントが DNS 名で表現されるマネージドリソースや、特定の IP アドレス、ドメイン名で表されるリソースを直接プライベート公開したいケースには、この前提が合いません。
また、VPC ピアリングや Transit Gateway は経路そのものをつなぐ技術であるため、接続する双方の VPC で CIDR が重複していると、宛先の判別ができずルーティングが破綻します。企業合併(M&A)やパートナー間接続、CIDR の計画が事前に調整されていなかった環境では、この重複問題が接続の障壁になりがちでした。VPC Resource Gateways は、リソースを個別のエンドポイントとして公開することで、経路レベルの CIDR 重複に左右されにくい接続を可能にします。
この機能は VPC Lattice のリソース機能群として提供され、PrivateLink のリソースエンドポイントから利用できます。つまり、VPC Lattice の大規模なサービスネットワークをフルに構築しなくても、リソースゲートウェイとリソースエンドポイントという最小構成から段階的に導入できるようになっています。
構成要素とプライベート接続の仕組み
VPC Resource Gateways を使ったプライベート接続は、主に 3 つの構成要素で成り立っています。それぞれの役割を理解すると、後述のユースケースがイメージしやすくなります。
Resource Gateway
Resource Gateway は、リソースが存在する VPC のプライベートサブネットに作成する入口です。1 つの VPC あたり最大 100 個まで作成できます。ゲートウェイからリソースへのアウトバウンド通信はセキュリティグループで制御でき、IPv4、IPv6、デュアルスタックのいずれにも対応します。プライベート DNS や Route 53 プライベートホストゾーンを利用する場合は、ゲートウェイの DNS 解決を IN_VPC に設定します。
Resource Configuration
Resource Configuration は、公開するリソースそのものを定義する設定です。ターゲットの種別は 3 つあり、ARN、ドメイン名(DNS)、IP アドレスから選べます。ARN をターゲットにする場合、現時点では Amazon RDS がサポート対象です。プライベート DNS や Route 53 プライベートホストゾーンを併用する場合は、前述のとおりゲートウェイの DNS 解決を IN_VPC にします。なお、子リソースの設定は AWS 側が自動的に管理します。
リソースエンドポイント
リソースエンドポイントは、コンシューマー側の VPC に作成する「resource」タイプの VPC エンドポイントです。ENI ベースで動作し、プロバイダー側に NLB を置く必要がありません。接続は単方向で、コンシューマーからプロバイダー側のリソースへプライベートにアクセスする形になります。この単方向性が、公開範囲を絞り込みたいセキュリティ要件と相性が良い点です。
アクセス方式そのものは、リソースエンドポイント、VPC Lattice サービスネットワークアソシエーション、サービスネットワークエンドポイントの 3 種類があります。本記事では、このうちリソースゲートウェイとリソースエンドポイントを組み合わせる方式に焦点を当てて解説します。
PrivateLink・VPC Lattice との違いと使い分け
VPC Resource Gateways を検討する際は、既存の PrivateLink エンドポイントサービスや VPC Lattice サービスネットワークとの位置づけを整理しておくと選択を誤りません。それぞれ得意とする領域が異なります。
方式 | NLB の要否 | 公開対象の考え方 | 向いている規模感 |
|---|---|---|---|
PrivateLink エンドポイントサービス | プロバイダー側に NLB が必要 | サービス提供者中心のモデル | 自前サービスの提供 |
リソースゲートウェイ + リソースエンドポイント | NLB 不要(ENI ベース) | RDS やドメイン名/IP などリソース中心 | 個別リソースの直接公開 |
VPC Lattice サービスネットワーク | 方式に依存 | 多数のサービス/リソースを論理ネットワークに束ねる | 大規模・多対多の一元管理 |
PrivateLink のエンドポイントサービスは、自分たちで作り込んだサービスを提供するのに適していますが、前段の NLB が前提になります。リソースゲートウェイとリソースエンドポイントの組み合わせは NLB を必要とせず、RDS やドメイン名、IP で表現されるリソースを直接プライベート公開できます。VPC Lattice サービスネットワークは、多数のサービスやリソースを 1 つの論理ネットワークに束ね、認可や監視を一元化したい大規模・多対多のシナリオに向いています。
重要なのは、これら 3 者が排他的ではないという点です。リソース設定はサービスネットワークにも関連付けられるため、まずリソースエンドポイントで小さく始め、対象が増えてきたら VPC Lattice のサービスネットワークへ発展させる、といった組み合わせも可能です。
代表的なユースケースと実装パターン
ここからは、VPC Resource Gateways が効果を発揮する代表的な 4 つのユースケースを、どんな場面か、従来どう回避していたか、そしてどう解決するか、という観点で見ていきます。
マルチアカウント/クロス VPC の RDS アクセス
ビジネスユニットごとにアカウントを分離している構成や、M&A で別々に運用されてきた環境をつなぐ場面です。従来はピアリングや Transit Gateway で経路をつなぎつつ、RDS の公開にあたっては NLB を挟むといった工夫が必要でした。リソースゲートウェイを使うと、ARN(RDS)をターゲットにしたリソース設定を作り、AWS RAM でコンシューマー側に共有します。コンシューマー側で共有を承認したうえでリソースエンドポイントを作成すれば接続できます。プライベート DNS が有効な場合は RDS の writer/reader/instance の DNS 名を利用でき、無効な場合はエンドポイントの DNS 名を利用します。
CIDR が重複する環境での接続
M&A やパートナー接続、CIDR 計画が調整されていなかった環境で、双方の IP 空間が重なってしまうケースです。従来は NAT Gateway や、NLB とエンドポイントサービスの組み合わせで重複を回避していました。リソースエンドポイントは ENI ベースの単方向接続であるため、経路上の CIDR 重複に左右されにくく、コンシューマー側にプライベートホストゾーンと CNAME を用意してリソースへの名前解決をマッピングすることで、重複環境でも接続を成立させやすくなります。
パブリックエンドポイントへの集中経路
すべての外向き通信を一元化 VPC 経由に義務づけている環境や、PrivateLink 非対応の SaaS やサービスへアクセスしたい場面です。従来は各 VPC で個別に外向き経路を用意していました。リソースゲートウェイを一元化 VPC に置き、その先を NAT Gateway 経由でパブリックエンドポイントへ流すことで、外向きの経路を集中させられます。この構成は Site-to-Site VPN や Direct Connect と併用でき、オンプレミスからも同じ経路を利用できます。
集約 VPC エンドポイントへのアクセス
各 VPC でインターフェース型 VPC エンドポイントを個別に多数作成すると、管理もコストも増えていきます。集約 VPC にエンドポイント群をまとめ、そこへリソースエンドポイント経由でアクセスさせることで、単一のリソースエンドポイントから複数の AWS サービスへ到達させる構成を取れます。エンドポイントの分散を抑え、運用をシンプルにできる点がメリットです。
設計・運用のベストプラクティスと注意点
VPC Resource Gateways を安定して運用するには、DNS と TLS まわりの設定を丁寧に押さえておくことが重要です。特に名前解決と証明書検証の噛み合わせでつまずきやすいので、事前に確認しておきましょう。
まず、リソース側の VPC では enableDnsHostnames と enableDnsSupport を有効化しておきます。リソース設定で指定する DNS 名はパブリックに解決可能である必要があり、インターフェース VPC エンドポイントのプライベート DNS 名はそのままでは意図どおりに機能しない点に注意してください。TLS 検証を通すためには、プライベートホストゾーンのレコードを <prefix>.<region>.vpce.amazonaws.com 形式にし、証明書の CN 検証が通るように整えます。クロスアカウントで利用する場合は AWS RAM でリソースを共有し、コンシューマー側での承認を経てから接続します。
料金については、リソースあたりの時間課金とデータ処理料金という体系になっており、Transit Gateway 経由と比べてデータ処理コストを抑えやすい場合があります。ただし単価は変動しうるため、最新の正確な料金は必ず AWS 公式の料金ページで確認してください。
導入前のチェックリストとして、以下の観点を押さえておくと設計の抜け漏れを減らせます。
- DNS 設定 … リソース VPC で enableDnsHostnames / enableDnsSupport を有効化し、必要に応じてゲートウェイの DNS 解決を IN_VPC にしているか
- TLS とホストゾーン … プライベートホストゾーンのレコードを vpce.amazonaws.com 形式にし、証明書の CN 検証が通る構成になっているか
- RAM 共有と承認 … クロスアカウントでは AWS RAM で共有し、コンシューマー側で承認済みか
- セキュリティグループ … ゲートウェイからリソースへの通信を最小権限で制御しているか
- 料金確認 … 時間課金とデータ処理料金の体系を理解し、公式料金ページで最新値を確認したか
VPC Resource Gateways は、NLB を必須としない ENI ベースの単方向接続によって、CIDR 重複やマネージドリソースの公開といった従来の悩みどころに現実的な解を与えてくれます。まずはリソースエンドポイントで小さく始め、規模の拡大に応じて VPC Lattice のサービスネットワークへ広げていく進め方が、無理のない導入につながります。
