【入門編】 DNS名前解決リクエスト（Route 53 Resolver / AmazonProvidedDNS）におけるプライベートサブネットのルーティング – クラウド＆コンテナネットワーク実践ガイド

皆さん、こんにちは！ SRE兼クラウドアーキテクトの〇〇です。
今日のテーマは、クラウドインフラを触り始めたばかりの皆さんが「あれ？これってどうなってるんだろう？」と首をかしげがちな、でもとっても重要な「プライベートサブネットからのDNS名前解決」についてです。

特に、AWSのVPCにおけるRoute 53 Resolver (通称 AmazonProvidedDNS) と、プライベートサブネット、そしてNATゲートウェイが織りなすネットワークの裏側を、まるで郵便配達の仕組みのように紐解いていきましょう。

「DNS？ルーティング？ NATゲートウェイ？なんか難しそう…」と感じた方もご安心ください。一つずつ、ていねいに解説していきますからね！

—

郵便配達で例えるクラウドネットワークの世界へようこそ！

私たちが普段使っているインターネット。Webサイトを見たり、SNSで友達とやり取りしたり、裏側ではものすごい数のデータが行き交っています。その中でも、特に縁の下の力持ちとして重要な役割を担っているのが「DNS（Domain Name System）」です。

DNSの役割は、例えるなら「インターネット上の住所録」のようなもの。皆さんが「google.com」と打ち込むと、DNSが「はい、google.comさんの住所は142.250.199.110番地ですよ！」と教えてくれることで、あなたのPCは迷わずGoogleのサーバーにたどり着けるわけです。

今日は、この「住所録の問い合わせ」が、AWSの「プライベートな部屋（プライベートサブネット）」から行われるとき、どんな旅路をたどるのかを見ていきましょう。

—

プライベートサブネット：安全だけどちょっと不便？

AWSのVPC（Virtual Private Cloud）には、大きく分けて2種類のサブネットがあります。

1. パブリックサブネット：インターネットから直接アクセスできるサブネットです。ここに配置されたサーバー（EC2インスタンスなど）は、パブリックIPアドレスを持つことができ、外の世界と直接やり取りが可能です。
2. プライベートサブネット：インターネットから直接アクセスできない、閉鎖されたサブネットです。ここに配置されたサーバーは、通常パブリックIPアドレスを持ちません。高いセキュリティが求められるデータベースサーバーや、バックエンドのアプリケーションサーバーなどを配置するのに適しています。

プライベートサブネットは、外部からの不要なアクセスを防ぐことができるため、セキュリティの観点から非常に重要です。しかし、その「閉鎖性」ゆえに、ちょっとした課題も生まれます。それが「インターネットとどうやって通信するの？」という疑問です。

プライベートサブネット内のサーバーが、例えば外部のAPIを呼び出したり、OSのアップデートのためにインターネット上のリポジトリにアクセスしたりする場合、どうすればいいのでしょうか？パブリックIPを持たないサーバーは、そのままではインターネットに接続できませんよね。まるで、外線電話のない部屋にいるようなものです。

—

DNS問い合わせの基本：VPC内部の「郵便局窓口」へ

さて、本題のDNS問い合わせに移りましょう。

プライベートサブネット内のEC2インスタンスが、google.comのような外部のドメイン名に対応するIPアドレスを知りたいとき、最初にどこへ問い合わせるのでしょうか？

実は、AWSのVPC内には、すべてのインスタンスが利用できる特別なDNSサーバーが用意されています。これがRoute 53 Resolver、または旧称であるAmazonProvidedDNSと呼ばれているものです。このDNSサーバーは、VPCのCIDRレンジのネットワークアドレスに+2されたIPアドレスに存在します。（例: VPCのCIDRが10.0.0.0/16なら、10.0.0.2がDNSサーバーのIPアドレスになります）。

プライベートサブネット内のインスタンスは、このVPC内部のDNSサーバーに対して、名前解決のリクエストを送ります。

このときがポイントです！
VPC内部のDNSサーバーへの問い合わせは、VPCの内部で行われるため、インターネットへの接続は一切必要ありません。
これは、まるで「同じマンションの管理人に、マンション内の住民の部屋番号を尋ねる」ようなものです。マンション内でのことなので、外に出る必要はありませんよね。

イメージとしてはこんな感じです。

[プライベートサブネットのEC2]
       ↓ (DNS問い合わせ: "google.comのIPは？")
[VPC内のDNSサーバー (Route 53 Resolver / AmazonProvidedDNS)]

