AWS Shield Advancedでは、アプリケーションレイヤー（L7）のDDoS保護方式が変わります。今後の標準となるのは、AWS WAF Anti-DDoSマネージドルールグループです。2026年7月27日から対象となるWeb ACLへCountモードで段階的に追加され、既存のShield AdvancedによるL7自動緩和と並行して動作します。その後、2027年1月1日に従来のShield Advancedアプリケーションレイヤー自動緩和が終了する予定です。
この変更は、単なるマネージドルールの追加ではありません。DDoS対策の検知・緩和ポイント、監視方法、請求、IaC、Firewall Managerの管理方法まで見直す必要があります。特に、Countモード期間を「何もしなくてよい期間」と捉えると、切り替え後の誤検知や監視漏れにつながります。
何が変わるのか
従来は、Shield Advancedが攻撃と判断したトラフィックに対して、アプリケーションレイヤーの自動緩和を適用していました。今後は、AWS WAFのマネージドルールグループがL7 DDoS対策の中心になります。
移行期間中は、次のような状態になります。
- Anti-DDoSマネージドルールグループが対象Web ACLにCountモードで追加される
- Countモードでは、ルールに一致したリクエストを記録するが、通常はブロックしない
- 既存のShield Advanced L7自動緩和は並行して動作する
- Count期間中にログ、メトリクス、誤検知、既存ルールとの関係を確認する
- 2027年1月1日以降は、従来のShield Advanced自動緩和に依存できなくなる
実際の適用対象、切り替え方法、ルールグループの詳細な挙動は、利用しているリソースやAWSの最新ドキュメントによって異なる可能性があります。対象Web ACLを一覧化し、AWSアカウントやリージョン単位で適用状況を確認することが第一歩です。
Countモードで確認すべきポイント
Countモードは、緩和機能を安全に検証するための観測期間です。まず、WAFログのruleGroupListやterminatingRule、非終了ルールの一致情報を確認し、どのURL、HTTPメソッド、送信元、ユーザーエージェントが検知対象になっているかを調べます。
特に確認したいのは、次の4点です。
1. 正常な大規模アクセスが検知されていないか
ログイン集中、セール開始、チケット販売、モバイルアプリのアップデートなど、短時間にアクセスが急増する処理はDDoS攻撃と似た特徴を持つことがあります。業務イベントの時間帯とルール一致数を突き合わせ、正当なバーストを誤検知していないか確認します。
2. 既存のWAFルールと競合していないか
既存のIP制限、レートベースルール、Bot対策、カスタムルールとAnti-DDoSルールグループの検知結果を分けて集計します。ルールの評価順序や、先に終了するAllow・Block・Challengeルールによって、期待した分析結果が得られない場合があります。
3. APIや特殊な通信を壊さないか
ブラウザアクセスだけでなく、API、Webhook、バッチ、IoTクライアントなども対象にします。特定のヘッダー、Cookie、HTTPメソッド、長時間接続を利用する通信は、代表的な正常リクエストを保存して検証すると安全です。
4. 運用担当者が検知理由を説明できるか
インシデント対応では、「攻撃らしい」という判断だけでなく、どのメトリクス、ログ、リクエスト属性を根拠にしたかが必要です。Count期間中に、検知から調査、緩和判断、解除までのRunbookを作成しておきます。
移行を5つのフェーズで進める
フェーズ1：資産と依存関係の棚卸し
Shield Advancedで保護しているCloudFront、ALB、API Gatewayなどと、それに関連するWeb ACLを一覧化します。Web ACLの所有者、適用環境、トラフィック量、重要度、障害時の連絡先も併記します。
あわせて、Web ACLをTerraform、CloudFormation、AWS CDK、AWS Firewall Managerのどれで管理しているかを確認します。コンソールで手作業により追加された設定があると、次回のIaC適用で意図せず削除される可能性があります。
フェーズ2：Countモードで観測する
AWS WAFログをS3、CloudWatch Logs、Security Lakeなどに集約し、Anti-DDoSルールグループの一致数を可視化します。CloudWatchメトリクスだけでなく、アクセスログやアプリケーション側のエラー率、レイテンシー、認証失敗数も同じ時間軸で確認します。
フェーズ3：誤検知と例外を整理する
誤検知が見つかった場合は、すぐに広範囲のAllowルールを追加するのではなく、対象パス、送信元、ヘッダー、レート、業務時間帯などを限定して影響を抑えます。例外設定が必要な場合は、なぜ例外にしたのか、どの攻撃シナリオを許容することになるのかを記録します。
フェーズ4：本番緩和を前提に運用を検証する
切り替え後に、誰がブロック状況を確認し、どの条件で緩和するかを決めます。ページャー通知の閾値、WAFログの保存期間、攻撃時のAWSサポートへの連絡手順、アプリケーション所有者との承認フローも事前に定義します。
フェーズ5：従来機能への依存を排除する
2027年1月1日の終了前に、監視ダッシュボード、アラート、Runbook、設計書から「Shield AdvancedのL7自動緩和が必ず動作する」という前提を取り除きます。障害訓練や負荷試験では、通常時だけでなく攻撃時の検知・通知・復旧手順も確認します。
IaCとFirewall Managerで見直す項目
IaCでは、Web ACLのルール定義、ルールの優先順位、Managed rule groupのバージョン指定、ログ設定、メトリクス名、タグを確認します。AWSが対象Web ACLへ自動的に追加する設定と、TerraformやCloudFormationが管理する定義が食い違うと、ドリフトや更新失敗が起きる可能性があります。
対策として、まず現状をエクスポートしてリポジトリとの差分を確認し、検証用アカウントでplanや変更セットを実行します。マネージドルールグループをIaCで明示的に管理する場合は、AWSが自動追加する設定と重複しないか、管理対象と適用方式を最新ドキュメントで確認してください。
AWS Firewall Managerを利用している場合は、ポリシーがWeb ACLを強制管理していないか、既存のWAFルールグループと競合しないかを確認します。組織内の複数アカウントへ展開するポリシーでは、例外アカウント、リージョン、リソース種別、ログ設定の差異も洗い出します。
請求とメトリクスは別途確認する
マネージドルールグループの導入に伴う料金は、Web ACL、ルールグループ、リクエスト数、Shield Advancedの契約状況など複数の要素に左右されます。Countモードだから追加費用がない、または本番緩和に切り替えると必ず一定額になる、と決めつけるのは危険です。AWSの料金ページと請求明細を確認し、検証環境を含めた月額見積もりを作成します。
メトリクス名や集計単位が変わる場合に備え、既存ダッシュボードをそのまま信頼しないことも重要です。WAFの許可・ブロック数、ルールグループの一致数、CloudFrontやALBの5xx、レイテンシー、アプリケーションエラーを組み合わせ、単一のメトリクスだけで攻撃判定しない構成にします。
移行チェックリスト
- Shield Advancedで保護するリソースとWeb ACLを棚卸しした
- Countモードの追加状況と適用対象を確認した
- WAFログとCloudWatchメトリクスを分析できる
- 正常なアクセス急増を使って誤検知を確認した
- 既存のWAFルールとの優先順位と競合を確認した
- Terraform、CloudFormation、CDKのドリフトを確認した
- Firewall Managerポリシーと例外設定を見直した
- 料金と請求明細への影響を試算した
- インシデント対応Runbookと通知先を更新した
- 2027年1月1日以降も成立する設計としてレビューした
今回の変更で重要なのは、AWSが提供する保護機能を有効化することではなく、検知結果を自社の監視・運用・変更管理に組み込むことです。Countモードの期間を検証と準備に使い、従来の自動緩和が終了した後も、何を根拠に守り、誰が判断し、どの設定をコードで再現するのかを明確にしておく必要があります。
出典： AWS公式ブログ