AWS CloudFront と BunnyCDN の比較：WordPressで選ぶときの判断基準

WordPress の配信を速くしたいとき、AWS CloudFront と BunnyCDN（bunny.net）はどちらも有力な選択肢です。結論から言うと、すでに AWS 上でサイトを運用していて WAF や細かいキャッシュ制御を AWS の仕組みでまとめたいなら CloudFront、画像やCSS・JSの静的配信を手早く安定させたいなら BunnyCDN が扱いやすい、というのが大まかな目安です。この記事では、両者の違いを WordPress 運用の観点で整理し、自分のサイトにどちらが合うかを判断できるようにします。

なお、両サービスとも機能や料金体系の更新が頻繁です。ここでの内容は（2026年10月現在）の一般的な傾向として読み、契約前には各社の公式ドキュメントと料金ページを確認してください。

比較の前に決めておくこと：何をCDNに載せるか

CDN の比較で最初に決めるべきなのは、サービス名ではなく「配信範囲」です。WordPress で CDN を使う方法は大きく2つあります。

• 静的ファイルだけを CDN から配信する：wp-content/uploads の画像や、テーマ・プラグインの CSS/JS を CDN 用ホスト名（例: cdn.example.com）に書き換えて配信します。HTML はこれまでどおりオリジンサーバーが返します。
• サイト全体を CDN 経由にする：DNS の向き先を CDN にして、HTML を含めたすべてのリクエストを CDN が受けます。

静的ファイルだけなら設定の難しさはどちらも大差がなく、価格・管理画面の分かりやすさ・画像最適化機能の有無で選べます。サイト全体を載せる場合は、ログイン中ユーザーや管理画面を誤ってキャッシュしない設計が必要になり、キャッシュ制御の細かさが選定の決め手になります。

機能の違いを整理する

CloudFront が向いているケース

