Route 53 と ConoHa DNS を比較する｜機能・自動化・費用の考え方と、WordPress のサーバーの置き場所で選ぶ条件

WordPress を ConoHa の VPS や WING で動かしていて、必要なのが A・CNAME・MX・TXT などの基本的なレコードだけなら、ConoHa DNS で足ります。サイトを AWS に置いている、障害時に別のサーバーへ自動で切り替えたい、権限や変更履歴を細かく管理したい、という条件があるなら Route 53 が向いています。この記事では、公開用の権威 DNS としての両者の違いを、機能、自動化、費用の考え方、乗り換えの注意点の順に整理し、どちらを選ぶかの判断材料をまとめます。

両サービスの機能や料金体系、画面の表記は更新されることがあります（2026年10月現在）。金額は書かないので、選ぶ前に各社の公式の料金ページと機能の案内で確かめてください。

前提：比べるのは「公開用の権威 DNS」

ここで比べるのは、ドメインのレコードをインターネットに向けて答える権威 DNS です。Route 53 ではパブリックホストゾーンがこれにあたります。AWS の VPC 内で名前を引くための Route 53 Resolver は役割が違うので、この比較には含めません。

ConoHa DNS は ConoHa のアカウントで使う DNS で、VPS などのコントロールパネルからゾーンとレコードを管理します。どちらも、ドメインをどこで登録したかに関係なく、レジストラでネームサーバーを設定すれば使えます。

機能の違い

違いがもっとも効いてくるのは頂点の扱いです。CloudFront などの CDN は IP アドレスが固定されないため、example.com そのものを向けるには CNAME 相当の仕組みが必要です。Route 53 のエイリアスレコードはこれに対応しますが、ConoHa DNS では頂点に A レコードで固定の IP を書く運用になります。WordPress を ConoHa の VPS で動かしているなら IP は固定なので、この違いは問題になりません。

もう1つは、障害時の切り替えです。Route 53 はヘルスチェックの結果を見て、応答を待機系のサーバーやメンテナンスページへ切り替えられます。ConoHa DNS で同じことをするには、監視の仕組みを別に用意し、API でレコードを書き換える処理を自分で作る必要があります。

自動化のしやすさ

Route 53 は AWS CLI、各言語の SDK、Terraform の AWS プロバイダー、CloudFormation など、使える道具がそろっています。レコードの変更は、変更内容を JSON に書いて送る形です。

{
  "Comment": "www の A レコードを更新",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{ "Value": "203.0.113.10" }]
      }
    }
  ]
}

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

ConoHa DNS にも REST の API があり、トークンを発行してレコードの取得・追加・変更・削除ができます。ただし API の接続先や仕様は ConoHa のサービスの世代によって異なり、Terraform の公式のプロバイダーは案内されていません。証明書の DNS-01 認証のように、ツール側が ConoHa に対応しているかで手間が変わる作業もあるので、使いたいツールの対応状況を先に確かめます。

レコードを年に数回しか変えないなら、どちらでも画面の操作で十分です。複数のサイトを担当者で分けて管理したい、変更をコードで見直したい、という場合は Route 53 のほうが仕組みを組みやすくなります。

費用の考え方

Route 53 は、ホストゾーンごとの月額と、問い合わせの量に応じた従量の料金がかかります。ヘルスチェックやクエリログの保存先も別に費用が発生します。一方で、CloudFront など一部の AWS リソースを指すエイリアスレコードへの問い合わせは、課金の対象外として扱われています。

ConoHa DNS は、ConoHa の契約に付いてくる機能として、DNS 単体の料金を意識せずに使える扱いになっています。条件は変わることがあるので、公式の案内で確かめてください。

小規模な WordPress サイトがいくつかある程度なら、Route 53 の料金は大きな額にはなりにくいものの、ドメインの数だけ毎月の固定費が積み上がります。使わない機能のために Route 53 を選ぶ理由は薄く、逆にフェイルオーバーや権限管理を使うなら、その費用は機能の対価と考えられます。

どちらを選ぶかの条件

ConoHa DNS が向いている場合

• WordPress を ConoHa の VPS や WING で動かしていて、サーバーと DNS を同じ画面で管理したい
• 必要なのは基本のレコードだけで、頂点を CDN に向ける予定がない
• 少数のドメインを1人で管理していて、変更の頻度が低い

Route 53 が向いている場合

• サイトを EC2 や Lightsail、CloudFront などの AWS 上に置いている、または移す予定がある
• ヘルスチェックによる自動の切り替えや、地域ごとの応答の出し分けを使いたい
• 複数の担当者がいて、IAM で権限を分け、変更履歴を残したい
• Terraform などでインフラ全体をコードで管理している

サーバーと DNS の事業者をそろえる必要はありません。ConoHa の VPS で WordPress を動かし、DNS は Route 53 に置く、という組み合わせも普通に使われています。判断の軸は「どこにサーバーがあるか」より「DNS にどの機能を求めるか」です。

乗り換えるときの注意点

どちらの方向でも、基本の手順は同じです。今のレコードをすべて書き出し、TTL を短くして待ち、移行先に同じレコードを登録して、移行先のネームサーバーへ直接問い合わせて値を確かめてから、レジストラでネームサーバーを切り替えます。

# 移行先のネームサーバーに直接聞いて、登録内容を確かめる（名前は割り当てられたものに置き換える）
dig @ns-123.awsdns-45.com www.example.com A +norec +short
dig @ns-123.awsdns-45.com example.com MX +norec +short

方向ごとに注意する点があります。

• ConoHa DNS から Route 53 へ：ホストゾーンを作ると4つのネームサーバーが割り当てられるので、その名前をレジストラに登録します。同じドメインのホストゾーンを誤って複数作ると、それぞれに別のネームサーバーが割り当てられるため、どのゾーンを使うかを確認します。
• Route 53 から ConoHa DNS へ：エイリアスレコードは書き出しても移せません。頂点が CloudFront などを指している場合、ConoHa DNS では同じ構成を作れないので、乗り換える前に構成を見直します。ヘルスチェックに頼っている切り替えも、移行先での代わりの手段を決めてから移ります。
• DNSSEC：有効にしている場合は、先にレジストラの DS レコードを外し、その TTL が切れてから切り替えます。
• メール：切り替えの後に MX・SPF・DKIM の値が移行先で返るかを確かめ、送受信を試します。

まとめ

• 比べるのは Route 53 のパブリックホストゾーンと ConoHa DNS で、どちらも公開用の権威 DNS です。
• 頂点のエイリアス、ヘルスチェックによる切り替え、IAM での権限管理が必要なら Route 53、基本のレコードを ConoHa のサーバーと一緒に管理したいなら ConoHa DNS が向きます。
• Route 53 はゾーン数と問い合わせ量で費用が増えるため、使う機能に見合うかで判断します。
• サーバーと DNS の事業者をそろえる必要はなく、求める機能で選びます。
• 乗り換えでは、エイリアスや DNSSEC など移せない設定を先に洗い出します。

• AWS Route 53でDNSを設定する方法｜ホストゾーン作成・ネームサーバー切り替え・WordPress向けレコード
• ネームサーバー変更時の注意点｜メール停止・DNSSEC・移行期間のトラブルを防ぐ