Módulo 2: Domain 1 Secure Architectures
5. Task 1.2 cont.: el perímetro — WAF, Shield y conexiones externas
Descripción
La lección 4 cubrió la mitad "de adentro hacia afuera" de Task 1.2: la red que rodea una carga de trabajo y la identidad de sus usuarios finales. Esta lección cierra la mitad "de afuera hacia adentro": los servicios que protegen esa carga de trabajo de amenazas que vienen de internet, y el vocabulario de las conexiones que entran a AWS desde fuera de la nube. Ningún servicio de esta lección fue construido por ninguna guía hermana —Andes Cargo, como API interna sin tráfico público expuesto a atacantes anónimos de internet, nunca necesitó defenderse de un DDoS o de una inyección SQL a través de un formulario web—. El examen sí lo exige, y esta lección lo cubre con precisión conceptual, sin fingir un laboratorio que el ecosistema nunca construyó.
Conexión con el módulo
La lista oficial de habilidades de Task 1.2 nombra explícitamente "integrating AWS services to secure applications (for example, AWS Shield, AWS WAF, IAM Identity Center, AWS Secrets Manager)" y "securing external network connections to and from the AWS Cloud (for example, VPN, AWS Direct Connect)". Esta lección cubre exactamente esas dos piezas — con un puntero explícito al Módulo 6, donde VPN y Direct Connect reciben la profundidad técnica completa que el examen exige, porque ese es, con precisión, el módulo 100% conceptual dedicado a los servicios que ningún laboratorio de este ecosistema pudo ejecutar.
Analogía: el guardia de la puerta principal vs. la barricada anti-tumultos
Retoma el edificio de Andes Cargo. Security groups y NACLs (lección 4) son los guardias de cada puerta interior — deciden, puerto por puerto, quién entra a cada oficina, una vez que ya está dentro del predio. Pero antes de llegar a esas puertas interiores, hay dos problemas distintos en la entrada principal del edificio, que ningún guardia de oficina puede resolver por sí solo. El primero: alguien se presenta con una identificación que parece válida, pero en realidad es un intento de fraude sofisticado —una solicitud que, con las palabras correctas, intenta manipular al recepcionista para que revele información que no debería—. Ese es el trabajo de AWS WAF: examina cada solicitud HTTP/HTTPS con reglas específicas, buscando patrones de ataque conocidos (inyección SQL, scripts maliciosos), antes de dejarla pasar. El segundo problema: no es una sola persona con mala intención, es una multitud de miles de personas —reales o fabricadas— tratando de entrar al mismo tiempo, con el único objetivo de saturar la puerta y que nadie legítimo pueda pasar. Ese es el trabajo de AWS Shield: absorbe y mitiga el volumen del ataque, no examina el contenido de cada solicitud individual.
AWS WAF: firewall de aplicación web, capa 7
La documentación oficial es directa sobre qué protege: "AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to your protected web application resources." Opera en la capa de aplicación (capa 7 del modelo OSI) — examina el contenido de cada solicitud, no solo su origen o volumen. Puede detectar, con reglas explícitas, "presence of SQL code that is likely to be malicious (known as SQL injection)" y "presence of a script that is likely to be malicious (known as cross-site scripting)" — los dos vectores de ataque que el propio task statement de Task 1.2 nombra como ejemplo ("threat vectors external to AWS (for example, DDoS, SQL injection)").
Dónde se adjunta WAF, con precisión: no protege cualquier recurso de AWS — se adjunta a un conjunto específico de servicios que reciben tráfico HTTP/HTTPS público, entre ellos CloudFront, Application Load Balancer, API Gateway (REST), AppSync y, notablemente, un Cognito user pool —la misma pieza nueva de la lección 4—. Esa combinación (Cognito user pool + WAF) es, con precisión, cómo Andes Cargo protegería el hipotético portal de clientes de la lección 4: Cognito autentica quién es la persona, WAF filtra el tráfico malicioso antes de que llegue siquiera al formulario de login.
AWS Shield: Standard (automático, gratis) vs. Advanced (pagado, ampliado)
La distinción central que el examen prueba, con la fuente oficial exacta: "AWS Shield Standard is automatically included at no extra cost beyond what you already pay for AWS WAF and your other AWS services." Todo el que usa AWS ya tiene Shield Standard activo, sin configurar nada — protege contra los vectores de DDoS volumétricos más comunes, en las capas de red y transporte (capa 3/4): "UDP reflection attacks and TCP SYN floods".
Shield Advanced es un servicio distinto, con suscripción y costo adicional, que "provides expanded DDoS attack protection (...) at the network and transport layers (layer 3 and 4) and the application layer (layer 7)". Protege un conjunto específico de recursos —EC2, Elastic Load Balancing, distribuciones de CloudFront, zonas hospedadas de Route 53, AWS Global Accelerator— y agrega tres cosas que Shield Standard no tiene: mitigación automática de DDoS en la capa de aplicación, visibilidad avanzada de eventos, y soporte dedicado del Shield Response Team (SRT) durante un ataque activo.
| Shield Standard | Shield Advanced | |
|---|---|---|
| Costo | Incluido, sin cargo adicional | Suscripción con costo adicional |
| Capas protegidas | Red y transporte (3/4) | Red/transporte (3/4) y aplicación (7) |
| Activación | Automática, para todos | Opcional, por recurso protegido |
| Soporte durante un ataque | No | Shield Response Team (SRT) dedicado |
La decisión de examen: cuando un escenario menciona "protección básica contra DDoS, sin costo adicional", la respuesta es Shield Standard — ya está activo, no hay nada que decidir. Cuando el escenario describe un sitio de alta visibilidad, con tolerancia cero a downtime durante un ataque, o que necesita soporte experto en vivo durante un incidente de DDoS, la respuesta es Shield Advanced. Y cuando el ataque descrito es específicamente a nivel de aplicación (una inundación de solicitudes HTTP legítimas en apariencia, diseñada para agotar recursos del backend, no solo saturar ancho de banda), la combinación correcta casi siempre es Shield Advanced + WAF juntos — Shield Advanced mitiga el volumen, WAF filtra el contenido malicioso específico.
AWS Network Firewall y Firewall Manager, nombrados
Dos piezas más del perímetro que el examen espera reconocer, sin la profundidad de WAF/Shield:
- AWS Network Firewall es un firewall de red con estado, desplegado dentro de tu VPC, que filtra tráfico usando reglas de dominio, de IP y reglas compatibles con el formato Suricata (un motor de detección de intrusiones de código abierto muy usado en la industria) — a diferencia de un security group (por instancia) o una NACL (por subred), Network Firewall opera a nivel de VPC completa, con inspección de tráfico más profunda que cualquiera de los dos.
- AWS Firewall Manager no es, en sí mismo, un firewall — es la capa de administración centralizada que aplica WAF, Shield Advanced, security groups, NACLs, Network Firewall y Route 53 Resolver DNS Firewall de forma consistente a través de múltiples cuentas de una AWS Organizations, incluso cuando se agregan cuentas o recursos nuevos automáticamente.
La decisión de examen: cuando el escenario describe la necesidad de aplicar la misma política de seguridad de red de forma consistente a través de docenas de cuentas, sin depender de que cada equipo la configure por separado, la respuesta es Firewall Manager — el mismo problema de consistencia multi-cuenta que Control Tower resuelve para SCPs (lección 2), aplicado a reglas de firewall.
VPN y Direct Connect: nombrados aquí, profundidad en el Módulo 6
El task statement 1.2 pide "securing external network connections to and from the AWS Cloud (for example, VPN, AWS Direct Connect)" — pero la profundidad técnica real (ancho de banda, costo, topología, cuándo cada uno gana sobre el otro) pertenece al Módulo 6 de esta guía, junto con el resto de conectividad híbrida (Transit Gateway, PrivateLink), porque son, con precisión, los servicios que ningún laboratorio gratuito de LocalStack de este ecosistema pudo ejecutar — algunos de ellos, como Direct Connect, son literalmente un circuito físico dedicado, sin sentido de "emular a costo cero" en ningún plan. Por ahora, el vocabulario mínimo que Task 1.2 exige: una Site-to-Site VPN cifra el tráfico sobre internet público entre tu red y AWS; Direct Connect es una conexión de red dedicada y privada, que no atraviesa internet público en absoluto — la elección entre ambas es, fundamentalmente, un trade-off de seguridad/latencia/costo que el Módulo 6 desarrolla a fondo.
Errores comunes
Elegir WAF para un problema de volumen puro (de confundir capa 7 con capa 3/4). Qué pasa: un escenario describe un ataque volumétrico masivo —millones de paquetes UDP por segundo, sin contenido HTTP identificable como malicioso— y alguien propone WAF como la solución. Cómo detectarlo: si tu respuesta a un ataque descrito en términos de "volumen" o "paquetes por segundo" (sin mención de HTTP, SQL o scripts) es WAF en vez de Shield. Cómo corregirlo: WAF examina el contenido de solicitudes HTTP/HTTPS específicas — no está diseñado para, ni puede, absorber un volumen masivo de tráfico de red genérico. Esa es, con precisión, la razón de ser de Shield.
Olvidar que Shield Standard ya está activo, y proponerlo como si hubiera que "activarlo" (de desconocimiento del default). Qué pasa: alguien responde "activa Shield Standard" a un escenario que ya tiene protección básica de DDoS sin haber hecho nada. Cómo detectarlo: si tu plan de arquitectura incluye un paso explícito para habilitar Shield Standard. Cómo corregirlo: Shield Standard es automático para todo el que use AWS, sin costo ni configuración — la pregunta de examen real casi nunca es "¿cómo activo Shield Standard?", sino "¿cuándo necesito Shield Advanced además del Standard que ya tengo?".
❓ Pregunta de práctica — Dominio 1 (Secure)
Escenario: Una plataforma de streaming de video en vivo (StreamNorte) sufre, durante un evento deportivo de alta audiencia, un ataque que combina dos vectores: una inundación de paquetes SYN que satura el ancho de banda de su balanceador de carga, y —simultáneamente— una oleada de solicitudes HTTP con parámetros de consulta diseñados para explotar una vulnerabilidad de inyección SQL en su API de comentarios en vivo. El equipo necesita mitigar ambos vectores durante el evento, que dura tres horas, y quiere soporte experto de AWS disponible mientras dure el ataque.
Pregunta: ¿Cuál es la combinación de servicios que responde a ambos vectores del ataque?
A. Solo AWS Shield Standard, que ya está activo de forma automática y gratuita.
B. AWS Shield Advanced (por el ataque volumétrico y el soporte del Shield Response Team) combinado con AWS WAF (por la inyección SQL en la API).
C. Solo AWS WAF, configurado con una regla que bloquee cualquier solicitud que contenga la palabra SELECT.
D. Amazon GuardDuty, configurado para bloquear automáticamente el tráfico que identifique como malicioso.
✅ Respuesta correcta: B
Por qué es correcta: el escenario describe explícitamente dos vectores distintos — un ataque volumétrico (SYN flood, capa 3/4) y un ataque de contenido de aplicación (inyección SQL, capa 7) — más un requisito de soporte experto en vivo. Shield Advanced cubre el vector volumétrico con mitigación ampliada y agrega el Shield Response Team que el escenario pide explícitamente; WAF cubre el vector de inyección SQL con reglas de inspección de contenido HTTP. Ninguno de los dos, por separado, resuelve el escenario completo — la combinación sí.
Por qué las demás fallan:
- A: Shield Standard mitiga vectores volumétricos comunes, pero no incluye mitigación de capa de aplicación ni soporte del Shield Response Team — ambos explícitamente requeridos por el escenario — y no hace nada contra la inyección SQL, que no es un problema de volumen.
- C: una regla que bloquea la palabra
SELECTes una simplificación ingenua de cómo funciona una regla de WAF real (que usa patrones más sofisticados de detección de inyección SQL, no coincidencia de texto literal), y de cualquier forma no resuelve el vector volumétrico del ataque, que WAF no está diseñado para mitigar. - D: GuardDuty es un servicio de detección de amenazas basado en análisis de logs — genera findings para que un humano o una automatización externa actúe, pero no es, por sí mismo, un mecanismo de mitigación de tráfico en tiempo real como WAF o Shield.
Recursos
- AWS Docs — What is AWS WAF? — fuente oficial completa, incluida la lista exacta de recursos que WAF puede proteger.
- AWS Docs — AWS Shield — fuente oficial de Shield Standard vs. Shield Advanced.
- AWS Docs — AWS Firewall Manager — administración centralizada multi-cuenta de WAF/Shield Advanced/Network Firewall.
- AWS Docs — AWS Network Firewall — firewall de red con estado, a nivel de VPC.