クラウドCDN比較解説まとめ

最終更新 2019-10-01

本ページでは、CDN とは何か、何の役に立つのかの初歩の説明と、Amazon CloudFront・Azure CDN・Google Cloud CDN の機能・料金の比較解説を行います。

2019/10/01 Azure Storage 等から Azure CDN へのデータ転送料金が、2019/10 より無料になる旨追記。

2019/04/15 Azure CDN Standard from Microsoft を追加。Google Cloud CDN で署名付きURLが可能であることを追記。署名付きURLの解説を追加。

CDN とは何か

Amazon CloudFront・Azure CDN・Google Cloud CDN の比較と説明の前に、CDN とは何かについて説明します。

CDN とは “Content Delivery Network” の略で、「シーディーエヌ」と発音します。 ざっくり言うと、CDN 事業者がサーバを立て、サービス事業者であるあなたの代わりにコンテンツを配信してくれる、というものです。

得られるメリットは下記です。

• サーバ負荷を受け持ってくれる
• ネットワーク帯域の節約になる
• エンドユーザ (利用者) の近くに CDN のサーバがあるので速い (かもしれない)
• キャッシュしてくれるので、レスポンスが早くなる
• ワンタイム URL やタイマ機能などを利用できる (かもしれない)

例えば、以前関わったことのある EC サイトにて、画像の CDN 化を行なったときは、 ネットワークピーク転送量 70% 減、サーバ負荷 20% 減となりました。 ネットワーク契約の帯域料を削減して月30万節約、一方で CDN 費用は 2万円/月でした。デメリットは下記です。

• お金がかかる
• 正しく使わないと、セキュリティ事故が発生する可能性がある (後述)
• 別 FQDN になる場合があるので、Cookie の扱いなどに注意が必要

CDN が向いているサービス

例えば、ある日の Gigazine のページを分析すると、下記のようになりました。

• 合計サイズ 2.5MB: 内訳は下記
• – 画像が 35% (893KB)
• – スクリプトが 25% (644KB)
• – HTML が 3% (86KB)
• – その他 が 35% (891KB) (うち動画 mp4 ファイルが 700KB 超)

Gigazine は、ぱっと見、誰が見ても同じコンテンツを返すように見えます (実は「シークレットクラブ」という会員機能があるようですが、ほとんどは非会員からのアクセスと思われます)。 このような誰が見ても同じコンテンツがある、というときに、CDN は最大の効果を発揮します。 利用者 A さんに送った画像ファイルを CDN でキャッシュしておけば、利用者 B さんにもそのキャッシュが使えるためです。

上記の比率を見ると、もし画像 + スクリプト + 動画 mp4 ファイルを CDN 化できたならば、 90% 以上のデータを CDN 経由とすることができ、その分 Gigazine サーバへのアクセスを減らすことができます。

いろいろなパターン

CDN を使わない場合、利用者とサービス事業者の関係は、下記です。

• 利用者 ←→ サービス事業者のサーバ

CDN を使う場合、CDN 事業者が間に入る形となります。この場合のサービス事業者のことを、 オリジンと言います (origin は起源とか発端という意味の英単語)。

• 利用者 ←→ CDN事業者のサーバ ←→ サービス事業者 (オリジン)

いろいろな接続方法があります。 下記は、そもそもクラウドサービスを使っていないけれども、画像だけを CloudFront に乗せた場合。

• HTML コンテンツ (www.myservice.xxx)
  • 利用者 ←→ サービス事業者
• 画像 (img.myservice.xxx)
  • 利用者 ←→ Amazon CloudFront ←→ サービス事業者サーバ

下記は、HTML は EC2 で、画像は S3 に起き、それぞれに CloudFront を使用する形。

• HTML コンテンツ (www.myservice.xxx)
  • 利用者 ←→ Amazon CloudFront ←→ サービス事業者が使用している EC2
