Route 53 Resolver - AWSマルチアカウント環境とオンプレミスで相互に名前解決（Advanced Networking - Specialty）

Route 53 Resolver AWS クラウド

今回のお話

AWS上のVPCとオンプレミス環境を DirectConnect / VPN で接続しているハイブリッドクラウド環境のお話です。

このようなハイブリッドクラウド環境では、

  • オンプレミスのサーバ／クライアントからELBといったVPC内リソースの名前解決
  • EC2といったVPC内リソースからオンプレミスのサーバの名前解決

といったように、オンプレミスとVPCで相互にシームレスに名前解決できる仕組み（以降、ハイブリッドDNS環境）が必要になります。 

f:id:imiky:20210320205310p:plain

AWS認定『高度なネットワーク – 専門知識』（AWS Certified Advanced Networking - Specialty）においても、この話が試験範囲であることが試験ガイドに明記されています（2021年3月時点）

分野 4: アプリケーションサービスとネットワークの連携を構成する

4.2 ハイブリッド IT アーキテクチャにおける DNS ソリューションを評価する

 

※試験ガイドは以下ページからダウンロードが可能です

aws.amazon.com

また、AWSにおいては、ワークロードごとにAWSアカウントを分離したマルチアカウント戦略を持つことがベストプラクティスとなっているため、通常、オンプレミス環境は複数のアカウントと接続されます。今回は、そのようなマルチアカウント環境とオンプレミス環境の名前解決についても検討します。

そもそもDNS

このページを開いた方にとっては釈迦に説法かと思いますが、DNSはFQDN（例：www.example.com.）からIPアドレス等の情報を取得する仕組みです。

ハイブリッドDNS環境の理解には、もう一歩踏み込んでDNSを理解する必要があります。一般的な企業におけるDNS構成例（下図）に沿って、DNSを構成する以下の4つの機能を説明します。いわゆる「DNSサーバ」は、これらの機能を内包しています。まだ、AWSに依存しない話です（ちょっと説明が長いので、そんなの知ってるよという方はこの章はとばしてください）

  1. Stub Resolver
  2. Name Server
  3. Forwarder
  4. Full-Service Resolver

f:id:imiky:20210320221151p:plain

  •  社内ネットワーク内でのみ名前解決可能な内部DNSゾーン example.local と、インターネット上で名前解決可能なDNSゾーン example.com の名前解決を考えます
  • 社内のユーザは、社内向けのポータルサイト www.example.local と、インターネット上の社外向けサイト www.example.com にアクセスします

まず、ユーザがPCから www.example.local にアクセスしようとすると、DNSサーバに www.example.local の名前解決を依頼します。この「このレコードを調べて」と依頼することを再帰的問い合わせと言い、再帰的問合せを投げられる機能が「1. Stub Resolver」です。みなさんのPCも Stub Resolver の機能を持っています。

www.example.local は、内部ゾーン example.local に含まれます。ゾーンのレコードとIPアドレス等の情報を管理し、自分が管理する情報を返答する機能を持つのが「2. Name Server」です。ここでのポイントは、Name Server はあくまで自分が管理・保持している情報のみしか答えません。また、Name Server は、ゾーンの一部を下位の Name Server に委譲し、階層的にゾーンを管理することができます（例：com の Name Server が example.com の管理を下位の Name Server に委譲）。ただし、この例においては、内部ゾーン example.local はゾーンの委譲はしていません。

www.example.local は内部DNSゾーンなので、問合せは内部の Name Server に誘導してあげる必要があります。この際、ルールに従って問合せを転送する機能「3. Forwarder」を利用します。Stub Resolver は、このような、ルールに従って複数の宛先に問合せを振り分ける機能は有していません。Stub Resolver からの www.example.local の問合せは、Forwarder に送信、Forwarder の転送ルールに従い、example.local の Name Server に転送されます。www.example.local は当該 Name Server が管理しているレコードなので、IPアドレス等の情報を返答し、名前解決に成功します。

一方、ユーザがPCから、インターネット上の社外向けサイト www.example.com にアクセスしようとすると、Stub Resolver が DNSサーバに www.example.com の名前解決を依頼します。www.example.com は外部のゾーンなので、内部の Name Server からは回答が得られません。そのため、問合せは Forwarder によって、内部ゾーンへの問合せとは別の宛先に転送されます。インターネット上のゾーンは、ルート（.）から階層的に管理を委譲されており、www.example.com を名前解決するためには、階層的に複数の Name Server をたどる（ルート(.)→com→example）必要があります。このような、Name Server をたどって名前解決をすることを反復問合せと言いますが、Stub Resolver は反復問合せの機能は持っていません。反復問合せをして結果を返す機能は「4. Full-Service Resolver」が有しています。そのため、www.example.com の問合せは Forwarder により、Full-Service Resolver に転送します。Full-Service Resolver が反復問合せを行うことで、www.example.com の名前解決に成功します。

