AWS WAFの導入事例

参考になった

レビュー投稿日の情報になります

合同会社DMM.com / d-ochiai

メンバー / バックエンドエンジニア

最終更新日2026/05/13投稿日2026/05/15

ツールの利用規模	ツールの利用開始時期
10名以下	2025年11月

ツールの利用規模	10名以下
ツールの利用開始時期	2025年11月

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

DMMオンラインサロンのサービスが定期的に外部からの攻撃を受けていた
アプリケーション層での対策により攻撃自体は防げていたが、「そもそもそこに到達する前にブロックしたい」という課題があった
攻撃のたびにアラートが飛び、状況確認に時間を取られていた

どのような状態を目指していたか

アプリケーション層に到達する前に攻撃をブロックできる状態
攻撃対応に追われることなく、本来の開発業務に集中できる状態

比較検討したサービス

Cloudflare WAF
Imperva

比較した軸

既存のCloudFront環境に簡単にアタッチできること
マネージドルールを活用でき、ゼロからルールを作成する必要がないこと
AWSの他サービスとの連携が容易であること

選定理由

既存のCloudFrontに簡単にアタッチできる
マネージドルールを活用すれば、ゼロからルールを作成する必要がない
AWSの他サービスとの連携が容易

導入の成果

改善したかった課題はどれくらい解決されたか

WAFをBlockモードにした後、攻撃によるアラートがほぼなくなった
アプリケーションに到達する攻撃が激減した

どのような成果が得られたか

攻撃アラートの消失により、状況確認に取られていた時間が削減
アプリケーションサーバーへの負荷が軽減され、サービス全体が安定化
攻撃対応に追われることがなくなり、本来の開発業務に集中できるようになった

導入時の苦労・悩み

ルール選定: WCU上限1500を超えると追加料金が発生するため、「とりあえず全部入れる」ことができず、サービス特性と想定攻撃パターンを考慮して1500WCUギリギリに収まる範囲で選定する必要があった
誤検知対応: サービス間で特殊なフォーマットのリクエストをやり取りしており、これがWAFのルールに引っかかり攻撃として分類されてしまった
検証期間の判断: 当初1ヶ月のCount検証を予定していたが、攻撃が継続しており「早くBlockモードにして攻撃を止めたい」状況のなか、2週間で前倒し移行を決断する必要があった

導入に向けた社内への説明

上長・チームへの説明

WAF導入を提案するにあたり、まず「どのWAFを採用するか」「WAFでできることの洗い出し」「費用のざっくり試算」を整理し、その結果をまとめてチームと上長に共有する形で進めた
AWS WAF・Cloudflare・Impervaの3サービスを「機能」「料金モデル」「運用」の3軸で比較し、機能ではボット対策やDDoS防御、検知インテリジェンスでCloudflareが優位である一方、基本的なWAFとしての役割(OWASP Top 10対応、レート制限など)はAWS WAFでも十分に果たせること、また既存のAWSリソースにアタッチするだけで導入できる手軽さがAWS WAFの大きな強みであることを伝えた
費用については、サロンの実トラフィックに即した試算を提示した
最終的には、(1)基本的なWAF機能はAWS WAFにも揃っている、(2)サロンのリクエスト数ならコスト面でも合理的、(3)インフラをAWS & Terraformで管理しているためAWS WAFの方が管理しやすいという3点を採用理由として説明した
- 加えて、誤検知やコストへの懸念に応える形で、段階的導入の方針もセットで提示した
- 具体的には、まずマネージドルールをカウントモードで導入して検知内容・トラフィック・コストを実測し、誤検知の状況を確認しながらBlockモードへ切り替えること、という運用ロードマップを合わせて共有し、合意を得て導入に至った