AWS WAF Anti-DDoS no Shield Advanced: guia prático das 5 fases

Eu acompanho mudanças de proteção em nuvem com atenção especial quando elas afetam operação real. E esta é uma delas. A AWS está incorporando o grupo de regras gerenciadas Anti-DDoS do AWS WAF como padrão para defesa contra DDoS na camada de aplicação, a L7, dentro do Shield Advanced. Na prática, isso muda como a mitigação automática passa a funcionar, como eu monitoro eventos e até como eu mantenho meu código de infraestrutura alinhado.

Isso faz sentido. Ataques DDoS em L7 usam requisições HTTP válidas e se misturam ao tráfego comum. Eu já vi esse tipo de situação confundir time técnico, painel de métricas e regra antiga ao mesmo tempo. Quando o ataque parece tráfego normal, resposta rápida e automática deixa de ser luxo e vira requisito.

O novo grupo Anti-DDoS aprende o perfil da aplicação em minutos e reage em segundos quando detecta um ataque.

Outro ponto que me chamou atenção foi a ação Challenge. Em vez de apenas bloquear ou contar, o WAF pode desafiar o navegador com uma verificação silenciosa, sem atrito para usuários legítimos. As sensibilidades de Block e Challenge são independentes e ajustáveis em Low, Medium ou High. Para quem opera ambientes críticos, como os atendidos pela Interserv Cloud, isso abre espaço para calibrar proteção com mais cuidado.

O que muda na prática

O grupo de regras também ficou mais leve. O consumo caiu de 150 para 50 WCUs, liberando capacidade do web ACL para outras regras. O dashboard Anti-DDoS já está ativo no console da AWS e mostra eventos, métricas e principais fontes do tráfego em tempo real. Além disso, toda requisição recebe labels, o que permite criar regras próprias no WAF com base nesses sinais.

A observabilidade agora fica mais rica, porque cada request carrega contexto que pode ser visto em logs, métricas e regras derivadas.

Na cobrança, há um detalhe muito bom. Durante mitigação ativa, o tráfego bloqueado por DDoS fica fora das cobranças mensais. E, no período de avaliação, web ACLs automaticamente cobertos não terão taxa por esse recurso. Ainda assim, eu recomendo olhar quantos recursos cada web ACL protege antes de fechar conta de custo.

Se você quiser ampliar a base do tema, eu sugiro a leitura de conteúdos sobre segurança em nuvem e também este material sobre defesa atual contra ataques DDoS na cloud.

Tráfego válido também ataca.

As 5 fases com datas e o que eu faria em cada uma

A transição ocorre em cinco fases. Aqui, seguir a ordem faz diferença.

1. Fase 1, de 27 de julho a 7 de agosto de 2026: o grupo Anti-DDoS começa a ser incluído em web ACLs elegíveis em modo Count, sem impacto no tráfego. Eu trataria esse momento como janela de observação. É a hora de abrir o dashboard, revisar labels e entender o comportamento novo sem risco de bloqueio indevido.

2. Fase 2, até 30 de setembro de 2026: período de avaliação gratuita. Eu compararia detecção do sistema antigo com o novo, conferiria logs e testaria prioridade de regras no web ACL. Começar com sensibilidade Low para Block ajuda a reduzir falso positivo.

3. Fase 3, a partir de 1º de outubro de 2026: atualização automática conforme a configuração anterior do cliente. Se o antigo estava mitigando, o novo tende a assumir ação compatível, ativando Block ou mantendo Count, conforme o caso. Aqui eu checaria se o web ACL real ficou igual ao esperado no console e no IaC.

4. Fase 4, antes de 1º de janeiro de 2027: migração assistida para quem não entrar na atualização automática ou precisar de ajuste manual. Esse ponto costuma pegar estruturas mais customizadas, principalmente com governança centralizada.

5. Fase 5, em 1º de janeiro de 2027: o sistema antigo de mitigação automática em L7 é desativado. Quem não migrar perde a proteção automática na camada de aplicação. Simples assim.

Em cenários de alto tráfego, eu não deixaria essa revisão para dezembro. A Interserv Cloud trabalha justamente com ambientes que não podem parar, e este tipo de mudança pede antecedência, não improviso.

Observabilidade em três níveis

Eu gostei da forma como a observabilidade foi ampliada. Agora há três níveis bem claros de monitoramento:

• Detecção de eventos, com métricas separadas para Shield e Anti-DDoS.

• Análise de labels, incluindo níveis de suspeita e requests elegíveis para Challenge.

• Métricas de mitigação, somando o que foi bloqueado ou desafiado.

Há também um alerta operacional que eu não ignoraria. Alarmes existentes baseados em DDoSDetected continuam valendo para eventos de infraestrutura, L3 e L4. Já para camada de aplicação, o novo indicador a acompanhar é DDoSAttackRequests.

