AWS Shield Advanced が AWS WAF Anti-DDoS マネージドルールグループを採用: 変更点と準備方法

2026 年 7 月 29 日: AWS Firewall Manager の移行パスを明確にするため、この記事を更新しました。

アプリケーションレイヤーの分散型サービス拒否 (DDoS) 攻撃は、正規のトラフィックと非常によく似ているため、検出が困難です。現在、HTTP リクエストフラッドはウェブアプリケーションを標的とする最も一般的な攻撃ベクトルの 1 つであり、通常のユーザーアクティビティに紛れ込む、正規に見えるリクエストを使用します。

2025 年 6 月、AWS はアプリケーションレイヤー (L7) の DDoS 保護に特化して構築された AWS WAF Anti-DDoS マネージドルールグループの提供を開始しました。AWS Shield Advanced は、これをアプリケーションレイヤー保護のデフォルトとして採用し、将来的には唯一の保護機能とします。2026 年 7 月 27 日から、AWS Shield Advanced は対象となるウェブアクセスコントロールリスト (ウェブ ACL) に Anti-DDoS マネージドルールグループを Count モードで追加し始めます。既存の L7 自動緩和および WAF ルールと併用しても、トラフィックが中断されることはありません。この記事では、Anti-DDoS マネージドルールグループの詳細と、この変更がウェブ ACL に適用される時期について説明します。また、完了期日までのフェーズと実施する必要がある手順に加え、モニタリングとメトリクスがどのように変わるかについても解説します。

Anti-DDoS マネージドルールグループは、Shield Advanced の自動緩和がすでに提供している機能を基盤としています。トラフィックをプロファイリングし、アプリケーションの通常のトラフィックを学習して、数時間ではなく数分でベースラインを確立します。攻撃が始まると数秒以内に対応し、ヘルスチェックを設定する必要はありません。このルールグループでは、すでに使用している Block および Count アクションに Challenge アクションが追加されます。Challenge の判断は、検査した各リクエストの疑わしさのレベルを示す Anti-DDoS マネージドルール (AMR) ラベルに基づいて行われます。選択肢の 1 つであるサイレントブラウザチャレンジでは、訪問者のブラウザ上でバックグラウンド検証が実行され、インタースティシャルページは表示されません。そのため、自動化されたトラフィックを除外しながら、正規ユーザーの操作を中断することはありません。また、Challenge をサポートしていないワークロードのパスを除外し、代わりに Block による緩和を適用することもできます。感度は Low、Medium、High のいずれかに設定でき、Block と Challenge に対して個別に設定します。Block と Challenge は個別に調整できます。つまり、より多くの疑わしいトラフィックを検出するために Challenge の感度を High にしながら、正規のリクエストをドロップしないよう Block を Low に保つことができます。逆に設定して、より厳格な保護態勢にすることも可能です。

その他の利点は、コストと可視性に関するものです。

• 従来よりも少ないキャパシティで動作します。 このルールグループに必要なウェブ ACL キャパシティユニット (WCU) は 50 です。従来の保護機能で必要だった 150 WCU から削減されるため、他のルールで使用できるキャパシティが増えます。
• AWS WAF の AWS マネジメントコンソールにダッシュボードが用意されています。 このダッシュボードはすでに利用可能で、進行中の DDoS イベント、マッチメトリクス、トラフィックの主な発生元となっている URI、地域、IP アドレスを確認できます。
• 検査するすべてのリクエストにラベルを付与します。 リクエストには、event-detected、段階的な疑わしさのレベル、特定のルールを示すラベルが付与されます。ルールグループだけでは対応できないロジックが必要な場合は、独自の AWS WAF ルールでこれらのラベルに対するマッチ条件を設定できます。
• 攻撃トラフィックに対する料金は発生しません。 緩和がアクティブな間、ブロックされた DDoS リクエストは月間リクエスト数から除外されます。この除外は、AWS WAF のリクエスト料金、Anti-DDoS マネージドルールグループのリクエスト料金、Shield Advanced のリクエスト料金に適用されます。