• 画像 (img.myservice.xxx)
  • 利用者 ←→ Amazon CloudFront ←→ サービス事業者が使用している S3

各クラウドサービスの CDN

Amazon・Microsoft・Google の提供する CDN サービスは下記のとおりです。 Azure はややこしいのですが、4種類あります。

• AWS が提供する CDN サービスは “Amazon CloudFront”
• Google が提供する CDN サービスは “Google Cloud CDN”
• Microsoft が提供する CDN サービスは下記の 4つで、Standard と Premium の2階層あります。
  • Azure CDN Standard from Microsoft (略称 Standard Microsoft) (2018/9 GA)
  • Azure CDN Standard from Akamai (略称 Standard Akamai)
  • Azure CDN Standard from Verizon (略称 Standard Verizon)
  • Azure CDN Premium from Verizon (略称 Premium Verizon)

Azure CDN だけたくさんあるので解説しておきます。

Akamai (アカマイ) というのは老舗の CDN 事業者です。 世界中の 10〜20% のトラフィックをさばいている、とはよく聞きますが、 昔はともかく今もそうなのかはちょっと疑問です。ソース希望。 Verizon (ベライゾン) は米国の大手通信会社です。 日本ではあまり馴染みがない名前ではありますが、グループ全体の売上高は 12兆円です。 売上12兆円というのは日本の企業だと第5位くらいで、要は、超巨大企業です。

最初は Verizon、その後 Akamai が追加、さらにそのあと Microsoft が追加、という順序です。

Amazon CloudFront・Azure CDN・Google Cloud CDN の機能比較表

機能比較表をまとめてみました。 詳細は後述。

比較表はここまでです。以下、詳細に説明していきます。

「接続方式」詳細説明

接続タイプ について

Amazon CloudFront・Azure CDN・Google Cloud CDN いずれも、リバースプロキシタイプです。 世の中の CDN には二通りあり、

• A. FTP 等で、指定のサーバの指定のフォルダにファイルをアップすることで配信が可能となる
• B. リバースプロキシ型。 どこかの Web サイトでコンテンツを配置しておき、CDN にアクセスがあった場合、そのサイトに取りに行くよう設定しておく

というものがありますが、3つの CDN はいずれも B です。 以前は A が多かった気がするのですが、ファイルをアップするのも手間ですし、A だと動的コンテンツに対応ができないので、現在は B が主流ではなかろうかと当ページ管理人は思っています。

ストレージへの接続

AWS・Azure・GCP いずれの CDN も、各社ストレージサービスとの接続ができます。

• Amazon CloudFront → Amazon S3
• Azure CDN → Azure Storage
• Google Cloud CDN → Google Cloud Storage

ということです。

なお、Amazon S3・Azure Storage いずれも、 配置したファイルを (CDN を使わずに) http/https で公開することは可能です。 CDN を使うと、さらに速度やキャッシュ等の付加価値が付くものと考えてください。 また、Google Cloud Storage の場合、デフォルトでエッジキャッシュ機能があります。

その他クラウド内への接続 について

CDN からストレージ以外への接続も可能です。

クラウド外のオリジンへの接続 について

クラウド以外をオリジンとすることは、Amazon CloudFront と Azure CDN では可能ですが、 Google Cloud CDN のみ不可です。 言い換えると、「Amazon CloudFront・Azure CDN はクラウドサービス以外、 例えば さくらインターネットやオンプレミスサーバをオリジンとして指定できるが、 Google Cloud CDN はできない」ということを意味します。

「料金・価格・コスト・費用」詳細説明

料金・コストについてざっくり言うと、AWS＞Azure＞＞＞＞GCP です (当ページ管理人の私見)。

データ転送料金 について

データ転送料金とは、CDN からインターネットへのデータ転送にかかる費用・コストです。例えば、 一般利用者のブラウザが CDN から画像ファイルを取得する際、この金額がかかります。 CDN でキャッシュしていようがしていまいが、この金額はかかります。 コンテンツが gzip で圧縮されていたり、304 Not Modfied で返した場合は節約できます。