Se o seu alarme de L7 ainda depende só de DDoSDetected, ele pode deixar de refletir o que mais interessa após a migração.

O contexto brasileiro reforça esse cuidado. Houve 470.677 ataques DDoS registrados no Brasil no segundo semestre de 2025, com peso grande na América Latina. Depois, um crescimento de 24% em maio de 2026 mostrou que o problema segue em alta. E eu achei bem revelador ver que Norte e Nordeste passaram a concentrar mais de metade das anomalias mitigadas, enquanto o país também respondeu por quase metade dos incidentes da América Latina.

IaC e Firewall Manager sem dor de cabeça

Um risco pouco comentado é a divergência entre infraestrutura real e código. Como a AWS pode fazer mudanças durante o upgrade, templates de IaC precisam ser atualizados para refletir que a proteção passa a vir do AWS WAF como fonte da regra, e não mais do mecanismo antigo no Shield para L7.

Eu faria assim:

• Mapear web ACLs cobertos pela migração automática.

• Revisar prioridades de regras, porque o novo grupo precisa entrar sem quebrar a ordem lógica do ACL.

• Atualizar módulos, templates e variáveis para refletir o grupo Anti-DDoS no WAF.

• Sincronizar o estado após o upgrade automático, evitando drift entre console e repositório.

Se a gestão estiver no AWS Firewall Manager, eu seguiria um roteiro simples:

1. Abrir a política de WAF atual.

2. Inserir o novo grupo de regras gerenciadas Anti-DDoS na política.

3. Manter ou ajustar o escopo para cobrir as mesmas contas e recursos protegidos antes.

4. Conferir prioridade e interação com regras existentes.

5. Só retirar estruturas antigas no fim da migração, nunca antes, para evitar desproteção em L3 e L4.

Quem quiser reforçar esse tema pode consultar também os materiais sobre boas práticas de segurança, técnicas atuais de defesa contra DDoS e resiliência em nuvem AWS.

Conclusão

Eu resumiria assim: a mudança melhora a defesa em L7, traz Challenge, reduz consumo de WCU, amplia visibilidade e exige atenção com datas, alarmes, custo e IaC. Entre 27 de julho e 7 de agosto de 2026 começa o modo Count. Até 30 de setembro ocorre a avaliação gratuita. Em 1º de outubro de 2026 entra a atualização automática. E em 1º de janeiro de 2027 o sistema antigo sai de cena.

Se eu estivesse planejando agora, revisaria o dashboard Anti-DDoS, compararia os dois modelos de detecção, leria as labels nos logs, iniciaria Block em Low e alinharia o código de infraestrutura logo após o upgrade. Para empresas com operação crítica, esse cuidado evita surpresa técnica e financeira. Se você quer apoio para desenhar essa migração com segurança, vale falar com a Interserv Cloud e entender como o ambiente pode ficar mais resiliente sem interromper o negócio.

Perguntas frequentes

O que é o AWS WAF Anti-DDoS?

É um grupo de regras gerenciadas do AWS WAF voltado à mitigação de ataques DDoS na camada de aplicação, a L7. Ele aprende o padrão de tráfego da aplicação em poucos minutos, reage em segundos e pode contar, bloquear ou aplicar Challenge em requisições suspeitas.

Como configurar o AWS WAF em 5 fases?

Eu seguiria a sequência da própria mudança. Na Fase 1, observar o modo Count. Na Fase 2, validar logs, labels e custo durante a avaliação gratuita até 30 de setembro de 2026. Na Fase 3, conferir a atualização automática a partir de 1º de outubro. Na Fase 4, ajustar casos manuais ou centralizados por Firewall Manager. Na Fase 5, antes de 1º de janeiro de 2027, garantir que o ambiente já não dependa do sistema antigo.

AWS WAF protege contra quais tipos de ataques?

Ele protege aplicações web contra vários ataques na camada HTTP e HTTPS, como DDoS em L7, padrões maliciosos em requisições, abuso de bots conforme a configuração adotada, exploração de falhas comuns em aplicações e tráfego fora de perfil definido pelas regras do web ACL.

Qual a diferença do Shield Advanced?

O AWS WAF aplica regras no tráfego web e toma ações como Count, Block e Challenge. Já o Shield Advanced é o serviço de proteção avançada que cobre também eventos de infraestrutura, como L3 e L4, e agora passa a incluir o grupo Anti-DDoS do WAF como padrão para assinantes na mitigação automática de L7.

AWS WAF vale a pena sem o Shield?

Sim, porque qualquer cliente pode ativar o grupo Anti-DDoS separadamente no AWS WAF. Para muitas aplicações, isso já entrega visibilidade, labels, dashboard e ações de mitigação úteis. Ainda assim, eu avaliaria o nível de exposição, o volume de tráfego e a necessidade de proteção mais ampla antes de definir o desenho final.