これらの機能を使用するために AWS Shield Advanced は必須ではありません。Shield Advanced をご利用のお客様は、このルールグループを AWS WAF に含まれる形で月間 500 億リクエストまで追加料金なしで利用できます。また、どのお客様でも個別に有効化できます。コストの詳細については、AWS WAF の料金を参照してください。

Shield Advanced は、5 つのフェーズでアプリケーションレイヤー DDoS 保護をアップグレードします。以下の日付は AWS が自動的に対応を行う日付であり、お客様が対応を開始できる最も早い日付ではありません。2026 年 7 月 27 日にルールグループが Count モードでデプロイされた後は、10 月の自動アップグレードを待たずに、すぐに移行を開始できます。保護が中断する期間はありません。現在の自動緩和は、Anti-DDoS マネージドルールグループが引き継ぐまで、すべてのフェーズを通じて有効なままです。この引き継ぎは一度のオペレーションで行われるため、切り替え時間は発生せず、トラフィックフローの保護に空白期間は生じません。

AWS は、このロールアウトの対象となるすべてのウェブ ACL に Anti-DDoS マネージドルールグループを Count モードで追加します。対象となるのは、アプリケーションレイヤー自動緩和を使用しているリソースが少なくとも 1 つあり、Anti-DDoS ルールグループをまだ実行していない Shield Advanced のウェブ ACL です。この対象範囲は、より厳格な条件が適用される 10 月の自動アップグレード (フェーズ 3) の対象ウェブ ACL よりも広くなります。デプロイは 7 月 27 日から段階的に行われ、2026 年 8 月 7 日までに完了する予定です。そのため、ウェブ ACL によって更新日が異なる場合があります。既存の自動緩和が引き続き実行される一方で、ルールグループはリクエストを監視してラベルを付与するだけであり、リクエストに対するアクションは実行しないため、トラフィックへの影響はありません。評価期間中は、追加料金なしで DDoS イベント、メトリクス、AWS WAF ラベルを利用できます。

既存の自動緩和と Anti-DDoS マネージドルールグループが並行して実行され、それぞれが独立して検出を行います。ルールグループが Count モードで動作する間も、自動緩和がリソースを引き続き保護します。両者の検出結果を比較するには、DDoSAttackRequests メトリクス、AWS WAF ラベル、Anti-DDoS ダッシュボードを使用します。この期間中は、フェーズ 1 の対象ウェブ ACL について、サブスクリプション料金、リクエストごとの料金、WCU 消費にかかる料金を含む、Anti-DDoS マネージドルールグループのすべての料金が免除されます。

対象のウェブ ACL では、自動アップグレードによって既存の自動緩和設定が引き継がれます。ルールグループは現在の設定を継承するため、Block 設定の場合は Block モードで、Count 設定の場合は Count モードで、単一のアトミックなオペレーションで切り替わります。自動緩和を無効化するのと同時にルールグループが保護を引き継ぐため、一瞬たりとも保護が失われることはありません。これは切り替え時間を伴うカットオーバーではなく引き継ぎであり、リソースが保護されない期間はありません。アップグレードを希望しない場合は、自動アップグレード日より前に AWS サポートに連絡することでオプトアウトできます。

移行するために 10 月の自動アップグレードを待つ必要はありません。2026 年 7 月 27 日から 8 月 7 日までの間にルールグループが Count モードでデプロイされ次第、お客様のスケジュールに合わせて移行できます。これは、フェーズ 3 の自動アップグレードの対象にならないウェブ ACL、つまりモードが混在するウェブ ACL や、自動緩和が有効になっていないリソースを含むウェブ ACL で使用する移行パスです。この期間中はいつでも、AWS アカウントチームおよび AWS サポートと連携して移行を計画し、完了できます。対象のウェブ ACL は 10 月 1 日から自動的にアップグレードされるため (フェーズ 3)、ガイド付き移行は主に、自動アップグレードでは対応できないウェブ ACL を対象としています。

