AWS WAF Anti-DDoSマネージドルールをCloudFrontで1年間運用した結果を確認してみた

はじめに

2025年2月、当サイトは ClaudeBot から1時間あたり5万件規模のスパイクを受けました。それ以降、AIクローラーによるトラフィックスパイクが1〜2か月に1回のペースで継続して発生しています。Bot Control の CategoryAI 基準で見ると、年8回ほど2σを超えるスパイクが記録されている状況です。この経緯は以前の記事にまとめています。

https://dev.classmethod.jp/articles/aws-waf-bot-control-claudebot-spike/

2025年6月12日、AWS WAF の Anti-DDoS マネージドルール（AWSManagedRulesAntiDDoSRuleSet）が一般提供（GA）されました。機能の概要はたかくにさんの記事が詳しいです。

https://dev.classmethod.jp/articles/aws-waf-automatic-application-layer-ddos-protection/

定期的に発生するスパイクへの追加の保険として、当サイトではこの Anti-DDoS マネージドルールを導入しました。導入時によく言われる「まずはカウントモードで様子を見ましょう」を、そのまま1年間実践してみた結果報告が本記事です。

本記事で確認するのは次の4点です。

• DDoSイベントの検知実績（13か月でルールは発火したのか）
• トラフィックスパイクの実態（そもそもスパイクは起きていたのか）
• スパイク時のサービスへの影響（エラー率は悪化したのか）
• 運用コスト（13か月でいくらかかったのか）

検証内容

Web ACL 設定の確認

Anti-DDoS マネージドルールを Priority 100 に配置し、ルールグループ全体とサブルールすべてを Count モードで運用してきました。Challenge の感度（Sensitivity）は HIGH、SensitivityToBlock は LOW です。API パスや静的アセットは ExemptUriRegularExpressions で除外しています。

設定の該当部分を抜粋します（アカウントID・リソースIDはマスク済み）。

{
    "WebACL": {
        "Name": "my-waf-bot-webacl",
        "ARN": "arn:aws:wafv2:us-east-1:123456789012:global/webacl/my-waf-bot-webacl/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "Rules": [
            {
                "Name": "AWS-AWSManagedRulesAntiDDoSRuleSet",
                "Priority": 100,
                "Statement": {
                    "ManagedRuleGroupStatement": {
                        "VendorName": "AWS",
                        "Name": "AWSManagedRulesAntiDDoSRuleSet",
                        "ManagedRuleGroupConfigs": [
                            {
                                "AWSManagedRulesAntiDDoSRuleSet": {
                                    "ClientSideActionConfig": {
                                        "Challenge": {
                                            "UsageOfAction": "ENABLED",
                                            "Sensitivity": "HIGH",
                                            "ExemptUriRegularExpressions": [
                                                {
                                                    "RegexString": "\\/api\\/|\\.(acc|avi|css|gif|ico|jpe?g|js|json|mp[34]|ogg|otf|pdf|png|tiff?|ttf|webm|webp|woff2?|xml)$"
                                                }
                                            ]
                                        }
                                    },
                                    "SensitivityToBlock": "LOW"
                                }
                            }
                        ],
                        "RuleActionOverrides": [
                            {
                                "Name": "ChallengeAllDuringEvent",
                                "ActionToUse": { "Count": {} }
                            },
                            {
                                "Name": "ChallengeDDoSRequests",
                                "ActionToUse": { "Count": {} }
                            },
                            {
                                "Name": "DDoSRequests",
                                "ActionToUse": { "Count": {} }
                            }
                        ]
                    }
                },
                "OverrideAction": { "Count": {} },
                "VisibilityConfig": {
                    "SampledRequestsEnabled": true,
                    "CloudWatchMetricsEnabled": true,
                    "MetricName": "AWS-AWSManagedRulesAntiDDoSRuleSet"
                }
            }
        ]
    }
}

OverrideAction と3つのサブルール（ChallengeAllDuringEvent / ChallengeDDoSRequests / DDoSRequests）の RuleActionOverrides をすべて Count にし、観測専用としています。まず Count モードで発動状況を確認し、検知が確認できた段階で本来のアクションに切り替える想定でした。具体的には OverrideAction を Count から None に変更し、各サブルールの RuleActionOverrides を削除します。これにより各サブルールのデフォルトアクションである Challenge / Block が有効になります。