HTTP/HTTPS リクエスト料金 について

「HTTP リクエスト料金」とは、GET メソッドを投げた回数に応じて請求されるものです。 1万リクエストあたり、AWS は 0.0090 USD、Google Cloud CDN は 0.0075 USD かかります。「HTTPS リクエスト料金」は、その HTTPS 版です。Amazon CloudFront では HTTP より HTTPS の方が 1.33 倍高いのですが、GCP では HTTP・HTTPS は同額です。そして Azure CDN は HTTPS でも無料です。 今後、HTTPS 化の流れがどんどん加速していくでしょうから、HTTPS が安いのはうれしいことです。

そして、Azure CDN は HTTP/HTTPS いずれもリクエスト回数に応じた請求はありません。すべてはデータ転送量次第です。後述しますが、ファイルサイズが小さく、リクエスト数が多い場合、この特性で他社よりも格段に安い値段にすることができます。

クラウドから CDN へのデータ転送料金 について

AWS では 2013年以降、「S3・EC2・ELB」→「CloudFront」とする際の S3・EC2・ELB の転送料が無料となりました (それ以前は有料だった)。

Azure CDN も 2019年10月より、「Azure Storage・Azure Media Services・Azure Application Gateway」→「Azure CDN」が無料となります。アナウンスはこちら。

一方、Google Cloud CDN の転送料金は残念ながら有料です。 つまり「Azure Storage」→「Azure CDN」や、「Google Cloud Storage」→「Google Cloud CDN」とする場合、 Azure Storage・Google Cloud Storage にてデータ転送料金がかかります。

動画配信のようなファイルサイズが大きい・ファイル数が多いようなシステムでは、 オリジン → CDN の転送量だけでもバカになりませんので、この点は重要でしょう。一方、EC サイトの商品画像のような、せいぜい数千〜数万種類の画像であれば、それほどは影響はないと思われます。

無効リクエスト について

Amazon CloudFront のみ、無効なリクエストに課金がなされます。 無効なリクエストとは、例えば 404 Not found になるようなリクエストです。「パス」とは、”/aaa” で 1パス、”/abc” でさらに 1パス、という数え方です。

たいした金額ではないのですが、もし悪意を持った第三者にさまざまなパスでリクエストされまくると…という点は不安です。

Azure CDN・Google Cloud CDN には無効リクエストの課金はありません。

クラウド CDN 料金コスト比較 (Gigazine 編)

CDN 料金がどの程度異なるか、Gigazine のサイトで見積もりを出してみることにしましょう。

Gigazine で確認したところ、 トップページは 121リクエスト、初回は 1.4MB、 二回目以降はおおむね 300KB。全ページ HTTPS。 仮定として、全ページが同じリクエスト数・サイズであり、 初回:二回目以降 の比率は 1:9 とします。 2015年時点で1億PV/月 だそうなので、リクエスト数は 121億。 となると、初回アクセスは転送量 14TB (=1億PV×10%×1.4MB)、二回目以降は転送量 27TB (＝1億PV×90%×300KB)。 合計で転送量 41TB、121億リクエスト。

結果は以下のとおり。なんと (失礼) Azure CDN の圧勝でした。

• Amazon CloudFront: 2,267,226円(税抜)
• Azure CDN: 620,940円(税抜)
• Google Cloud CDN: 1,347,257円(税抜)

その他の細かな前提は下記。

