AWS WAF Shield Advanced: guía práctica

Todo lo que siempre quisiste saber sobre AWS WAF y Shield Advanced (pero nunca te atreviste a preguntar). Si has pasado tiempo configurando AWS WAF y Shield Advanced para un servicio en producción, probablemente has chocado con preguntas que la documentación oficial responde a medias o reparte entre cinco paginas distintas. Este post es un Q&A practico basado en experiencia real en
producción, casos de soporte con AWS y una lectura atenta de la documentación oficial.

Fundamentos de Shield Advanced

¿Que añade Shield Advanced sobre Shield Standard?

Shield Standard:

esta incluido para todos los clientes de AWS y protege automáticamente contra ataques comunes de red y transporte (L3/L4).

Shield Advanced añade:

• Visibilidad sobre eventos DDoS detectados por recurso protegido (pestaña Events)
• Automatic Application Layer Mitigation (AALM) — opcional, hay que activarlo explicitamente
• Integracion con Route 53 Health Check para mayor precision en la deteccion
• Proactive Engagement: el Shield Response Team (SRT) te contacta directamente durante un ataque
• Proteccion de costes contra cargos inesperados por escalado causado por un ataque DDoS
• Acceso directo al SRT via casos de soporte Si ya tenemos reglas WAF configuradas, ¿para que necesitamos Shield Advanced? Sin Shield Advanced, tu unica proteccion L7 son las reglas que tienes en tu WebACL. Vuelas parcialmente a ciegas: sin visibilidad de eventos por
  recurso, sin mitigacion automatica, sin escalado al SRT. Shield Advanced añade deteccion y respuesta automatizada encima de tus reglas existentes. ¿Cual es la diferencia entre que Shield detecte un evento y que lo mitigue? Son dos mecanismos separados que se confunden con frecuencia:
• Deteccion: Shield monitoriza patrones de trafico contra baselines historicas y marca anomalias como eventos. Ocurre independientemente de si AALM
  esta activado o no.
• Mitigacion: Shield despliega reglas en el ShieldMitigationRuleGroup dentro de tu WebACL para contar o bloquear el trafico del ataque. Esto solo
  ocurre cuando AALM esta activado. Si AALM no esta activado, Shield detecta y reporta el evento pero no actua sobre el trafico. Tus reglas WAF gestionan todo.

• Cuales son los cuatro escenarios de proteccion?

VAmos a explicarlo con una imagen.

Automatic Application Layer Mitigation (AALM)

¿Que es AALM y que hace exactamente?

AALM es la funcionalidad que convierte a Shield Advanced en activamente defensivo a nivel L7. Cuando se activa, añade un managed rule group llamado
ShieldMitigationRuleGroup_ a tu WebACL. Este rule group contiene siempre:

1. ShieldKnownOffenderIPRateBasedRule — siempre activa, aplica rate limiting a peticiones desde IPs conocidas como fuentes de ataques DDoS.
2. Reglas dinamicas — creadas por Shield durante un ataque activo en funcion de los patrones de trafico detectados. La accion (COUNT o BLOCK) depende de tu configuracion de AALM. ¿Cual es la diferencia entre COUNT y BLOCK en AALM?

• COUNT: Shield despliega sus reglas y contabiliza las peticiones que coinciden, sin bloquearlas. Modo seguro para el periodo de observacion.
• BLOCK: Shield bloquea activamente las peticiones que coinciden. Es el estado de proteccion completa.
• ¿Añade AALM overhead a mi WebACL? Si. El ShieldMitigationRuleGroup consume 150 WCUs (Web ACL Capacity Units). El limite por defecto de una WebACL es 1.500 WCUs. Si tu WebACL ya tiene muchas reglas, tenlo en cuenta antes de activar AALM.
• ¿Debe aplicarse AALM sobre CloudFront o sobre el ALB? Siempre sobre CloudFront cuando hay un CDN delante de tu servicio. AWS afirma explicitamente que cuando un CDN esta delante del ALB, las capacidades de mitigacion automatica sobre el ALB son reducidas porque el CDN no preserva los atributos originales del trafico del cliente que Shield necesita para una deteccion precisa.
• ¿Que es el nuevo Anti-DDoS Managed Rule Group (marzo 2026)? A partir del 26 de marzo de 2026, AWS introdujo el Anti-DDoS Managed Rule Group como reemplazo del mecanismo legacy L7AM. La diferencia clave es la velocidad de respuesta:
  • AALM legacy: minutos
  • Anti-DDoS Managed Rule Group: segundos. Los nuevos clientes de Shield Advanced ya usan el nuevo mecanismo por defecto. Los clientes existentes con AALM legacy necesitan contactar con AWS Support para evaluar la migracion.

