Route 53 Resolver ハイブリッドDNS設計パターン4選|SAA-C03 頻出 オンプレ↔AWS の名前解決を完全攻略
AWS SAA-C03 で頻出の Route 53 Resolver によるハイブリッド DNS 設計を完全整理。オンプレミスから AWS プライベートホストゾーンを解決する Inbound Endpoint・AWS から社内 DNS を解決する Outbound Endpoint・双方向ハイブリッド DNS・Resolver DNS Firewall の4パターンを体系化。試験シナリオを解法パターンで即断できる粒度まで分解する。
「Route 53 はドメインと 7 種類のルーティングポリシーだけ覚えれば良い、と思ったら大間違い。SAA-C03 のハイブリッド設計問題では Route 53 Resolver の Inbound/Outbound Endpoint が核心になる。オンプレ↔AWS の DNS 通信フローを図で描けない受験者は、この問題群で確実に失点する」 — 本記事では SAA-C03 頻出の Route 53 Resolver を使ったハイブリッド DNS 設計パターン4選を体系化し、Inbound/Outbound の区別から DNS Firewall まで、試験シナリオを即断できる粒度まで分解する。
※ 本記事はアフィリエイト広告(Amazon アソシエイト等)を含みます
📑 目次
- 結論:Route 53 Resolver の選択軸
- Route 53 Resolver の基本構造
- パターン1:Inbound Endpoint(オンプレ→AWS の名前解決)
- パターン2:Outbound Endpoint(AWS→オンプレの名前解決)
- パターン3:双方向ハイブリッド DNS(Inbound + Outbound 同時構成)
- パターン4:Route 53 Resolver DNS Firewall(マルウェアドメイン遮断)
- Resolver ルール共有(RAM)とマルチアカウント設計
- 試験頻出シナリオ → 解法パターン早見表
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論:Route 53 Resolver の選択軸
Route 53 Resolver は、AWS VPC と外部ネットワーク(オンプレミス・他 VPC)の間で DNS クエリを橋渡しするマネージドサービスだ。基本の Route 53(7 種類のルーティングポリシー)とは別レイヤーで動作する。
Route 53 Resolver が必要な2つの方向:
| 方向 | エンドポイント | 用途 |
|---|---|---|
| オンプレ → AWS | Inbound Endpoint | 社内クライアントが AWS プライベートホストゾーン(例:app.internal)を解決 |
| AWS → オンプレ | Outbound Endpoint | EC2 が社内 DNS サーバー(例:corp.example.local)を解決 |
2. Route 53 Resolver の基本構造
エンドポイントとは
Resolver Endpoint は、VPC 内の ENI(Elastic Network Interface)の集合体だ。ENI が実際の DNS クエリを受け取るか転送するかを決める。
- 各エンドポイントは 2つ以上の AZ に ENI を持つ(高可用性設計)
- 各 ENI にはプライベート IP アドレスが割り当てられる
- ENI への通信は VPN / Direct Connect を経由したプライベートネットワークで行う
オンプレミス DC
├─ DNS サーバー(10.0.0.53)
│ ↕ DNS クエリ(UDP/TCP 53)
│ Site-to-Site VPN または Direct Connect
│
AWS VPC
├─ Resolver Inbound Endpoint(ENI: 10.10.0.5, 10.10.1.5)
└─ Resolver Outbound Endpoint(ENI: 10.10.0.6, 10.10.1.6)
Resolver ルール(Forwarding Rule)
Outbound Endpoint は単体では機能しない。どのドメインをどこへ転送するかを定める「転送ルール(Forward Rule)」が必要だ。
| ルール種別 | 動作 |
|---|---|
| Forward ルール | 指定ドメインのクエリを特定の IP アドレス(オンプレ DNS 等)へ転送 |
| System ルール | AWS 内のデフォルト動作(amazonaws.com の解決など)を上書き |
| Recursive ルール | デフォルト:Route 53 Resolver が再帰的に解決(インターネット DNS) |
3. パターン1:Inbound Endpoint(オンプレ→AWS の名前解決)
シナリオ:オンプレミスのアプリケーションサーバーが、AWS 上の RDS のプライベートエンドポイント(db.app.internal)を解決したい。
オンプレ DNS サーバー
→ Resolver Inbound Endpoint(ENI IP: 10.10.0.5)
→ Route 53 プライベートホストゾーン(app.internal)
→ RDS エンドポイント(10.20.5.100)
設定ステップ:
- VPC に Inbound Endpoint を作成(2 AZ 以上に ENI 配置)
- Route 53 プライベートホストゾーン(
app.internal)を VPC に関連付け - オンプレミス DNS サーバーに**条件付き転送(Conditional Forwarder)**を設定
app.internal→ Inbound Endpoint の ENI IP(10.10.0.5, 10.10.1.5)
AWS 側の設定は Inbound Endpoint の作成とホストゾーン関連付けのみ。オンプレ側の Conditional Forwarder 設定を忘れると解決できない。
4. パターン2:Outbound Endpoint(AWS→オンプレの名前解決)
シナリオ:AWS 上の EC2 が、社内 Active Directory の DNS 名(fileserver.corp.example.local)を解決したい。
EC2(VPC 内)
→ Route 53 Resolver(VPC デフォルト DNS: 169.254.169.253)
→ Outbound Endpoint(転送ルール: corp.example.local → 10.0.0.53)
→ オンプレ DNS サーバー(10.0.0.53)
→ 応答(fileserver.corp.example.local = 10.0.1.200)
設定ステップ:
- VPC に Outbound Endpoint を作成(2 AZ 以上に ENI 配置)
- **転送ルール(Forward Rule)**を作成:
- ドメイン名:
corp.example.local - 転送先 IP:オンプレ DNS サーバーのアドレス(例:
10.0.0.53)
- ドメイン名:
- 転送ルールを対象 VPC に関連付け(Associate)
転送ルールの優先度
VPC に複数の転送ルールが関連付けられている場合、**最も長いプレフィックス(longest prefix match)**が優先される。
| ルール | ドメイン | 優先度 |
|---|---|---|
| ルール A | example.local | 低(短い) |
| ルール B | corp.example.local | 高(長い・具体的) |
5. パターン3:双方向ハイブリッド DNS
シナリオ:Direct Connect 接続の大規模ハイブリッド環境で、オンプレ↔AWS 双方向の DNS 解決を実現する。
AWS VPC
├─ Inbound Endpoint(ENI: 10.10.0.5)
│ ← オンプレから app.internal クエリを受け取る
└─ Outbound Endpoint(ENI: 10.10.0.6)
→ オンプレへ corp.example.local クエリを転送
Route 53 プライベートホストゾーン:app.internal(VPC 関連付け済み)
転送ルール:corp.example.local → 10.0.0.53(オンプレ DNS)
オンプレ DNS サーバー(10.0.0.53)
├─ Conditional Forwarder: app.internal → 10.10.0.5(Inbound ENI)
└─ 社内レコード: fileserver.corp.example.local = 10.0.1.200
設計原則:
- Inbound と Outbound は別々のエンドポイントとして作成する(同一 ENI の共用は不可)
- 両エンドポイントともに高可用性のため 2 AZ 以上に ENI を配置
- Direct Connect や VPN を経由してオンプレ DNS との ポート 53 通信を許可するセキュリティグループ設定が必須
6. パターン4:Route 53 Resolver DNS Firewall(マルウェアドメイン遮断)
シナリオ:VPC 内の EC2 がマルウェアに感染し、C2(Command & Control)サーバーへの DNS クエリを送信するリスクを防ぎたい。
Route 53 Resolver DNS Firewall は、VPC 内の DNS クエリを検査してブロック・許可・アラートを設定するセキュリティレイヤーだ。
EC2(感染済み)
→ Route 53 Resolver(DNS クエリ: malicious-c2.example.com)
→ DNS Firewall(ルールグループを検査)
→ BLOCK: NODATA / NXDOMAIN を返す(マルウェアの通信を遮断)
主要コンポーネント:
| コンポーネント | 説明 |
|---|---|
| ドメインリストグループ | AWS 管理の脅威インテリジェンスリスト(マルウェア・フィッシング)、またはカスタムリストを定義 |
| ルールグループ | ドメインリストとアクション(BLOCK/ALLOW/ALERT)を紐付けたルールの集合体 |
| アクション: BLOCK | 指定応答(NODATA/NXDOMAIN/Override)を返し、実際のクエリをキャンセル |
| アクション: ALERT | クエリを通過させつつ CloudWatch Logs に記録(監視用途) |
| アクション: ALLOW | 許可リスト(BLOCK ルールの例外として使用) |
7. Resolver ルール共有(RAM)とマルチアカウント設計
大規模な AWS 環境では、複数アカウントが同じ Outbound Endpoint と転送ルールを使う。毎アカウントに同じエンドポイントを作ると管理コストが増大する。
AWS RAM(Resource Access Manager)でルールを共有する:
共有サービスアカウント(Network Hub)
├─ Outbound Endpoint(ENI: 10.10.0.6)
├─ 転送ルール(corp.example.local → 10.0.0.53)
└─ RAM でルールを Organization 内の他アカウントへ共有
↓
子アカウント A(VPC に転送ルールを関連付けるだけで利用可能)
子アカウント B(同上)
設計のポイント:
- 共有されるのは転送ルールのみ(Endpoint 自体は共有アカウントが所有・管理)
- 子アカウント側では「転送ルールを VPC に関連付け」する操作だけで利用開始できる
- 共有サービスアカウントを Transit Gateway Hub と同じアカウントに置くと DNS・ルーティング管理を一元化できる
8. 試験頻出シナリオ → 解法パターン早見表
| シナリオ(問題文のキーワード) | 正解パターン |
|---|---|
| 「オンプレのサーバーが AWS プライベートホストゾーンを解決できない」 | Inbound Endpoint + オンプレ Conditional Forwarder |
| 「AWS EC2 が社内 Active Directory / オンプレ DNS を解決できない」 | Outbound Endpoint + Forward Rule(VPC 関連付け忘れに注意) |
| 「オンプレ↔AWS の双方向 DNS 解決が必要」 | Inbound + Outbound 両方 作成 |
| 「VPC 内の EC2 のマルウェア DNS 通信を自動ブロックしたい」 | Route 53 Resolver DNS Firewall |
| 「マルウェア DNS を検知・ログに記録したいが通信は通したい」 | DNS Firewall の ALERT アクション |
| 「GuardDuty で脅威を検知後、自動でブロックしたい」 | GuardDuty + EventBridge → Lambda → DNS Firewall 更新 |
| 「複数アカウントで同じオンプレ DNS 転送ルールを使いたい」 | RAM で転送ルールを共有 |
| 「Resolver ルールを作ったが VPC の EC2 からオンプレを解決できない」 | 転送ルールを VPC に関連付けていない(Associate 漏れ) |
| 評価項目 | Inbound Endpoint | Outbound Endpoint |
|---|---|---|
| DNS クエリの方向 | オンプレ → AWS | AWS → オンプレ |
| オンプレ側の設定 | Conditional Forwarder(DNS → Endpoint IP) | 不要(AWS 側で転送ルールを設定) |
| AWS 側の設定 | エンドポイント作成(ENI 自動割り当て) | エンドポイント作成 + 転送ルール作成 + VPC 関連付け |
| 解決できるドメイン | Route 53 プライベートホストゾーン・VPC 内 DNS | オンプレ DNS の保有ドメイン |
| 組み合わせるサービス | Route 53 プライベートホストゾーン | オンプレ AD / 社内 DNS |
9. 次のアクション チェックリスト
- Inbound と Outbound の方向を図で描いて区別できるか確認する
- Outbound Endpoint 作成後に「転送ルールの VPC 関連付け」を忘れないよう手順を整理する
- DNS Firewall の BLOCK / ALLOW / ALERT アクションの使い分けを覚える
- RAM を使ったマルチアカウント転送ルール共有の設計フローを把握する
- GuardDuty と Resolver DNS Firewall の役割(検知 vs 遮断)を整理する
10. 関連記事
- Amazon Route 53 完全ガイド|DNS・ヘルスチェック・トラフィック管理
- Route 53 ルーティングポリシー 7 種完全解説
- SAA ハイブリッドクラウド設計パターン
- SAA Transit Gateway & Direct Connect 設計パターン4選
- SAA マルチアカウント設計パターン5選
- SAA ネットワークセキュリティ設計パターン4選
- Amazon VPC 完全ガイド