• ほぼ静的コンテンツでしょうから、キャッシュヒット率は 95% とします。
• 為替レートは 1USD=121円 (2018/1 時点)。
• Azure CDN は Standard とします (Premium ではなく)。
• Azure CDN でデータ転送アクセラレーション (DSA) は使わないものとします。
• リージョン間の転送はないものとします (東京のユーザ → 東京の CDN → 東京にあるサーバ、という前提)
• オリジンサーバはクラウド外にあるものとします。Amazon CloudFront → EC2 ではなく、Amazon CloudFront → さくら等の外部サーバ ということです。
• 各社料金表示の記載は税抜とします。AWS・Azure は税抜と記載がありましたが、GCP は記載を見つけられませんでした。
• 転送量は Chome の開発者ツールを利用しています。転送量はレスポンスヘッダ分が含まれていると認識しているのですが、確証はありません。最近はレスポンスヘッダにとても長い Cookie が付いていることが多いので、この認識が間違いであればデータ転送量が 10〜20% 増えるかもしれません。

金額内訳は下記。

• Amazon CloudFront: 2,267,226円
  • 最初の10TBの転送量: 10,240GB(=10TB)×0.14USD×112円＝160,563円
  • 次の40TB分の転送量: 31,744GB(=31TB)×0.135USD×112円＝480,423円
  • リクエスト: 121億リクエスト÷1万PVあたり×0.012USD×112円＝1,626,240円
• Azure CDN: 620,940円
  • 最初の10TB分の転送量: 10,240(=10TB)×15.46円＝158,310円
  • 次の40TB分の転送量: 31,744B(31TB)×14.56円＝462,629円
• Google Cloud CDN: 1,347,257円
  • 最初の10TB分の転送量: 10,240GB(=10TB)×0.09USD×112円＝103,219円
  • 次の140TB分の転送量: 31,744GB(=10TB)×0.06USD×112円＝213,521円
  • リクエスト: 121億リクエスト÷1万PVあたり×0.0075USD×112円＝1,016,400円
  • キャッシュ フィル: 42,014GB(=41TB)×キャッシュミス5%×0.06USD×112円＝14,117円

結局リクエスト数が多いので、リクエスト数に応じた課金がない Azure CDN の勝利となってしまったわけですね。逆に言うと、サイズが大きめの画像のみ CDN 経由としたり、 アイコン類を CSS Sprite で1枚にまとめたりするとリクエスト数は減らせるでしょう。 また、広告系の Javascript 呼び出しなど、CDN 化する意味がないリクエストがぱっと見で 3割くらいあるようなので、実質リクエスト数は減らすべきかもしれません。

なお、Amazon CloudFront と Google Cloud CDN は同じような料金体系ですが、 Google Cloud CDN の方が 40% 近く安いというのは興味深いところです。

前提で置いた、「オリジンサーバはクラウド外にあるものとします」について、 もしオリジンサーバが EC2・S3・Azure VM・Azure Storage・Google Conmpute Engine・Google Cloud Storage などの「クラウド内」である場合、AWS の場合は追加料金はありませんが、 Azure・GCP はデータ転送量がかかります。 ただし、キャッシュヒット率 95% という前提であれば、5% 分のデータ転送になるので、 それほどの金額ではないと考えます。

なお、月間で数百テラバイト〜ペタバイトクラスの転送量をお持ちの場合、 各社営業に見積もり依頼するとよいでしょう。 月間数十 TB だとちょっと微妙かもしれませんが、 ペタバイトまでいくと定価の数分の1 の金額が出てくると思います。

「SSL/TLS」 詳細説明

「キャッシュ無効化 (削除)」 詳細説明

一度キャッシュしたコンテンツを無効化したい場合が、たまによく非常にあります。 「誤った画像をアップしてしまったので、すぐに差し替えてほしい」 「上げてはいけない画像をアップしてしまったので、すぐに削除してほしい」 系ですね。「そんなのしばらく待てばそのうち差し替わるよ」と思いつつも、 他社が権利を持つタレントや商品の画像だったりすると「すぐに！いますぐに！！」と言われることもあり、悩ましいところです。 あとは、開発者のミスとしては、 「プログラムのミスで TTL を 1ヶ月にしてしまった」というのも、たまにまれによくありますね。

