HAQM Route 53 プロファイルで AWS PrivateLink の DNS 管理を効率化

本記事は 2025 年 2 月 18 日に公開された ”Streamline DNS management for AWS PrivateLink deployment with HAQM Route 53 Profiles” を翻訳したものです。

はじめに

AWS PrivateLink インターフェイスエンドポイントを採用するエンタープライズ企業における主な課題は、導入プロセスの効率化、エンドポイント数の最小化、コストの最適化です。これらの課題に対処するための実績あるアプローチは、AWS Transit Gateway と HAQM Route 53 Resolver を組み合わせて使用し、複数の HAQM Virtual Private Cloud(VPC) およびオンプレミス環境で AWS PrivateLink インターフェイスエンドポイントを効率的に共有することです。これにより、必要なインターフェイスエンドポイントの数を最小限に抑えることができ、コストと運用オーバーヘッドの削減を実現できます。

PrivateLink は、VPC とサポートされている AWS サービス、Software as a Service (SaaS) アプリケーション、AWS またはオンプレミスでホストされているサードパーティサービス間のプライベート接続を実現します。PrivateLink は VPC インターフェイスエンドポイントを使用して、VPC とターゲットサービス間の安全な接続を確立します。しかしながら、組織が VPC とアカウントを大規模に拡張していった場合、マルチアカウント環境で、数千規模の VPC に横断してインターフェイスエンドポイントをデプロイすることになり、複雑性とコストが増加しかねません。

HAQM Route 53 プロファイルは、このアーキテクチャを再検討し、改善することができます。Route 53 プロファイルを統合することで、複数の AWS アカウントを横断する膨大な数の VPC で DNS 管理を簡素化、および一元化できるため、PrivateLink の展開はスケーラブルになります。

本稿では、PrivateLink が、同じアカウント内、複数のアカウント間、オンプレミス環境と統合された VPC や AWS サービス間で、どのように安全なプライベート接続を実現するかを説明します。また、インフラストラクチャを拡張する場合でも、アーキテクチャを最適化する場合でも、 PrivateLink のデプロイを習得するための実用的なステップバイステップのガイドとなります。

ソリューション概要

ハブアンドスポークモデルで PrivateLink を一元的に展開すると、多数の VPC とアカウントに PrivateLink を展開する際の課題に対応できます。図 1 では、PrivateLink VPC エンドポイントが一元化され、Shared Services VPC 内に展開されています。Dev アカウントと Prod アカウントのスポーク VPC は、Transit Gateway または AWS Cloud WAN を介して Shared Services VPC に接続することで、エンドポイントにアクセスできます。オンプレミスのデータセンターは、AWS Direct Connect または AWS Site-to-Site VPN を介して AWS 環境とのハイブリッド接続を確立することで、これらの一元化された PrivateLink VPC エンドポイントにアクセスできます。

図 1 : Shared Services VPC の集中型 VPC エンドポイント

DNS 管理は、集中型デプロイメントモデルを実装する際に重要な要素です。PrivateLink 対応サービスの VPC インターフェイスエンドポイントを作成する際のセットアッププロセス内で [DNS 名を有効にする] オプションを選択してプライベート DNS を有効にすることができます。この機能を有効にすると、AWS サービスのパブリック DNS 名は VPC エンドポイントのプライベート IP アドレスに解決する AWS マネージドの Private Hosted Zone(PHZ) が作成されます。ただし、このマネージド PHZ は、VPC エンドポイントをホストするハブ VPC 内でのみアクセス可能であり、他のスポーク VPC と共有することはできません。これを克服するために、次のセクションで説明するカスタム PHZ を使用します。

PrivateLink の DNS 解決のためのカスタム PHZ

VPC-to-VPC およびオンプレミス接続の場合、VPC エンドポイントのプライベート DNS を無効にすることから始めます。

1. VPC コンソールで、 [エンドポイント] を選択して対象のエンドポイントを選択します。
2. [アクション] を選択し、 [プライベートDNS名を変更] を選択します。
3. [プライベート DNS 名の設定を変更] で、[このエンドポイントで有効にする] のチェックを外します。
4. [変更を保存] を選択します。