2027 年 1 月 1 日をもって、Shield Advanced のアプリケーションレイヤー自動緩和機能は利用できなくなります。Anti-DDoS マネージドルールグループに移行していないリソースでは、アプリケーションレイヤー DDoS の自動緩和が失われます。

既存の自動緩和と Anti-DDoS マネージドルールグループは、それぞれ異なる Amazon CloudWatch 名前空間とメトリクス構造を使用します。このルールグループでは、3 つの階層 (ティア) でオブザーバビリティを提供します。ティア 1 では攻撃が発生しているかどうかを確認でき、ティア 2 ではフラグが付けられたリクエストとその理由を確認でき、ティア 3 ではそれらのリクエストに対して実行されたアクションを確認できます。最初から 3 つすべてを使用する必要はありません。多くのお客様のチームでは、まずティア 1 で検出が機能していることを確認し、その後、調整を進めながら他のティアを追加します。

それぞれ異なる名前空間を使用する 2 つの CloudWatch メトリクスによって、DDoS イベントを検出できます。

既存のアラームへの影響:

• アプリケーションレイヤー自動緩和機能の終了後も、DDoSDetected はインフラストラクチャレイヤーであるレイヤー 3 およびレイヤー 4 のイベントに対して発報します。そのため、既存のネットワークレイヤーおよびトランスポートレイヤーのアラームは引き続き有効です。すべてのメトリクスについては、AWS Shield Advanced メトリクスを参照してください。
• DDoSAttackRequests は、Anti-DDoS マネージドルールグループにおけるアプリケーションレイヤーのイベント検出用メトリクスです。すべてのイベントを検出するには Sum >= 1 でアラームを設定します。重大度に基づくアラートを行う場合は、ボリュームのしきい値 (例えば、1 分あたり 10,000 リクエスト超) を設定します。
• 評価期間中は両方のメトリクスが独立して発報するため、アプリケーションレイヤーのアラームを移行する前に、検出の同等性を検証できます。
• アクティブな DDoS イベントがない場合、DDoSAttackRequests はデータが存在しない状態になるため、このメトリクスのアラームでは treat-missing-data を missing または notBreaching に設定してください。

Anti-DDoS マネージドルールグループが評価するすべてのリクエストにはラベルが付与されます。ティア 1 では攻撃が始まったことを確認できるのに対し、ティア 2 では疑わしいと判断されたリクエストと、ルールグループによる判断の確信度を確認できます。これらのラベルは、AWS/WAFV2 名前空間の AWS WAF メトリクス (AllowedRequests、BlockedRequests、CountRuleMatch) として公開されます。各メトリクスは、awswaf:managed:aws:anti-ddos: 名前空間の LabelName および LabelNamespace ディメンションを持ちます。

• event-detected – 検出された DDoS イベント中に観測されたリクエスト
• ddos-request – 攻撃の一部として識別されたリクエスト
• low-suspicion-ddos-request、medium-suspicion-ddos-request、high-suspicion-ddos-request – 段階的な疑わしさのレベル
• challengeable-request – ブラウザチャレンジの対象になりうるリクエスト

CloudWatch ダッシュボードに疑わしさのレベルの傾向をグラフ表示すると、攻撃が拡大する様子を確認できます。独自の AWS WAF ルールでラベルに対するマッチ条件を設定することも、特定のイベントを事後に把握する必要がある場合に、CloudWatch Logs Insights または Amazon Athena を使用して AWS WAF ログを詳しく調査することもできます。

ティア 2 ではルールグループがフラグを付けた対象を確認できるのに対し、ティア 3 ではイベント中にそれらのリクエストに対して実行したアクションを確認できます。これらのメトリクスは ChallengeRequests、BlockedRequests、CountRuleMatch として確認でき、それぞれ、生成元のルールラベルごとに区分されます。

