🤔

【仕事日記】なぜ Web インフラは「CDN」「WAF」「静的ドメイン分離」が必要なのか？

に公開
仕事
WAF
インフラ
CDN
tech

近年、Web サービスのインフラ構成は複雑になっています。
特に CDN と WAF の順番、そして 静的ドメイン（static.example.com）の分離は、実際に運用している人でも混乱するテーマです。

この記事では、初心者でも理解できるように CDN・WAF・静的ドメイン分離の理由や仕組みをわかりやすく解説します。

✅ この記事でわかること

  • CDN と WAF の違いと役割
  • なぜ 静的ファイルを別ドメインで配信するのか？
  • なぜ Internet → WAF → CDN → App が微妙で、Internet → CDN → WAF → App が推奨されるのか？
  • でも WAF → CDN の構成を使うケースはあるのか？
  • 実際の運用現場で起きる問題（sub_filter の障害など）
  • 将来どういう構成が理想なのか

1. まずは用語の基本

CDN（Content Delivery Network）

  • 画像、CSS、JavaScript などの静的ファイルをキャッシュして高速に配信する仕組み
  • エッジサーバーが世界中にあり、ユーザーに近い場所から配信 → レイテンシ削減
  • 代表例：CloudFront, Akamai, Fastly

WAF（Web Application Firewall）

  • Web アプリケーションへの攻撃（SQLインジェクション、XSS）を検知・ブロック
  • アプリケーションの前に置く防御壁
  • 代表例：Imperva, AWS WAF, Cloud Armor

2. CDN と WAF の一般的な順番

✅ 推奨される構成


Internet → CDN → WAF → Application

理由：

  1. 静的リソースは CDN で完結
    → WAF に不要なトラフィックが行かない
  2. WAF は動的リクエストだけに集中
    → コスト削減 & レイテンシ低下
  3. DDoS の初期防御は CDN が担当
    → エッジで防御して、WAF の負担軽減

❌ 逆に WAF → CDN だと？


Internet → WAF → CDN → Application
  • すべてのリクエスト（画像/CSSまで）が WAF を通過 → WAF の負荷が増大
  • キャッシュされるはずの静的リソースも WAF で検査 → 無駄な課金・コスト増
  • 結果的に CDN のメリットが薄れる

じゃあなぜ WAF → CDN にするケースがあるの？

  • 金融・官公庁など、すべての通信を必ず WAF で検査する必要がある環境
  • CDN を完全に信用できない場合
  • DDoS 時に CDN 側の転送料金が跳ね上がるのを嫌う場合

Imperva WAF には CDN 機能もあるけど、
CDN キャッシュしたレスポンスも 課金対象なので、
コスト読みが難しい → 分離運用を選ぶケースもある。

3. 静的ドメイン（static.example.com）を分ける理由

  1. WAF 通過を避けてコスト削減

    • 画像やCSSまで WAF を通すと通信量課金が高額になる
    • 静的リソースは CloudFront などで完結 → 安価＆高速

  2. キャッシュポリシーの最適化

    • 静的ファイルは Cache-Control: max-age=1y
    • 動的 API はキャッシュしない → ドメイン分けると管理が楽

  3. HTTP/1.x 時代の同時接続制限回避

    • 同じドメインは 6 接続まで → ドメイン増やして並列ロード
    • 今は HTTP/2/3 でほぼ不要だが、昔の慣習が残ることも

  4. セキュリティ分離

    • static.example.com は Cookie やセッション情報を持たせない
    • XSS 時にメインドメインへの影響を分離できる

4. 実際の運用で起きた問題

nginx sub_filter による障害

  • 1つのサイトなのに静的ファイル用ドメインを分ける構成だった
  • しかし HTML 内の URL を書き換えるために nginx の sub_filter という機能を利用
  • これが EKS 移行後に不具合を起こし、CSS が崩れる障害が発生

5. Imperva CDN 機能は使えないのか？

  • Imperva などのクラウド WAF は CDN 機能も持っている
  • しかし、キャッシュ済みレスポンスも Imperva の転送料金に含まれる
  • stale-while-revalidate の挙動もイマイチ
  • 結果 → CloudFront + Imperva の分離構成が採用された

6. 結局、今はどんな構成が最適？

現状のベストプラクティスは…


\[ユーザー]
↓
CDN(CloudFront)
↓
WAF(Imperva)
↓
ロードバランサ(ALB/Nginx)
↓
Spring Boot アプリケーション
↓
DB/キャッシュ/S3
  • 静的リソースは static.example.com → CloudFront 100% キャッシュ
  • 動的リクエストは api.example.com → CDN → WAF → App

7. HTTP/2/3 時代のこれから

  • HTTP/1.x の制約（同時接続6本）はもう不要
  • セキュリティ/Cookie 分離も CSP で代替可能
  • 将来的には ドメイン分離しない統合構成もあり得る

でも現実は…

  • WAF課金モデル
  • CDN課金モデル
  • DDoS 対策の運用コスト
    → これらの理由でまだ「静的分離」が続いているケースが多い

8. まとめ

  • CDN はキャッシュ、WAF はセキュリティ、それぞれ役割が違う
  • 理想的な順序は CDN → WAF → App
  • しかしコストやセキュリティ要件で WAF → CDN になることもある
  • 静的ドメイン分離は WAF コスト削減 & キャッシュ最適化のためにやることが多い
  • ただし nginx sub_filter などの暫定対応は障害リスク大
  • HTTP/2 以降ではドメイン分離のメリットは減ってきており、将来は統合も検討すべき

🔜 次に考えるべきこと

  • WAF/CDN の統合コスト比較
  • HTTP/2/3 + CSP ベースでドメイン統合できるか検討
  • sub_filter のようなワークアラウンドを排除した安全な構成

💡 さらに学びたい人向け

  • Imperva Cloud WAF + CDN のキャッシュ挙動
  • CloudFront と WAF の課金モデルの違い
  • Spring Boot や SPA のデプロイ戦略と CDN 連携

Discussion