⚡ まず結論：3つの核心ポイント
ハイブリッド DNS とは「2つのオフィスにある内線電話帳を、交換機で相互接続する」仕組みです。Route 53 Resolver のインバウンド＆アウトバウンドエンドポイントを設置し、DNS クエリ転送ルールを設定するだけで、オンプレミス↔AWS 間の名前解決がマネージドで実現します。
DNS クエリ受け口
DNS クエリ転送口
問い合わせ先を振り分け
たとえ話で全体像をつかむ
🏢 ２つのオフィスビルの内線電話帳
ある大企業が「東京本社ビル」（= オンプレミス）と「大阪支社ビル」（= AWS クラウド）を持っていると想像してください。 それぞれのビルには独自の内線電話帳（= DNS）があります。
東京の社員が大阪の「田中さん（内線 2051）」に電話したいとき、東京の電話帳には大阪の情報が載っていません。 そこで必要なのが、2 つのビルをつなぐ交換機（= Route 53 Resolver エンドポイント）と、 「大阪の番号は大阪に聞いてね」という転送ルールです。
corp.example.com
「大阪の田中さんに電話したい」
オンプレ DNS リゾルバー
→ 大阪に転送
→ 東京に転送
aws.example.com
「東京の鈴木さんに電話したい」
Route 53 Resolver
現在の構成（Before）と課題
現在は、AWS 側にオープンソースの再帰 DNS リゾルバーを EC2 上に構築して、オンプレミスとの名前解決を実現しています。これには運用上の課題があります。
/ VPN
相互転送
（EC2 上で自己管理）
OSS DNS リゾルバーの問題点
Route 53 Resolver に置換
Route 53 Resolver の 2 つのエンドポイント
🚪 ビルの「受付窓口」と「外部電話回線」
インバウンドエンドポイントは、ビルの正面受付のようなもの。外部（オンプレ）からの電話（DNS クエリ）を受け付ける窓口です。
アウトバウンドエンドポイントは、外線電話機のようなもの。ビル内（AWS）から外部（オンプレ）に電話をかけるための回線です。
📥 インバウンドエンドポイント
オンプレミス環境からの DNS クエリを VPC 内で受信するための ENI（ネットワークインターフェース）です。
📤 アウトバウンドエンドポイント
VPC 内の DNS クエリをオンプレミスの DNS リゾルバーへ転送するための ENI です。転送ルールと組み合わせて使います。
🔑 覚えるコツ：「誰が聞きたいか」で判断
オンプレの人が AWS の名前を知りたい
→ オンプレからクエリが入ってくる
→ インバウンドエンドポイント
AWS の人がオンプレの名前を知りたい
→ AWS からクエリが出ていく
→ アウトバウンドエンドポイント
DNS クエリの流れを図解する
移行後のアーキテクチャ（After）
aws.example.com → インバウンド EP の IP へ転送
/ VPN
転送
オンプレ→AWS のクエリ受信
AWS→オンプレのクエリ転送
corp.example.com → オンプレ DNS の IP へ転送
構築手順：4 ステップで完成
🔧 たとえ話：新しい交換機の設置手順
① 受付窓口（インバウンド EP）を設置 → ② 外線電話機（アウトバウンド EP）を設置 → ③ 転送先リスト（ルール）を作成 → ④ 東京本社にも「大阪の番号はこの受付に聞いて」と伝達。古い交換機（OSS リゾルバー）は撤去！
📥 インバウンドエンドポイントの作成
VPC 内にインバウンドエンドポイントを作成します。少なくとも 2 つの AZ に ENI を配置して高可用性を確保します。
aws route53resolver create-resolver-endpoint \
--name "hybrid-inbound-ep" \
--direction INBOUND \
--security-group-ids "sg-0abc1234def56789" \
--ip-addresses \
SubnetId=subnet-aaaa1111,Ip=10.0.1.10 \
SubnetId=subnet-bbbb2222,Ip=10.0.2.10
📤 アウトバウンドエンドポイントの作成
VPC からオンプレミスへ DNS クエリを転送するためのエンドポイントを作成します。
aws route53resolver create-resolver-endpoint \
--name "hybrid-outbound-ep" \
--direction OUTBOUND \
--security-group-ids "sg-0abc1234def56789" \
--ip-addresses \
SubnetId=subnet-aaaa1111 \
SubnetId=subnet-bbbb2222
📋 転送ルールの作成（AWS → オンプレ）
corp.example.com ドメインの DNS クエリをオンプレミスの DNS リゾルバーに転送するルールを作成します。
aws route53resolver create-resolver-rule \
--name "forward-to-onprem" \
--rule-type FORWARD \
--domain-name "corp.example.com" \
--resolver-endpoint-id "rslvr-out-xxxxxxxxxxxx" \
--target-ips \
Ip=192.168.1.10,Port=53 \
Ip=192.168.1.11,Port=53
🏢 オンプレミス DNS の転送設定変更
オンプレミスの DNS サーバーで aws.example.com ドメインの条件付き転送先を、作成したインバウンドエンドポイントの IP アドレスに設定します。
// named.conf - 条件付き転送設定
zone "aws.example.com" {
type forward;
forwarders {
10.0.1.10; // Inbound EP - AZ-a
10.0.2.10; // Inbound EP - AZ-c
};
};
DNS 転送ルール まとめ表
| 方向 | クエリ対象ドメイン | 設定場所 | 転送先 | 使用エンドポイント |
|---|---|---|---|---|
| 🏢 → ☁️ | aws.example.com | オンプレ DNS | インバウンド EP の IP | 📥 インバウンド |
| ☁️ → 🏢 | corp.example.com | Route 53 Resolver ルール | オンプレ DNS の IP | 📤 アウトバウンド |
🔑 最重要ポイント：転送の「入口」と「出口」
オンプレ側から見ると「AWS の名前が知りたい → AWS に入れてもらう = インバウンド EP」。
AWS 側から見ると「オンプレの名前が知りたい → AWS から出ていく = アウトバウンド EP + 転送ルール」。
常に「AWS 視点」で IN / OUT を考えると間違えません。
Route 53 Resolver を使うメリット
🏠 たとえ話：自前の交換機 vs. 電話会社の交換機
OSS DNS リゾルバーは「自分でビルの地下室に交換機を置いて自分で管理する」状態。故障したら夜中でも修理に行かなきゃいけません。 Route 53 Resolver は「電話会社（AWS）が提供する交換サービスに切り替える」こと。メンテナンスも障害対応もプロにお任せ、あなたは電話帳（DNS レコード）を管理するだけです。
よくある質問（FAQ）
まとめ：覚えておくべき 3 行
EC2 / Lambda (VPC内) ──→ 📤 アウトバウンド EP ──→ オンプレ DNS (corp.example.com)
② アウトバウンド EP + 転送ルールでオンプレへクエリを送信
③ OSS リゾルバーを廃止して、マネージドサービスの恩恵を受ける