cloudflare入れてみた

• AKS 環境の月次コストが高止まりしており、現状の構成維持が難しい状況

• Azure Front Door のリクエスト課金・転送量課金が想定以上に影響

• コスト削減と構成の簡素化を実現する方策を検討する必要がある

• 目的：月次コスト削減と構成の簡素化

• AIとの壁打ちの結果、Cloudflare で同等機能を低コストに実現可能と判断

• slidict に Cloudflare を導入した経緯

  • 理由は「コストを下げられそう」という結論に至ったため

• 現在の構成（実施後/現状）：

  • Internet → Cloudflare DNS/CDN → Cloudflare Tunnel → Internal Ingress → AKS

• Cloudflare 採用の判断軸

  • コスト：無料枠＋定額で予測しやすい

  • 通信経路：AKS をインターネット非公開化、Public IP/LB削減、セキュリティ向上

  • 運用：Azure 依存度を下げ、グロobal 配信/TLS/DNSを集約

• 現時点の評価基準

  • 月次コストの低減

  • レイテンシの実用域（特に日本）

  • AKS 側の Public Endpoint 減少

  • Tunnel 経由の通信安定性

• 防御面については現時点で WAF 未導入のため今後強化予定

• 判断・意思決定

  • Front Door から Cloudflare への移行を決定

  • Cloudflare Tunnel による通信量抑制を期待

  • WAF は現状未導入だが、将来的な導入を想定

• 運用上の方針

  • Azure 依存度を低下させ、グローバル配信・TLS・DNS を Cloudflare に集約

• 今後の展望と段階的な導入案

  • Cloudflare WAF 導入案を検討

  • 段階導入候補：Managed WAF Rules、Rate Limiting、Bot Management

• 注意点

  • 高度なルーティングや Azure ネイティブ連携が必要なケースでは Front Door の価値が残る可能性

• 現状の解決策

  • AKS + Cloudflare Tunnel に移行し、Front Door を置換

  • 外部公開を抑え、セキュリティとコストの両面で改善を狙う

• 主な成果と現状の効果

  • 月次コストの低減見込み/実績の向上

  • Public Ingress/LoadBalancer の削減による運用負荷低減

  • Cloudflare Tunnel 経由の通信安定性の向上

  • インターネット露出の低減とセキュリティ向上の可能性

• 今後の課題と計画

  • WAF 導入による防御強化を段階的に進める予定

  • 追加の最適化（キャッシュ戦略、ボット対策、レートリミット等）を検討

• Cloudflare Analytics での検証

  • Tunnel 経由トラフィック量、キャッシュヒット率、国別/ボット比率を確認

• AKS 側の最適化

  • Ingress Controller を internal 寄りに配置、不要な LoadBalancer を削除

• WAF 導入準備（段階導入）

  • ログモードでの WAF 有効化 → 実運用での影響度を可視化

  • Managed WAF Rules、Rate Limiting、Bot Management の効果を評価

• ベースラインの再検討

  • Front Door 導入時の想定コストを試算し、将来の比較材料として残す

• 進行状況の可視化

  • トラフィック構成とコストの定常的なモニタリング体制を整備

補足: 現状、WAF は未導入である点を明記し、将来的な導入検討を「次のアクション」として位置づけています。