詳細解説：ガバメントクラウド名前解決編

こんにちは。 AWS パブリックセクター技術統括本部の小林です。

2024 年 6 月 20 日、21 日に AWS Summit Japan が開催され、その中には、「先行事例から分かってきた、自治体職員がガバメントクラウド利用をする上で考えておくこと」のセッションがありました。詳細は、AWS Summit Japan 2024 のセッション「先行事例から分かってきた、自治体職員がガバメントクラウド利用をする上で考えておくこと」をご確認ください。
その際に「業務システムの名前解決について」のセクションがあり、ガバメントクラウド上での名前解決の構成検討を進めることが多くなってきているかと思います。
本ブログは、名前解決のアーキテクチャに関して深堀していきます。ガバメントクラウド特有の制限ではなく、オンプレミスとAWS 環境をハイブリッドに構成するネットワーク設計では一般的な内容です。ぜひご検討の際に参考にしていただければと思います。

ガバメントクラウドの基本的な情報を知りたい方はガバメントクラウドの道案内『自治体職員編』をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。
また、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、ガバメントクラウド活用のヒント『共同利用方式におけるコスト・セキュリティ管理について』をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。

AWSにおいてDNSでの名前解決が必要なリソース

一例となりますが、下記のサービスは DNS で名前解決を行い接続します。IP アドレスでの接続が出来るサービスもありますが、マルチ AZ の冗長構成を DNS で実現しているサービスもあるため、ホスト名でのアクセスを推奨しています。
例えば、Application Load Balancer は IP アドレスがスケールアウトに伴って変動するので、IP アドレスを直接指定するのは非推奨です。詳細は [AWS Black Belt Online Seminar] Elastic Load Balancing をご覧ください。

どう名前解決を実現すれば良いのか

オンプレミスから AWS 環境の名前解決についてですが、Route 53 Resolver インバウンドエンドポイントを利用することで、実現できます。地方公共団体からガバメントクラウド環境のシステムの名前解決を行う場合に、Amazon Route 53 のインバウンドエンドポイントを地方公共団体の基幹ネットワークのオンプレミスの DNS フォワーダーに、フォワード先として設定することで名前解決することが可能です。

AWS 環境からオンプレミス向けの名前解決についてですが、Amazon Route 53 Resolver のリゾルバルールに転送ルールを追加することで実現します。転送ルールが追加された問い合わせは、Route 53 Resolverアウトバウンドエンドポイントを通って指定された IP アドレス、ここではオンプレミス DNS サーバに転送されます。

AWS の Amazon Route 53 Resolver の知識を深めたい方は[AWS Black Belt Online Seminar] Amazon Route 53 Resolverをご覧ください。

課題と解決の方向性

ガバメントクラウドにおいては、複数の事業者の役割が定義されています。事業者としては、自治体ごとに他の事業者の振る舞いによって自分の役割を変えないといけないことが現状としてあり、最適な構成が見えづらいという以下の課題感があるかと思います。

環境全体を考える人がいないため、全体最適な構成が採用されづらい
各アカウントでどういった設定をすればいいか見えづらい (他事業者とどういった調整をすればいいか不明瞭)

この課題感を少しでも解消すべく、本ブログでは以下のパターンでの名前解決の方法をご紹介します。

Route 53 Resolver を利用した名前解決
AD を利用した名前解決

本ブログでの構成における前提条件

地方公共団体の基幹系ネットワーク上にオンプレミス DNS (リゾルバ) が存在していること
- 無い場合は、業務端末の DNS 設定等で対応すること
地方公共団体と AWS 環境が Direct Connect でプライベートに接続されていること
Route 53 Resolver インバウンドエンドポイント及びアウトバウンドエンドポイントを利用すること

Route 53 Resolver を利用した名前解決

地方公共団体 (オンプレミス) から AWS の名前解決

地方公共団体から AWS の名前解決を行う方法を複数ご紹介します。
ご要件に応じて、この中から方式を選択いただく必要があります。

Route 53 Private Hosted Zone を他の VPC へ共有する方法

この方式は、Route 53 Private Hosted Zone を他の VPC へ共有する方法です。
詳細については、別AWS アカウントのプライベートホストゾーンの関連付けをご参照ください。
システム追加時に、運用管理アカウントの事業者と単独利用方式あるいは共同利用方式でアプリケーションを提供する事業者間で連携の上、設定が必要です。
各 VPC 毎にインバウンドエンドポイントを設けると費用が高くなってしまいますが、インバウンドエンドポイントが集約できる構成のため、コスト最適化に繋がります。また、地方公共団体の基幹ネットワークのオンプレミス DNS サーバーに、フォワーダーとして設定するルールがシンプルになることも特徴です。
複数の VPC と AWS アカウントで Amazon Route 53 プロファイルを使用して DNS 管理を統合するについてはこちらのブログをご参照ください。

