こんにちは！SREとして日夜クラウドの海を泳ぎ回っている私ですが、今回はAWSのネットワークの裏側でこっそりと、しかしものすごく重要な役割を果たしている「DNSの仕組み」についてお話ししたいと思います。
AWSを触り始めると、パブリックサブネットやプライベートサブネット、そしてインターネットゲートウェイといった言葉にはすぐに馴染むようになりますよね。でも、「EC2インスタンスがどうやって名前解決（ドメイン名からIPアドレスへの変換）を行っているのか」という部分まで、深く考えたことはありますでしょうか？
「なんとなく nslookup や dig を叩いたら名前が引ける」……それも大事な第一歩ですが、その裏側ではAWSが用意してくれた「魔法のIPアドレス」がこっそりと大活躍しています。今回は、この仕組みを身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！
—
1. 郵便配達員にお願いするようなもの？ VPC内DNSリゾルバーの正体
皆さんがAWSのVPC（Virtual Private Cloud）内にEC2インスタンスを立ち上げたとき、そのインスタンスには必ず「そのVPCのネットワークアドレス範囲の先頭から4番目のIPアドレス」がDNSサーバーとして割り当てられます。
具体的には、どのVPCであっても 169.254.169.253 という特別なIPアドレスがDNSサーバー（正式名称：AmazonProvidedDNS）として使われます。
身近な例えで考えてみましょう
この 169.254.169.253 は、いわば「マンション専属の超優秀なコンシェルジュ」です。
あなたが住むマンション（VPC）の住民（EC2インスタンス）が、「隣町のカフェの住所（外部のウェブサイトのIPアドレス）が知りたい！」と思ったとします。住民はわざわざ自分で街に出て地図を探したりしませんよね。代わりに、エントランスにいるコンシェルジュ（AmazonProvidedDNS）のところへ行って、「このお店の住所を教えて！」とお願いします。
コンシェルジュは、自分で知っていること（VPC内のプライベートDNS名など）であれば即座に答えてくれますし、知らないことであれば外部のDNS世界へ問い合わせに行って、最新の住所情報を住民に届けてくれるのです。
—
2. 独自のドメインとオンプレミスへの橋渡し：Route 53 Resolverの登場
さて、コンシェルジュが活躍する日常はそれで平和なのですが、実務の現場ではもう少し複雑なケースによく直面します。
例えば、「社内のオンプレミス環境（データセンターやオフィス）にあるサーバーと、AWS上のVPCをAWS Direct ConnectやVPNで接続している」という状況です。このとき、AWS側のEC2からオンプレミス側にある社内システム（例: corp.internal という独自ドメイン）の名前を引きたくなったらどうなるでしょうか？
そのままでは、先ほどの「マンションのコンシェルジュ（AmazonProvidedDNS）」は、インターネットの広い世界を探しても corp.internal の住所を見つけることができません。「そんな住所、私の持っている電話帳には載っていません！」と困ってしまいます。
ここで登場するのが、Amazon Route 53 Resolver（の条件付きフォワーディング機能）です！
条件付きフォワーディングを郵便配達に例えると…
コンシェルジュに新しいルールをこう教え込みます。
- 「もし
corp.internal宛ての荷物（DNSクエリ）が来たら、うちのマンションのルールブックで見ようとせず、専用の連絡通路を通って、社内の総務部（オンプレミスのDNSサーバー）に直接転送（フォワード）しなさい！」
これが条件付きフォワーディング（Conditional Forwarding）の仕組みです。特定のドメイン名宛ての問い合わせだけを、指定した宛先（オンプレミスのDNSサーバー等）へ賢くバトンタッチしてくれるのです。
—
3. 実務でどう設定する？ Route 53 Resolverのハンズオン風設定
百聞は一見にしかず。実際にAWS環境でこのフォワーディングを構築するための設定イメージを見てみましょう。AWS CLIを使って、オンプレミスのDNSサーバーへクエリを転送するルール（リゾルバー規則）を作成する手順の一例です。
実務では、次のようなステップで設定を行います。
ステップ1: アウトバウンドエンドポイントの作成
まず、VPC内からオンプレミス側へDNSクエリを「送り出す」ための窓口（アウトバウンドエンドポイント）を作成します。
# アウトバウンドエンドポイントを作成するAWS CLIの例
aws route53resolver create-resolver-endpoint \
--creator-request-id "outbound-endpoint-2023-10" \
--security-group-ids sg-0123456789abcdef0 \
--direction OUTBOUND \
--ip-addresses SubnetId=subnet-01111111111111111,Ip=10.0.1.5 \
SubnetId=subnet-02222222222222222,Ip=10.0.2.5 \
--name "onpremises-outbound-endpoint"> 💡 ここがポイント！
> エンドポイントには、VPC内のプライベートサブネットを指定し、オンプレミス側のDNSサーバーと通信できるようにセキュリティグループの穴あけ（ポート53のTCP/UDP許可）を忘れないようにしましょう。
ステップ2: フォワードルールの作成とVPCの関連付け
次に、「どのドメイン宛ての問い合わせを、どこに飛ばすか」というルール（リゾルバー規則）を作成し、それをVPCに関連付けます。
# 条件付きフォワードルールを作成する例
aws route53resolver create-resolver-rule \
--creator-request-id "forward-rule-corp" \
--rule-type FORWARD \
--domain-name "corp.internal." \
--name "forward-to-onpremise" \
--target-ips Ip=192.168.10.10,Port=53 \
--resolver-endpoint-id rslvr-out-0123456789abcdef0
# 作成したルールを対象のVPCに関連付ける
aws route53resolver associate-resolver-rule \
--resolver-rule-id rslvr-rule-0123456789abcdef0 \
--vpc-id vpc-0123456789abcdef0 \
--name "associate-vpc-with-corp-rule"これで設定は完了です！
この設定を入れたあとに、VPC内のEC2インスタンスから nslookup internal-server.corp.internal と叩いてみると……見事にオンプレミス側のサーバーのIPアドレスが返ってくるようになります。感動の瞬間ですね！
—
まとめ：仕組みが分かればトラブルも怖くない！
今回は、VPC内のDNSリゾルバー（169.254.169.253）の基本的な働きと、オンプレミス環境と連携するためのRoute 53 Resolverの条件付きフォワーディングについて解説しました。
- AmazonProvidedDNS (
169.254.169.253) は、VPC内のすべてのEC2にとっての頼れる専属コンシェルジュであること。 - 自社独自のドメイン名やオンプレミス環境のシステムの名前を引くためには、Route 53 Resolverの条件付きフォワーディングを使って、適切な宛先へパスを繋いであげる必要があること。
この2点さえ押さえておけば、「あれ、なぜか社内システムの名前解決だけできないぞ……？」という現場のトラブルに直面したときも、「どのコンシェルジュに聞きにいっていて、宛先のルールはどうなっているんだっけ？」と冷静にパケットの気持ちになって原因を切り分けることができます。
クラウドのネットワークは、一見すると黒魔術のように見えますが、一つひとつの機能を紐解いていくと非常に筋が通っていて美しい仕組みで作られています。ぜひ皆さんのインフラ構築や日々の運用にも役立ててみてくださいね。それでは、また次回の技術解説でお会いしましょう！
コメント