オンプレミスのサーバーとAWSのVPCを接続したとき、こんな問題が起きることがありませんか？
ネットワーク的にはつながっているのに、名前解決だけができない問題です。
このDNSの橋渡し役を担うのが Amazon Route 53 Resolver です。
今回はRoute 53 ResolverとProfilesの役割を、基本のDNSの仕組みからざっくり解説します。
- そもそもDNSとは ドメイン名をIPアドレスに変換する仕組み
- AWS Route 53 Resolverとは VPCのDNS問い合わせを制御するサービス
- Resolverの機能① インバウンドエンドポイント オンプレからAWSへのDNS問い合わせを受け取る
- Resolverの機能② アウトバウンドエンドポイントと転送ルール AWSからオンプレへDNSを問い合わせる
- Resolverの機能③ DNS Firewallで悪意のあるドメインへのアクセスをブロック
- Route 53 Resolverが必要になる場面 ハイブリッドクラウドの典型ケース
- Route 53 Profilesとは Resolverの設定を複数VPCにまとめて配布する仕組み
- Route 53 Profilesに含められる設定の種類
- Profilesがない場合とある場合の比較 設定作業がどう変わるか
- 複数アカウントをまたいでProfileを共有する方法
- Route 53 Profilesが役立つ場面 こんな環境で効果が出る
- Route 53 ResolverとProfilesの使い分け まずResolverを理解してからProfilesへ
そもそもDNSとは ドメイン名をIPアドレスに変換する仕組み
DNSは「Domain Name System」の略。
人間が読めるドメイン名（例：example.com）をコンピューターが通信に使うIPアドレス（例：203.0.113.1）に変換する仕組みです。
電話帳に名前と番号が載っているように、DNSは名前とIPアドレスの対応を管理します。
ブラウザにURLを入力すると、裏側でDNSサーバーへの問い合わせが自動的に行われ、接続先のIPアドレスが返ってきます。
この「名前を問い合わせてIPを返す」処理を担うサーバーが「DNSリゾルバー」です。
AWS Route 53 Resolverとは VPCのDNS問い合わせを制御するサービス
Amazon Route 53 Resolver は、AWS VPC内でのDNS問い合わせを管理・制御するサービスです。
VPCとオンプレミス環境の間でDNS問い合わせを相互に転送する「ハイブリッドDNS」の構築が主な用途です。
VPCには最初からDNSリゾルバーが内蔵されている
実はAWSのVPCを作成すると、最初から「VPC内部のDNSリゾルバー」が自動的に用意されます。
VPCのCIDRブロックの最初のIPアドレス＋2（例：10.0.0.2）がそのアドレスです。
EC2インスタンスを立てると、このリゾルバーを使ってAWSのサービス名（s3.amazonaws.comなど）やVPC内のプライベートホスト名を解決できます。
ただし、この内蔵リゾルバーは「VPCの外からは直接使えない」という制約があります。
オンプレミスのサーバーから「AWS側のプライベートDNS名を解決したい」という場合、この内蔵リゾルバーへ直接問い合わせを送ることができません。
そこでRoute 53 Resolverの出番になります。
Resolverの機能① インバウンドエンドポイント オンプレからAWSへのDNS問い合わせを受け取る
「インバウンドエンドポイント」は、オンプレミスのDNSサーバーからAWS側へDNS問い合わせを送るための入口です。
インバウンドエンドポイントを作成すると、VPC内にIPアドレスが割り当てられます。
オンプレ側のDNSサーバーに「aws.example.com というドメインの問い合わせはこのIPに転送する」という設定を加えるだけで、オンプレミスのサーバーがAWS上のプライベートホスト名を解決できるようになります。
たとえばAWS上のRDSデータベースに社内システムからアクセスしたい場合、RDSのエンドポイント名（プライベートDNS名）をオンプレから解決できるようになります。
Resolverの機能② アウトバウンドエンドポイントと転送ルール AWSからオンプレへDNSを問い合わせる
「アウトバウンドエンドポイント」は逆方向、つまりAWS側からオンプレミスのDNSサーバーへ問い合わせを送るための出口です。転送ルール（Forwarding Rule）と組み合わせて使います。
転送ルールでは「このドメイン名の問い合わせはオンプレのDNSサーバーに転送する」という設定を定義します。
たとえば「corp.example.com というドメインへの問い合わせは、オンプレのDNSサーバー（192.168.1.53）に転送する」という設定を入れると、AWS上のEC2やLambdaから社内システムのホスト名を解決できるようになります。
転送ルールはAWS Resource Access Manager（RAM）を使って複数のVPCで共有することもできます。
RAMを使うと「同じ転送設定を10個のVPCにそれぞれ作る」という手間が省けます。
Resolverの機能③ DNS Firewallで悪意のあるドメインへのアクセスをブロック
Route 53 ResolverにはDNS Firewall（ファイアウォール）機能も含まれています。
VPC内のリソースが悪意のあるドメインへ名前解決しようとした際に、それをブロックまたは警告する仕組みです。
マルウェアに感染したEC2インスタンスが、攻撃者のC2サーバー（指令サーバー）に接続しようとするとき、最初にDNSで名前解決を行う場合がほとんどです。
DNS Firewallでその段階でブロックすることで、外部への不正通信を未然に防ぎます。
AWSはマネージドドメインリスト（既知の悪意あるドメインのリスト）を提供しており、自分でリストを管理しなくてもすぐに使い始めることができます。
もちろん、カスタムリストを追加することも可能です。
Route 53 Resolverが必要になる場面 ハイブリッドクラウドの典型ケース
Route 53 Resolverは、以下のような場面で特に使えると思います。
Route 53 Resolverはハイブリッドクラウド環境の「DNS配管工事」ともいえる存在です。ネットワークはつながっているのに名前解決だけうまくいかない、という状況の多くがResolverの設定で解決できます。
Route 53 Profilesとは Resolverの設定を複数VPCにまとめて配布する仕組み
Resolverを使い始めると、VPCが増えるにつれて「同じ設定を何度も作る」手間が生じます。
Resolverの転送ルールやDNS Firewallのルールグループを、VPCのたびに手作業で設定するのはミスが起きやすく、管理も大変です。
Route 53 Profiles はその繰り返しをなくすための仕組みです。DNS設定をひとまとめにして、複数のVPCに一括で配布できます。
Route 53 Profilesに含められる設定の種類
1つのProfileには以下の設定をまとめて含めることができます。
- Resolver転送ルール：特定ドメインの問い合わせをオンプレのDNSサーバーに転送するルール
- DNS Firewallルールグループ：悪意のあるドメインをブロックするルールのセット
- プライベートホストゾーン：VPC内部専用のDNSレコード（例：internal.example.com）
これらをProfileとしてひとまとめにしておき、必要なVPCに関連付けるだけで設定が反映されます。
Profilesがない場合とある場合の比較 設定作業がどう変わるか
VPCが10個ある環境で、全VPCに同じ転送ルール5本とDNS Firewallルールグループを適用したいケースで考えてみましょう。
Profilesなしの場合
転送ルール5本 × 10VPC = 50回の設定作業。
DNS Firewallも10VPC分。合計で大量の手作業が発生します。
新しいVPCを追加するたびに同じ作業を繰り返す必要があります。
Profileありの場合
転送ルール5本とDNS Firewallをまとめた「標準DNS Profile」を1つ作成。
10個のVPCそれぞれにそのProfileを関連付けるだけ（10回の操作）。
新しいVPCを追加するときも、Profileを関連付けるだけで完了します。
さらに、Profile内の設定を変更すると、関連付けられたすべてのVPCに自動的に反映されます。
「転送先のDNSサーバーのIPが変わった」というときも、Profileを1か所直すだけで済みます。
大分作業負荷が下がりますよね。
複数アカウントをまたいでProfileを共有する方法
Route 53 Profilesは AWS Resource Access Manager（RAM）と連携することで、複数のAWSアカウント間でProfileを共有できます。
組織のネットワークチームが「標準DNS Profile」を1つのアカウントで管理し、RAMを通じて各部署・プロジェクトのAWSアカウントに共有するという運用が可能です。
各チームはそのProfileを自分たちのVPCに関連付けるだけで、組織の標準DNS設定が適用されます。
個別のチームが勝手にDNS設定を変えてしまうリスクを減らしながら、標準化を進められるのが大きなメリットです。
Route 53 Profilesが役立つ場面 こんな環境で効果が出る
特に以下のような環境でProfilesの効果が大きく出そうです。
逆に、VPCが1〜2個しかない小規模な環境では、Profilesを使わずResolverを直接設定する方がシンプルです。
Route 53 ResolverとProfilesの使い分け まずResolverを理解してからProfilesへ
Route 53 Resolverは「DNSの制御そのもの」、Route 53 Profilesは「その設定を効率よく管理・配布するための仕組み」です。
Profilesだけでは動かず、Resolverの設定がベースにあってはじめてProfilesが意味を持ちます。
まずはRoute 53 Resolverでインバウンド・アウトバウンドエンドポイントや転送ルールの概念を理解し、それが複数のVPCに必要になったタイミングでProfilesの導入を検討するのがオススメの順番です。
どちらもAWSマネジメントコンソール・CLI・CloudFormationから設定できます。
VPCのDNS管理が複雑になってきたと感じたら、まずResolverの設定を整理してみるところから始めてみませんか？