そもそも CDN において、キャッシュ削除というのはかなり時間がかかる処理です。 世界各国のエッジサーバ拠点が数十〜数百もあり、それぞれに数百〜数千台のサーバがあるでしょうから、 全サーバに削除処理を投げるだけでも結構な仕事であることは理解いただけるかと思います。

しかしながら、以前は数十分とか数時間かかっていた気がするのですが、 最近は遅くとも数分で完了するようになっているようです。

また、3社とも “/images/*” などのワイルドカード指定ができますが、 Azure CDN は Akamai のみワイルドカード指定ができないことに注意です。 ワイルドカード指定ができない場合、”/images/0001.jpg”、”/images/0002.jpg” … とひとつずつ無効化を行うしかありません。

無効化にはお金がかかる場合があります。

• Amazon Cloud Front では 1000リクエストは無料、その後は 1リクエストあたり 0.005 USD、
• GCP Cloud CDN では、1リクエストあたり 0.005 USD (最初の 1回目から有料)

Azure CDN では無効化は無料のようです。

「gzip等のCDNでの圧縮」詳細説明

オリジンでのgzip等の圧縮 について

オリジンサーバがもともと gzip 圧縮等に対応している場合、 クライアント (ブラウザ) がオリジンに Accept-Encoding: gzip 付きのリクエストを渡すと、 オリジンサーバはレスポンスヘッダ Content-Encoding: gzip を返した上で、レスポンスボディを gzip 圧縮して返します。

一方、クライアント (ブラウザ) がオリジンに Accept-Encoding: gzip なしでリクエストすると、オリジンは未圧縮のコンテンツを返します。

このような状況でクライアントとオリジンの間に CDN が入ると、どうなるか。Amazon CloudFront・Azure CDN・Google Cloud CDN いずれを経由した場合でも、ヘッダを適切に中継してくれて、上記のとおりに正しく動作します。

CDNでのgzip等の圧縮 について

「オリジンサーバでは圧縮コンテンツを保持していないが、CDN で圧縮を代行してほしい」という場合があります。

この機能は Amazon CloudFront、Azure CDN で使用できます。 Google Cloud CDN では 2019年4月現在、未実装のようです。

「独自ドメイン」 詳細説明

独自ドメイン設定 (http) について

前提として、CDN の設定を行うと、独自の FQDN が割り振られます。 CloudFront であれば d123456abcdef.cloudfront.net などと自動的に設定されますし、 Azure CDN であれば example.azureedge.net などと自分で example の部分を入力します (他の人が使っていない文字列を探す必要があります)。

上記のような FQDN で問題ないなら、そのまま利用すればよいわけですが、 あなたが myservice.net というドメインを持っている場合、 cdn.myservice.net という FQDN にしたくなると思います。

独自ドメイン設定 (https/SSL) について

「公開制限」 詳細説明

国ごとの公開可否設定 について

権利者が存在する動画や画像コンテンツの場合、配信先に「日本のみ」などと制限をかけたい場合があります。

Amazon CloudFront では、国別に許可または拒否を設定可能です。 ホワイトリスト・ブラックリストを選択できるので、 「日本のみ許可」「この国とこの国は拒否」いずれも簡単に設定可能です。 ただし、これらの設定は CloudFront 全体での共通設定になりますので、 例えば「通常ページは見えてよいが、/contents 以下のみ日本のみに制限したい」 という場合は、新たに別の CloudFront 設定を新規作成する必要があります。

Azure CDN でも、ホワイトリスト・ブラックリスト方式で定義ができますが、 「/contents」などのパス別に制御ができるのは AWS よりよい点です。

Google Cloud CDN では、国別のコントロールはできないようです。

署名付き URL (期限付きURL・ワンタイムURL) について

署名付きURLとは、期限付きURL・ワンタイムURLとも呼ばれます。「このコンテンツをダウンロードできるのはN時間以内だけ」と期限を設定したい場合がありますが、これを実現するのが署名付き URL です。

Amazon CloudFront と Google Cloud CDN は署名付き URL に対応しています。Azure CDN は、Premium from Verizon のみです (Standard は不可)。

以下、署名付き URL とは何かを説明します。

例えば動画配信システムなどでは、コンテンツ URL の有効期限を非常に短くしておくのが普通です。これにより「動画ファイルのURL を掲示板などに貼り付けても、他の人が見るころにはすでに期限切れ」が実現できます (他の人が絶対に見ることができない、ではなく、他の人が見るのは現実的には難しい、というリスク軽減策です)。

そもそも、期限管理をしたいのであれば、下記のようにすれば実現できます。

• 一意な ID を払い出す。システム内でDBなどに ID と期限の情報を記憶しておく。
• URL に download?id=xxxxxxxx と指定する。
• アクセスがあるたびに、ID を元に内部のDBを参照し、期限内かどうかをチェックする。
• 期限内ならコンテンツを返す。期限を過ぎていたらエラーとする。

ただし上記のやり方では、DB 内のデータを確認して判定するアプリケーションが必要になってしまいます。動画配信のように大量アクセスが見込まれる場合、これではさばききれません。また、CDN で配信をしたいわけなので、CDN 側で期限内かどうかの判断をしてほしいものです。

また、同じ動画コンテンツをある人は今日視聴し、ある人は明日視聴するわけなので、時間が来たらコンテンツそのものを削除するわけにもいきません。同じコンテンツを「本日12:00に閲覧した人には 12:05 まで、明日12:00に閲覧した人には明日12:05 まで」としたいのです。

そこで、URL に download?expires=123456789012 などと期限のタイムスタンプ秒数をくっつけて CDN 側で期限チェックをできるようにしましょう。CDN 側では expires の値が現在時刻を過ぎていなければ OK、過ぎていたら NG という単純なロジックになります。

「この URL の expires の値を増やした URL にアクセスすれば、誰でも閲覧できてしまうのでは?」と思うかもしれませんが、そのとおりです。ですので、その対策として URL 全体の「署名」をくっつけます。

公開鍵暗号方式にて、 download?expires=123456789012 を秘密鍵で暗号化し、それを末尾に追加します。つまり下記のような感じです。

download?expires=123456789012&signature=jxcGpgMxAJrhF4QMhPrSSZaT7A(略)

署名の検証は CDN 側で公開鍵で行うことができます。よって、単純に expires の値をいじると署名が失敗するので NG というわけです。署名検証が成功するには新しい expires の値に対して秘密鍵で暗号化すればよいのですが、一般利用者は秘密鍵を持っていないので不可能です。

ですから、署名付き URL を 期限設定のために使うのはあくまでひとつの使いみちなだけで、URL パラメータが正しいことを保証する、というのが本来の使い方です。

Amazon CloudFront では期限設定以外にも、「いつ以降なら閲覧可能」「IPアドレスが～なら閲覧可能」という設定が可能です。

Basic・Digest認証 について

「エラー表示」 詳細説明

オリジンが 404 なり 503 なりのエラーを返した場合、 CDN は無味乾燥な英語のエラー画面を表示します。 これで OK であればそれでいいのですが、 「どうしても日本語を出したい」などの要望が出る場合があります。 また、「混み合っているときに 503 になるのは仕方がないとしても、 意味不明な英語ページでは利用者が怒ってしまうので、せめて状況説明とお詫びの言葉を出したい」 という要望もあります。

Amazon CloudFront では、カスタマイズ時に表示する HTML を指定できます。 その際、404 の場合はこのページ、503 の場合はこのページ、などとレスポンスコードごとに指定が可能です (逆に言うと、ひとつひとつレスポンスコードごとに定義をしないといけないのは面倒です)。 また、エラーページの TTL を指定したり (300秒で5分間キャッシュ)、 オリジンが 403 を返した場合は 404 として利用者に返すなど、レスポンスコードの変換も可能です (とはいえいまいち使い所がわからない)。

Azure・Google では、この機能はありません。

その他

オリジンタイムアウト設定について

独自ヘッダ設定について

オリジンへの直接アクセスの禁止 について

「オリジンへの直接アクセスの禁止」について。 CDN に割り振ったドメインが www.example.com であって、 オリジンが www-internal.example.co.jp だとするとき、 www-internal.example.co.jp に直接アクセスされてしまうのは避けたいところです。

オリジンサーバに余計な負荷がかかってしまいます。また、CDN とオリジン両方で正しく動作するように作るのは結構大変ですし、 正しく動作するとしても検証の手間が 2倍になってしまいます。 そのような場合、Amazon CloudFront では独自のヘッダ、例えば “X-CDN-From: hogehoge” という独自のカスタムヘッダを付与し、 オリジンにリクエストを送ることができます。 一方オリジンでは、Apache や Nginx などでそのヘッダが存在しない場合、 直接アクセスとみなして拒否する設定を行います。

クエリ文字列設定について

CDN での TTL 指定について

事前キャッシュ (プリフェッチ) について

マルチオリジンについて

IPアドレスについて

Amazon CloudFront・Azure CDN は、それぞれが提供する IP アドレスのレンジがあり、CDN サービスが提供するのはその中の複数個の IP アドレスとなります。

一方、Google Cloud CDN は CDN 設定ごとに一つだけの IP アドレスを使います。これはリージョンが異なったとしても単一の IP アドレスです。些細な点ですが、運用の簡便さという観点では Google Cloud CDN に軍配が上がるでしょう。

「セキュリティ事故が発生する可能性がある」について

CDN にかぎらず、nginx や Apache proxy などでの内部キャッシュを立てている場合も同じですが、 注意喚起として書いておきます。

2017/06、メルカリが CDN 切替作業の際、やらかしました (詳細)。

簡単にまとめると、下記です。

• マイページなどの個人情報が記載されたページは CDN でのキャッシュ対象外としていた (具体的には Cache-Control: no-cache を出力)。
• これまで利用していた CDN とは別の CDN に切り替え作業を行なった。
• 新 CDN では、Cache-Control: no-cache によってキャッシュ対象外とはならない仕様であった。
• マイページなどがキャッシュされてしまったため、他人の個人情報が閲覧できてしまった。

また、はまりがちな点として、 セッション ID が入った Set-Cookie ヘッダをキャッシュしてしまう、というものがあります。 これにより、他人のセッション ID を受け取ってしまい、次回以降のアクセスでは他人として扱われてしまう事故が考えられます。

CloudFront では、デフォルトでは Cookie・Set-Cookie の中継はしませんが、 中継するように設定することもできます。 GCP Cloud CDN では、Set-Cookie ヘッダが含まれている場合はキャッシュ保存しません。 しかしながら、body 内の Javascript で Set-Cookie している場合は CDN はそれを検知できませんので、 他の人向けの Cookie が設定されてしまう可能性があります。

「CDN の仕様把握をちゃんとしましょう」「Cookie 発行は気をつけましょう」という話ではあるのですが、 そもそも「動的ページでも CDN を通すべきか」はよく考えるべきでしょう。

動的ページでも CDN 経由とするメリットはあります。例えば下記。

• CDN に SSL 復号をまかせたい
• CDN で DDoS 対策を行なってほしい
• DNS の名前解決のスピードを減らすため、img.XXXXX.net のような別 FQDN は極力減らしたい
• 動的ページだけれども、数分間だけキャッシュさせる、といった風に細かなコントロールを行いたい

しかしながらその代償は、 「キャッシュ対象・非対象をちゃんと管理しないと、情報漏えい事故が起こり得る」 です。メリット・デメリットをよく考えて決めてください。