この問い合わせは、VPCのルーティングテーブルに自動的に設定されているローカルルートによって処理されます。特に意識せずとも、VPC内部のDNSサーバーへたどり着くことができるわけです。

—

外部リソースの名前解決とNATゲートウェイの登場！

では、VPC内部のDNSサーバーは、どのようにしてgoogle.comのような外部ドメインのIPアドレスを知るのでしょうか？

ここが重要です！
VPC内のDNSサーバーは、自身が知らないドメイン（つまり、AWSのRoute 53で管理されていないような外部のドメイン）については、インターネット上のルートDNSサーバーや権威DNSサーバーに問い合わせを行います。

この「VPC内のDNSサーバーが、外部のDNSサーバーに問い合わせに行く」という処理は、インターネットへの通信が必要になります。

しかし、私たちのプライベートサブネット内のインスタンスは、パブリックIPを持たないので直接インターネットに出られません。そして、そのインスタンスからのDNS問い合わせはVPC内のDNSサーバーに向かっています。

じゃあどうするの？ここで救世主となるのが「NATゲートウェイ (Network Address Translation Gateway)」です！

NATゲートウェイは、プライベートサブネット内のインスタンスがインターネットと安全に通信するための「代理人」のような役割をします。

例えるなら、外線電話のない部屋（プライベートサブネット）から、外部の人（インターネット）に電話したい場合を想像してください。あなたは部屋にいる管理人さん（NATゲートウェイ）に頼んで、「〇〇さんに電話してください」と伝えます。管理人さんは、自分の電話を使って外部に電話をかけ、相手から返ってきた情報をあなたに伝えてくれるわけです。

NATゲートウェイがあることで、プライベートサブネット内のインスタンスは、パブリックIPを持たなくても、NATゲートウェイが持つパブリックIPを使ってインターネットと通信できるようになります。

DNS問い合わせの流れ（NATゲートウェイ経由）

1. プライベートサブネットのEC2：「google.comのIPは？」と、VPC内部のDNSサーバー（例: 10.0.0.2）に問い合わせます。
2. VPC内部のDNSサーバー：google.comが自身の管理外のドメインだと判断し、「外部のDNSサーバーに問い合わせる必要があるな…」と考えます。
3. VPC内部のDNSサーバー：インターネット上の権威DNSサーバーに向けて、google.comの問い合わせをします。
4. ルーティングテーブルとNATゲートウェイ：この「外部への問い合わせ」トラフィックは、プライベートサブネットのルーティングテーブルに設定されたNATゲートウェイを経由してインターネットに出て行きます。

この時、VPC内部のDNSサーバーはプライベートIPアドレスを持っていますが、NATゲートウェイがそのパブリックIPアドレスに変換（NAT）して通信を仲介します。

5. インターネット上のDNSサーバー：google.comのIPアドレスをVPC内部のDNSサーバーに返します。
6. VPC内部のDNSサーバー：受け取ったIPアドレスを、最初に問い合わせてきたプライベートサブネットのEC2インスタンスに伝えます。
7. プライベートサブネットのEC2：google.comのIPアドレスを知り、晴れてgoogle.comにアクセスできるようになります。

つまり、プライベートサブネット内のインスタンス自体がNATゲートウェイを直接経由してDNS問い合わせをしているわけではない、という点がミソです！
インスタンスは常にVPC内部のDNSサーバーに問い合わせ、そのVPC内部のDNSサーバーが外部のDNSサーバーに問い合わせる際に、インターネットへの経路としてNATゲートウェイを利用する、という流れになります。

—

ルーティングテーブルの設定例：NATゲートウェイを「転送センター」に！

プライベートサブネットからインターネットに通信するために、ルーティングテーブルにNATゲートウェイへの経路を設定する必要があります。これは、郵便配達における「転送センターへの指示」のようなものです。

前提条件

VPCが作成済み
パブリックサブネットとプライベートサブネットが作成済み
パブリックサブネットにNATゲートウェイがデプロイ済み
NATゲートウェイは必ずパブリックサブネットに配置し、Elastic IPアドレスを関連付ける必要があります。

ルーティングテーブルの設定

プライベートサブネット用のルーティングテーブルに、0.0.0.0/0（すべての宛先）へのトラフィックをNATゲートウェイへ向ける設定を追加します。

# まず、VPC IDとプライベートサブネットのルートテーブルIDを取得します。
# ※実際にはご自身の環境のIDに置き換えてください。
VPC_ID="vpc-0123456789abcdef0"
PRIVATE_SUBNET_ROUTE_TABLE_ID="rtb-0fedcba9876543210"