図 2 :プライベートDNS名を変更する

プライベート DNS 名を無効にすると、Route 53 PHZ を作成できます。サービスエンドポイント名を使用し、AWS サービスの VPC エンドポイント名をポイントするエイリアスレコードを設定します。図 3 : Route 53 エイリアスレコードの作成

この例では、us-east-1 AWS リージョンに AWS Lambda のエンドポイントを作成しているため、エンドポイントの末尾は lambda.us-east-1.vpce.amazonaws.com となります。

このカスタム PHZ をハブ VPC に作成し、それを他のスポーク VPC に関連付けしていきます。これにより、すべてのスポーク VPC で AWS サービスのパブリック DNS 名をエンドポイントのプライベート IP アドレスに解決できるようになり、複数の VPC 間でシームレスな接続が可能になります。

通常、複数の VPC 間で VPC エンドポイントの DNS 解決を有効にするには、各 VPC エンドポイントの PHZ を全てのスポーク VPC に手動で関連付ける必要があります。ハブ VPC とスポーク VPC の両方が同じ AWS アカウント内にある場合、この関連付けは AWS マネジメントコンソールで設定できます。異なるアカウントにある場合は、AWS コマンドラインインターフェイス (AWS CLI) または SDK を使用して関連付けをする必要があります。このプロセスについては、Route 53 デベロッパーガイドをご参照ください。

図 4 :クロスアカウント PHZ 関連付けを使用した Shared Services VPC 内の集中型 VPC エンドポイント

次のセクションでは、Route 53 Resolver プロファイル を使用して、このプロセスを効率化し、よりスケーラブルにする方法を紹介します。

Route 53 プロファイルを使用した VPC to VPC PrivateLink の DNS 解決

図 5 のアーキテクチャ図は、単一リージョンのワークロードを示しています。Dev アカウントには Dev VPC 、Prod アカウントには Prod VPC という VPC がデプロイされています。前述のように、これらの VPC は Transit Gateway または AWS Cloud WAN で接続されています。このアーキテクチャにより、HAQM Elastic Compute Cloud (HAQM EC2) インスタンスから Shared Services VPC の VPC エンドポイントが使用できるようになっています。Dev VPC または Prod VPC のいずれかに存在するインスタンスは、HAQM Kinesis および Lambda にプライベートにアクセスできます。

図 5 : DNS 解決に Route 53 プロファイル を使用する Shared Services VPC 内の集中型 VPC エンドポイント

次の手順では、どのように Route 53 プロファイルがこのプロセスを効率化するかを示します。

1. Shared Services VPC で、PrivateLink を使用して Kinesis と Lambda に安全にアクセスする VPC Interface エンドポイントを作成します。
2. これらのエンドポイントごとに PHZ を設定します。
3. Shared Services アカウントに Route 53 プロファイルを作成し、Shared Services VPC に関連付けます。
4. この Route 53 プロファイルに Kinesis と Lambda の両方の PHZ を関連付けます。
5. この新しく作成された Route 53 プロファイル を Dev アカウントと Prod アカウントを拡張するために、AWS Resource Access Manager (AWS RAM) を使用して両方のアカウントとプロファイルを共有します。
6. 共有後、Dev アカウントと Prod アカウントから、Route 53 プロファイルを各々の VPC に関連付けをします。

この VPC エンドポイントの実装は、すべての VPC において、Kinesis および Lambda のパブリック DNS 名をプライベート IP アドレスに解決できることを意味します。スポーク VPC 内のすべてのリソースは、Transit Gateway または AWS Cloud WAN を介して Kinesis, Lambda サービスにパブリックインターネットを経由せずに、Shared Services VPC の VPC エンドポイント経由で安全にアクセスできるということです。

今後、サポートされている他の A​​WS サービスの新しい VPC エンドポイントを作成する場合、必要な手順は、各 VPC エンドポイントの PHZ を一元化された Route 53 プロファイルに関連付けるだけです。関連付けが確立されると、この Route 53 プロファイルにリンクされている VPC は、新しく作成された VPC エンドポイントへの DNS 名の解決ができるようになります。

