オンプレミスとAWSをまたぐDNS（ハイブリッドDNS）は、AWSの中でも特に「覚えることが多くて混乱する」テーマです。Inbound・Outbound・Resolverルール・プライベートホストゾーン（PHZ）・RAM……どれがどれだか分からなくなる。正直に書くと、私はSAPの学習でこのDNS項目を自己診断で0点から始めました。とどめに、本番形式の演習で「共有といえばRAM」と反射的に答えて事故っています。本記事は、私がその0点から抜け出した整理——ハイブリッドDNSは「向き(Inbound/Outbound)」と「共有対象」の2軸だけで決まる——を、実際にやらかした失敗とともに解説します。
1. 結論：ハイブリッドDNSは「向き」と「共有対象」の2軸で決まる
細部に入る前に、混乱を消す2つの軸を置きます。ハイブリッドDNSの設問は、突き詰めると毎回この2点しか聞いていません。
- 軸1：向き ― 誰が、誰の名前を解決したいか。オンプレがAWSの名前を引くなら Inbound（入ってくる）、AWSがオンプレの名前を引くなら Outbound（出ていく）。
- 軸2：共有対象 ― 何をマルチアカウントに配るか。Resolverルールを配るなら RAM、PHZを配るなら association authorization（PHZはRAMで共有できない）。
この2軸を分けて持つだけで、ハイブリッドDNSの引っかけはほぼ無力化されます。逆に、ここを混ぜるから事故ります（私がそうでした）。
2. 向き：オンプレ→AWSはInbound、AWS→オンプレはOutbound
最初の軸は「向き」です。IN＝AWSに入ってくる問い合わせ、OUT＝AWSから出ていく問い合わせ。主語を「誰が名前を引くのか」に固定すると、向きは一発で決まります。
オンプレ→AWS（AWSの私的名を引きたい）＝ Inbound
オンプレのサーバーが、AWS側のプライベートな名前（PHZの名前など）を解決したいケースです。これは問い合わせがAWSに入ってくるので Inbound Resolverエンドポイントを立てます。そして見落としがちなのがオンプレ側の設定——オンプレのDNSで、対象ドメインの問い合わせをInboundエンドポイントのIPへ条件付きフォワードする設定が必要です。AWS側にエンドポイントを置くだけでは終わりません。
AWS→オンプレ（オンプレの名前を引きたい）＝ Outbound
逆に、AWS上のリソースがオンプレの名前（社内ドメイン）を解決したいケース。問い合わせがAWSから出ていくので Outbound Resolverエンドポイント＋Resolverルール（転送ルール）を使い、対象ドメインの問い合わせをオンプレDNSへ転送します。「Outboundには転送ルールがセットで要る」と覚えておくと取りこぼしません。
3. 共有：ResolverルールはRAM、PHZはassociation authorization
2つ目の軸が「共有対象」です。ここに最大の罠があります。マルチアカウントで何かを共有するとき、つい「共有＝AWS RAM」と条件反射してしまう。ところが、共有する対象によって仕組みが割れます。
| 共有したいもの | 使う仕組み | 補足 |
|---|---|---|
| Resolverルール | AWS RAM | 複数アカウントへルールを配布。これは素直にRAM |
| プライベートホストゾーン(PHZ) | association authorization | PHZはRAMで共有できない |
PHZを別アカウントのVPCに関連付けるには、PHZ所有アカウントで create-vpc-association-authorization を実行し、相手アカウントで associate-vpc-with-hosted-zone を実行する、という2段階のassociation authorizationを踏みます。RAMの出る幕はありません。「ルール＝RAM／ゾーン＝association authorization」と対で覚えるのが、事故を防ぐ唯一のコツです。
4. 私がやらかした事故（実体験）
偉そうに整理していますが、私はここで派手に転びました。失点は2つ、しかも根っこは同じです。
- 「共有＝RAM」の脊髄反射：直前の設問で「Resolverルールの配布＝RAM」と正解した直後、次の「PHZを別アカウントのVPCに関連付ける手順は？」で、その残像のまま反射的にRAMと誤答。正解はassociation authorizationでした。
- 否定の地雷を読み飛ばした：その設問には「RAMとは別の仕組みで」という一文が入っていました。これを読み飛ばしたのが致命傷。正解を自分から消していたわけです。
対策はシンプルです。回答する前に、設問内の「否定・例外・〜とは別・〜以外」に丸を付ける。たった1動作ですが、「直前の正解を引きずる」本番頻出の罠を機械的に止められます。私はこの1動作を入れてから、同種の事故がゼロになりました。知識の穴ではなく読解の事故だと気づけたのが、0点項目を抜け出せた転機でした。
まとめ
ハイブリッドDNSは「向き」と「共有対象」の2軸。オンプレ→AWSはInbound（＋オンプレ側で条件付きフォワード）、AWS→オンプレはOutbound（＋Resolverルール）。共有はResolverルール＝RAM、PHZ＝association authorization（RAM不可）。そして「共有＝RAM」の反射と否定文の読み飛ばしに注意する。この2軸＋1動作で、DNSの引っかけはもう怖くありません。
マルチアカウント共有では、ここで出てきた「RAMで配るもの／そうでないもの」の区別が他のサービスでも効いてきます。Transit Gatewayのルートテーブル設計（associationとpropagation）も同じ「共有・配布」の発想でつながるので、合わせてどうぞ。学習の全体像はまとめページから追えます。