CDNが配信すべきものを決める
まずはインベントリを作成します。画像、スタイルシート、スクリプト、フォント、ダウンロードなどのバージョン管理されたアセットと、HTML、API、アカウントページ、チェックアウト、管理画面を分離してください。CDNはオンデマンドでキャッシュを埋めることが多く、最初のリクエストはオリジンに到達する一方、その後の一致するリクエストはエッジで配信される可能性があります。近隣のエッジとキャッシュヒットは別個の利点です。
各パスにファイルを供給するホスト、アプリケーション、ストレージバケット、またはロードバランサーを書き留めてください。キャッシュミス時に応答できる必要があります。
すべての訪問者で同一のアセットから始め、宣言された寿命が切れるまで安全に利用可能であるものに長めの寿命を与えてください。
個人用ダッシュボード、セッションに紐づくページ、顧客データは、資格のあるエンジニアが分離を設計・テストしていない限り共有しないでください。
コンテンツの挙動からキャッシュポリシーを決める
HTTPレスポンスヘッダーはキャッシュ挙動を表現します。Cache-Controlはレスポンスが保存可能かどうかとどれだけ新鮮であるか（TTL：time to live）を示します。ブラウザはプライベートキャッシュであり、CDNは通常共有キャッシュです。明示的なヘッダーを使ってください。HTTP標準では s-maxage により共有キャッシュの寿命を max-age と別に設定できます。
内容が変わるときは新しい URL を公開してください（例：コンテンツハッシュを含むファイル名）。不変のバージョンには長めの寿命を与えます。
古いコンテンツのコストに基づいて短い寿命か検証ベースの挙動を選んでください。価格、在庫、アカウント状態に対してアセットルールを使い回さないでください。
一人のユーザー向けレスポンスには private を使ってください。クッキーだけでは共有キャッシュで安全とはなりません。
無効化（パージ）は例外にし、リリース計画にしない
無効化（パージ）は管理されたCDNに保存された特定のオブジェクトを通常の有効期限前に破棄する指示です。修正時に使い、すべてのデプロイで使うべきではありません。パージする前にオリジンが既に置換物を返すことを確認してください。そうしないとリフィルで古い誤ったレスポンスが残る可能性があります。ブラウザキャッシュはCDNのパージ制御外なので、変更ファイルにはURLバージョン管理が確実です。
サイト全体のパージより、特定のパス、リリースグループ、プロバイダがサポートするキャッシュタグを優先してください。広範なミスは突然オリジンへ負荷をかけます。
分散パージはすべてのエッジに一度に到達しないことがあります。プロバイダの完了意味論を確認し、代表的な URL をテストしてください。
古いと新しい URL、キャッシュルール、パージ範囲、想定結果、逆戻し手順を記録してください。
オリジンを配信レイヤーの裏に置く
オリジンへ直接アクセスされるとCDNのキャッシュやエッジ制御をバイパスできます。CDNだけ、または意図した経路のみが到達できるように制限してください。使用するスタックによってはクラウドのオリジンアクセス制御、CDNのエグレス範囲を記載したファイアウォールルール、プライベートネットワーク、署名付きオリジンリクエスト、または相互TLS（mTLS）のように両側が証明書で認証する方法を使います。
許可されたテストロケーションから、オリジンが公開リクエストを拒否し、CDNホスト名が機能することを確認してください。
ヘルスチェック、デプロイツール、内部アクセスは広い公開ルールではなく、アイデンティティとネットワークでスコープしてください。
オリジン認証はCDNとオリジンによって異なります。最新のプロバイダ設定ガイダンスとセキュリティレビューを使ってください。
TLSは二つの接続として扱う
エッジでのHTTPSは来訪者とCDN間を保護しますが、CDNとオリジン間の接続も保護する必要があります。両方の区間で暗号化を要求し、CDNモードに応じてオリジン証明書を検証し、ホスト名と更新の所有権を割り当ててください。OWASPはデフォルトで TLS 1.3 を推奨し、互換性のために TLS 1.2 を許容し、TLS 1.0 と 1.1 は無効にすべきだと述べています。規制データ、支払いフロー、または特殊なクライアント互換性がある場合は資格あるレビューを受けてください。
エッジとオリジンの証明書所有者、更新経路、失敗時の対応を列挙してください。
HTTP→HTTPS、正規ホスト、深いリンクのリダイレクトでループやパス喪失が起きないかテストしてください。
暗号化はレスポンスをキャッシュして安全にするものではありません。認証済み・個人化・支払いに関連するページには別個にキャッシュルールを設定してください。
トラフィックを切り替える前に実際の配信経路をテストする
ステージングホスト名や狭いプロダクション経路から始め、オリジンだけでなくCDNホスト名をテストしてください。Chrome DevTools の Network パネルはステータス、ドメイン、タイミング、サイズ、ヘッダーを表示します。初回訪問を近似するために空のキャッシュでハードリロードを実施し、その後の再訪問で再利用を確認してください。見た目が速いだけでなく期待するヘッダーとコンテンツを比較してください。受信者が広い地域に分散している場合は代表的な地域から繰り返しテストしてください。
Cache-Control とプロバイダの cache-status ヘッダーを検査してください。公開アセットが再利用され、機密ページが誤って共有されていないことを確認します。
ミス、古いコンテンツの修正、オリジンエラー、単一アセットやルートのロールバックを広範な展開前に実行してください。
テストしたURL、ヘッダーキャプチャ、ルートルールのバージョン、変更前後のタイミングを変更記録と一緒に保存してください。
運用ニーズでCDNを選び、証明する
PoP数（ポイント・オブ・プレゼンス）や一般的な速度主張だけでCDNを選ばないでください。パフォーマンスは地理、時間、トラフィック分布、ルーティング、キャッシュヒット率で変わります。候補は代表的な経路、アセット、地域で比較してください。各社が必要なキャッシュ制御、ターゲット無効化、オリジン制限、証明書ワークフロー、ログ、アクセス役割、価格、サポート、変更プロセスをサポートするか確認してください。
候補ごとに同一のキャッシュヘッダー、オリジン挙動、ページを使い、初回訪問と再訪問の結果を別々に記録してください。
リクエスト、転送、無効化、ログ、サポート費用に加え、キャッシュミス急増時のコストを検討してください。価格と制御はプランによって異なります。
エクスポート可能な設定、最小権限、テスト済みロールバック、明確な所有権をクリティカルなルートに適用することを要求してください。