既存または新規のアカウントで新しい VPC をプロビジョニングする場合でも同様に、その VPC を共有している Route 53 プロファイルに関連付けます。また、Transit Gateway または AWS Cloud WAN を使用して、Shared Services VPC とのレイヤー 3 接続も提供します。その結果、新しい VPC は、Shared Services アカウント内のすべての PHZ に自動的に関連付けられるようになり、それぞれの VPC エンドポイントへのシームレスな DNS 解決が提供されます。

オンプレミスネットワークにおける PrivateLink の DNS 解決

図 6 に示すこのシナリオでは、AWS 環境と外部ネットワークの間にレイヤー 3 接続を確立します。オンプレミスのリソースは Kinesis や Lambda などの AWS サービスに到達する必要があるため、オンプレミスの DNS 解決のためのソリューションを実装しなければなりません。

図 6 :オンプレミスでの DNS 解決に Route 53プロファイルを使用する Shared Services VPC 内の集中型 VPC エンドポイント

1. Direct Connect または Site-to-Site VPN を使用して、既存の Transit Gateway または AWS Cloud WAN にレイヤー 3 の接続を確立します。(2025/3 時点で AWS Cloud WAN の Direct connect gateway 接続は東京リージョン未対応：参考)
2. Route 53 Resolver のインバウンドエンドポイントを、Shared Services VPC にデプロイします
3. オンプレミスの DNS Resolver では、Kinesis と Lambda の DNS クエリを Route 53 Resolver のインバウンドエンドポイントの IP アドレスに送信する転送ルールを設定します。
4. Route 53 Resolver のインバウンドエンドポイントが作成されている Shared Services VPC に関連づけられている PHZ は、クエリを解決するときに VPC に関連付けられた Route 53 プロファイルよりも優先されます。

考慮点とベストプラクティス

• VPC エンドポイントは、高可用性を実現するために、複数のアベイラビリティゾーン (AZ) (理想的には 2 つ以上) に配置すべきです。Route 53 Resolver インバウンドエンドポイントも、同様に複数のAZで構成し、AZレベルの障害の影響を軽減しましょう。
• PHZ が Route 53 プロファイル に関連付けされ、そのプロファイルが VPC に関連付けられている場合、PHZ を VPC に明示的に関連付ける必要はありません。
• Route 53 プロファイルを個々のアカウントと共有するのではなく、特定の組織単位 (OU) または組織全体と共有できます。Route 53 プロファイルが OU または組織全体と共有されている場合、その範囲内の既存と新しく作成されたアカウントは自動的にこの Route 53 プロファイルにアクセスできます。これにより、Route 53 プロファイルを個々の AWS アカウントと手動で共有する必要はありません。
• Route 53 の料金ページで説明されているように、Route 53 プロファイルは、プロファイルと VPC の アソシエーション 1 時間あたりの料金で請求されます。多数のプロファイルを作成すると、コストが高くなる可能性があります。
• VPC が PHZ と Route 53 プロファイルの両方に関連付けられている場合、Route 53 Resolver は PHZ の直接の関連付けを優先します。「Route 53 プロファイル設定の優先順位付け方法」のドキュメントで説明されています。
• 各インターフェイスエンドポイントは、AWS PrivateLink クォータのドキュメントに記載があるように、AZ ごとの持続トラフィックとバーストトラフィックの特定の帯域幅をサポートしています。より高い帯域幅要件をサポートするには、このソリューションを検討してください。

まとめ

本稿では、AWS PrivateLink の展開に AWS Transit Gateway または AWS Cloud WAN を使用した集中型モデルを使用する際に、HAQM Route 53 プロファイルを簡単に統合して DNS 管理を支援する方法について紹介しました。開始するには、AWS PrivateLink と HAQM Route 53 プロファイルのページにアクセスしてください。

翻訳は Solutions Architect の齋藤が担当しました。原文はこちらです。

著者について