AWS recomienda empezar en COUNT y cambiar a BLOCK despues de 30 dias. ¿Por que 30 dias? Shield necesita entre 24 horas y 30 dias para establecer una baseline fiable del trafico normal de tu recurso. Sin esa baseline, la mitigacion automatica no puede distinguir con precision el trafico de ataque del trafico legitimo. Cambiar a BLOCK antes de que la baseline este establecida aumenta el riesgo de falsos positivos.

Reglas WAF y configuracion

¿Es obligatoria una regla de rate limiting en la WebACL para que Shield funcione?

No es obligatoria, pero si critica. Sin una rate-based rule, un ataque de tipo request flood llega al origen sin ningún freno. AWS la describe como la primera linea de defensa contra ataques volumétricos L7. Si AALM no esta activado, la rate-based rule es tu principal proteccion automatizada contra request floods.

¿Por que el WAF debe desplegarse en us-east-1 para CloudFront?

AWS WAF con scope CLOUDFRONT solo puede desplegarse desde us-east-1 (N. Virginia). Es una restriccion de AWS: CloudFront es un servicio global anclado en us-east-1, y el WAF debe estar co-ubicado para poder asociarse a el. Si despliegas el stack de WAF desde cualquier otra region, el scope
CLOUDFRONT no esta disponible.

¿Cual es la estrategia recomendada para activar las reglas WAF?

1. Despliega todas las reglas en modo COUNT primero.
2. Analiza los logs de WAF y las sampled requests para identificar falsos positivos.

Luego cambia aBLOCK de forma progresiva, en orden de menor a mayor riesgo de falso positivo:

1. IP Reputation list — riesgo bajo
2. Reconnaissance list — riesgo bajo
3. Anonymous IP list — riesgo medio (puede afectar VPNs corporativas)
4. Hosting Provider IP list — riesgo medio-alto (puede afectar integraciones cloud)
5. Common Rule Set (XSS, LFI, RFI, SSRF) — riesgo alto, analizar bien antes.

Metricas y observabilidad

¿Que mide exactamente la metrica DDoSDetected?

DDoSDetected (namespace: AWS/DDoSProtection) indica si hay un evento DDoS en curso para un ARN especifico. Es una señal de deteccion unicamente — te dice que Shield ha identificado un ataque, no lo que ha hecho al respecto.

“Indicates whether a DDoS event is underway for a particular Amazon Resource Name (ARN). This metric has a non-zero value during an event.” — AWS Shield Advanced metrics documentation

¿Que otras metricas existen en el namespace AWS/DDoSProtection?

¿Puedo ver las metricas del rule group de Shield en CloudWatch?

No. AWS lo confirma explicitamente:

“The Shield Advanced rule group generates AWS WAF metrics, but they are not available to view. This is the same as for any other rule groups that you use in your protection pack (web ACL) but do not own, such as AWS Managed Rules rule groups.” — AWS WAF Developer Guide

Si las metricas del AALM no son visibles, ¿como se si esta bloqueando trafico legitimo?

Los logs de WAF son la unica via. Cuando AALM esta en COUNT, las peticiones que coinciden con el rule group de Shield aparecen como nonTerminatingMatchingRules. En BLOCK, aparecen como terminatingRuleId. Query en CloudWatch Log Insights:

fields @timestamp, httpRequest.clientIp, httpRequest.uri
| filter nonTerminatingMatchingRules.0.ruleId like /ShieldMitigationRuleGroup/
| stats count(*) as hits by httpRequest.clientIp, httpRequest.uri
| sort hits desc
| limit 100

El logging de WAF debe estar activado para que esto funcione. Sin el, no hay visibilidad de lo que hace el rule group de Shield.

¿Cual es la relacion entre DDoSDetected y AALM?

No estan acoplados directamente como podrias esperar. DDoSDetected = 1 significa que Shield identifico trafico anomalo. Lo que ocurre despues
depende de AALM:

• Si AALM esta desactivado: nada. Tus reglas WAF gestionan el trafico.
• Si AALM esta activado: Shield intenta identificar una firma del ataque. Si puede aislar el trafico del ataque del legitimo con suficiente
  confianza, despliega reglas en su rule group. Si no puede, no despliega nada — aunque DDoSDetected haya disparado.