ここまで、長々と説明しましたが、4つの機能について理解できましたでしょうか？以降はこの4つの機能を区別して説明していきます。

※さっぱりわからんという方は以下のBlackbeltセミナーがとても分かりやすいので、ぜひご視聴ください

【AWS Black Belt Online Seminar】Amazon Route 53 Resolver - YouTube

まずは単一VPC内の名前解決

ここまで読み進めた方には説明不要かと思いますが、VPC内ではVPCのネットワークアドレス+2のIPアドレスをエンドポイント（VPCが 10.0.0.0/24 の場合は 10.0.0.2）とする Provided DNS を参照することでVPC内の名前解決、および、インターネット上の名前解決が可能です。EC2やALBといったVPC内リソースには、デフォルトでVPC内で名前解決可能な内部DNS名が付与されますが、Provided DNS を利用することで、この内部DNS名が解決可能です。EC2であれば ip-x-x-x-x.ap-northeast-1.compute.internal 、ALBであれば internal-xxx.ap-northeast-1.elb.amazonaws.com といった内部DNS名が付けられます。

4つの機能で言うと、Provided DNS は Forwarder と Full-Service Resolver の機能を内包しています。Forwarder がVPC内ゾーンとインターネットゾーンの問合せを振り分け、Full-Service Resolver が反復問合せを行います。

※最近は Provided DNS を単に Route 53 Resolver と呼ぶみたいですね

次に単一VPCとオンプレミス環境での名前解決（オンプレミス→VPC）

まず、オンプレミスからVPC内リソースの名前解決を考えます。ぱっと思いつく案として「Provided DNSに問合せを転送すればええやん」と思いますが、Provided DNS はVPC専用なので、VPC以外からの問合せには応答しません。

f:id:imiky:20210320235306p:plain

また、オンプレミスのDNSサーバに転送ルール（ドメイン名に応じて転送）を設定しようにも、VPC内で既定で付与される内部DNS名はサービスごとにDNS名のパターンが多様なので、一貫した転送ルールを設定できません。

まずは、VPC内で一貫したドメインを利用できるようにします。Route 53 Private Hosted Zone を利用すると、マネージドに独自の内部DNSゾーンを構成できます。Route 53は複数の機能を持ちますが、そのうち Hosted Zone は Name Server のサービスです。また、Hosted Zone は インターネット上で名前解決可能なゾーンを管理する Public Hosted Zone と、VPC内でのみ名前解決可能なゾーンを管理する Private Hosted Zone を利用可能です。ここでは Private Hosted Zone を利用し、aws-example.local という独自のVPC内部ゾーンを構成することにします。aws-example.local でVPC内リソースのDNSレコードを一元管理することで、オンプレミスのDNSサーバが受信した aws-example.local の問合せは一貫してAWS側に転送すれば良い状況にします。これで、後は転送先さえ準備すればOKです。

Provided DNS がVPC外からの問合せに応答しないのであれば、この要件を満たすために必要なものは、VPC内でオンプレミスからの問合せをProvided DNSに仲介する機能です。やり方はいくつか考えられます。

  1. VPC内にEC2等で Forwarder の機能を持つDNSサーバを構築する
  2. Directory Service の Simple AD をVPC内に構築、Forwarder の機能を利用する
  3. Route 53 Resolver の Inbound Endpoint を利用する

現在は、3 の Inbound Endpoint を利用した構成が最も構築・運用の負荷が少なく実装できるため、3 を第一選択に考えます。本記事でも、3 の Inbound Endpoint を利用した構成を説明します。

Inbound Endpoint はVPC内に構築されるエンドポイント（実体はENI）で、VPC外からの問合せを Provided DNS に仲介します。これにより、オンプレミスのDNSサーバから aws-example.local の問合せを Inbound Endpoint に転送することで、問合せは Provided DNS に中継され、オンプレミスからVPC内リソースの名前解決が可能になります。いくつか設計・運用の注意点がありますが、注意点については後述します。

f:id:imiky:20210321101530p:plain

単一VPCとオンプレミス環境での名前解決（VPC→オンプレミス）