• ChallengeAllDuringEvent – アクティブなイベント中にチャレンジされたリクエスト
• ChallengeDDoSRequests – 疑わしさのレベルに基づいてチャレンジされた、DDoS の疑いがあるリクエスト
• DDoSRequests – ブロックされた (Count モードでカウントされた) リクエスト

進行中のイベントでこれらを監視し、緩和が攻撃に対応できているかを確認してください。ブロックするリクエストよりもはるかに多くのリクエストにチャレンジしている場合、設定が慎重すぎる可能性があります。数値を信頼できるようになった後で、感度レベルを引き上げることができます。

Shield Advanced サブスクリプションには、組織全体について支払いアカウントレベルで集計される、1 か月あたり最大 500 億リクエスト分の Anti-DDoS マネージドルールグループの利用が含まれています。ほとんどのお客様にとって、この上限は通常のトラフィック量を大きく上回るため、非常に大規模なトラフィックを処理している場合を除き、この項目が請求に現れることはありません。正確な料金については、AWS WAF の料金および Shield Advanced の料金を参照してください。

Anti-DDoS マネージドルールグループがアクティブに緩和を行っている間は、DDoS トラフィックに対する料金は発生しません。アクティブな緩和とは、Count モードではなく、Block または Challenge モードで動作している状態を指します。この措置は、AWS WAF のリクエスト料金、Anti-DDoS マネージドルールグループのリクエスト料金、Shield Advanced のリクエスト料金に適用されます。評価期間を過ぎてもルールグループを Count モードのままにしておくと、保護が得られないまま、請求免除も受けられなくなります。そのため、検証に必要な期間を超えて Count モードを継続することは避けてください。

評価期間 (2026 年 7 月 27 日 ～ 9 月 30 日) 中は、AWS が自動的に登録した対象ウェブ ACL について、Count モードで設定されている場合も含め、リクエストごとの料金や WCU 消費にかかる料金は発生しません。

Anti-DDoS マネージドルールグループはウェブ ACL レベルで動作するため、ウェブ ACL に関連付けられているすべてのリソースが同じ保護を共有します。単一のリソースがコスト全体を占めていると判断する前に、各ウェブ ACL の背後にあるリソースがどれくらいあるかを確認してください。20 個のリソースを保護するウェブ ACL と 2 個のリソースを保護するウェブ ACL では請求額が異なります。まずこの数を確認し、各ウェブ ACL が保護するワークロードを把握してください。

お客様自身でウェブ ACL に Anti-DDoS マネージドルールグループを追加することはアップグレードパスの一部ではないため、有効化した時点から標準料金が適用されます。ロールアウト前からルールグループを実行していたリソースについても同様です。無料評価を利用するには、ルールグループを事前に追加せず、自動ロールアウトがウェブ ACL に適用されるのを待ってください。お客様自身で追加してもペナルティはありませんが、そのウェブ ACL では料金免除を受けられません。

AWS CloudFormation、AWS Cloud Development Kit (AWS CDK)、Terraform、またはその他の Infrastructure as Code (IaC) でウェブ ACL を管理している場合、自動アップグレードによって、テンプレートの外部からインフラストラクチャ設定が変更されます。コードは引き続き信頼できる唯一の情報源であるため、2 つの作業が必要です。まず、保護を宣言する場所を変更します。現在、アプリケーションレイヤー自動緩和は Shield API (EnableApplicationLayerAutomaticResponse) を通じて有効化し、保護対象リソースごとに設定します。一方、Anti-DDoS マネージドルールグループでは、設定スコープはリソース単位ではなくウェブ ACL 単位となり、AWS WAF API (CreateWebACL および UpdateWebACL) を通じて、ウェブ ACL 内のマネージドルールグループステートメントとして設定します。IaC では、Shield の自動レスポンスブロック (例えば Terraform の aws_shield_application_layer_automatic_response) を削除し、次のセクションで示す WAF マネージドルールグループステートメントを追加します。次に、次回のデプロイ前に、アップグレードされたウェブ ACL をツールに取り込みます。これを行わないと、パイプラインが変更を元に戻そうとします。

