Amazon Web Services ブログ
Route 53 Resolverでマルチアカウント環境の DNS 管理を簡素化する
訳者注記：原文記事は 2019 年の記事となりますが、定期的にメンテナンスされており、且つ DNS 管理において有用であるため翻訳対象として選定しています。
前回の投稿では、マルチアカウント環境にCentral DNS を実装するソリューションを紹介しました。これにより、クロスアカウントや AWS からオンプレミスへのドメイン解決を実装するときに必要なサーバーとフォワーダーの数が減り、DNS 管理が簡素化されます。Amazon Route 53 Resolver サービスのリリースにより、ハイブリッド DNS 解決をさらに簡素化するネイティブの条件付きフォワーダーにアクセスできるようになりました。
この記事では、Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を一元化する最新のソリューションを紹介します。このソリューションにより、AWS でドメインコントローラーを実行しなくても、複数のアカウントにわたって、また AWS とオンプレミスで実行されているワークロード間でドメインを解決できます。
ソリューションの概要
このソリューションでは、ドメイン解決の 3 つの主要なユースケースを解決する方法を示します。
- VPC で実行されているワークロードからオンプレミスドメインの名前解決
- オンプレミスで実行されているワークロードから AWS 環境内のプライベートドメインの名前解決
- 異なる AWS アカウントで実行されているワークロード間のプライベートドメインの名前解決
次の図は、大まかなアーキテクチャを示しています。
図 1: アーキテクチャ図
アーキテクチャ図中の 1 ~ 6 について説明します。
- Central DNS VPC 用のAmazon が提供するデフォルト DNS サーバーです。ここでは、これを DNS-VPC と呼びます。これは VPC CIDR 範囲内の 2 番目の IP アドレスです (図に示されているように、 172.27.0.2 を持ちます)。このデフォルトの DNS サーバーは、参加している AWS アカウントで実行されるすべてのワークロードのプライマリドメインリゾルバーになります。
- Route 53 Resolver Endpoint を示しています。インバウンドエンドポイントは、オンプレミスの DNS サーバーと、参加している AWS アカウントで実行されているワークロードから転送されたクエリを受信します。アウトバウンドエンドポイントは、ドメインクエリを AWS からオンプレミス DNS に転送するために使用されます。
- 条件付き転送ルールを示しています。このアーキテクチャでは、2 つのルールが必要です。1 つは onprem.private ゾーンのドメインクエリをアウトバウンドエンドポイント経由でオンプレミス DNS サーバーに転送するルール、もう 1 つは awscloud.private のドメインクエリを DNS-VPC のリゾルバーインバウンドエンドポイントに転送するルールです。
- これら 2 つの転送ルールが AWS Resource Access Manager を介して他のすべての AWS アカウントと共有され、これらのアカウントのすべての VPC に関連付けられていることを示しています。
- awscloud.private という固有のサブドメインを使用して各アカウントに作成されたプライベートホストゾーンを示しています。
- awscloud.private ゾーンへのクエリを Resolver インバウンドエンドポイントの IP アドレスに転送するように設定された条件付きフォワーダーを備えたオンプレミスの DNS サーバーを示しています。
注:このソリューションでは、送信元/宛先の VPC と DNS-VPC 間の VPC ピアリングや接続は必要ありません。
仕組み
次に、このアーキテクチャのドメイン解決フローが、3 つのユースケースに従ってどのように機能するかを示します。
ユースケース ①
図 2: AWS で実行されているワークロードからオンプレミスドメインを解決するユースケース
最初に、AWS で実行されているワークロードからオンプレミスドメインを解決する方法を見ていきます。プライベートドメイン host1.acc1.awscloud.private のサーバーが host1.onprem.private というアドレスを解決しようとすると、次のようになります。
- DNS クエリは、host1.acc1.awscloud.private をホストしている VPC のデフォルト DNS サーバーにルーティングされます。
- VPC は Central DNS アカウントから共有される転送ルールに関連付けられているため、これらのルールは VPC 内の Amazon が提供するデフォルトの DNS によって評価されます。
- この例では、ルールの 1 つが onprem.private のクエリをオンプレミス DNS サーバーに転送するように指示しています。このルールに従って、クエリはオンプレミスの DNS サーバーに転送されます。
- 転送ルールは Resolver アウトバウンドエンドポイントに関連付けられているため、クエリはこのエンドポイントを介してオンプレミスの DNS サーバーに転送されます。
このフローでは、参加しているアカウントの1つで開始されたDNSクエリが Central DNS サーバーに転送され、次にオンプレミス DNS に転送されます。
ユースケース ②
次に、オンプレミスのワークロードで AWS 環境のプライベートドメインを解決する方法は次のとおりです。
図 3: オンプレミスのワークロードで AWS 環境のプライベートドメインを解決する方法のユースケース
この場合、host1.acc1.awscloud.private のクエリはオンプレミスホストから開始されます。次に何が起こるかは次のとおりです。
- ドメインクエリはオンプレミスの DNS サーバーに転送されます。
- その後、クエリはオンプレミスDNSサーバー上の条件付き転送ルールを介して Resolver インバウンドエンドポイントに転送されます。
- クエリは、DNS-VPC のデフォルト DNS サーバーに到達します。
- DNS-VPC はプライベートホストゾーン acc1.awscloud.private に関連付けられているため、デフォルトの DNS サーバーがこのドメインを解決できます。
この場合、DNS クエリはオンプレミスで開始され、インバウンドエンドポイントを通じて AWS 側の Central DNS に転送されています。
ユースケース③
最後に、複数の AWS アカウントにまたがるドメインの解決が必要になる場合があります。これを実現する方法は次のとおりです。
図 4: 複数の AWS アカウントにまたがるドメインを解決する方法のユースケース
host1.acc1.awscloud.private のホスト 1 が host2.acc2.awscloud.private というドメインを解決しようとしたとすると、次のことが起こります。
- ドメインクエリは、VPC ホスティングソースマシン (host1) のデフォルト DNS サーバーに送信されます。
- VPC は共有転送ルールに関連付けられているため、これらのルールは評価されます。
- awscloud.private ゾーンのクエリは、DNS-VPC のインバウンドエンドポイントに (アウトバウンドエンドポイント経由で) 転送する必要があるというルールがあります。
- 次に、アウトバウンドエンドポイントは DNS クエリをターゲット IP に転送します。この例では、ターゲット IP は受信エンドポイントの IP アドレスです。
- DNS-VPC は acc2.awscloud.private ホストゾーンに関連付けられているため、デフォルトの DNS は自動定義ルールを使用してこのドメインを解決します。
このユースケースでは、DNS クエリが 1 つの参加アカウントで開始され、別の AWS アカウントのドメイン解決のために Central DNS に転送される、AWS 間ケースについて説明します。次に、このソリューションをお客様の環境で構築するために何が必要かを見ていきます。
ソリューションの導入方法
このソリューションを 4 つのステップで構成する方法を説明します。
- 一元化された DNS アカウントを設定します。
- 各参加アカウントを設定します。
- プライベートホストゾーンと Route 53 の関連付けを作成します。
- オンプレミスの DNS フォワーダーを設定します。
ステップ 1: Central DNS アカウントを設定する
このステップでは、一元管理された DNS アカウントにリソースを設定します。主に、DNS-VPC、リゾルバーエンドポイント、転送ルールが含まれます。
- ウェブコンソールまたはAWS クイックスタートを使用して、ビジネスシナリオに応じて DNS-VPC として動作する VPC を作成します。Amazon VPC ユーザーガイドで一般的なシナリオを確認できます。非常に一般的なシナリオの 1 つは、パブリックサブネットとプライベートサブネットを持つ VPC です。
- リゾルバーエンドポイントを作成します。DNS クエリをオンプレミス DNS に転送するアウトバウンドエンドポイントと、オンプレミスのワークロードや他の AWS アカウントから転送された DNS クエリを受信するインバウンドエンドポイントを作成する必要があります。
- 2 つの転送ルールを作成します。最初のルールは、ゾーン onprem.private の DNS クエリをオンプレミスの DNS サーバーの IP アドレスに転送することです。2 番目のルールは、ゾーン awscloud.private の DNS クエリをリゾルバーのインバウンドエンドポイントの IP アドレスに転送することです。
- ルールを作成したら、ゾーン onprem.private のルールをステップ #1 で作成した DNS-VPC に関連付けます(他の転送ルールを DNS-VPC に関連付ける必要はありません)。これにより、Route 53 リゾルバーはドメインクエリの転送をそれに応じて開始できます。
- 最後に、2 つの転送ルールをすべての参加アカウントと共有する必要があります。そのためには、AWS Resource Access Manager を使用し、ルールを AWS 組織全体または特定のアカウントと共有できます。
注:ドメインクエリをオンプレミスの DNS サーバーに転送するには、データセンターと DNS-VPC 間の接続が必要です。接続は、Site-to-Site VPN または AWS Direct Connect を使用して確立できます。
ステップ 2: 参加アカウントを設定する
参加しているアカウントごとに、共有転送ルールを使用するように VPC を設定し、アカウントごとにプライベートホストゾーンを作成する必要があります。
- AWS Resource Access Manager からの共有ルールに同意します。ルールが AWS 組織と共有されている場合、このステップは不要です。次に、転送ルールを各アカウントのワークロードをホストするVPC に関連付けます。関連付けが完了すると、リゾルバーはルールに従ってDNSクエリの転送を開始します。
この時点で、共有転送ルールに関連付けられている任意の VPC で実行されているワークロードからオンプレミスドメインを解決できるはずです。AWS でプライベートドメインを作成するには、プライベートホストゾーンを作成する必要があります。
ステップ 3: プライベートホストゾーンを作成する
このステップでは、awscloud.private のサブドメインを使用して各アカウントにプライベートホストゾーンを作成する必要があります。環境内でのドメインの競合を避けるため、プライベートホストゾーンごとに一意の名前を使用してください (たとえば、acc1.awscloud.private または dev.awscloud.privateなどです)。
- awscloud.private のサブドメインを持つ各参加アカウントにプライベートホストゾーンを作成し、そのアカウントで実行されている VPC に関連付けます。
- プライベートホストゾーンを DNS-VPC に関連付けます。これにより、集中管理された DNS-VPC はプライベートホストゾーンのドメインを解決し、AWS アカウント間の DNS リゾルバーとして機能できます。
プライベートホストゾーンと DNS-VPC は異なるアカウントにあるため、プライベートホストゾーンを DNS-VPC に関連付ける必要があります。そのためには、プライベートホストゾーンを所有するアカウントから認証を作成し、DNS-VPC を所有するアカウントからこの承認を受け入れる必要があります。これは AWS CLI を使用して行うことができます。
- 参加している各アカウントで、プライベートホストゾーン ID、リージョン、関連付ける VPC ID (DNS-VPC) を使用して認証を作成します。
- Central DNS アカウントで、参加している各アカウントのホストゾーンに DNS-VPC を関連付けます。
ステップ 4: オンプレミス DNS フォワーダーを設定する
オンプレミスで実行されているワークロードから awscloud.private ドメイン内のサブドメインを解決できるようにするには、Central DNS アカウントに作成されたリゾルバーインバウンドエンドポイントの 2 つの IP アドレスにドメインクエリを転送する条件付き転送ルールを設定する必要があります。これには、データセンターと DNS-VPC 間の接続が必要であることに注意してください。接続には、Site-to-Site VPN または AWS Direct Connect を使うことができます。
その他の考慮事項と制限事項
Route 53 Resolverの柔軟性と条件付き転送ルールにより、どのクエリを Central DNSに送信し、どのクエリを同じアカウントでローカルに解決するかを制御できます。これは、AWS PrivateLink や Amazon Elastic File System (EFS) など一部の AWS サービスを使用する予定がある場合に特に重要です。これらのサービスに関連するドメイン名は、それらを所有するアカウントのローカルで解決する必要があるためです。
可能であれば、アカウントのローカルドメインを解決することをお勧めします。たとえば、同じアカウントのプライベートホストゾーンにあるプライベートドメインの場合です。そのためには、アカウントのローカルに条件付き転送ルールを作成し、ルールタイプに「system」を使用して、これらのルールを VPC に関連付けることができます。
※訳者注記：ルールタイプについてのドキュメントはこちらを参照ください。
Route 53 リゾルバーの制限に関する注意：Route 53 リゾルバーには、エンドポイントの IP アドレスあたり 1 秒あたり 10,000 クエリという制限があります。より高い制限を必要とするワークロードがある場合は、EC2 インスタンス上で実行されている適切に設定されたローカル DNS サーバーにこれらのクエリを転送することを検討してください。サービスの制限について詳しくは、こちらをご覧ください。
このセクションでは、追加の考慮事項が必要な 2 つのユースケースを挙げます。
-
インターフェイス VPC エンドポイント (AWS PrivateLink)
AWS PrivateLink インターフェイスエンドポイントを作成すると、AWS はサービスとの通信に使用できるエンドポイント固有の DNS ホスト名を生成します。AWS サービスと AWS Marketplace パートナーサービスでは、オプションでエンドポイントのプライベート DNS を有効にできます。このオプションは、プライベートホストゾーンを VPC に関連付けます。ホストゾーンには、サービスのデフォルト DNS 名のレコードセット (たとえば、ec2.us-east-1.amazonaws.com) が含まれています。このレコードセットは、VPC 内のエンドポイントネットワークインターフェイスのプライベート IP アドレスになります。これにより、エンドポイント固有の DNS ホスト名ではなく、デフォルトの DNS ホスト名を使用してサービスにリクエストを行うことができます。エンドポイントにプライベート DNS を使用する場合は、アカウントのローカルエンドポイントへの DNS クエリを解決し、AWS が提供するデフォルトの DNS を使用する必要があります。そのため、この場合は、amazonaws.comのドメインクエリをローカルで解決し、これらのクエリを Central DNS に転送しないことをお勧めします。
-
DNS 名を使用して EFS をマウントする
DNS 名を使用して Amazon EFS ファイルシステム Amazon EC2 インスタンスにマウントできます。ファイルシステム DNS 名は、接続している Amazon EC2 インスタンスのアベイラビリティーゾーンにあるマウントターゲットの IP アドレスに自動的に解決されます。そのためには、VPC は Amazon が提供するデフォルト DNS を使用して EFS DNS 名を解決する必要があります。ご使用の環境で EFS を使用する予定がある場合は、EFS DNS 名をローカルで解決し、これらのクエリを Central DNS に送信しないことをお勧めします。その場合、クライアントはアベイラビリティーゾーンに最適化された回答を受け取ることができず、オペレーションのレイテンシーが高くなり、耐久性が低下する可能性があります。
まとめ
この記事では、マルチアカウントおよびハイブリッド環境で Central DNS 解決を実装するための簡単なソリューションを紹介しました。このソリューションでは、AWS Route 53 Resolver、AWS Resource Access Manager、および Route 53 のネイティブ機能が使用され、AWS 環境でカスタム DNS サーバーやフォワーダーが不要になるため、複雑さと運用の労力が軽減されます。
著者について
この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文はこちらです。