運用管理アカウントで集中管理する方法

この方式は、運用管理アカウントで DNS レコード含めて集中管理する方法です。
Route 53 Private Hosted Zone を他の VPC へ共有する方法と同様でインバウンドエンドポイントは集約される構成のため、コスト最適化につながります。
運用管理アカウントで集中管理を行うため、他事業者のエントリの更新等が発生する場合は、都度依頼を受けて設定変更等の対応をする必要があります。

Route 53 Resolver エンドポイントを連携する方法

この方式は、Route 53 Resolve エンドポイントを連携する方法です。運用管理アカウントではインバウンドエンドポイント及びアウトバウンドエンドポイント、共同利用方式 A アカウントそれぞれでインバウンドエンドポイントを持ち、構成図の矢印のイメージで通信します。こちらは上記の 2 パターンと比較して、各アカウントの VPC にインバウンドエンドポイントを構築する必要があるので、費用が高くなってしまいます。
事業者毎の独立度が高く、共同利用方式でアプリケーションを提供する事業者がこの方式でインバウンドエンドポイントを提供する場合は、選択肢の 1 つになるかもしれません。

各事業者で個別の Resolver エンドポイント (インバウンドエンドポイント及びアウトバウンドエンドポイント)を運用する方法

この方式は、各事業者で個別の Route 53 Resolver エンドポイントを運用する方法です。地方公共団体側の DNS にフォワーダーの設定が都度必要になります。こちらも各アカウントの VPC にインバウンドエンドポイントを構築する必要があるので、費用が高くなってしまいます。
また Route 53 Resolver エンドポイントを連携する方法と同様に事業者毎の独立度が高く、共同利用方式でアプリケーションを提供する事業者がこの方式でインバウンドエンドポイントを提供する場合は、選択肢の 1 つになるかもしれません。

AWS から地方公共団体(オンプレミス)の名前解決

AWS から地方公共団体のオンプレミスにある DNS サーバーで管理されているドメインの名前解決を行う方法を複数ご紹介します。地方公共団体から AWS の名前解決を行う方法と同様に、ご要件に応じて方式を選択いただく必要があります。地方公共団体のオンプレミス側に名前解決するケースがあるかは、 ASP 事業者、運用管理補助者あるいはネットワーク構築運用補助者にご確認ください。

Route 53 Resolver Rule を他の AWS アカウントへ共有する方法

この方式は、Resolver Rule を他の AWS アカウントへ共有する方法です。Resolver ルールを共有すると、該当 VPC のアウトバウンドエンドポイントを利用して構成図のようにオンプレミス DNS にアクセスできます。詳細は、Resolver ルールを他の AWS アカウントと共有し、共有ルールを使用するをご参照ください。
各 VPC 毎にアウトバウンドエンドポイントを設けると費用が高くなってしまいますが、アウトバウンドエンドポイントを集約できる構成のため、コスト最適化につながります。

DHCP を変更する方法

この方式は、DHCP オプションセットを作成し、VPC に関連付ける方法です。名前解決を運用管理アカウントのインバウンドエンドポイントへ向けて Resolver の DNS を利用する方法です。詳細は、DHCPオプションセットをご参照ください。ただし注意点として、DHCP オプションセットを変更すると、その VPC にある VPC エンドポイントを利用できなくなる点があります。VPC エンドポイントを集約する構成の詳細については、こちらをご確認ください。

Route 53 Resolver エンドポイントを連携する方法

この方式は、Route 53 Resolve エンドポイントを連携する方法です。運用管理アカウントではインバウンドエンドポイント及びアウトバウンドエンドポイント、共同利用方式 A アカウントそれぞれでアウトバウンドエンドポイントを持ち、構成図の矢印のイメージで通信します。こちらは上記の 2 パターンと比較して、各アカウントの VPC にアウトバウンドエンドポイントを構築する必要があるので、費用が高くなってしまいます。
事業者毎の独立度が高く、共同利用方式でアプリケーションを提供する事業者がこの方式でアウトバウンドエンドポイントを提供する場合は、選択肢の 1 つになるかもしれません。

各事業者で個別の Resolver エンドポイント (インバウンドエンドポイント及びアウトバウンドエンドポイント)を運用する方法

この方式は、各事業者で個別の Resolver エンドポイントを運用する方法です。各事業者で地方公共団体側の DNS に転送ルールを追加する設定が都度必要になります。こちらも各アカウントにアウトエンドポイントを構築する必要があるので、費用が高くなってしまいます。
またRoute 53 Resolver エンドポイントを連携する方法と同様に事業者毎の独立度が高く、共同利用方式でアプリケーションを提供する事業者がこの方式でアウトバウンドエンドポイントを提供する場合は、選択肢の 1 つになるかもしれません。