CloudFront の強みは、パスごとに動作を分けられるビヘイビアと、Cookie やヘッダーをどこまでオリジンへ渡すかを分けて定義できるポリシーの仕組みです。たとえば /wp-admin/* と /wp-login.php はキャッシュせずに全 Cookie を渡し、/wp-content/* は長期キャッシュにする、といった設計を明示的に書けます。EC2 や Lightsail、S3 をすでに使っているなら、オリジンへの接続や証明書管理、AWS WAF によるログイン画面の保護までを同じアカウント内で完結できます。

一方で、設定項目が多く、どの Cookie を転送するかを誤ると「キャッシュが効かない」「ログイン状態が崩れる」といった問題が起きやすくなります。AWS の操作に慣れたメンバーがいることが前提です。

BunnyCDN が向いているケース

BunnyCDN は Pull Zone を作ってオリジンの URL を指定すれば、すぐに静的ファイルの配信を始められます。画像の自動圧縮やリサイズを行うオプションがあり、WordPress 向けには公式プラグイン（「bunny.net」名義で配布されているもの）も用意されています。プラグインの機能や設定画面の表記はバージョンで変わるため、導入時に配布ページの説明を確認してください。

サイト全体の配信にも使えますが、ログイン Cookie を見てキャッシュを回避するといった制御は、エッジルールなどを使って自分で組む必要があります。動的な部分は WordPress 側のキャッシュプラグインやオリジンに任せ、BunnyCDN は静的配信に絞ると運用がシンプルになります。

WordPressで両方に共通する設定の注意点

どちらを選んでも、つまずきやすい点はほぼ共通しています。

HTTPS の判定

サイト全体を CDN 経由にすると、オリジンには CDN から接続が届きます。CDN とオリジンの間が HTTP の場合、WordPress は自分が HTTPS で表示されていると判断できず、リダイレクトループや混在コンテンツの原因になります。CloudFront では、オリジンリクエストポリシーで CloudFront-Forwarded-Proto ヘッダーを転送するよう設定したうえで、wp-config.php の require_once ABSPATH . 'wp-settings.php'; より前に次のような判定を入れる方法があります。

// CloudFront 経由のアクセスで、閲覧者側が HTTPS なら WordPress に HTTPS と伝える
if ( isset( $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] )
	&& 'https' === $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

このヘッダーは外部から偽装できるため、オリジンを CDN 以外から直接アクセスできないようにしておくことが前提です。BunnyCDN など X-Forwarded-Proto を付けるサービスの場合は、ヘッダー名を合わせて同様に判定します。どの転送ヘッダーが付くかはサービスの仕様を確認してください。CDN とオリジンの間も HTTPS にしておけば、この問題自体を避けやすくなります。

ログイン中ページと管理画面をキャッシュしない

WordPress のログイン状態は wordpress_logged_in_ で始まる Cookie で判定されます。パスワード保護ページは wp-postpass_、コメント投稿者情報は comment_author_ で始まる Cookie を使います。サイト全体を載せる場合は、これらの Cookie を持つリクエストと、/wp-admin/・/wp-login.php・/wp-json/ などをキャッシュの対象外にしてください。ここを誤ると、管理者向けの表示が他の訪問者に配信されるおそれがあります。

更新が反映されないときのパージ

テーマの CSS を変えたのに古い見た目のまま、という相談は CDN 導入後に非常によくあります。WordPress は wp_enqueue_style() の第4引数にバージョンを渡すと ?ver= 付きの URL を出力するので、ファイル更新時にバージョンを上げればクエリ文字列の違いで新しいファイルが取得されます。そのためには CDN 側でクエリ文字列をキャッシュキーに含めておく必要があります。CloudFront ではキャッシュポリシーのクエリ文字列設定、BunnyCDN ではクエリ文字列を無視する設定の有無を確認してください。急ぎの場合は CloudFront の無効化（Invalidation）や BunnyCDN のパージで消します。

費用を比べるときの考え方

料金は改定が多いため本記事では金額を扱いませんが、比較するときの観点は次のとおりです。

• 転送量の課金単位と地域差：どちらも転送量に応じた課金が基本で、配信地域によって単価が異なる場合があります。日本中心のサイトなら、アジア地域の単価を確認します。
• リクエスト数や付加機能の課金：CloudFront はリクエスト数や無効化、Functions の実行などが別に課金される項目があります。BunnyCDN も画像最適化などのオプションは別料金です。
• オリジン側の費用：AWS ではオリジンからのデータ転送の扱いも関係します。CDN のキャッシュヒット率が低いと、オリジン負荷と費用の両方が増えます。

実際の請求額は、アクセスログから月間の転送量とリクエスト数を見積もり、各社の料金計算ツールに当てはめて比べるのが確かです。

選び方の目安

• AWS 上で運用している、WAF・ログ・権限管理を AWS にまとめたい、パス単位で細かく制御したい → CloudFront
• レンタルサーバーや VPS で運用している、まず画像と静的ファイルを速くしたい、管理の手間を減らしたい → BunnyCDN
• どちらか迷う → まず静的ファイルだけを載せて効果を測り、必要になってからサイト全体の配信を検討する

切り替えの前には、サイトのバックアップを取り、ステージング環境やサブドメインで表示とログインを確認してから本番の DNS を変更してください。

まとめ

• CloudFront はビヘイビアとポリシーで細かく制御でき、AWS の他サービスと組み合わせやすい反面、設定の前提知識が多い
• BunnyCDN は静的配信を素早く始めやすく、画像最適化などのオプションも選べる
• どちらでも、HTTPS の判定、ログイン Cookie と管理画面の除外、クエリ文字列とパージの扱いが WordPress でのつまずきどころ
• 料金と機能は変わりやすいので、契約前に公式の料金ページと実際の転送量で見積もる

• AWS CloudFront を CDN として設定する手順
• BunnyCDN で WordPress の画像を最適化する方法