DDoSイベント検知の結果

Count モードでの運用なので、ルールが発火していれば CloudWatch メトリクスにデータポイントが残ります。GA前後の2025年6月から2026年7月18日まで、運用全期間のメトリクスをルール全体と各サブルールについて確認しました。

結果は、全サブルールでデータポイントなしでした。確認した CloudWatch メトリクスの範囲では、13か月間に Anti-DDoS の3つのサブルールへ一致したリクエストは記録されていません。特に、イベント中の challengeable なリクエストに一致する ChallengeAllDuringEvent もゼロだったことから、DDoSイベントの検知を示す挙動は確認できませんでした。

一方で、別のマネージドルールグループである Amazon IP Reputation List の AWSManagedIPDDoSList は日常的に反応しています。直近8日間の推移が次のとおりです（2026年7月18日はデータ取得時点までの途中値）。

完了済みの7月11〜17日を見ると、IP DDoS List は日20〜170件ほどのペースで反応しており、AWS が DDoS 活動への関与を特定した IP アドレスからのアクセスは日常的に届いていることが分かります。ただしこれは IP レピュテーションによる評価であって、Anti-DDoS マネージドルールが行う「DDoSイベントの検知」とは別物です。

参考までに、Anti-DDoS マネージドルールのサブルール構成は次のとおりです。3つのサブルールはいずれも DDoSイベント検知後に作用するため、イベントが検知されなければ発動しません。

トラフィックスパイクの分析

Anti-DDoS ルールが発火しなかったのは、そもそもスパイクが起きていなかったからではないか。トラフィックの日次統計で確認します。

集計期間は18か月（2025年1月18日〜2026年7月18日）としました。起点はデータ取得日から18か月前です。Anti-DDoS 導入前の約5か月間もベースラインとして含めることで、導入前後を通してスパイクの有無を確認できます。

平均+2σ（約328万リクエスト/日）を閾値として超過日を抽出すると、次の4日が該当しました。なお、これは全体トラフィックを基準にした2σ超えであり、「はじめに」で触れた Bot Control CategoryAI 基準の「年8回」とは別の指標です。

最大となった2026年4月9〜10日のスパイクを1時間単位で詳しく見てみます。なお、日次集計はUTC基準、時間単位の分析はJSTで表記しています。JSTで4月10日に発生した増加の一部は、UTC基準の日次表では4月9日分に含まれます。

4月10日は CountedRequests が730万件に達しましたが、Anti-DDoS マネージドルールの反応はゼロでした。AllowedRequests は393万件でした。Count は非終端アクションであり、複数ルールのメトリクスに同一リクエストが重複して計上されるため、両者を単純に差し引くことはできません。ただし Bot Control などの Count ルールで多数のマッチが発生していたことは確認できます。IP DDoS List のヒットもこの日は45件にとどまっています。日次最大の4月9日（平均の3.8倍）を含むこのスパイク期間中、Anti-DDoS マネージドルールは一度も発火しませんでした。

スパイク時のサービス影響

最大スパイク前後（2026年4月8〜11日）の TotalErrorRate です。

この期間の CloudFront 5xxErrorRate（CloudFront がビューアーに返した5xxレスポンスの割合）は、スパイク当日の4月9〜10日（48時間帯）で0.000%でした。トラフィックが平均の3.8倍に達した日を含めて、5xxレスポンスの増加は確認できませんでした。

次に2025年12月のスパイク前後（12月1〜5日）です。

この期間の5xxエラー率は平均0.002556%でした。ピークでも12月4日23時の0.1188%で、しかもスパイクが収束した後の深夜帯です。スパイクのピークと5xxのピークは一致していません。

比較のため、スパイクのない通常時（2026年7月14〜17日）も見ておきます。

通常時の5xxエラー率は平均0.000019%でした。TotalErrorRate は2.7〜3.7%ありますが、5xxErrorRate が極小であることからその大半は4xxです。

