Route 53 のゾーン作成方法｜パブリックとプライベートの選び方、サブドメインの委任、重複作成を防ぐ手順

Route 53 のゾーン（ホストゾーン）は、作る前に「インターネットに公開するパブリックか、VPC の中だけで使うプライベートか」「ドメイン全体を1つのゾーンにするか、サブドメインを別のゾーンに分けて委任するか」を決めておくと、後から作り直す手間を減らせます。作成の操作そのものはコンソールでも AWS CLI でも数分で終わりますが、同じ名前のゾーンを誤って2つ作ったり、プライベートゾーンを作った途端に VPC 内から一部の名前が引けなくなったりと、つまずく点は作成の前後にあります。この記事では、ゾーンの種類の選び方、CLI での作成、サブドメインの委任、作成後の確認までを説明します。

既存のドメインを他の DNS サービスから Route 53 に移す作業（レコードの移行とネームサーバーの切り替え）は扱いません。ここではゾーンを新しく作る場面に絞ります。内容は（2026年10月現在）のものです。画面の表記や CLI のオプションは更新されることがあるため、作業時は AWS の公式ドキュメントも参照してください。料金はゾーンの数と問い合わせの量に応じてかかるので、試しに作ったゾーンを放置しないよう注意します。

パブリックとプライベートの違い

パブリックホストゾーンは、インターネット上の誰からの問い合わせにも答えるゾーンです。Web サイトやメールなど、外部に公開する名前はこちらに登録します。作成すると、Route 53 が4台のネームサーバーを割り当て、NS レコードと SOA レコードが自動で作られます。レジストラ（または親ゾーン）にこの4台を登録した時点で、インターネットからの問い合わせが届くようになります。

プライベートホストゾーンは、関連付けた VPC の中からの問い合わせにだけ答えるゾーンです。データベースや社内向けサーバーの名前など、外部に見せたくない名前を登録します。レジストラへの登録は不要で、VPC 内の Route 53 Resolver（VPC の DNS）が答えます。

プライベートゾーンを使うときの注意点が2つあります。

• VPC の DNS 設定：関連付ける VPC で「DNS 解決」と「DNS ホスト名」の両方が有効になっている必要があります（属性名は enableDnsSupport と enableDnsHostnames）。
• 同じ名前のパブリックゾーンがある場合：VPC 内からはプライベートゾーンが優先されます。プライベートゾーンに無い名前は、パブリックゾーンにあっても VPC 内からは引けません。たとえば example.com のプライベートゾーンを作ると、VPC 内の EC2 から www.example.com が引けなくなることがあります。内部用には internal.example.com のような別の名前を使うか、必要なレコードを両方のゾーンに登録します。

作成前に決めておくこと

• ゾーンの名前：作成後に名前は変えられません。綴りの誤りに気づいたら、作り直すことになります。
• ゾーンを分けるかどうか：本番と開発でゾーンを分けたい、別のチームや別の AWS アカウントにサブドメインの管理を任せたい、といった場合は、dev.example.com のようにサブドメインのゾーンを別に作り、親ゾーンから委任します。
• ネームサーバーをそろえるかどうか：ゾーンを作るたびに割り当てられるネームサーバーは異なります。多数のドメインで同じネームサーバーを使いたい場合は、後述の「再利用可能な委任セット」を作成時に指定する必要があります。後からは変更できません。

AWS CLI でパブリックゾーンを作る

コンソールでは Route 53 の「ホストゾーン」の画面から作成でき、ドメイン名・説明・種類（パブリックかプライベートか）を入力します。手順を記録に残したい場合や、複数の環境で同じ作り方をしたい場合は CLI が便利です。

# 同じ名前のゾーンが既に無いかを先に確認する
aws route53 list-hosted-zones-by-name --dns-name example.com \
  --query "HostedZones[?Name=='example.com.'].[Id,Config.PrivateZone]" --output text

# 作成する（caller-reference は一意の文字列）
aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "example-com-$(date +%Y%m%d%H%M%S)" \
  --hosted-zone-config Comment="production public zone"

--caller-reference は、同じリクエストを誤って2回送ったときに二重に作られるのを防ぐための値です。同じ値で再送するとエラーになります。日時を入れておけば、作り直すときにも重複しません。

Route 53 では、同じ名前のパブリックゾーンを複数作れてしまいます。それぞれ別のネームサーバーが割り当てられるため、レジストラに登録したネームサーバーとは違うゾーンにレコードを追加して「登録したのに反映されない」という混乱が起きます。作成前の確認を習慣にし、既にある場合は新しく作らずにそれを使います。

作成に成功すると、出力の DelegationSet に4台のネームサーバー、HostedZone.Id にゾーンの ID（/hostedzone/Z... の形）が表示されます。後の作業で使うので控えておきます。

プライベートゾーンを作る

プライベートゾーンは、作成時に関連付ける VPC を指定します。

