SAA / SAP 攻略ナビ
ホーム ネットワーク接続

ハイブリッド DNS — Route 53 Resolver とオンプレミス連携

Route 53 Resolver のインバウンド/アウトバウンドエンドポイント、オンプレミス DNS との双方向解決、ハイブリッド DNS アーキテクチャを SAA 基礎から SAP 高度設計まで解説。

最終更新: 2026-07-27 カテゴリ: ネットワーク接続

ハイブリッドクラウド環境では、AWS リソースとオンプレミスリソースが相互に名前解決 できる必要があります。 AWS 側は Route 53 Resolver、オンプレミス側は Active Directory DNS などを連携させます。 本記事ではハイブリッド DNS の設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

ハイブリッド DNS の課題

VPC には AWS 提供の DNS サーバー (Route 53 Resolver) が VPC+2 番地（例: 10.0.0.2）にあります。 しかしデフォルトでは以下の制約があります：

  • パブリック DNS 名: 解決可能
  • VPC 内のプライベートホストゾーン: 解決可能
  • オンプレミスのプライベート DNS 名: 解決不可（オンプレミス DNS に問い合わせられない）

SAA レベル：基礎概念

ハイブリッド DNS の課題は 「AWS の Resolver がオンプレミスのプライベート DNS に問い合わせられない」 点です。 逆にオンプレミス DNS から AWS のプライベートホストゾーンも解決できません。 この双方向のギャップを埋めるのが Route 53 Resolver のエンドポイントです。

Route 53 Resolver エンドポイント

Route 53 Resolver には 2 種類のエンドポイント があります。

エンドポイント種別方向用途
Inbound Endpointオンプレミス → AWSオンプレミスから AWS プライベート DNS を解決
Outbound EndpointAWS → オンプレミスAWS からオンプレミス DNS を解決
[オンプレミス DNS]                   [AWS VPC]
       │                                │
       │ (問い合わせ)                   │
       ▼                                │
  Inbound Endpoint ───────────── Route 53 Resolver
                                        │
                                        │ (転送ルール)
                                        ▼
  Outbound Endpoint ───────────── [オンプレミス DNS]

SAA 試験のポイント

  • Inbound = オンプレミスから AWS の名前を引く
  • Outbound = AWS からオンプレミスの名前を引く この 方向の覚え方 が SAA の定番です。「AWS 側から見て入ってくるか出ていくか」で判断します。

転送ルール (Forwarding Rule)

Outbound Endpoint を使うには 転送ルール を定義します。 これは「このドメインの問い合わせはオンプレミス DNS に転送せよ」という設定です。

ドメイン転送先意味
corp.example.comオンプレミス DNS (10.0.0.53)社内ドメインはオンプレミスへ
aws.example.comRoute 53 PHZAWS 側ドメインはそのまま
その他パブリック DNSインターネット名前解決

プライベートホストゾーン (PHZ)

Private Hosted Zone (PHZ) は VPC 内でのみ有効な DNS ゾーンです。

  • VPC に 関連付け することで有効化
  • 同じドメイン名でもパブリックホストゾーンとは独立
  • 複数 VPC に関連付け可能（クロスアカウントも対応）

SAA 頻出

プライベートホストゾーンは VPC に「関連付け」が必要 です。 関連付けないと、DNS レコードを定義していても VPC 内で解決できません。 この「関連付け」ステップは SAA の頻出ポイントです。

SAP レベル：高度な設計シナリオ

双方向ハイブリッド DNS 設計

SAP では AWS ⇔ オンプレミスの双方向名前解決 を設計します。

SAP レベル：高度な設計シナリオ

実務では 「Inbound と Outbound の両方を構成する双方向ハイブリッド DNS」 が基本です。

  • AWS から onprem.corp.internal を引く → Outbound + 転送ルール
  • オンプレミスから api.aws.internal を引く → Inbound + PHZ この双方向構成を設計できるかが SAP の核心論点です。
[オンプレミス AD DNS]
  - corp.internal ゾーン管理
  - オンプレミスホストのレコード
       │ ▲
       │ │ (オンプレミス → AWS の問い合わせ)
       ▼ │
[AWS VPC]
  Inbound Endpoint (10.0.0.10, 10.0.1.10)
       │
  Route 53 Resolver
       │
  PHZ: aws.internal (AWS リソースのレコード)
       │
  Outbound Endpoint (10.0.0.20, 10.0.1.20)
       │
       ▼ (AWS → オンプレミスの問い合わせ)
[オンプレミス AD DNS]

Active Directory 統合

オンプレミスに Active Directory (AD) がある場合、 AWS 側に AWS Managed Microsoft AD を構築して AD トラスト を結ぶ設計がよく取られます。

