Amazon Web Services ブログ

VPC Resource Gateways の実装パターンとユースケース

本記事は、2025 年 6 月 11 日に Networking & Content Delivery で公開された VPC resource gateways: Implementation patterns and use cases を翻訳したものです。

Amazon Virtual Private Cloud (Amazon VPC) 間でアプリケーションを接続する際、従来の AWS PrivateLink のプロバイダー・コンシューマーモデルに適合しないサービスへの接続が必要になると、VPC ピアリングや AWS Transit Gateway だけでは簡単に解決できない複雑なネットワーク課題に直面します。これは特に、IP アドレス空間が重複している場合に顕著です。

従来の PrivateLink の Provider-Consumer Model に適合しないサービスへの接続を、VPC リソースゲートウェイを使用することで実現でき、ネットワークアーキテクチャを簡素化できます。プロバイダーがサービスの前段に Network Load Balancer を配置することを求める VPC エンドポイントサービスとは異なり、リソースゲートウェイはロードバランサーインフラストラクチャの追加オーバーヘッドなしに、より幅広いターゲットを公開できます。

これまで複雑な追加設定が必要だったシナリオでも、追加インフラストラクチャの管理オーバーヘッドなしにサービスにアクセスできるようになりました。リソースゲートウェイは、ARN、DNS、または IP ベースのサービスへの接続を可能にしながら、セキュリティの維持、複雑さの軽減、コストの最適化を実現します。

リソースゲートウェイには複数のアクセス方法があります。リソースエンドポイント、Amazon VPC Lattice サービスネットワークアソシエーション、および VPC Lattice サービスネットワークに接続されたサービスネットワークエンドポイントです。本記事では、リソースへのアクセスを提供するために、リソースゲートウェイとリソースエンドポイントを使用したアーキテクチャパターンに焦点を当てます。Amazon VPC Lattice のサービスネットワークエンドポイントのユースケースと使用方法の詳細については、こちらのブログを参照してください。

以下のユースケースとトラフィックフローパターンを通じて、リソースゲートウェイの機能を理解していきましょう。

ユースケース 1：RDS リソースへのプライベートかつセキュアなアクセス

異なるビジネスユニットやアプリケーションコンポーネント間で厳密な分離を維持するために、マルチ VPC またはマルチアカウント戦略を採用している場合、アプリケーションサーバーとデータベースが異なる VPC や AWS アカウントに配置されます。また、このアーキテクチャパターンの要件は、合併・買収（M&A）の際にも発生します。

Amazon Relational Database Service (Amazon RDS) は、管理タスクを自動化することで従来型データベースの管理を簡素化します。Amazon Aurora は、MySQL および PostgreSQL との完全な互換性を持つグローバルスケールのリレーショナルデータベースです。

Web/アプリケーションサーバーと RDS/Aurora データベースが異なる VPC に存在する場合、VPC ピアリングによる直接的な VPC 間通信や、AWS Transit Gateway / AWS Cloud WAN を使用したネットワーク接続のセットアップにより接続を確立できます。しかし、コンシューマーの数が急速に増加すると、これらの VPC ピアリング接続や AWS Transit Gateway / AWS Cloud WAN を経由するネットワークフローの管理オーバーヘッドが増大します。

リソースゲートウェイとリソース VPC エンドポイントを使用して、アプリケーションから Amazon RDS リソースへの接続を可能にできます。図1は、このユースケースのハイレベルアーキテクチャ図を示しています：

図1：RDS リソースへのプライベートかつセキュアなアクセス

RDS リソースへのプライベートかつセキュアなアクセスを実現するために、以下の手順でリソースエンドポイントとリソースゲートウェイを構成できます：

  • RDS リソースが存在する VPC にリソースゲートウェイを作成する。

  • アクセスしたい各 RDS クラスターまたはインスタンスに対して「ARN」タイプのリソース設定を作成し、リソースゲートウェイに関連付ける。

  •  注意：ARN ベースのリソースは現在、パブリックでない Amazon RDS リソースでサポートされています。ARN ベースのリソース設定の子リソース設定は、AWS によって自動的に管理されます。

  • （オプション） コンシューマー VPC と RDS VPC が異なる AWS アカウントにある場合、RDS VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。

  • コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、ARN タイプのリソース設定に関連付ける。VPC エンドポイントの作成時に、オプションで「Private DNS」を有効化する。Private DNS を有効にすると、リソース VPC エンドポイントを通じたプライベート接続を活用しながら、AWS サービスがリソースに対してプロビジョニングした DNS 名を使用してリクエストを続けることができます。

  •   注意：Private DNS を使用するには、コンシューマー VPC の DNS ホスト名および DNS 解決が「有効」（enableDnsHostnames, enableDnsSupport）に設定されていることを確認してください。

  • リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。

  • VPC エンドポイントの Private DNS が有効時と無効時での動作を示す：

    •  有効（推奨）：RDS リソースの DNS 名（ライターエンドポイント、リーダーエンドポイント、またはインスタンスエンドポイント）を使用してリソースにアクセスできます。

    •  無効：リソース VPC エンドポイントの DNS 名を使用して RDS リソースにアクセスします。ただし、これはデータベース証明書のコモンネーム（CN）を検証していない場合にのみ機能します。これは、リソース VPC エンドポイントの DNS 名が RDS/Aurora DB インスタンスの証明書のサブジェクト代替名（SAN）に含まれていないためです。

