🎯 結論：この組み合わせで何ができる？
VPC内のリソースが、オンプレミスのDNSサーバーで管理されているドメイン名を解決できるようになります！
オンプレミスドメイン解決
VPCのEC2から「server.corp.local」のようなプライベートドメインにアクセス可能
セキュアな通信
VPNトンネル経由でDNSクエリも暗号化されて安全に転送
ハイブリッド環境の統合
クラウドとオンプレミスを1つのネットワークのように運用
🏢 会社の内線電話で例えると超わかりやすい！
本社（オンプレミス）
内線番号簿（DNSサーバー）があり、
「田中さん → 内線1234」
「会議室A → 内線5678」
のように名前で電話できる
新設の支社（AWS VPC）
本社の内線番号簿を持っていないので、
「田中さんに電話して」と言われても
番号がわからない😢
💡 解決策：専用回線 + 内線転送システム
Site-to-Site VPN = 本社と支社をつなぐ専用の内線回線
Route 53 Resolver アウトバウンドエンドポイント = 「本社の番号簿を見て！」と問い合わせを転送する窓口
これで支社（VPC）からも「田中さん」と言えば本社の番号簿で調べて電話できる！🎉
🏗️ アーキテクチャ全体図
オンプレミス環境
DNSサーバー
corp.local ドメインを管理
Customer Gateway
VPN接続の終端装置
オンプレミスサーバー
server.corp.local
VPN
IPsecトンネル
この経路で転送
AWS VPC
Virtual Private Gateway
VPN接続のAWS側終端
Route 53 Resolver
アウトバウンドエンドポイント
DNSクエリの転送窓口
転送ルール
「corp.local」→オンプレミスDNSへ
EC2インスタンス
server.corp.localにアクセスしたい
🔄 DNSクエリの流れ（4ステップ）
EC2からDNSクエリ
EC2が「server.corp.local」のIPアドレスを問い合わせ
アウトバウンドエンドポイントが受信
転送ルールに基づき、corp.localドメインをオンプレミスDNSへ転送
VPNトンネル経由で転送
暗号化されたVPNトンネルを通じてオンプレミスDNSサーバーへ
IPアドレスを返却
オンプレミスDNSがIPを返し、EC2がサーバーに接続可能に
🧩 主要コンポーネントの役割
Site-to-Site VPN
オンプレミスとAWS VPCを暗号化されたIPsecトンネルで接続する「専用回線」
- インターネット経由でも安全に通信
- 2つのトンネルで冗長性確保
- DNSトラフィックもこの経路で転送
Route 53 Resolver アウトバウンドエンドポイント
VPC内のDNSクエリを外部（オンプレミス）のDNSサーバーに転送する「問い合わせ窓口」
- VPCのサブネット内にENIとして作成
- 複数AZに配置して高可用性を実現
- 転送ルールと組み合わせて使用
転送ルール（Forwarding Rules）
「このドメインはここに転送して」という指示書
- ドメイン名（corp.local）を指定
- 転送先DNSサーバーのIPを設定
- 複数VPCで共有可能（RAM経由）
Virtual Private Gateway (VGW)
VPN接続のAWS側の「入口」
- VPCにアタッチして使用
- Customer Gatewayと対になる
- ルートテーブルでルーティング設定
⚙️ 設定手順（6ステップ）
Customer Gateway作成
オンプレミスのVPN機器の情報を登録。パブリックIPアドレスとBGP ASNを設定。
Virtual Private Gateway作成・アタッチ
VGWを作成し、VPCにアタッチ。これがAWS側のVPN終端点になります。
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-xxx --vpc-id vpc-xxx
Site-to-Site VPN接続作成
CGWとVGWを接続するVPNコネクションを作成。設定をダウンロードしてオンプレミス機器に適用。
アウトバウンドエンドポイント作成
Route 53 Resolverのアウトバウンドエンドポイントを作成。複数AZに配置して高可用性を確保。
転送ルール作成
「corp.local」ドメインをオンプレミスDNSサーバーに転送するルールを作成。
転送先: オンプレミスDNSのIP（例：10.0.0.53）
ルートテーブル・セキュリティグループ設定
VPCのルートテーブルにオンプレミスへのルートを追加。DNS通信（UDP 53）を許可。
SG: UDP 53 outbound to 10.0.0.53
💼 こんな場面で活躍！
ハイブリッドクラウド移行
段階的なクラウド移行中、オンプレミスの既存システムとAWSの新システムが相互に通信する必要がある場合
Active Directory連携
オンプレミスのActive Directoryドメインに参加するEC2インスタンスのドメイン解決
既存システム連携
オンプレミスのERPやCRMなどの基幹システムとAWSアプリケーションの連携
📊 インバウンドvsアウトバウンドエンドポイント比較
| 項目 | アウトバウンドエンドポイント | インバウンドエンドポイント |
|---|---|---|
| 方向 | VPC → オンプレミス | オンプレミス → VPC |
| 用途 | VPCからオンプレミスドメインを解決 | オンプレミスからVPCドメインを解決 |
| 転送先 | オンプレミスDNSサーバー | Route 53 Resolver（VPC+2） |
| 転送ルール | ✅ 必須 | ❌ 不要 |
| プライベートホストゾーン | 関係なし | 解決可能にする |
| 今回の構成での役割 | ✅ 使用 | （双方向なら追加） |
💡 ベストプラクティス & Tips
🔄 高可用性の確保
アウトバウンドエンドポイントは必ず2つ以上のAZに作成。オンプレミスDNSサーバーも複数台を転送先に指定しましょう。
🔒 セキュリティグループ設定
エンドポイントのセキュリティグループでUDP 53（DNS）のアウトバウンドをオンプレミスDNSサーバーのIPに限定。
📊 CloudWatchでモニタリング
Route 53 Resolverのクエリログを有効化して、DNS解決の成功・失敗をモニタリング。問題の早期発見に役立ちます。
🌐 複数VPCでの共有
転送ルールはRAM（Resource Access Manager）で他のVPCやアカウントと共有可能。組織全体で一元管理できます。
🎓 まとめ
🏢 会社の内線電話システム = ハイブリッドDNS
Site-to-Site VPNは「本社と支社をつなぐ専用回線」
Route 53 Resolver アウトバウンドエンドポイントは「本社に問い合わせる窓口」
この組み合わせで、VPCからオンプレミスのプライベートドメインを解決！