自治体基幹業務システムをガバメントクラウドの AWS 環境で運用するとき、ネットワークで考慮しなければならないことの一つが名前解決です。
自治体基幹業務システムのクライアントは基本的に閉域のオンプレミスにあり、さらに AWS 環境のリソースにもアクセスする必要があるため、クライアントが参照する DNS リゾルバーは、オンプレミスと AWS の両方の環境の名前解決をできなくてはなりません。
また、AWS 環境に構築したサービスや VPC 内のリソースを閉域の中で名前解決しようとするとき、AWS ならではの注意ポイントがいくつか登場してきます。
そこで、これら自治体基幹業務システムを閉域の AWS 環境で運用するときに考慮すべき名前解決のポイントは何か、自治体情シスの目線で知っておいた方がよいと思ったことを解説してみたいと思います。
本記事は ガバメントクラウド Advent Calendar 2025 の 5 日目の投稿となります。
VPC 内の名前解決の仕組み
VPC 内で名前解決が必要な場面には、以下のようなものがあります。
- EC2 や RDS のインスタンスにホスト名でアクセスするとき
- S3 などの AWS サービスにアクセスするとき
クライアントとサーバーがともにインターネット接続環境にいてパブリックなドメインを名前解決できる DNS を参照している場合は、AWS がよしなにやってくれる部分もあり、特に難しく考える必要はないかもしれません。
しかし、閉域で完結する環境では、しっかり AWS の名前解決を理解しておかないと、思ったとおりにネットワーク接続できない場合があります。
それでは具体的に AWS 環境での名前解決の仕組みについて見ていきます。
Route 53 Resolver を理解すれば大丈夫
そもそも VPC 内の EC2 インスタンスなどのリソースが名前解決の時に参照する DNS リゾルバーはどこにあるのでしょうか？
VPC には Route 53 Resolver (AmazonProvidedDNS) という DNS リゾルバーが自動的に作成されます。
VPC 内のリソースは、デフォルトでは VPC に設定された DHCP の設定（DHCP Option Set）により DNS 参照先をこの Route 53 Resolver に設定されています。
Route 53 Resolver は、インターネット上のパブリックなドメインの名前解決ができるほか、以下の名前解決も行うことができます。
- VPC 内でプライベートに名前解決するように設定したリソース（VPC エンドポイントや RDS など）
- VPC に関連付けた Route 53 Private Hosted Zone で設定した DNS レコード
VPC エンドポイントや Route 53 Private Hosted Zone などの聞き慣れない用語が出てきましたが、一旦はこれらを閉域で AWS のサービスや VPC のリソースを名前解決するための機能であると考えておけば大丈夫です。
つまり、Route 53 Resolver とは、パブリックか閉域かによらず、AWS の VPC 内での名前解決の基盤であり、語弊があるかもしれませんが、AWS 関係の名前解決をさせたい時はとりあえず DNS 参照先を Route 53 Resolver へ向けておけばなんとかなる、と今は思ってください。
Route 53 Private Hosted Zone とは？
Route 53 Private Hosted Zone とは、Amazon Route 53 という AWS の DNS に関するサービスの機能の一つで、プライベートに閉じた DNS のホストゾーンを管理できるものです。インターネットへホストゾーンを公開する Public Hosted Zone もありますが説明は割愛します。
DNS サーバーを自前で立てることなく DNS のホストゾーンを安価に設定できる上、Route 53 Resolver との連携も容易なため、AWS で DNS を構築する際はよく使われるサービスです。
作成した Route 53 Private Hosted Zone を VPC に関連付けるだけで、その VPC の Route 53 Resolver が Route 53 Private Hosted Zone の名前解決をできるようになります。
VPC エンドポイントとは？
AWS のサービスは、通常インターネット経由で利用しますが、ガバメントクラウドの自治体基幹業務システムは VPC 内もオンプレからもインターネット接続できないため、そのままでは AWS サービスの利用ができません。
一部の AWS サービスは、VPC のプライベートサブネット内に接続口（エンドポイント）を作成することで、インターネット接続がなくても利用できる仕組みがあり、これを VPC エンドポイントと言います。
閉域で VPC を運用する際は、VPC 内から使いたい AWS サービスの VPC エンドポイントを作成する必要があります。
VPC のリソースが VPC エンドポイントへアクセスする場面においても、名前解決は重要な役割を担っています。
VPC エンドポイントを作成する時にプライベート DNS 名を有効に設定することで、VPC の Route 53 Resolver は VPC エンドポイントに設定されたプライベート DNS 名を名前解決し VPC エンドポイントのプライベート IP アドレスへアクセスできるようになります。
このように、VPC の Route 53 Resolver は、AWS 環境の名前解決で重要な役割を担っていることが分かります。
オンプレミスから VPC のリソースやエンドポイントを名前解決するには？
それでは、自治体の庁内ネットワーク（オンプレミス）のクライアントから、VPC に構築したサーバーやエンドポイントを名前解決するにはどうしたらよいでしょうか？
ここまでの説明で、オンプレミスのクライアントが Route 53 Resolver で名前解決できるようにすればいいことが分かると思います。
ここで、オンプレミスから VPC の Route 53 Resolver を参照する時に注意するポイントがあります。
それは、Route 53 Resolver の IP アドレスを直接参照して名前解決できるのは、VPC 内のリソースに限られるということです。つまり、ある VPC に作られた Route 53 Resolver は、そのままではオンプレミスや他の VPC のリソースからは、直接参照することができません。
ではこれらの VPC 外からでも Route 53 Resolver を参照させたいときはどうすればいいのでしょうか？
オンプレミスや他の VPC から Route 53 Resolver を参照させるためにインバウンドエンドポイントを作る
オンプレミスや他の VPC から Route 53 Resolver を参照させるためには、VPC に Route 53 インバウンドエンドポイントという Route 53 Resolver への特殊な VPC エンドポイントを作成することで実現できます。
VPC に Route 53 インバウンドエンドポイントを作成すると、設定したプライベートサブネットに IP アドレスを持ったエンドポイントが作成されます。
このエンドポイントの IP アドレスをオンプレミスや他の VPC から名前解決要求を転送する先として参照させることで、エンドポイントを通じて Route 53 Resolver での名前解決が実行される仕組みです。
オンプレミスの DNS リゾルバーには AWS 環境で使うドメインの条件付きフォワーダーを設定する
オンプレミスのクライアントの DNS 参照先を直接 Route 53 インバウンドエンドポイントにすることは可能です。しかし、多くのクライアントは既存の DNS 参照先としてオンプレミスの DNS リゾルバーが設定されており、オンプレミス内のリソースへの名前解決も引き続き必要だと思います。
それでは既存のオンプレミス環境と AWS 環境を同時に名前解決できるようにするにはどうすればよいでしょう？
それは、既存の DNS リゾルバーに、AWS 環境で使うドメインへの名前解決要求は Route 53 インバウンドエンドポイントへ転送する条件付きフォワーダーの設定をすることで実現できます。
例えば VPC に fuga.example.jp の Route 53 Private Hosted Zone が関連付けられているとします。
この fuga.example.jp ホストゾーンをオンプレミスのクライアントからも名前解決させたい場合は、オンプレミスの DNS リゾルバーに fuga.example.jp ドメインへの条件付きフォワーダーを設定します。
これにより、クライアントからオンプレミスの DNS リゾルバーへの名前解決要求が VPC の Route 53 インバウンドエンドポイントへ転送され、VPC の Route 53 Resolver からの応答がオンプレミスのクライアントまで返るようになります。
具体的な実装方法に興味があれば、過去記事で解説していますのでぜひ参考にしてください。
名前解決を統一することで VPC 間で共通で使うリソースを節約できる
この応用で、互いにルーティングできる他の VPC のリソースの名前解決を Route 53 インバウンドエンドポイントに向けさせることで、他の VPC のリソースが Route 53 Resolver で名前解決できるようにすることもできます。
名前解決を統一することで、VPC エンドポイントを 1 つの VPC に集約し、他の VPC から VPC エンドポイントを使う時はこの集約用 VPC にあるエンドポイントへアクセスさせる、といった構成も可能になります。
こちらも具体的な実装を過去記事に解説しています。
ただし、これは VPC を管理するベンダーが単独である場合でなければ難しいです。ガバメントクラウドの共同利用方式で、異なるベンダーが管理する VPC 間でこういった調整を図ろうとしても、中々応じてもらえないのが現状です。
それでも名前解決の仕組みを理解することは、こういった効率化を図る可能性に気付くことへ繋がるので、自治体情シスとして学ぶことの意味はあると思います。
DNS 名でのアクセスが必須である AWS サービスには注意
自治体基幹業務システムでもよく使われる AWS サービスのうち、IP アドレスが不定で必ず名前解決を通じてアクセスしなければならないものがいくつかあります。
代表的なものは RDS と Application Load Balancer です。RDS はオンプレミスのクライアントから直接アクセスされることはほぼないでしょうからいいのですが、Application Load Balancer は、これまで説明した AWS 環境の名前解決を使わなければアクセスできませんので注意が必要です。
これらのサービスをどうしても固定 IP アドレスで使いたい場合は、前段に IP アドレスの固定が可能な Network Load Balancer を挟む必要があります。
AWS の名前解決は一筋縄ではいかない
実は今回説明した AWS の名前解決の仕組みは、全容を説明できていません。
というのも、AWS の名前解決を突き詰めると本当に一筋縄ではいかず、例えば、
- プライベートに作成してもパブリックな DNS からも名前解決されてプライベート IP アドレスが返るもの（Application Load Balancer など）
- プライベートに作成すると他の VPC からも名前解決ができるようになるもの（RDS など）
- プライベート DNS 名を有効にすると VPC 内のみで名前解決が可能で、無効にすると Private Hosted Zone で設定しなければプライベート IP アドレスを返せないもの（AWS サービスのインターフェース型 VPC エンドポイントなど）
といった具合で、何のサービス・リソースを、どの環境から名前解決させたいかをしっかり検討しないと、名前解決ができるできないといった状況が生じてしまいます。
この名前解決の難しさについて、東京支部 CommunityBuilders Night #2 / Jr.Championsコラボ の発表資料で分かりやすいと思ったものがあったので紹介します。
まとめ
まずは自団体の構成で名前解決がどのように行われているかについて、構成図を見ながら流れを追ってみると理解がしやすくなるかと思います。
名前解決の仕組みを押さえておくと、AWS でのネットワーク構築や運用で必ず役に立つと思いますので、この記事が参考になれば幸いです。