CDN設定で迷わないために：CloudFront と Cloudflare の設計思想の違いから

公開日:2025/09/12

1 はじめに
2 CloudFront：Distribution 中心の設計
3 Cloudflare：ドメイン委任中心の設計
4 設計思想の本質的な違い
- 4.1 実際に混乱した例
5 まとめ

はじめに

現代のウェブサービス運用において、CDN の利用は一般的になりました。 CDN はどれも「コンテンツ配信を効率化する」という点では共通していますが、各サービスはその設計思想に基づいて異なる追加機能や、異なるサービスの提供範囲を持っています。

そのため、ある CDN を使い慣れていても、別の CDN を同じ感覚で利用できるとは限りません。異なるサービスの設定を行う場合、これまで対応してきた設計思想と異なるサービスの設定を行うため、その設定自体に戸惑うケースも少なくないでしょう。

本記事では、AWS が提供する CloudFront と、広く使われている Cloudflare の 2 つの CDN を取り上げ、それぞれの設計思想を比較します。これにより、片方を理解している方がもう一方を利用するときの基礎知識を整理することを目的とします。

CloudFront：Distribution 中心の設計

CloudFront は Distribution と呼ばれる配信設定単位を作成し、その中で詳細設定を行います。
各 Distribution は AWS WAF、Amazon S3、Lambda@Edge などの AWS サービスと組み合わせることで機能を拡張できます。

大きな特徴は「Distribution 単位での独立した設定管理」が可能なことです。
1つの Distribution に複数のドメイン名（Alternate Domain Names / CNAME）を関連付けられ、キャッシュポリシー・オリジン設定・セキュリティルールを個別に定義できます。
例えば www.example.com と api.example.com を別々の Distribution として作成し、それぞれに最適化された設定を適用する、といった運用が可能です。

Cloudflare：ドメイン委任中心の設計

Cloudflare は基本的にドメイン全体のネームサーバー委任を前提としています。
追加したドメインの DNS レコードごとに Proxy（プロキシ）機能の有効／無効を切り替えられ、Proxy を有効にすると Cloudflare のグローバルネットワークを経由してオリジンサーバーへ通信されます。

Cloudflare は CDN に加えて、セキュリティ、パフォーマンス最適化、エッジプログラミング（Workers）などを統合的に提供します。重要な設定のスコープはゾーン単位（ドメインごと）が基本ですが、一部の機能（Firewall Rules や Bulk Redirects など）はアカウント単位で動作します。
例えば Page Rules や Cache Rules はゾーン単位で管理されます。 Free プランでは 1 ゾーンにつき最大 3 つまでという制約があります。

なお、本文中の記載ですが基本はフリープランやProプランなどの、一般的なプランでの話となります。 Enterprise プランとなるといくつかの例外的挙動が認められる場合がありますが、その詳細はこの記事には記載しておりません。

設計思想の本質的な違い

CloudFront の設定は「Distribution に紐づく」のに対し、Cloudflare の設定は「ゾーン単位（ドメイン単位）が基本で、一部はアカウント単位に及ぶ」という構造の違いがあります。
この差異こそが、片方の CDN を理解している人がもう片方を使おうとしたときに混乱を招く原因になると考えています。

実際に混乱した例

筆者自身も、CloudFront を使い慣れた後に Cloudflare を利用し、混乱した経験があります。
メインドメイン www.example.com とサブドメイン assets.example.com に異なる設定を適用しようとしたときのことです。

CloudFront であれば、これらを別々の Distribution に割り当て、それぞれに個別設定を行うのが自然な考え方です。ところが Cloudflare ではゾーン単位での管理となるため、明示的に「サブドメインごとに独立した管理単位を作る」方法は一般プランでは提供されておりません。代わりにルールを使って条件分岐する必要があります。
具体的には「このホスト名かつ、このパスの場合に適用する」といった形で Page Rules などを設定する必要があるということです。

また、CloudFront では Distribution に複数のオリジンを登録でき、オリジンごとに通信プロトコル（HTTP/HTTPS）やタイムアウトなどの細かい設定を行えます。一方で Cloudflare は DNS レコードに基づいてオリジンを解決する仕組みであり、レコードごとに「このホストは HTTP で、このホストは HTTPS で」といった個別のオリジン設定を行う項目はありません。
この違いは、CloudFront に慣れていると混乱しやすい点の一つでした。

このように、サブドメインごとに異なる挙動を定義しようとすると、CloudFront と Cloudflare の設計思想の違いが顕著に現れます。サービスを切り替える際は、この点に特に注意が必要です。

また、Cloudflare を利用する際にもう一つ注意が必要なのが、通常はネームサーバー移行が必須であるという点です。CloudFront の場合、任意のドメインの DNS に対して CNAME（Route 53の場合は ALIAS）を設定すれば利用できますが、Cloudflare はその仕組みとは異なります。

Cloudflare の Proxy 機能（通信をいったん Cloudflare が受けてそこからオリジンに転送する仕組み）はユーザーが設定した DNS レコードを通して「暗黙的に」実現されます。この設計上、Cloudflare が正しく機能するためには、ドメインのネームサーバーを Cloudflare に委任し、DNS レコード管理そのものを Cloudflare 側で行う必要があります。

この前提を理解していないと、「CNAME でエッジを噛ませたいだけなのに、なぜネームサーバーを変えないといけないのか？」という疑問や混乱につながります。逆に言えば、Cloudflare は「CDN と DNS を不可分の仕組みとして統合」している設計思想を持つ、と整理できます。