今度は、VPC内、例えばEC2からオンプレミスサーバの名前解決を考えます。こちらもぱっと思いつく案としては、EC2（Stub Resolver）のDNS参照先をオンプレミスのDNSサーバに変更するという方式が思いつきます。「VPC内のEC2からオンプレミスサーバの名前解決をしたい」という要件に対しては、たしかにこの方式でも充足しますが、通常、EC2のようなVPC内リソースは、オンプレミスだけでなくVPC内の名前解決やAWSサービスの名前解決も合わせて必要です。DNS参照先をオンプレミスのDNSサーバに変更してしまうと、Inbound Endpoint 等を利用してオンプレミスDNSサーバからVPCに問合せを転送する機能を構築していない場合、VPC内の名前解決ができなくなってしまいます。また、Inbound Endpoint 等でオンプレミスDNSサーバからVPCに問合せを転送する機能を構築していれば名前解決は可能ですが、VPC内に閉じた名前解決のためにも、VPC内の各リソース（Stub Resolver）→オンプレミスのDNSサーバ→VPCと問合せの通信が流れてしまい、パフォーマンス・コストの観点で非効率です。VPC内リソースがVPC内の名前解決をする場合は、問合せの通信はVPC内に留めるべきです。

f:id:imiky:20210321110219p:plain

Provided DNS は Forwarder と Full-Service Resolver の機能を内包すると前述しました。ここで思いつく案としては、Provided DNS が Forwarder の機能を持つのであれば、Provided DNS の Forwader にオンプレミスDNSサーバへの転送ルールを設定するという方式が思いつきます。これは、Provided DNS の転送ルールは利用者で変更できない（単体では）ため叶いません。

f:id:imiky:20210321120506p:plain

すなわち、効率よく要件を満たすために必要な機能は、VPC内でVPC内の名前解決とオンプレミスの名前解決を振り分けて転送するForwarderの機能です。こちらも、EC2で構築したDNSサーバや Simple AD の Forwarder を利用して実現することは可能ですが、マネージドな方法として、Route 53 Resolver の Outbound Endpoint ＋ 転送ルールを活用します。Outbound Endpoint はVPC内に構成されるエンドポイント（実体はENI）で、 Provided DNS からVPC外のDNSサーバに問合せを転送します。また、Outbound Endpoint とセットで転送ルールを設定できるようになります。この転送ルールとして、オンプレミスのDNSゾーン example.local の問合せはオンプレミスのDNSサーバに転送するように設定することで、EC2は Provided DNS を参照したままオンプレミスの名前解決が可能になります。Provided DNS を参照したままなので、VPC内の問合せはオンプレミスには転送されず、問合せはVPC内に留まります。

f:id:imiky:20210321134552p:plain

単一VPCとオンプレミス環境での名前解決のまとめと設計・運用上の注意点

まとめると、Route 53 Resolver の Inbound Endpoint と Outbound Endpoint + 転送ルールを利用することで、単一VPCとオンプレミス環境で相互に名前解決が可能になります。

f:id:imiky:20210321141550p:plain

ここで設計・運用上の注意点をまとめます。注意点の背景にある最大のポイントは、DNSの可用性がハイブリットクラウド環境全体の可用性のボトルネックになり得るという点です。各システムを高可用に構成しても、そもそも名前解決ができなければ、そのシステムを利用できない状態になり得るためです。そのため、上記構成においても、単一障害点がないことを慎重に確認する必要があります。Inbound / Outbound Endpoint の仕様を確認すると、実体はENIでありサブネット内に構成されるAZリソースです。1つの Inbound / Outbound Endpoint に対して、複数のIPアドレス（ENI）を構成することができます。また、各ENIごとに1秒当たりに処理できるクエリ数（QPS）に 10,000 QPS という上限があります。この2点を考慮すると、設計・運用の注意点として以下が考えられます。

  1. Inbound / Outbound Endpoint のそれぞれに対して、マルチAZに渡って複数のIPアドレス（ENI）を構成すること
  2. オンプレミスのDNSサーバに設定する転送ルールでは、転送先として Inbound Endpoint に構成した複数のIPアドレスを設定すること
  3. Outbound Endpoint の転送ルールでは、転送先としてオンプレミスの複数のDNSサーバのIPアドレスを設定すること
  4. CloudWatch で Inbound / Outbound Endpoint の QPS を監視すること
  5. ENIのIPアドレスは自動割当も可能であるが管理性を考慮し、IPアドレスは指定することを推奨

マルチアカウント環境に拡張させます

では、AWS側がマルチアカウント環境の場合を考えます。1つの方法として、Shared VPC でハイブリットDNS環境が構成されたVPCを全てのアカウントに共有する方式が考えられます。ただ、Shared VPC を利用したとしても、単一のVPCのみで全てを運用することは考えにくく、Shared VPC が組織のAWS運営に合わないケース（VPCの管理を各システムに委譲したい場合など）もあります。ここでは、複数のアカウントでオンプレミスとの相互の名前解決が必要な複数のVPCを運用しているケースを考えます。ここまでの話から、下図のように1つのVPCにはハイブリットDNS環境を構築済みとします。