Terraform、CloudFormation、AWS CDK の完全なステートメントと、自動アップグレード後に状態を同期する方法 (terraform plan、CloudFormation のドリフト検出、cdk diff) については、iac-webacl-examples ヘルパーを参照してください。

現在 AWS Firewall Manager で Shield Advanced ポリシーを実行している場合、作業を開始する前に Automatic application layer DDoS mitigation (アプリケーションレイヤー DDoS の自動緩和) 設定を確認してください。この設定によって、本セクションのどの部分が該当するかが決まります。設定が Ignore (無視) または Disable (無効) の場合、そのポリシーはこの緩和を一切管理していません。リソースに適用されている緩和は、リソース自体または Shield を通じて有効化されたものであり、無効化する際もそれらの同じ場所で行う必要があります。

Shield Advanced ポリシーの設定が Enable (有効) の場合は、まず AWS WAF Firewall Manager ポリシーを追加するか既存のポリシーを再利用し、そのポリシーに Anti-DDoS マネージドルールグループを含めます。そのうえで、Shield Advanced ポリシーが対象としているものと同じアカウントおよびリソースを、そのポリシーのスコープに設定する必要があります。

移行プロセス全体を通じて、Shield Advanced ポリシーはそのまま維持してください。アカウントやリソースをスコープから削除したり、ポリシーを削除したりしないでください。Firewall Manager は、スコープから外れた対象について、自身が作成した Shield Advanced の保護を解除してしまいます。これにより、置き換えようとしているアプリケーションレイヤーの緩和に加えて、L3 および L4 の保護も終了します。代わりに、設定変更によって従来の緩和を終了します。新しいルールグループが有効になり、2 つの保護機能を比較した後、現在 Enable (有効) になっている Shield Advanced ポリシーの Automatic application layer DDoS mitigation (アプリケーションレイヤー DDoS の自動緩和) を Disable (無効) に設定します。

この変更は、コンソールまたはコードで実施できます。Firewall Manager ポリシーをコードで管理している場合は、コンソールで編集しないでください。テンプレートに新しい AWS WAF ポリシーを追加するか、既存のポリシーを更新して Anti-DDoS マネージドルールグループを含め、後述の「IaC を使用する Firewall Manager ポリシー」の手順に従ってデプロイします。それ以外の場合は、コンソールを使用します。

コンソールでは、AWS WAF 用の AWS Firewall Manager ポリシーの作成の手順に従ってポリシーを作成し、Edit policy rules (ポリシールールの編集) ページに移動します。そこでは AWS AntiDDoS Protection for Layer 7 attacks (AWSManagedRulesAntiDDoSRuleSet) と表示される Anti-DDoS ルールグループを、First rule groups (最初のルールグループ) の新しいルールグループとして追加します。これにより、他のマネージドルールグループより先に評価されます。ただし、既知の安全なトラフィックを迅速に処理するために使用している許可カスタムルールがある場合は、そのルールより後に配置します。

CloudFront ディストリビューションを保護する場合は、Global ポリシーでこの変更を行い、リージョンリソースについては各 AWS リージョンのポリシーで同じ操作を行います。ポリシーを保存すると、Firewall Manager がスコープ内のアカウントに変更をロールアウトします。これには数分かかる場合があります。

追加後、次のスクリーンショットのように、ルールグループがポリシーの最初のルールグループとして表示されます。

図 1: AntiDDoS が有効になっている状態

Firewall Manager ポリシーをコードで管理している場合は、コンソールではなくテンプレートで変更します。Anti-DDoS マネージドルールグループは、AWS WAF ポリシーの ManagedServiceData に追加します。これは JSON 文字列として渡される WAFV2 ポリシー定義です。早い段階で評価されるよう、最初のルールグループに追加します。CloudFormation、Terraform、AWS CDK の例を含む ManagedServiceData JSON については、firewall-manager-examples ヘルパーを参照してください。

