2026年6月9日

AWS Route 53 Resolver で複数ドメインを管理する方法｜転送ルールとエンドポイントでVPCの名前解決を整理する

DNS・名前解決

AWS Route 53 Resolver で複数のドメインを扱うときは、「どのドメインの問い合わせを、どこに解決させるか」をドメインごとの転送ルールとして定義し、そのルールを必要な VPC に関連付けます。社内 DNS にあるドメインは送信エンドポイント経由で転送し、AWS 側のプライベートホストゾーンは受信エンドポイント経由で社内から引けるようにする、という形が基本です。この記事では、Resolver の役割の整理、エンドポイントとルールの作り方、複数ドメイン・複数アカウントでの管理方法、動作の確かめ方を説明します。

最初に押さえておきたいのは、Route 53 Resolver は「問い合わせを解決する側（リゾルバー）」であり、ドメインのレコードを公開する権威 DNS ではないことです。インターネットに公開するドメインのレコードは Route 53 のパブリックホストゾーンで管理します。この記事で扱うのは、VPC 内のサーバーやオンプレミスの環境から見た「名前の引き方」の管理です。

Route 53 Resolver で管理するもの

VPC を作ると、その中には AWS が用意したリゾルバー（VPC の CIDR の先頭に2を足したアドレスや 169.254.169.253）が置かれ、EC2 などは標準でここに問い合わせます。このリゾルバーが Route 53 Resolver です。何も設定しなければ、次の順で答えを探します。

VPC に関連付けたプライベートホストゾーンにあるドメインは、そのゾーンの内容で答える
それ以外は、インターネット上の権威 DNS に問い合わせて答える

ここに、次の部品を足して複数ドメインを管理します。

部品	役割
送信エンドポイント（OUTBOUND）	VPC から社内 DNS など外部の DNS サーバーへ問い合わせを転送する出口
受信エンドポイント（INBOUND）	社内 DNS から VPC 側の名前（プライベートホストゾーンなど）を問い合わせる入口
転送ルール（FORWARD）	「このドメインはこの DNS サーバーへ転送する」という指定
システムルール（SYSTEM）	転送ルールの対象から特定のサブドメインを外し、Resolver 自身に解決させる指定

ルールは VPC に関連付けて初めて効きます。ルールを作っただけで関連付けを忘れると何も変わらないため、作成と関連付けを1組の作業として扱います。

設計：ドメインの一覧と行き先を表にする

作業の前に、扱うドメインと行き先を一覧にします。例として、次のような状況を考えます。

corp.example.com：社内の Active Directory が管理。社内の DNS サーバー（10.10.0.53、10.20.0.53）で解決する
legacy.example.net：データセンターの古いシステム用。別の DNS サーバー（10.30.0.53）で解決する
aws.example.com：AWS のプライベートホストゾーン。社内からも引けるようにしたい

ルールが重なるときは、より長く一致するドメイン（より具体的なドメイン）のルールが選ばれます。example.com 全体を社内に転送するルールと、aws.example.com を対象にしたルールが両方あれば、aws.example.com 配下の問い合わせには後者が使われます。転送ルールとプライベートホストゾーンが同じドメインを対象にしている場合の扱いも決まっていますが、設計の段階で重ならないようにしておくほうが、障害時に原因を追いやすくなります。優先順位の細かな規則は、AWS の公式ドキュメント（Resolver が問い合わせを処理する仕組みの項目）で確かめてください。

エンドポイントを作る

エンドポイントは時間単位の料金がかかるリソースで、料金や上限値は改定されることがあります（2026年10月現在）。作る数と場所は、料金ページとサービスクォータを確かめてから決めます。エンドポイントは、指定したサブネットにネットワークインターフェースを作り、そこを経由して DNS の通信をします。可用性のため、異なるアベイラビリティーゾーンのサブネットに2つ以上の IP アドレスを割り当てます。

セキュリティグループは、送信エンドポイントでは転送先の DNS サーバーへの TCP／UDP 53 番の送信を、受信エンドポイントでは社内ネットワークからの TCP／UDP 53 番の受信を許可します。DNS は応答が大きいと TCP に切り替わるため、UDP だけ許可していると一部の問い合わせだけ失敗する、という分かりにくい症状になります。

AWS CLI で送信エンドポイントを作る例です。ID やサブネットは自分の環境のものに置き換えます。

aws route53resolver create-resolver-endpoint \
  --creator-request-id outbound-main-202610 \
  --name outbound-main \
  --direction OUTBOUND \
  --security-group-ids sg-0123456789abcdef0 \
  --ip-addresses SubnetId=subnet-0aaa1111bbbb2222c SubnetId=subnet-0ddd3333eeee4444f

