CloudFront con WAF y Lambda@Edge

AWS WAF (Web Application Firewall) filtra y supervisa las solicitudes HTTP/HTTPS que llegan a su distribución de CloudFront. Al asociar una Web ACL de WAF a su distribución, puede bloquear exploits web habituales —inyección SQL, cross-site scripting (XSS), bots maliciosos y ataques del OWASP Top 10— antes de que lleguen al origen.

WAF opera en la ubicación periférica de CloudFront, lo que significa que las solicitudes maliciosas se rechazan en la ubicación periférica más cercana, en lugar de llegar a su ALB o servidor de aplicaciones. Esto reduce la carga del backend y detiene los ataques más cerca del atacante.

Una Web ACL de WAF contiene reglas y grupos de reglas ordenados que comparan atributos de las solicitudes y realizan una acción (Allow, Block, Count, CAPTCHA). Las reglas se evalúan por orden de prioridad y se aplica la acción de la primera regla coincidente.

AWS proporciona grupos de reglas administradas: conjuntos de reglas prediseñados y mantenidos por AWS y por vendedores de AWS Marketplace. El AWS Managed Rules - Core Rule Set cubre el OWASP Top 10 sin necesidad de configuración. AWS actualiza los grupos de reglas administradas cuando aparecen nuevas amenazas, lo que reduce su carga operativa.

Las reglas basadas en velocidad de WAF cuentan las solicitudes de cada IP de origen durante una ventana de 5 minutos. Si una IP supera el umbral (por ejemplo, 2.000 solicitudes cada 5 minutos), WAF bloquea las solicitudes posteriores de esa IP hasta que la velocidad disminuye. Las reglas basadas en velocidad protegen contra ataques de fuerza bruta, ataques de relleno de credenciales y ataques sencillos de extracción mediante DDoS.

AWS WAF Bot Control es un grupo de reglas administradas que clasifica el tráfico en categorías: bots verificados (Googlebot, Bingbot), scrapers, herramientas de supervisión y tráfico humano. Puede configurar acciones diferentes para cada categoría: permitir los bots de motores de búsqueda, desafiar a los bots desconocidos con CAPTCHA y bloquear los scrapers maliciosos.

Las Web ACL de WAF tienen el ámbito CLOUDFRONT (global, para utilizarse con CloudFront) o REGIONAL (para utilizarse con ALB, API Gateway, AppSync o Cognito User Pools en una Región específica). Las ACL de WAF con ámbito de CloudFront deben crearse en la Región us-east-1, independientemente de dónde se origine el tráfico, porque CloudFront se administra desde esa Región.

Este es un detalle importante del examen: si crea una Web ACL de WAF en eu-west-1 e intenta asociarla a CloudFront, la asociación falla. Cree siempre las ACL de WAF de CloudFront en us-east-1.

Lambda@Edge permite ejecutar funciones Lambda de Node.js o Python en ubicaciones periféricas de CloudFront en respuesta a eventos de CloudFront. Las funciones se ejecutan a pocos milisegundos de la solicitud del usuario, sin enrutar el tráfico de vuelta a una Región central para procesarlo.

Las funciones de Lambda@Edge se implementan en la Región us-east-1, pero se replican automáticamente en todas las ubicaciones periféricas de CloudFront a nivel global. Esto significa que el código se ejecuta lo más cerca posible del usuario, lo que permite realizar personalización, autenticación y pruebas A/B en la ubicación periférica con una sobrecarga de latencia mínima.

Las funciones de Lambda@Edge pueden interceptar solicitudes y respuestas de CloudFront en cuatro puntos del ciclo de vida:

• Viewer Request: después de que CloudFront recibe la solicitud del visitante y antes de comprobar la caché; se utiliza para autenticación, redirecciones y manipulación de encabezados.
• Origin Request: después de un fallo de caché y antes de reenviar la solicitud al origen; se utiliza para reescritura de URL y encabezados personalizados para el origen.
• Origin Response: después de recibir la respuesta del origen y antes de almacenarla en caché; se utiliza para añadir encabezados de seguridad y modificar la respuesta.
• Viewer Response: antes de que CloudFront envíe la respuesta al visitante; se utiliza para añadir o modificar encabezados de respuesta.

AWS ofrece dos opciones de computación en el perímetro con diferentes ventajas y desventajas:

