キャッシュしない CloudFront とそのメリット・デメリット

Posted on

AWS WAF は CloudFront と統合されているので、AWS WAF を単体で使うことはできません。よくある EC2 + ELB といった構成で AWS WAF を導入するには、ELB の前段にキャッシュしない CloudFront を挟むことで実現できます（そのうち ELB にも AWS WAF が導入できるようになると思いますが）。

このキャッシュしない（させない） CloudFront を検証する機会があったので、その手順とメリット・デメリットについて考えてみました。

キャッシュしない CloudFront の設定

Cache Behavior を次のように設定すれば、CloudFront にまったくキャッシュされず、すべてのリクエストがオリジンサーバに届きます。

CloudFront の Cache Behavior Settings

  • Allowed HTTP Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
  • Forward Headers: ALL
  • Object Caching: Forward Headers を ALL にすると 3 つの TTL は強制的に 0 になる
    • Minimum TTL: 0
    • Maximum TTL: 0
    • Default TTL: 0
  • Forward Cookies: ALL
  • Query String Forwarding and Caching: Forward all, cache based on all

動的なコンテンツを意図せずキャッシュしてしまうと重大な障害になるので、この情報を鵜呑みにせずよく検証してから導入してください。

キャッシュしない CloudFront のメリット・デメリット

キャッシュしない CloudFront は CDN 本来の「エッジサーバにコンテンツをキャッシュし高速に配信する」というメリットがありません。

ですが、CloudFront には他にもメリットがあります。

  • HTTP/2 や IPv6、gzip 圧縮といった技術要素を手軽に導入できる（オリジン側の変更は不要）
  • DDoS 対策に一定の効果がある（「AWS 上での DDoS 対策」の P.42 を参照）
  • 単一リージョンで世界中にサービス展開しているような構成だとレイテンシ改善が期待できる
    • CloudFront のエッジは世界中に 50 以上あり、最も近いエッジサーバに誘導されるから
    • CloudFront のエッジサーバからオリジンサーバへのリクエストは AWS の太いバックボーンを通るから

ざっとこんなところでしょうか。 Slack は上記で挙げたメリットを最大限に享受しているようです。

デメリットについても考えてみます。

  • キャッシュしない CloudFront だと毎回オリジンサーバにアクセスするため、ホップ数が増えることによるレイテンシ悪化が考えられる
  • X-Forwarded-For ヘッダが変わる
    • クライアントの IP アドレスを取得している処理を見直す
    • ログ分析基盤にも影響があるかも

1 つ目は HTTP/2 や gzip 圧縮といった技術で高速化が期待できるので、ユーザーの体感速度にそれほど影響はなさそうです。 2 つ目も十分に検証すれば回避できるはずなので、導入をためらうほどの大きなデメリットはなさそうです。

まとめ

AWS WAF を導入するために検証していましたが、それ以外にもいろいろなメリットがあることがわかりました。

サービスインしてから CloudFront を導入するのはなかなか大変ですが、これから新規に作るのであればとりあえず設定しておくのが良さそうですね。

Popular Entries

Recent Entries