総括

From / 解決対象	方式	メリット	デメリット	備考
地方公共団体（オンプレミス）からAWSの名前解決	PHZ 共有	エンドポイントが集約されるのでコスト最適事業者の独立度が高い	システム追加時に事業者が連携して設定を行う必要がある
	集中管理	エンドポイントが集約されるのでコスト最適他事業者は設定不要	設定変更作業がある場合は都度依頼を要けて、対応する必要がある
	エンドポイント連携	事業者の独立度が高い	エンドポイントが集約されていないのでコストが高くなる	共同利用方式でアプリケーションを提供する事業者がこの方式を採用している場合がある
	個別エンドポイント	事業者の独立度が高い	エンドポイントが集約されていないのでコストが高くなる	共同利用方式でアプリケーションを提供する事業者がこの方式を採用している場合がある

From / 解決対象	方式	メリット	デメリット	備考
AWS から地方公共団体 (オンプレミス) の名前解決	ルール共有	エンドポイントが集約されるのでコスト最適	システム追加時に事業者が連携して設定を行う必要がある
	DHCP 変更	エンドポイントが集約されるのでコスト最適	個別に VPC エンドポイントを利用できない	VPC エンドポイントも集約する構成であれば問題無い
	エンドポイント連携	事業者の独立度が高い	エンドポイントが集約されていないのでコストが高くなる	共同利用方式でアプリケーションを提供する事業者がこの方式を採用している場合がある
	個別エンドポイント	事業者の独立度が高い	エンドポイントが集約されていないのでコストが高くなる	共同利用方式でアプリケーションを提供する事業者がこの方式を採用している場合がある

各AWSアカウントにインバウンドエンドポイント/アウトバウンドエンドポイントがある構成だと費用が高くなってしまうため、集約の検討をお勧めします。また方針の決定に併せて、DNS 管理の事業者と他の事業者との調整事項を決めていただくと運用もスムーズに進むと考えます。以下が観点として挙げられるかと思います。

いずれかの運用管理補助者に AWS 環境の DNS 管理を依頼する
共同利用方式でアプリケーションを提供する ASP 事業者に名前解決の方針を確認する
設定変更の際の、段取りやスコープの調整
障害発生時の ASP・自治体とのコミュニケーションパスや対応フローの整理

また、データ連携等で各 VPC 間で通信が発生しない想定の場合も、名前解決の方法によっては各 AWS アカウントの VPC 間で通信が発生する場合もあります。そのため、Transit Gateway のルートテーブルの設定等で各 VPC 同士が通信できないと名前解決ができない場合もあるため、名前解決の方針に併せ、各 VPC 間でどういった通信が発生するか整理をお勧めします。
Amazon Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を一元化するソリューションはこちらのブログをご参照ください。

AD を利用した名前解決

ここまで、Amazon Route 53 Resolver エンドポイントを利用することを前提での名前解決の方法をご紹介しました。AWS 上で DNS サーバーの機能を有するサーバーを立てる場合は、必ずしも Amazon Route 53 Resolver エンドポイントを使う必要はありません。その場合の構成について、代表的なケースとしては、AWS Managed Microsoft ADを利用する場合があります。
VPC 内の EC2 は AWS Managed Microsoft AD ディレクトリに結合することで、AWS Managed Microsoft AD によって名前解決されます。また AWS Managed Microsoft AD にはフォワーダとしてRoute 53 Resolver が設定されており、AWS リソースはResolver によって名前解決されます。
AWS Managed Microsoft AD は DNS サーバー以外の機能も含んでおり、Route53 との単純な比較は難しいです。OS バージョンアップデート等の管理や運用面も考慮する必要があります。そのため、AD の配置戦略と併せてご検討されることをお勧めします。また ASP 事業者のアプリケーションに依っては、ADを利用した名前解決を行う構成となっている場合もございますので、併せてご確認いただければと思います。

まとめ

本ブログでは、ガバメントクラウド上での全体のネットワーク設計の肝である名前解決で検討すべきポイントと構成例をご紹介しました。重要なポイントとしては、方針の決定に併せて、DNS管理の事業者と他の事業者との調整事項を決めていただく点が挙げられます。
地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。

免責事項

本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。
本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。
本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。
本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾンウェブサービスジャパンは一切の責任を負いかねますことご了承ください。

ガバメントクラウドに関するお問い合わせ

AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。
本記事で紹介した名前解決に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。
https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

Amazon Web Services ブログ