aws route53 create-hosted-zone \
  --name internal.example.com \
  --caller-reference "internal-$(date +%Y%m%d%H%M%S)" \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-0123456789abcdef0 \
  --hosted-zone-config Comment="internal zone",PrivateZone=true

別の VPC からも引けるようにするには、aws route53 associate-vpc-with-hosted-zone で追加の関連付けをします。別の AWS アカウントの VPC と関連付ける場合は、ゾーンを持つアカウント側で create-vpc-association-authorization を実行して許可を出してから、相手のアカウントで関連付けます。オンプレミスの環境からプライベートゾーンを引きたい場合は、Route 53 Resolver のインバウンドエンドポイントなど別の仕組みが必要です。

サブドメインのゾーンを作って委任する

dev.example.com を別のゾーンとして管理する場合は、子のゾーンを作り、そのネームサーバーを親のゾーン（example.com）に NS レコードとして登録します。

# 子ゾーンを作り、割り当てられたネームサーバーを確認する
aws route53 create-hosted-zone --name dev.example.com \
  --caller-reference "dev-$(date +%Y%m%d%H%M%S)"
aws route53 get-hosted-zone --id Z_CHILD_ZONE_ID \
  --query "DelegationSet.NameServers" --output text

{
  "Comment": "delegate dev.example.com",
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "dev.example.com",
      "Type": "NS",
      "TTL": 300,
      "ResourceRecords": [
        {"Value": "ns-111.awsdns-11.com."},
        {"Value": "ns-222.awsdns-22.net."},
        {"Value": "ns-333.awsdns-33.org."},
        {"Value": "ns-444.awsdns-44.co.uk."}
      ]
    }
  }]
}

aws route53 change-resource-record-sets --hosted-zone-id Z_PARENT_ZONE_ID \
  --change-batch file://delegate-dev.json

JSON のネームサーバーは例なので、get-hosted-zone で表示された子ゾーンの4台に置き換えます。委任の NS は、最初は TTL を短めにしておくと、誤りに気づいたときに直しやすくなります。親子で同じ AWS アカウントでなくても、この手順は同じです。

再利用可能な委任セット

ゾーンごとにネームサーバーが変わると、多数のドメインを管理するときにレジストラ側の登録が煩雑になります。再利用可能な委任セットを作り、ゾーンの作成時に指定すると、同じ4台のネームサーバーを複数のゾーンで共有できます。

aws route53 create-reusable-delegation-set --caller-reference "ds-$(date +%Y%m%d%H%M%S)"
aws route53 create-hosted-zone --name example.net \
  --caller-reference "example-net-$(date +%Y%m%d%H%M%S)" \
  --delegation-set-id N_DELEGATION_SET_ID

委任セットはパブリックゾーン向けの機能で、CLI や API から操作します。既存のゾーンに後から適用することはできないので、使う予定があれば最初のゾーンを作る前に用意します。

作成後の確認

ゾーンを作ったら、レジストラや親ゾーンに登録する前に、割り当てられたネームサーバーへ直接問い合わせて応答を確かめます。

dig @ns-111.awsdns-11.com example.com SOA +norec
dig @ns-111.awsdns-11.com example.com NS +norec

# Route 53 の API で、登録したレコードの答えを確かめる
aws route53 test-dns-answer --hosted-zone-id Z_ZONE_ID \
  --record-name www.example.com --record-type A

dig の flags に aa が付き、SOA と NS が返れば、ゾーンは問い合わせに答えています。test-dns-answer は、委任の前でもレコードの内容を確かめられます。プライベートゾーンは、関連付けた VPC 内の EC2 などから dig internal.example.com SOA を実行して確認します。

作成後に行う作業としては、レコードの登録のほかに、用途や担当者を示すタグの付与（change-tags-for-resource）、DNSSEC 署名の有効化があります。DNSSEC の署名はパブリックゾーンでのみ使え、米国東部（バージニア北部）リージョンの KMS 鍵が必要になるなど条件があるため、別の作業として手順を確認してから進めます。ゾーンを削除する場合は、自動で作られた NS と SOA 以外のレコードを先に消す必要があります。

まとめ

• 外部に公開する名前はパブリック、VPC 内だけの名前はプライベートのゾーンに分けます。同じ名前のプライベートゾーンを作ると、VPC 内からはパブリックの名前が引けなくなる点に注意します。
• 作成前に list-hosted-zones-by-name で重複を確認し、--caller-reference には一意の値を入れます。
• サブドメインは子ゾーンを作り、親ゾーンに NS レコードを登録して委任します。
• ネームサーバーをそろえたい場合は、再利用可能な委任セットをゾーンの作成時に指定します。
• 登録前に、割り当てられたネームサーバーへ dig で直接問い合わせて確かめます。

• NSレコードの仕組みとゾーン委任の設定｜サブドメインの委任と確認方法
• 内部DNSと外部DNSの混在トラブル｜社内だけサイトが開けない・時々名前が引けない原因と対処