ユースケース 2：VPC IP CIDR が重複する環境での接続

CIDR が重複する VPC にコンシューマーとリソースが 存在する場合、それら間の直接通信が困難になります。このシナリオは、合併・買収時、パートナーネットワークへの接続時、または CIDR の計画が調整されていないマルチアカウント環境で一般的に発生します。この問題に対処する従来のソリューションには、NAT（ネットワークアドレス変換）を実行するアプライアンスの設定、NAT ゲートウェイの使用、または Network Load Balancer の作成と VPC エンドポイントサービスを使用したサービスの公開が含まれます。これらの解決策は有効ですが、追加リソースの作成が必要なため、複雑さとコストが増加します。

VPC リソースエンドポイントとリソースゲートウェイは、このような状況でコンシューマーがリソースにアクセスできるようにする、よりシンプルな代替手段を提供します。図2は、このユースケースのハイレベルアーキテクチャ図を示しています。

図2：重複 CIDR ユースケースにおけるリソースエンドポイントとリソースゲートウェイの使用

このケースでコンシューマーがリソースにアクセスできるようにするには、以下を実行します。

  • アクセス対象のリソースが存在する VPC にリソースゲートウェイを作成する。

  • リソースまたはリソースグループを表すリソース設定を作成し、リソースゲートウェイに関連付ける。

  • （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。

  • コンシューマー VPC に、各リソース設定に対応する「Resource」タイプの VPC エンドポイントを作成する。

  • リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。

  • リソース VPC エンドポイントの DNS 名を使用して、リソース VPC 内のリソースにアクセスする。フレンドリーな名前を使用してリソースにアクセスしたい場合は、「コンシューマー VPC」に関連付けられたプライベートホストゾーンを作成し、フレンドリー DNS 名をリソース VPC エンドポイントの DNS 名にポイントする CNAME レコードを追加できます。リソース VPC エンドポイントの DNS 名は、関連するリソース VPC エンドポイントを選択した際の「Associations」の下で確認できます。

図3：リソース VPC エンドポイントの DNS 名

ユースケース 3：パブリックドメインへの接続プロキシ

パブリックエンドポイント宛ての通信であっても、一元化されたVPCを経由させるか、あるいはプライベートかつ制御されたネットワーク経路を使用することを義務付けるような厳格なポリシーを採用する場合を想定します。こうしたパブリックエンドポイントは、多くの場合 AWS 外の SaaS サービスか、AWS 上にありながら PrivateLink 経由ではプライベートに公開されていないサービスです。

リソースゲートウェイを使用して、集約 VPC 経由で、または AWS VPN、AWS Direct Connect、VPC ピアリングなどのプライベート接続オプションを介したインクラウド接続ユースケースとして、パブリックエンドポイント（AWS またはサードパーティ）にアクセスできます。図4は、VPC 内のクライアントが集約 VPC とリソースゲートウェイを通じてパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。

図4：集約 VPC とリソースゲートウェイによるパブリックエンドポイントへのアクセス

リソースゲートウェイを使用して集約 VPC 経由でパブリックエンドポイントへの接続を確立するには、以下のアプローチに従います：

  • パブリックサブネットとプライベートサブネットを持つ VPC（「リソース VPC」）を作成する。VPC ルーティングを設定し、プライベートサブネットからインターネットへのトラフィックがパブリックサブネット内の NAT ゲートウェイを経由してルーティングされることを確認する。

  • リソース VPC のプライベートサブネットにリソースゲートウェイを作成する。

  • コンシューマーにアクセスさせたい各ドメイン名に対して、「DNS」タイプのリソース設定を作成する。各 DNS リソース設定は、コンシューマーにアクセスさせたい単一のドメイン名にマッピングされます。複数のドメイン名にアクセスさせたい場合は、複数のリソース設定を単一の「リソースグループ」にグループ化し、単一のリソース VPC エンドポイントで複数ドメインにアクセスできるようにできます。

  • （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS Resource Access Manager(RAM) を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。

  • コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。

  • リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。

  • プライベートホストゾーン（コンシューマー VPC に関連付け）を作成し、アクセスするパブリック FQDN をリソースエンドポイントの対応する DNS 名にマッピングする CNAME タイプのレコードを追加する。リソースエンドポイントの DNS 名の確認方法については、図2を参照。

  • プライベートホストゾーンで作成したレコードを使用して、アプリケーションからパブリックエンドポイントにアクセスする。