# NATゲートウェイIDも取得します。
NAT_GATEWAY_ID="nat-0123456789abcdef0"

# プライベートサブネットのルートテーブルに、NATゲートウェイへのルートを追加
aws ec2 create-route \
    --route-table-id $PRIVATE_SUBNET_ROUTE_TABLE_ID \
    --destination-cidr-block "0.0.0.0/0" \
    --nat-gateway-id $NAT_GATEWAY_ID

echo "プライベートサブネットのルーティングテーブルにNATゲートウェイへのルートを追加しました。"

この設定により、プライベートサブネット内のインスタンスからインターネット（0.0.0.0/0）へ向かう通信は、すべて指定したNATゲートウェイを経由するようになります。これには、VPC内部のDNSサーバーが外部のDNSサーバーに問い合わせる通信も含まれます。

—

よくある疑問とトラブルシューティングのヒント

1. 「プライベートサブネットのEC2からインターネットに繋がらない！」

これは一番よくあるトラブルですね。以下の点を確認しましょう。

NATゲートウェイの存在とステータス：
NATゲートウェイがパブリックサブネットにデプロイされていますか？
ステータスが Available になっていますか？
Elastic IPアドレスが正しく関連付けられていますか？
ルーティングテーブルの設定：
プライベートサブネットに関連付けられているルーティングテーブルに、0.0.0.0/0 からNATゲートウェイへのルートが正しく設定されていますか？
セキュリティグループ/ネットワークACL：
EC2インスタンスのセキュリティグループや、サブネットのネットワークACL (NACL) が、アウトバウンド（外向き）の通信をブロックしていませんか？特に、HTTP/HTTPS (ポート80/443) やDNS (ポート53 UDP/TCP) のアウトバウンドを許可しているか確認しましょう。
VPC内部のDNSサーバーへの問い合わせは、VPC内部の通信なので、セキュリティグループやNACLでブロックされることは通常ありません。しかし、外部への通信（NATゲートウェイ経由）はこれらの設定の影響を受けます。

2. 「DNSの名前解決が遅い、またはタイムアウトする」

VPC内部のDNSサーバーへの疎通確認：
プライベートサブネットのインスタンスから、VPC内部のDNSサーバー（例: 10.0.0.2）に対してpingやtelnetで疎通を確認してみましょう。
ping 10.0.0.2 （実際のVPCの.2アドレスに置き換えてください）
もし疎通できない場合、インスタンスのセキュリティグループやNACLでVPC内部の通信がブロックされている可能性があります。
NATゲートウェイの負荷：
多数のインスタンスが同時にインターネットにアクセスしている場合、NATゲートウェイがボトルネックになっている可能性があります。CloudWatchメトリクスでNATゲートウェイの使用率を確認しましょう。
NATゲートウェイのリージョン：
NATゲートウェイはアベイラビリティゾーン (AZ) に依存します。インスタンスと同じAZにNATゲートウェイがあるか、またはインスタンスのルートテーブルが別のAZのNATゲートウェイを参照していないか確認しましょう。

—

まとめ：プライベートサブネットとNATゲートウェイ、DNSの賢い連携

今回は、プライベートサブネット内のインスタンスがDNSの名前解決を行う際のネットワーク経路と、NATゲートウェイの重要な役割について深掘りしました。

重要なポイントは以下の3点でしたね。

1. VPC内部のDNS問い合わせは、VPC内部で完結する：プライベートサブネットのインスタンスは、常にVPC内部のRoute 53 Resolver (例: .2のアドレス) に問い合わせます。この際、NATゲートウェイは不要です。
2. 外部ドメインの名前解決にはNATゲートウェイが必要：Route 53 Resolverが外部のドメイン情報を知るためには、インターネット上のDNSサーバーに問い合わせる必要があります。この「外部への通信」を可能にするのが、NATゲートウェイです。
3. ルーティングテーブルで経路を制御：プライベートサブネットのルーティングテーブルに、0.0.0.0/0 からNATゲートウェイへのルートを設定することで、プライベートインスタンスからインターネットへの通信（およびRoute 53 Resolverからの外部DNSへの問い合わせ）が実現します。

クラウドインフラのネットワークは、一見複雑に見えますが、一つ一つのコンポーネントの役割を理解し、郵便配達のような身近な例に置き換えて考えてみると、意外とスッキリ理解できるものです。

この知識が、皆さんの日々のインフラ構築やトラブルシューティングに役立つことを願っています。一歩ずつ、着実に理解を深めていきましょう！

それでは、また次回の記事でお会いしましょう！