3つの期間を並べると、スパイク中の TotalErrorRate（0.5〜0.6%）はむしろ通常時（2.7〜3.7%）より低いという結果になりました。スパイク中は正常レスポンス（2xx/3xx）の割合が相対的に増え、総リクエスト数の増加によって TotalErrorRate が低下したと考えられます。少なくとも CloudFront の 5xxErrorRate を見る限り、トラフィックが3.8倍になった期間にもビューアーへの5xxレスポンスの増加は確認できませんでした。

コスト実績

13か月間の月別コスト内訳です。Anti-DDoS マネージドルールの料金は、サブスクリプション（$20/月、時間按分）とリクエスト処理料金（$0.15/100万リクエスト）の合算になります。これは WAF 基本リクエスト料金（$0.60/100万リクエスト）とは別に発生する追加料金です。2025年6月から2026年6月までの13請求月分の累計は$393.33、月平均は$30.26でした（2026年7月分は請求確定前のため含めていません）。

初月（2025年6月）はサブスクリプション料金が請求されず、リクエスト料金の$0.85のみが計上されていました。公式にはサブスクリプション料金は時間単位で按分されるとされていますが、初月に計上されなかった理由は請求データからは特定できませんでした。それ以降は毎月サブスクリプション$20が発生しています。料金体系の詳細はAWS WAF の料金ページに記載されています。参考までに、同じく DDoS 保護を強化する AWS Shield Advanced は$3,000/月です。ただし WAF 料金込み・DRT 支援込みなど機能範囲が大きく異なるため、単純な価格比較はできません。

challengeable-request ラベルの活用

DDoSイベントの検知はゼロでしたが、このルールには常時利用していた副次的な機能があります。awswaf:managed:aws:anti-ddos:challengeable-request ラベルです。

Anti-DDoS マネージドルールが付与する6種のラベルのうち、challengeable-request だけが DDoSイベントの発生に関係なく常時付与されます（除外URI以外）。

当サイトでは、この常時付与される challengeable-request ラベルを Rate-based rule の条件として使っていました。具体的には Priority 203 の waf-bot-Ratebased-JA4-NonJPUS ルールのスコープダウンステートメントに組み込んでいます。DDoSイベントの検知がゼロでも、このラベルの利用目的だけで Anti-DDoS マネージドルールを維持する価値がありました。

なぜ発火しなかったのか

発火しなかった具体的な理由は、公開情報と今回取得したメトリクスだけでは特定できません。Anti-DDoS マネージドルールの検出条件はトラフィックベースラインからの「著しい逸脱（significant deviation）」です。このベースラインは AWS が自動構築するもので、ユーザーが検知閾値を直接調整する手段はありません。

ピーク1時間値は418,867リクエスト（1時間平均で約116 req/sec）でした。今回確認できたのは、このトラフィック変化では Anti-DDoS サブルールへの一致が記録されなかったという点です。CloudFront がトラフィックを処理できたことと、Anti-DDoS の検知条件を満たすかどうかは別の問題です。

詳細はAnti-DDoS ルールグループの公式ドキュメントおよびアプリケーション層 DDoS 保護のドキュメントに記載されています。

まとめ

Anti-DDoS マネージドルールを CloudFront 環境で13か月間 Count モード運用した結果、DDoSイベントの検知を示すメトリクスはゼロでした。平均の3.8倍に達するスパイクを含めても Anti-DDoS サブルールへの一致は記録されず、確認したスパイク期間中の CloudFront 5xxErrorRate も増加は見られませんでした。当サイトのトラフィック規模と13か月間の観測範囲では、今回確認した程度のスパイクではこのルールは発動しなかった、というのが運用結果です。一方で、常時付与される challengeable-request ラベルを Rate-based rule の条件として活用できたのは副次的な収穫でした。月$30程度を「発火しなくても安心料として払えるか」は、サイトの規模やリスク許容度次第だと思います。小規模サイトなど、保護対象のワークロード費用に対してサブスクリプション$20/月の比率が大きい場合は、費用対効果を定期的に見直したほうがよいかもしれません。当サイトでは、DDoSイベント発生時の検知と challengeable-request ラベルの利用を目的に、引き続き Count モードで維持することにしました。