• CloudFront Functions: ejecución en menos de un milisegundo, solo JavaScript, coste extremadamente bajo (aproximadamente 1/6 del precio), se ejecuta únicamente en eventos Viewer Request y Viewer Response, límite de 1 ms de tiempo de cómputo y sin acceso a VPC ni a la red.
• Lambda@Edge: hasta 30 segundos de tiempo de ejecución (Viewer) / 30 segundos (Origin), Node.js o Python, los cuatro puntos de activación, posibilidad de realizar solicitudes de red y acceso a los cuerpos de las solicitudes y respuestas.

Utilice CloudFront Functions para la manipulación sencilla de encabezados, la normalización de URL y el cálculo de claves de caché. Utilice Lambda@Edge para lógica compleja que requiera llamadas de red, un cálculo más prolongado o procesamiento en el lado del origen.

Patrones habituales de Lambda@Edge en el examen SAA-C03:

• Validación de JWT en la ubicación periférica: una función Viewer Request valida un encabezado Authorization; las solicitudes no autorizadas devuelven 401 sin llegar al origen.
• Pruebas A/B: Viewer Request asigna a los usuarios al grupo A o B (mediante una cookie) y modifica la solicitud para obtener /a/page.html o /b/page.html.
• Reescritura de URL: Origin Request reescribe las URL limpias a las rutas de archivo reales en S3.
• Redimensionamiento dinámico de imágenes: Origin Request construye una solicitud a una función Lambda de procesamiento de imágenes; Origin Response almacena en caché la imagen redimensionada.
• Encabezados de seguridad HTTP: Viewer Response inyecta los encabezados CSP, HSTS y X-Frame-Options.

Lambda@Edge tiene varias restricciones en comparación con Lambda estándar:

• Las funciones deben estar en la región us-east-1
• No admite VPC (no puede acceder a recursos de una VPC)
• No admite variables de entorno (incorpore la configuración en el código de la función o recupérela de Parameter Store durante un inicio en frío)
• No se pueden usar Lambda Layers
• Tiempo de espera de eventos del visor: 5 segundos; tiempo de espera de eventos del origen: 30 segundos
• Límite de tamaño del paquete de implementación: 1 MB (eventos del visor) / 50 MB (eventos del origen)

Estas limitaciones hacen que Lambda@Edge no sea adecuado para cálculos de larga duración, operaciones que dependan de una VPC o funciones que necesiten una configuración dinámica en cada implementación.

WAF y Lambda@Edge cumplen funciones de seguridad diferentes y se complementan:

• WAF: bloqueo de ataques basados en firmas (inyección de SQL, XSS, actores maliciosos conocidos, limitación de velocidad); las reglas administradas gestionan automáticamente los ataques comunes
• Lambda@Edge: lógica de seguridad personalizada para el negocio (validación de JWT, comprobaciones de sesión y verificación de tokens de acceso); es flexible, pero requiere trabajo de desarrollo

Una arquitectura de defensa en profundidad: WAF bloquea primero los patrones de ataque conocidos; Lambda@Edge valida la autenticación a nivel de negocio; las URL y cookies firmadas de CloudFront restringen el acceso al contenido; OAC mantiene S3 privado. Cada capa evita de forma independiente una clase de ataque diferente.

Supervise su capa de seguridad en el edge con estas herramientas:

• Registros de WAF: habilite el registro completo de solicitudes en S3, CloudWatch Logs o Kinesis Firehose para ver qué reglas coinciden y qué tráfico se bloquea
• Métricas de WAF: BlockedRequests, AllowedRequests y CountedRequests por regla en CloudWatch
• Registros de Lambda@Edge: los grupos de CloudWatch Logs se crean en cada región donde se ejecuta la función; use CloudWatch Insights para consultar datos entre regiones
• Registros en tiempo real de CloudFront: transmita los registros de acceso a Kinesis para analizarlos de inmediato (a diferencia de los registros de acceso estándar, que se procesan por lotes cada pocos minutos)

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección aprendió que: AWS WAF bloquea ataques web comunes en el edge de CloudFront mediante grupos de reglas administrados y personalizados; Lambda@Edge ejecuta código personalizado globalmente en cuatro puntos de activación de CloudFront; y CloudFront Functions ofrece una ejecución inferior a un milisegundo para lógica sencilla del lado del visor. Las ACL de WAF para CloudFront deben crearse en us-east-1. A continuación, exploraremos los balanceadores de carga de aplicaciones, de red y de gateway.