どちらの方法を取る場合でも、移行中にアプリケーションレイヤーの保護を失うリソースがないよう、既存の Shield Advanced ポリシーが対象としているものと同じアカウントおよびリソースをポリシーのスコープに設定します。

2026 年 7 月 27 日から 8 月 7 日までの間に、AWS は、アプリケーションレイヤー自動緩和を使用しているリソースを含み、Anti-DDoS ルールグループをまだ使用していない Shield Advanced のウェブ ACL に、Anti-DDoS マネージドルールグループを Count モードで追加します。ウェブ ACL に追加された後は、10 月の自動アップグレードを待たずにルールグループを評価し、準備が整い次第移行できます。

• AWS WAF コンソールで Anti-DDoS ダッシュボードを確認します。 ダッシュボードには、リアルタイムの DDoS イベント、マッチメトリクス、トラフィックの主な発生元が表示されます。
• イベント検出を並べて比較します。 Count モードでは、両方のシステムが独立して検出を行います。リソースにおける検出の同等性を検証するため、AWS/DDoSProtection の DDoSDetected メトリクスと AWS/WAFV2 の DDoSAttackRequests を並べて確認します。AWS Samples リポジトリから CloudWatch 比較ダッシュボードをデプロイすると、両方のシステムを 1 つのダッシュボードで確認できます。
• AWS WAF ラベルを調査します。 AWS WAF ログを有効にし、awswaf:managed:aws:anti-ddos: 名前空間のラベルをクエリします。疑わしさのレベル (low-suspicion-ddos-request、medium-suspicion-ddos-request、high-suspicion-ddos-request) と、event-detected、challengeable-request を確認し、検出されたイベントをリクエスト単位で可視化します。
• Block アクションの感度は Low から開始します。 評価中は感度を Low にすることで、誤検知のリスクを最小限に抑えられます。Anti-DDoS ダッシュボードと AWS WAF ラベルのデータから確信を得られるようになったら、感度を引き上げます。
• 設定を計画します。 感度レベル、非 HTML パスに対する URI の除外設定、ウェブ ACL 内の優先順位を確認します。Anti-DDoS マネージドルールグループはウェブ ACL 内で最も高い優先順位に配置するか、Allow アクションを設定したカスタムルールがある場合は、その直後に配置します。
• IaC テンプレートを同期します。 自動アップグレードによってウェブ ACL に Anti-DDoS マネージドルールグループが追加された後、次回のデプロイ前に、現在の状態を IaC ツールに取り込みます (Terraform refresh、CloudFormation のドリフト検出、AWS CDK import)。

Anti-DDoS マネージドルールグループは、数時間かけてベースラインを確立していた従来の自動緩和を基盤としながら、数分以内にトラフィックをプロファイリングし、数秒以内に緩和を行います。また、実行している処理を詳細に可視化できます。評価期間は、何かが変更される前に、お客様自身のトラフィックで両方のシステムが動作する様子を確認できるように設けられています。最初の数週間は Count モードで、新しい検出が現在確認している結果と一致することを検証してください。その後、アラームを移行し、適切と判断した感度レベルを選択します。複数のリソースにまたがってウェブ ACL を使用している場合や、AWS Firewall Manager でルールを管理している場合は、後から設定を元に戻す必要が生じないよう、作業を開始する前に AWS サポートに連絡してください。Shield Advanced のアプリケーションレイヤー自動緩和機能は 2027 年 1 月 1 日に終了します。この機能に依存しているリソースは、それまでにすべて移行する必要があります。

• アプリケーションレイヤー (L7) DDoS 保護のドキュメント
• Introducing the AWS WAF Application Layer DDoS Protection
• AWS Shield Advanced メトリクス
• 移行ヘルパーと CloudWatch 比較ダッシュボード
• AWS WAF の料金
• AWS Shield Advanced の料金

翻訳はテクニカルアカウントマネージャーの松本が担当しました。