Route 53 と Cloudflare DNS を比較する｜AWS 連携・プロキシ・ゾーン頂点の扱いで選ぶ条件

Route 53 と Cloudflare DNS は、どちらも信頼性の高い権威 DNS ですが、得意な場面がはっきり分かれます。サイトが AWS 上にあり、ロードバランサーや CloudFront への接続、ヘルスチェックによる切り替え、VPC 内向けの名前解決まで DNS で扱いたいなら Route 53 が向いています。レンタルサーバーや VPS の WordPress の前に CDN と WAF を置きたい、あるいは DNS を手軽に管理したいなら Cloudflare が向いています。この記事では、両者の違いを WordPress サイトの運用で関わる点に絞って整理し、条件ごとの選び方と、移行・併用のときの注意点を説明します。

機能の範囲や管理画面の表記、プランごとの提供内容は変わることがあります（2026年10月現在）。料金はここでは扱わず、課金の考え方の違いだけに触れます。最終的な判断の前に、両社の公式ドキュメントで最新の条件を確認してください。

前提：比べているのは「DNS をどこで管理するか」

ドメインを登録するレジストラと、レコードを返す権威 DNS は別の役割です。お名前.com などでドメインを持ったまま、ネームサーバーだけを Route 53 や Cloudflare に向ける構成は一般的です。どちらもドメイン登録のサービスを持っていますが、扱える TLD は各社で異なり、たとえば .jp が対象かどうかも一覧で確かめる必要があります。この記事の比較は、権威 DNS としての違いが中心です。

違いの早見表

Route 53 が向いている条件

AWS のリソースにつなぐことが多いなら、Route 53 の利点が大きくなります。エイリアスレコードを使うと、example.com の頂点を Application Load Balancer や CloudFront のディストリビューションに向けられます。これらは IP アドレスが変わるため、A レコードに直接書くことはできません。エイリアスであれば、Route 53 が背後のアドレスを追いかけて答えます。

ヘルスチェックで切り替えたい場合も Route 53 が扱いやすい場面です。フェイルオーバーのルーティングとヘルスチェックを組み合わせると、メインのサーバーが応答しなくなったときにメンテナンス用のページや待機系へ答えを切り替えられます。加重ルーティングで新しいサーバーへ少しずつ流す、といった移行にも使えます。

VPC 内の名前解決や権限の分離が必要な組織でも候補になります。プライベートホストゾーンで社内向けの名前を管理でき、IAM のポリシーでホストゾーンごとに編集できる人を絞れます。問い合わせのログを CloudWatch Logs に出す機能もあり、監査の要件がある場合に役立ちます。

一方で、AWS を使っていないサイトにとっては、IAM の設計や請求の管理が増えるぶん、手間に見合わないこともあります。

Cloudflare DNS が向いている条件

WordPress の前に CDN と WAF を置きたい場合は、Cloudflare の特徴が生きます。レコードのプロキシを有効にするだけで、訪問者は Cloudflare を経由して元のサーバーにつながり、キャッシュや攻撃の遮断を受けられます。レンタルサーバーや VPS の構成を変えずに足せるのが利点です。

ただし、プロキシを使うと WordPress 側で調整が必要になります。

• 訪問者の IP アドレス：サーバーから見ると接続元が Cloudflare になるため、Web サーバーで CF-Connecting-IP ヘッダーを実際の接続元として扱う設定（Apache の mod_remoteip、nginx の real_ip モジュールなど）を入れないと、ログやセキュリティ系プラグインの記録が Cloudflare のアドレスで埋まります。
• SSL の設定：元のサーバーにも有効な証明書を入れ、Cloudflare 側は元のサーバーとの間も証明書を検証するモード（Full (strict) に当たる設定）にします。元のサーバーとの間を暗号化しないモードは避けます。
• キャッシュの範囲：管理画面やログイン中のページ、カートなどをキャッシュしないようにルールを確認します。
• メールのレコード：プロキシが扱うのは Web の通信です。MX の向け先やメールサーバーのホスト名はプロキシを使わない「DNS のみ」にします。

DNS を手軽に管理したい場合にも向いています。画面がシンプルで、頂点の CNAME もフラットニングで扱え、DNSSEC も画面から有効にできます。

注意したいのは、Cloudflare の標準的な構成ではネームサーバーを Cloudflare に切り替える必要があることです。ほかの DNS に権威を残したまま一部の名前だけ Cloudflare を通す構成は、上位のプランに限られます。

WordPress サイトでよくある構成と選び方

1. レンタルサーバーか VPS 1台で WordPress を動かしている：Cloudflare が第一候補です。まず「DNS のみ」で移し、動作を確かめてから必要なレコードだけプロキシを有効にすると、問題の切り分けがしやすくなります。
2. EC2 や Lightsail、ALB、CloudFront など AWS で組んでいる：Route 53 が自然です。エイリアスとヘルスチェックを使え、構成の管理を AWS の中にまとめられます。
3. AWS で組んでいて、Cloudflare の WAF も使いたい：Cloudflare の DNS で頂点を CNAME フラットニングにして ALB などへ向け、プロキシを通す構成が考えられます。この場合、Route 53 のエイリアスやヘルスチェックによる切り替えは使えなくなるため、どちらの機能を優先するかで決めます。

移行・併用のときに気をつけること

• 独自のレコードは書き出しで移らない：Route 53 のエイリアスと Cloudflare のプロキシ・フラットニングは、どちらも標準のゾーンファイルでは表せません。移す前に該当するレコードを一覧にし、移行先での表し方を決めておきます。
• DNSSEC は先に外す：署名を有効にしたまま事業者を移すと、名前解決に失敗するおそれがあります。レジストラの DS レコードを外して TTL が切れてから切り替え、移行先で改めて有効にするのが単純で安全な順序です。
• 2社を併用して冗長化する場合：Route 53 はゾーン転送に対応していないため、同じレコードを API や Terraform で両方に書き込む構成になります。Cloudflare のプロキシを使うレコードは、問い合わせ先によって答えが変わる点に注意します。
• 切り替えの前に直接問い合わせる：移行先のネームサーバーへ dig @ネームサーバー名 example.com A +norec のように直接問い合わせ、今と同じ答えが返ることを確かめてからレジストラの NS を変えます。

決める前に確かめる項目

• サイトとメールのサーバーはどこにあり、AWS のリソースに頂点を向ける必要があるか
• CDN と WAF を DNS と一体で使いたいか、別のサービスで用意するか
• ヘルスチェックによる切り替えや、位置・遅延による振り分けが必要か
• 社内向けの名前解決や、ゾーンごとの権限の分離が必要か
• 変更をコードで管理するか、画面で操作するか

まとめ

• AWS のリソースへの接続、ヘルスチェックによる切り替え、プライベートホストゾーンが必要なら Route 53 が向いています。
• WordPress の前に CDN と WAF を手軽に置きたい、DNS をシンプルに管理したいなら Cloudflare が向いています。
• Cloudflare のプロキシを使う場合は、接続元 IP の扱い、SSL のモード、キャッシュの範囲、メールのレコードを確認します。
• エイリアス・プロキシ・フラットニングは書き出しで移らないため、移行前に一覧にします。DNSSEC は外してから移します。
• 提供内容は変わることがあるので（2026年10月現在の情報）、決める前に両社の公式ドキュメントで条件を確認します。

• AWS Route 53でDNSを設定する方法｜ホストゾーン作成・ネームサーバー切り替え・WordPress向けレコード
• CloudflareでDNSを管理する初期設定：ネームサーバー移行からWordPress側の調整まで