AWS WAF: Guía a Fondo — Reglas Administradas, Limitación de Tasa y Protección contra Bots para la Defensa Web (con comparaciones con GCP Cloud Armor y Azure WAF)
Introducción: Un WAF no es la “última línea de defensa”—es un sistema operativo que funciona a través del diseño
A medida que crece una aplicación web o una API, los ataques suelen evolucionar de “desordenados” a “prácticos”. Más allá de amenazas clásicas como la inyección SQL y XSS, cada vez verás más tráfico que daña directamente el negocio: intentos automatizados de inicio de sesión, scraping, acaparamiento de inventario/reservas y abuso de alta frecuencia en endpoints de búsqueda. Para estas amenazas de la capa de aplicación (Capa 7), AWS WAF (Web Application Firewall) es una forma potente de añadir controles en la nube rápidamente, manteniendo una gobernanza manejable. 0
AWS describe oficialmente AWS WAF como un servicio que supervisa solicitudes HTTP(S) enviadas a recursos protegidos y ejecuta acciones como permitir (allow), bloquear (block) o contar (count, solo detección) según condiciones definidas. Entre los recursos compatibles se incluyen CloudFront, API Gateway (REST API), Application Load Balancer, AppSync, Cognito, App Runner, Verified Access, Amplify y más. 1
Este artículo va un paso más allá de “simplemente activarlo” y explica—de forma práctica—cómo ensamblar reglas, reducir falsos positivos, entender la estructura de costos y diseñar el registro (logging) y la operación. También alinea GCP Cloud Armor y Azure Web Application Firewall (WAF) para que tu toma de decisiones sea consistente incluso en entornos multi-nube. 2
A quién ayuda: qué equipos se benefician más
1) Equipos de desarrollo de aplicaciones (backend/frontend) que suelen “dejar la seguridad para después”
Los WAF pueden parecer herramientas solo de seguridad, pero en la práctica están muy ligados a la calidad de la app. Limitar la tasa (rate limit) en APIs de búsqueda abusadas, reducir bots de login y bloquear patrones de explotación conocidos desde temprano mejora la disponibilidad y los costos tanto como la seguridad. AWS WAF suele presentarse como compatible con el bloqueo de patrones generales como SQLi y XSS, además de monitoreo/bloqueo/limitación de tasa para bots. 3
2) Equipos SRE/operaciones que durante incidentes luchan por distinguir “ataque vs. bug”
Cuando el tráfico se dispara, es fácil dudar: ¿comportamiento tipo DDoS, viralidad en redes, bots o una regresión de la app? Con logs del WAF y una operación disciplinada de reglas, el triaje se acelera mucho. Piensa en el WAF no solo como monitorización, sino como una pista de auditoría operativa.
3) Equipos IT/seguridad que deben aportar “controles defendibles” para auditorías y requisitos de clientes
Decir “usamos un WAF” cada vez es menos suficiente. Te preguntan qué reglas usas, cómo gestionas falsos positivos y cómo gobiernas excepciones. El modelo de precios y control de AWS WAF (Web ACLs, reglas, conteo de solicitudes) facilita relativamente documentarlo en diseños y auditorías. 4
1. Visión general de AWS WAF: define “qué solicitudes se permiten” con Web ACLs y reglas
La unidad central en AWS WAF es la Web ACL (Access Control List). Dentro de una Web ACL colocas reglas (o grupos de reglas). Para cada solicitud entrante, AWS WAF evalúa las reglas en orden y aplica acciones como permitir/bloquear/contar cuando las condiciones coinciden.
Operativamente, “evaluar reglas en orden” importa mucho porque lo que se debe bloquear vs. permitir depende de cómo funcione tu aplicación. Por ejemplo, aplicaciones tipo CMS o con búsquedas intensivas pueden incluir naturalmente muchos símbolos en query strings, lo que puede disparar falsos positivos en reglas administradas. AWS señala que las reglas administradas ahorran tiempo, pero es realista asumir desde el día uno que necesitarás ajustes específicos de la aplicación. 5
2. Qué puedes proteger: coloca AWS WAF primero en la “entrada”
AWS WAF supervisa solicitudes HTTP(S) enviadas a recursos protegidos y puede adjuntarse a múltiples servicios de “entrada” como CloudFront, API Gateway (REST API) y Application Load Balancer, entre otros. 6
Un enfoque práctico es simple:
- Identificar cada punto de entrada externo (CDN, load balancer, endpoints de API, etc.)
- Colocar el WAF en esos puntos para detener el tráfico antes de que llegue a la app
- Dividir responsabilidades: el WAF bloquea lo que puede en el borde; la app maneja autorización y controles nativos de la app
Como un WAF no es omnipotente, decidir temprano qué “pertenece a la app” vs. qué “pertenece al WAF” evita que el diseño de reglas se desvíe.
3. Fundamentos de diseño de reglas: empieza con “Reglas administradas + Limitación de tasa”
Una gran ventaja de AWS WAF es que no necesitas construir todo desde cero con reglas regex. Puedes usar grupos de reglas administradas para ataques comunes y añadir reglas personalizadas solo donde haga falta. La documentación y los materiales de producto de AWS suelen resaltar cobertura para patrones generales como SQLi y XSS y enfatizan el ahorro de tiempo con reglas administradas. 7
Orden recomendado de implementación (el menos propenso a causar conflictos en equipos reales)
- Empezar con Count (solo detección)
Si saltas directo a Block, los falsos positivos pueden bloquear usuarios legítimos. Empieza con Count, recopila logs y aprende qué dispara qué reglas. - Añadir reglas basadas en tasa (rate limiting)
El abuso de alta frecuencia conviene suprimirlo temprano incluso cuando es difícil clasificarlo. Funciona bien para login, búsqueda, restablecimiento de contraseña, chequeos de inventario, etc. - Añadir excepciones guiadas por el negocio (Allow / scope-down)
Codifica explícitamente necesidades operativas: allowlists de IP para admin, exclusiones de health checks, rutas específicas, etc.
Esta secuencia te permite fortalecer el WAF de forma segura mientras mejoras el lado de la app en paralelo (validación de entrada, comportamiento de respuesta, resiliencia ante bots).
4. Entender el costo: el costo del WAF se construye sobre “Web ACLs, reglas, solicitudes”
El precio de AWS WAF se describe como una tarifa mensual por Web ACL, una tarifa mensual por regla (o grupo de reglas) y cargos por cantidad de solicitudes web procesadas (por millón). Las páginas de precios de EE. UU. suelen ilustrar valores como 5 USD/Web ACL/mes, 1 USD/regla/mes y 0,60 USD por millón de solicitudes, con cálculos de ejemplo. 8
Palancas clave de control de costo:
- No fragmentar en exceso las Web ACLs (las fronteras necesarias están bien, pero dividir demasiado aumenta el costo fijo)
- Evitar la proliferación de reglas (duplicar intención en muchas reglas infla costo y operación)
- En puntos de entrada de alto tráfico, la eficiencia de reglas importa (evitar inspeccionar en exceso todo)
Nota también: complementos orientados a bots (p. ej., Bot Control) pueden tener precios separados según lo que habilites, así que aclara requisitos antes de estimar. 9
5. Plantillas prácticas: ten listos estos tres “patrones”
Abajo hay patrones de adopción fáciles de compartir dentro de equipos. El foco es el razonamiento, no el código exacto.
Plantilla A: Conjunto mínimo para APIs — “Reglas administradas + Limitación de tasa”
Objetivo: Bloquear ataques clásicos (SQLi/XSS) y limitar abuso en APIs propensas.
- Regla 1: Grupo de reglas administradas de AWS (empezar con Count → pasar a Block tras validación) 10
- Regla 2: Rate limiting para
/loginy/password-reset(por ejemplo, por IP N solicitudes por minuto) - Excepciones: permitir IPs internas y health checks de monitoreo (Allow / scope-down)
Esto es especialmente eficaz en productos que priorizan velocidad: detener primero el tráfico malo de alto impacto en lugar de buscar una clasificación perfecta.
Plantilla B: Para sitios estáticos/frontends — Organizar por “País / IP / Ruta”
Objetivo: Reducir volumen de ataques cuando se concentra en ciertas regiones o redes.
- Regla 1: Bloqueos geográficos para países claramente irrelevantes
- Regla 2: Bloquear rangos de IP conocidos como maliciosos (mantenidos en un formato operativo actualizable)
- Regla 3: Rutas admin (p. ej.,
/admin) bloquean a todos excepto IPs/VPN en allowlist
El geo-blocking suele chocar con objetivos del negocio, así que registra la justificación (“qué países y por qué”) para evitar conflictos futuros.
Plantilla C: Cuando dan miedo los falsos positivos — operación “Count → Block por etapas”
Objetivo: Evitar daño de UX por falsos positivos justo después del despliegue.
- Revisión semanal de logs en Count para identificar falsos positivos
- Añadir excepciones (por ruta/cabecera/query)
- Promover solo reglas claramente maliciosas a Block primero
- Mantener reglas inciertas en Count (aceptar “configurado pero no aplicado” como estado válido)
La fortaleza del WAF proviene de mejoras operativas con el tiempo, no de intentar publicar un conjunto perfecto el primer día.
6. AWS WAF vs. AWS Shield: capas distintas, división de roles clara
La guía de AWS suele enmarcar AWS WAF como filtrado de tráfico HTTP/S en la capa de aplicación (Capa 7) para proteger aplicaciones web y ayudar a abordar ataques web comunes como SQLi/XSS/CSRF. 11
Esta distinción importa: intentar resolver DDoS de gran escala a nivel de red solo con WAF puede distorsionar tu diseño. Mantén clara la división: usa WAF para ataques de Capa 7/bots/patrones maliciosos y apóyate en otras protecciones (capacidades del servicio / protección DDoS) para eventos grandes de capa de red.
7. Comparación con GCP Cloud Armor: operar WAF + protección DDoS mediante “políticas”
GCP Cloud Armor suele discutirse como combinación de WAF y protección DDoS. Sus páginas de precios presentan ejes como “política de seguridad (recurso protegido)” y “solicitudes (por millón)”. 12
Materiales de nivel empresarial también describen precios en unidades como políticas/reglas/solicitudes y pueden incluir tarifas base (p. ej., mensual por proyecto) y cargos por recurso protegido. 13
Un marco comparativo útil:
- AWS: “apilas” Web ACLs y reglas (grupos de reglas) 14
- GCP: gestionas alrededor de políticas de seguridad, vinculándolas a recursos protegidos y solicitudes 15
En la práctica, ambos comparten la misma esencia operativa: filtrar en la entrada, codificar excepciones y afinar usando logs. Las diferencias aparecen sobre todo en unidades de precio y estructura de gestión.
8. Comparación con Azure WAF: elígelo junto con tu “servicio de entrada”
El Web Application Firewall de Azure suele presentarse como parte de Azure Front Door Premium, y las estructuras de precios pueden incluir elementos mensuales fijos más componentes por solicitudes (según la edición del servicio). 16
Los materiales de precios en inglés también muestran elementos como facturación por tiempo para la política de WAF (p. ej., por hora) vinculada a productos específicos de gateway, ilustrando cómo el costo y la estructura del WAF se ligan al servicio de entrada. 17
En Azure, la “forma” de la decisión suele depender de la entrada:
- ¿Quieres protección global tipo CDN (Front Door)?
- ¿O protección regional tipo balanceador (Application Gateway)?
- ¿Ya tienes ese servicio de entrada, o lo estás eligiendo ahora?
Como precios y capacidades se agrupan con el servicio de entrada (o con facturación por tiempo de la política de WAF), es especialmente importante definir temprano la arquitectura de entrada. 18
9. Ejes estables de comparación multi-nube: usa estos 6 criterios
Antes de perderte en diferencias finas de funcionalidades, alinea la evaluación con estos seis puntos:
- Dónde se sitúa (recurso de entrada)
- Qué detiene (SQLi/XSS, bots, rate limiting, restricciones geo/IP, etc.) 19
- Cómo se crean excepciones (paneles admin, health checks, crawlers legítimos)
- Operación de falsos positivos (Count → Block por etapas, cadencia de revisión)
- Diseño de logging/auditoría (quién revisa, dónde se almacena, retención)
- Unidades de precio (AWS: Web ACL/reglas/solicitudes; GCP: política/solicitudes; Azure: a menudo ligado a servicios de entrada) 20
Cuando estos seis puntos están alineados, tu “base de decisión” se mantiene consistente entre nubes y las reuniones se vuelven mucho más fáciles.
10. Conclusión: el valor de AWS WAF proviene de cómo lo “haces crecer”, no de cómo lo “instalas”
AWS WAF se describe oficialmente como un WAF que supervisa solicitudes HTTP(S) y las controla por condiciones, y puede aplicarse a múltiples servicios de entrada como CloudFront, API Gateway y ALB. 21
Sus fortalezas incluyen aprovechar reglas administradas para ataques comunes como SQLi/XSS y abordar tráfico molesto del mundo real mediante monitoreo/bloqueo/limitación de tasa para bots. 22
Como el precio se acumula según Web ACLs, reglas (grupos de reglas) y volumen de solicitudes, puedes prever el comportamiento del costo con relativa claridad durante el diseño. 23
GCP Cloud Armor tiende a centrarse en políticas tanto en gestión como en expresión de precios, mientras que Azure WAF suele evaluarse junto con Front Door o Application Gateway (servicios de entrada). 24
Aun así, el núcleo es consistente entre nubes: “bloquear lo que puedas en la entrada, afinar falsos positivos operativamente y codificar excepciones como reglas”. Eso es lo que crea una defensa duradera.
Si quieres un siguiente paso práctico, empieza con solo uno:
- Habilitar un grupo de reglas administradas en modo Count y visualizar falsos positivos durante una semana
- Añadir rate limiting a APIs propensas al abuso como login/búsqueda
- Restringir por IP la entrada de administración y convertir “excepciones” en reglas (no solo procedimientos)
Empieza pequeño, pero opera con cuidado. Hecho así, un WAF crece hasta convertirse en un sistema confiable que mejora no solo la seguridad, sino también la disponibilidad y el control de costos.
Enlaces de referencia (centrados en fuentes oficiales)
- AWS WAF (Guía del desarrollador: visión general) 25
- AWS WAF (Página del producto) 26
- Precios de AWS WAF (Global) 27
- Precios de AWS WAF (Japonés) 28
- Elegir AWS WAF vs. AWS Shield (Guía de decisión) 29
- Precios de Google Cloud Armor 30
- Visión general de Cloud Armor Enterprise (modelo de precios) 31
- Precios de Azure Web Application Firewall (Japonés) 32
- Precios de Azure Web Application Firewall (Inglés) 33