同様に、オンプレミスと AWS 間の確立済みプライベート接続を通じて、パブリックエンドポイントへのトラフィックをルーティングすることもできます。これにより、アウトバウンドインターネット接続を信頼できるエンドポイントに制限し、オンプレミスのクライアントがネットワーク分離を維持しコンプライアンス要件を満たしながら、パブリック FQDN とセキュアに通信できるようになります。図5は、オンプレミスのクライアントが AWS Site-to-Site VPN / AWS Direct Connect を介してリソースゲートウェイ経由でパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。

※訳者注：集約 VPC の IGW からのアウトバウンド通信は TGW での接続が分かりやすく一般的ですが、TGW のデータ処理料金は $0.02/GB、リソースエンドポイントのデータ処理料金は $0.01/GB であり、本方式は特にデータ量が圧倒的である場合、コスト削減に大きく寄与します。

図5：集約 VPC とリソースゲートウェイによるオンプレミスからのパブリックエンドポイントへのアクセス

ユースケース 4：Transit Gateway や VPC ピアリングを経由せずに AWS サービスのインターフェースエンドポイントを集約する

インターネットを経由せずに AWS サービスへのプライベート接続を実現するには、インターフェース VPC エンドポイントを使用できます。しかし、各 VPC でサービスごとに個別のインターフェース VPC エンドポイントを作成すると、大きなコストと管理の複雑さにつながる可能性があります。そのため、より効率的なアプローチは、必要なすべてのインターフェースエンドポイントをホストする集約 VPC を用意し、AWS Transit Gateway または AWS VPC ピアリング接続を使用してコンシューマー VPC とリソース VPC 間の接続を確立し、集約 VPC エンドポイントへの接続を実現することです。

リソースゲートウェイとリソースエンドポイントは、このユースケース（特に大規模ネットワーク）に対処するための、よりシンプルでコスト効率の高いオプションを提供します。Transit Gateway アタッチメントよりも低い全体コスト（時間あたりおよびデータ処理）で、単一のリソースエンドポイントを作成して複数の AWS サービスエンドポイントにアクセスできます（集約 VPC エンドポイントが主なユースケースであることを前提）。図6は、このユースケースのハイレベルアーキテクチャ図を示しています。

図6：リソースゲートウェイを使用した集約 VPC エンドポイントへのアクセス

リソースゲートウェイを使用して集約 VPC エンドポイントへのプライベート接続を確立する方法は以下のとおりです。

  • リソース VPC に、要件に応じた AWS サービスの集約インターフェース VPC エンドポイントを作成する。

  • リソース VPC にリソースゲートウェイを作成する。

  • 各 AWS サービス VPC エンドポイントに対して、「DNS」のリソース定義を持つリソース設定を作成する。ドメイン名には、インターフェース VPC エンドポイントのリージョナル DNS 名を追加する（例：vpce-xxxx.ec2.<region>.vpce.amazonaws.com）。

  •   注意：リソースゲートウェイでは、リソース設定の DNS 名がパブリックに解決可能である必要があるため、インターフェース VPC エンドポイントのプライベート DNS 名は機能しません。

  • 子 DNS リソース設定を持つリソースグループを作成し、リソースグループをリソースゲートウェイに関連付ける。

  • （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。

  • コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。

  • リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。

  • （オプション）異なるドメイン名を使用してサービスエンドポイントにアクセスしたい場合は、ドメイン名 <region>.amazonaws.com のプライベートホストゾーンを作成し、コンシューマー VPC に関連付ける。アクセスする各サービスに対してプレフィックス付きの CNAME タイプのレコードを追加し（例：<prefix>.ec2.<region>.vpce.amazonaws.com）、リソースエンドポイントの対応する DNS 名にポイントする。TLS 検証が正常に行われるようにするため、プライベートホストゾーンとレコードは上記の形式である必要がある。

  • プライベートホストゾーンで作成したレコード（例：<prefix>.<region>.vpce.amazonaws.com）、またはリソースエンドポイントの DNS 名を使用して、アプリケーションからインターフェースエンドポイントにアクセスする。

まとめ

本記事では、VPC リソースゲートウェイを使用して AWS 環境における複雑なネットワーク課題を簡素化する方法を説明しました。プライベートなデータベース接続の確立、IP アドレスが競合するネットワーク間の通信の実現、セキュアなインターネットアクセスの作成、AWS サービスアクセスの合理化について解説しました。これらのソリューションは、VPC リソースゲートウェイが強固なセキュリティを維持しながら一般的なネットワーク課題に対処する方法を示しており、成長に合わせたクラウドアーキテクチャの構築に有用なツールとなります。

AWS ネットワーク構成を簡素化する準備はできましたか？VPC リソースゲートウェイのドキュメントを参照して、今すぐリソースゲートウェイの実装を開始し、ご自身の AWS 環境でこれらのパターンを試してみてください。

翻訳はソリューションアーキテクトの長屋が担当しました。