構成説明ユースケース
AWS Managed AD (単体)AWS 内に独立 ADクラウドネイティブ
AD トラスト (Forest Trust)オンプレミス AD と信頼関係既存 AD 活かす
AD Connectorオンプレミス AD へのプロキシ軽量統合

AD 統合の DNS 論点

AD トラストを結ぶと DNS の条件付きフォワーダ (Conditional Forwarder) が自動設定され、 双方向の名前解決が可能になります。ただし 転送ルールの競合 に注意し、 Route 53 Resolver の転送ルールと AD 側のフォワーダが矛盾しない設計が必要です。

マルチ VPC / マルチアカウントでの PHZ 共有

複数 VPC / 複数アカウントで同じプライベートドメインを解決したい場合、 1 つの PHZ を複数 VPC に関連付け ます。

  • 同一アカウント内: PHZ に複数 VPC を直接関連付け
  • クロスアカウント: AWS RAM で PHZ の関連付けを共有
  • 共有サービスアカウントに集約: 共有サービスアカウントで PHZ を一元管理
[共有サービスアカウント]
  └── PHZ: internal.corp
        ├── VPC-A (本番アカウント) ← RAM 共有
        ├── VPC-B (開発アカウント)  ← RAM 共有
        └── VPC-C (共有サービス)    ← 直接関連付け

RAM 共有の落とし穴

PHZ の クロスアカウント共有には AWS RAM が必要 ですが、 RAM 共有は 組織内 (Organizations 内) または招待ベース です。 組織外のアカウントと共有する場合は招待を送る必要があり、この手順を忘れると 「VPC に関連付けたのに名前解決できない」というトラブルになります。

Resolver エンドポイントの冗長化

Resolver エンドポイントは 複数 AZ に ENI を配置 して冗長化します。

設計要素推奨理由
ENI の AZ 数2 AZ 以上AZ 障害対応
オンプレミス DNS サーバー2 台以上サーバー障害対応
転送ルールのターゲット複数 IP単一障害点回避

冗長化のベストプラクティス

Inbound/Outbound それぞれ 2 AZ に ENI を置き、転送ルールは複数のオンプレミス DNS を指定 します。 これで AZ 障害、ENI 障害、DNS サーバー障害のいずれにも耐えられます。 SAP ではこの完全冗長構成が求められます。

ハイブリッド DNS のトラブルシュート

よくある問題と対策：

症状原因対策
AWS からオンプレミス名が引けない転送ルール未設定 / Outbound 未配置転送ルールと Outbound ENI を確認
オンプレミスから AWS 名が引けないInbound 未配置 / PHZ 関連付け漏れInbound と PHZ 関連付けを確認
一部 VPC でだけ解決できないPHZ の RAM 共有未完了RAM 共有の招待承認を確認
VPC DNS サポート無効化enableDnsSupport が falseVPC 設定で DNS サポート有効化

enableDnsSupport / enableDnsHostnames

VPC の enableDnsSupport が無効だと Route 53 Resolver 自体が動作しません。 また enableDnsHostnames はパブリック IP 付き EC2 の DNS 名付与に影響します。 これらの VPC 設定がハイブリッド DNS の前提となる点を SAP では押さえます。

DNS キャッシュと TTL 設計

ハイブリッド環境では DNS TTL (Time To Live) の設計が重要です。

  • 短 TTL: 変更伝播が速いがクエリ負荷増
  • 長 TTL: クエリ負荷低減だが変更伝播が遅い
  • フェイルオーバ時: TTL が長いと古い IP に引き続ける

DR 時の DNS 設計

ディザスタリカバリで DNS を切り替える場合、TTL を短く設定 しておかないと クライアントが古い IP をキャッシュし続け、フェイルオーバーが遅延します。 DR シナリオの DNS は 60 秒以下の短 TTL が SAP の定石です。

制約と考慮事項

項目制約
Resolver エンドポイント AZ2 AZ 以上推奨
1 VPC あたり PHZ 関連付け50（クォータ拡張可）
転送ルールドメイン単位で定義
クロスアカウント共有AWS RAM 経由

まとめ

  • SAA: Inbound / Outbound の方向、PHZ の VPC 関連付け、転送ルールの基本を理解する。
  • SAP: 双方向ハイブリッド DNS、AD 統合、マルチアカウント PHZ 共有、 冗長化、DR 時の TTL 設計が求められる。

次は Cloud WAN とグローバルネットワーク設計 で、より大規模なグローバル展開を学びましょう。

スポンサーリンク（広告枠） 728×90

関連記事