f:id:imiky:20210321152151p:plain

まず、全てのVPCに Inbound / Outbound Endpoint を同じように構成する必要はないという点は先に述べておきます。その前提で、ぱっと思いつく案として、各VPCでDNSの参照先を構成済みの Inbound Endpoint に変更する方法が考えられますが、これはアンチパターンと言えます。この構成では、本来 Provided DNS に直接クエリしていた問合せが Inbound Endpoint に集中し、QPS や可用性の観点でホットスポットになってしまいます。また、Inbound Endpoint が存在するVPCと全てのVPCの間でVPC間接続を確保する必要があり、VPCや場合によってはAZをまたぐ通信が発生してしまいます。

f:id:imiky:20210321154240p:plain

では、Inbound / Outbound Endpoint を各VPCに構成せず、かつ、DNS参照先を変更せずに、複数のVPCでハイブリッドDNS環境を構成するにはどうすれば良いのでしょうか？これに対して、AWSはマルチアカウント／マルチVPCにおけるハイブリットDNS環境のために、必要なリソースはアカウント間／VPC間で共有できるようにしてくれています。まず、複数のアカウント／VPCでリソースを共有するので、ハイブリットDNS機能は専用のVPCに分離し、そのVPCにはアプリケーションリソースを構築しないようにします（役割を分離するため）。ここで共有するリソースは以下の2つです。

  • Private Hosted Zone で構成した内部DNSゾーン：他の複数のアカウント／VPCにも紐付け可能
  • Outbound Endpoint の転送ルール：他アカウントに共有可能（Resource Access Manager (RAM) で共有）

Private Hosted Zone と転送ルールを他のVPCに共有することで、共有されたVPCではオンプレミスと相互に名前解決が可能になります。以下は構成例の1つです。

f:id:imiky:20210321165928p:plain

オンプレミスからVPC内リソースの名前解決を見てみます。Private Hosted Zone "aws-example.local" が共有されているので、他のVPCでもVPC内リソースを aws-example.local に登録できます。名前解決はハイブリッドDNS環境専用のVPCで aws-example.local の全てのレコード（VPCに依らず）を解決できるため、Inbound Endpoint はハイブリッドDNS環境専用のVPCだけに構成されていれば、問題なく名前解決ができます。

この例では、1つの内部DNSゾーンをハイブリッドDNS環境専用のVPCで構成し、他のVPCに関連付ける方式を示しましたが、複数の内部DNSゾーンを構成し、各VPCに個別に関連付けても問題ありません。また、逆に各アカウントで個別の Private Hosted Zone を構成し、ハイブリッドDNS環境専用のVPCに関連付ける方式でも問題ありません。どちらでゾーンを構成した場合でも、ハイブリッドDNS環境専用のVPCにオンプレミスから名前解決したい全てのゾーンが関連付けられていれば、ハイブリッドDNS環境専用のVPCの Inbound Endtpoint のみで全ての名前解決が可能です。ハイブリッドDNS環境専用のVPCでゾーンを構成し他のVPCに関連付ける方式では、中央集権的に全てのゾーンを管理することができます。一方で、各VPCで個別にゾーンを構成し、ハイブリッドDNS環境専用のVPCに関連付ける方式では、各アカウント／VPCの管理者にゾーンの管理を委任できます。これは組織の運営方針にしたがって選択すれば良いかと思います。

次に、VPCからオンプレミスへの名前解決を見てみます。EC2といったVPC内リソースは、いずれのVPCでも引き続き Provided DNS を参照します。転送ルールがハイブリッドDNS環境専用のVPCから共有されているので、共有されているVPCで発生したオンプレミスの example.local に対する問合せは、転送ルールに従いハイブリッドDNS環境専用のVPCに構成したOutbound Endpoint を経由して、オンプレミスDNSサーバに転送され、正常に名前解決ができます。このとき、各VPCからハイブリッドDNS環境専用のVPCに構成された Outbound Endpoint への問合せの転送は、Provided DNS からAWSのバックエンドを通して行われるため、利用者で Outbound Endpoint への通信経路を確保する必要はありません（VPC間が接続されている必要はなく、VPC間に通信も流れない）。

このように、Private Hosted Zone と転送ルールという2つのリソースを共有するだけで、単一のVPCのハイブリットDNS環境をマルチアカウント／マルチVPCに拡張することができます。

おわりに

長かったですが、ハイブリットDNS環境についてまとめてみました。最後まで読んでいただけた方のお役に立てれば幸いです。