受信エンドポイントは --direction INBOUND にして同じように作ります。作成後に割り当てられた IP アドレスを、社内 DNS の条件付きフォワーダー（aws.example.com はこのアドレスへ転送する、という設定）に登録します。

ドメインごとに転送ルールを作って関連付ける

ルールは1ドメインに1つ作ります。転送先は複数指定でき、片方が応答しないときにもう一方へ問い合わせます。

aws route53resolver create-resolver-rule \
  --creator-request-id rule-corp-example-com \
  --name corp-example-com \
  --rule-type FORWARD \
  --domain-name corp.example.com \
  --resolver-endpoint-id rslvr-out-0123456789abcdef0 \
  --target-ips Ip=10.10.0.53,Port=53 Ip=10.20.0.53,Port=53

aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-0123456789abcdef0 \
  --vpc-id vpc-0123456789abcdef0

corp.example.com の中に、例外として AWS 側で解決させたいサブドメインがある場合は、そのサブドメインに SYSTEM ルールを作って同じ VPC に関連付けます。SYSTEM ルールには転送先もエンドポイントも指定しません。

ドメインが増えてくると、CLI を1件ずつ打つより、Terraform などでドメインの一覧から生成するほうが管理しやすくなります。

locals {
  forward_domains = {
    "corp.example.com"   = ["10.10.0.53", "10.20.0.53"]
    "legacy.example.net" = ["10.30.0.53"]
  }
}

resource "aws_route53_resolver_rule" "forward" {
  for_each             = local.forward_domains
  name                 = replace(each.key, ".", "-")
  domain_name          = each.key
  rule_type            = "FORWARD"
  resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id

  dynamic "target_ip" {
    for_each = each.value
    content {
      ip   = target_ip.value
      port = 53
    }
  }
}

resource "aws_route53_resolver_rule_association" "main_vpc" {
  for_each         = aws_route53_resolver_rule.forward
  resolver_rule_id = each.value.id
  vpc_id           = aws_vpc.main.id
}

ドメインの追加は map に1行足すだけになり、レビューでも「どのドメインがどこへ行くか」が一目で分かります。

複数アカウントで同じルールを使う

AWS Organizations で複数のアカウントを使っている場合、ネットワーク用のアカウントでエンドポイントとルールを作り、AWS Resource Access Manager（RAM）でルールを他のアカウントに共有する構成がよく使われます。共有を受けたアカウントは、自分の VPC にルールを関連付けるだけで済み、エンドポイントをアカウントごとに作らずに済みます。

この構成では、ルールの変更が共有先のすべての VPC に及びます。転送先の DNS サーバーを変えるといった変更は、影響範囲を確かめ、業務時間外に行うなど、本番の設定変更として扱います。

動作を確かめる

まず、VPC の DNS 属性（DNS 解決の有効化）がオンになっていることを確かめます。これがオフだと Resolver 自体が使われません。

次に、VPC 内の EC2 から、ドメインごとに引いてみます。

dig corp.example.com SOA +short
dig app.legacy.example.net A +short
dig aws.example.com SOA +short

意図した応答が返らない場合は、次の順で確かめると早く切り分けられます。

ルールがその VPC に関連付けられているか（aws route53resolver list-resolver-rule-associations）
ルールのドメイン名の綴りと、より具体的な別ルールが優先されていないか（aws route53resolver list-resolver-rules）
エンドポイントのセキュリティグループとネットワーク ACL で、TCP／UDP 53 番が通るか
VPN や Direct Connect の経路で、転送先の DNS サーバーまで届くか
転送先の DNS サーバーが、エンドポイントの IP アドレスからの問い合わせを許可しているか

問い合わせの記録を残したい場合は、Resolver のクエリログを有効にして CloudWatch Logs などに送ると、どのドメインがどのルールで処理されたかを後から追えます。ログの量が増えるため、対象の VPC と保存期間は用途に合わせて決めます。

まとめ

Route 53 Resolver は VPC の名前解決を担うリゾルバーで、公開するレコードはホストゾーンで管理する
複数ドメインは「ドメインごとの転送ルール＋VPC への関連付け」で管理し、例外は SYSTEM ルールで外す
エンドポイントは異なる AZ に2つ以上の IP を割り当て、TCP と UDP の 53 番を両方許可する
ドメインと行き先の一覧をコード（Terraform の map など）にすると、追加とレビューが楽になる
機能の細部や優先順位の規則は変わることがあるため、AWS の公式ドキュメントで確認する（2026年10月現在の情報です）