• La ShieldKnownOffenderIPRateBasedRule puede mitigar trafico de IPs DDoS conocidas antes de que DDoSDetected alcance un valor distinto de cero. DDoSDetected te dice que Shield vio algo. Si AALM actuo es una pregunta separada que solo los logs de WAF pueden responder. ¿Los ataques SYN Flood que se ven en el dashboard global de Shield requieren Shield Advanced? No. Los SYN Floods son L3/L4 y los mitiga automaticamente la infraestructura de AWS para todos los clientes, incluido Shield Standard. El dashboard
  global muestra actividad agregada de toda la red de AWS — no significa que tus recursos especificos esten siendo atacados. Shield Advanced añade
  visibilidad por recurso y proteccion L7, que Shield Standard no ofrece.

HealthChecks y SRT

¿Necesitamos un HealthCheck para cada recurso protegido?

Es muy recomendable. Sin un Route 53 HealthCheck asociado al recurso:

• El Proactive Engagement no esta disponible — el SRT no te contactara automaticamente durante un ataque
• La precision y velocidad de deteccion de Shield se reduce
• La unica forma de hablar con el SRT es abriendo tu propio caso de soporte ¿Como se asocia un HealthCheck — desde la consola de Route 53 o desde Shield? Desde la consola de Shield (Protected Resources → Configure Protections). No directamente desde la consola de Route 53. ¿Cuando llamara el SRT proactivamente? Solo cuando se cumplen las dos condiciones simultaneamente:

1. Proactive Engagement esta activado en Shield Advanced
2. El recurso afectado tiene un Route 53 HealthCheck asociado y ese HealthCheck esta fallando activamente durante el evento Si el HealthCheck no cae — es decir, tu servicio sigue respondiendo aunque este bajo ataque — el SRT no te llamara aunque DDoSDetected este a 1. Si no tienes HealthCheck configurado, la unica forma de hablar con el SRT es abrir un caso de soporte manualmente. La logica tiene sentido: AWS no quiere llamarte cada vez que detecta trafico anomalo si tu servicio sigue funcionando correctamente. El HealthCheck
   cayendo es la señal de que el ataque esta teniendo impacto real en la disponibilidad.

Eventos DDoS y tipos de ataque

¿Que significa “Identified (subsided)” en la pestaña Events de Shield?

Significa que Shield detecto trafico sospechoso pero este ceso por si solo antes de que se desplegara ninguna mitigacion. No se tomo ninguna accion.
El ataque se disipo antes de que Shield tuviera oportunidad de responder.

¿Que es un ataque de tipo “Request flood”?

Un ataque volumetrico L7 en el que el atacante envia un alto volumen de peticiones HTTP — potencialmente desde multiples origenes — para saturar la capacidad del destino de procesarlas. Es el tipo de ataque que AALM y las rate-based rules estan diseñados especificamente para contrarrestar.

Cambiar de COUNT a BLOCK

¿Que debo verificar antes de cambiar AALM a BLOCK?

1. Han pasado 30+ dias desde que AALM fue activado — la baseline debe estar establecida.
2. Revisar DDoSDetected en el ultimo mes. Si nunca disparo, no hay falsos positivos de AALM que evaluar — el cambio es de bajo riesgo.
3. Si DDoSDetected estuvo a 1 en algun momento, consulta los logs de WAF en esa ventana temporal para verificar si el rule group de Shield matcheo trafico legitimo.
4. El logging de WAF debe estar activado — sin el, el paso 3 es imposible.
5. Verifica el allowlist IPSet — confirma que las fuentes legitimas de alta frecuencia (sistemas internos, pipelines de CI/CD, integraciones con terceros) estan incluidas.
6. Para servicios de trafico masivo: ten especial cuidado, ya que los patrones de trafico burst de clientes legitimos pueden parecerse a firmas de ataque. Para servicios donde habilitar el logging completo de WAF no es viable por volumen, usa un filtro de logging que capture solo matches de COUNT y BLOCK. Esto mantiene el volumen de logs manejable independientemente del trafico total.

Links

• Comportamiento de AALM — AWS WAF Developer Guide
• Como Shield mitiga eventos
• Metricas de Shield Advanced — DDoSDetected y namespace AWS/DDoSProtection
• Metricas del rule group de Shield no visibles
• Estados de eventos Shield — subsided
• https://www.rubenortiz.es/2019/05/01/aws-solutions-architect-associate-saa-2018-ii/