AWS is changing how customers use Shield Advanced for application-layer DDoS protection. Help Net Security reported on July 28, 2026 that AWS is adding the AWS WAF Anti-DDoS managed rule group to eligible web ACLs and that the older Shield Advanced application-layer automatic mitigation feature will no longer be available as of January 1, 2027.
AWS's own Security Blog describes the rollout as a phased migration. The rule group is being added in Count mode between July 27 and August 7, 2026, eligible web ACLs are scheduled for automatic upgrade starting October 1, and guided migration is available through December 31. AWS says existing protection remains active during the transition, but resources that have not migrated by January 1, 2027 will lose automatic application-layer DDoS mitigation.
Why this belongs on an owner's calendar
DDoS protection can sound like a background technical service, especially when it lives inside a cloud subscription. This change is different because it touches policy ownership, monitoring, rule priority, alerting, infrastructure-as-code, and possibly AWS Firewall Manager. That is enough moving parts to deserve a named owner, not a casual note in a ticket queue.
The business risk is not that every AWS-hosted website is suddenly exposed today. The practical risk is that a company assumes its provider handled the migration while alarms, templates, or managed policies still describe the older Shield Advanced setup. DDoS protection is not where anyone wants calendar drift.
The decision is about evidence, not panic
Owners do not need to tune AWS WAF sensitivity settings themselves. They should ask for proof that the people responsible for the environment have reviewed the change and know which web ACLs, applications, and policies are affected.
That review should include whether the AWS WAF Anti-DDoS managed rule group is present in Count mode, whether the team has compared the older Shield metrics with the newer AWS WAF metrics, and whether any non-HTML paths need URI exemptions before Challenge or Block actions are used. If infrastructure-as-code manages the web ACL, the template also needs to match the live cloud configuration after AWS adds the rule group.
Questions to ask your IT provider or cloud team
- Which AWS accounts and web ACLs are eligible for this Shield Advanced migration?
- Has the AWS WAF Anti-DDoS managed rule group appeared in Count mode yet?
- Who is comparing DDoSDetected and DDoSAttackRequests metrics before the migration is treated as complete?
- Will our IaC, AWS CDK, CloudFormation, Terraform, or Firewall Manager policies preserve the new configuration?
- Are there application paths where a Challenge action could break legitimate traffic?
- What date will we use internally, before January 1, 2027, to confirm the old mitigation path is no longer a dependency?
A practical next step
If your business runs public-facing applications on AWS, ask your MSP, hosting provider, or internal cloud team for a short migration note. It should list affected resources, current mode, planned Block or Challenge sensitivity, alert changes, template updates, and the person accountable for signoff.
For New Jersey businesses that depend on online quoting, scheduling, payments, donations, portals, or customer service workflows, this is a good example of cloud security work that should be visible to management. The technical team can handle the AWS WAF details, but the owner should know the deadline, the decision path, and the evidence that protection did not quietly fall between services.
Sources and further reading
