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 は未導入である点を明記し、将来的な導入検討を「次のアクション」として位置づけています。