Introducción
La arquitectura tradicional para servir contenido dinámico generado por funciones serverless suele implicar una capa intermedia de API Gateway o un balanceador de carga (ALB/NLB) que actúe como puente hacia las funciones. Esta topología añade latencia, costos adicionales por invocations de red y complejidad en la gestión de certificados TLS. AWS ha eliminado este intermediario al habilitar, a partir de octubre de 2026, que Amazon CloudFront acepte AWS Lambda Web Functions como origen primario.
Para los equipos de DevOps y SRE, esto no es solo una actualización de compatibilidad, sino un cambio en el modelo de seguridad perimetral de las aplicaciones web. La capacidad de terminar TLS en el borde, aplicar caching y gestionar dominios personalizados directamente sobre una función Lambda altera cómo se deben diseñar las políticas de seguridad, especialmente en lo que respecta a la protección contra ataques DDoS y la integridad de las sesiones de usuario. El riesgo medio radica en configurar incorrectamente el Origin Access Control (OAC) o la política de caché, lo que podría exponer datos sensibles o degradar la experiencia del usuario.
Qué ocurrió
AWS ha expandido la lista de orígenes compatibles con CloudFront para incluir específicamente las «Lambda Web Functions». A diferencia de las funciones Lambda estándar, que están optimizadas para procesamientos asíncronos o de integración backend, las Web Functions están diseñadas para responder a solicitudes HTTP/S con una latencia de arranque en frío significativamente menor y tiempos de respuesta consistentes.
Anteriormente, para exponer una Web Function a Internet, los ingenieros debían configurar un ALB o API Gateway HTTP, gestionar los certificados SSL/TLS en esa capa intermedia y configurar reglas de enrutamiento complejas. Con la nueva funcionalidad, CloudFront se conecta directamente a la función. Esto significa que el tráfico HTTPS termina en los servidores de borde de CloudFront, no en la función ni en un intermediario. La función recibe la solicitud ya desencriptada, procesa la lógica de negocio y devuelve la respuesta, la cual CloudFront puede cachear en sus nodos globales.
Esta integración está disponible globalmente, excluyendo la región de CloudFront China, y no conlleva costos adicionales de licencia o habilitación. La configuración se realiza mediante la consola de CloudFront, SDK, CLI o CloudFormation, permitiendo una adopción gradual o automatizada dentro de pipelines de infraestructura como código (IaC).
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto inmediato es la reducción de la superficie de ataque y la simplificación de la arquitectura de red. Al eliminar el ALB o API Gateway del camino crítico, se reducen los puntos únicos de fallo y los costos asociados a las transferencias de datos intrarregionales y las invocations de intermediarios. Para los equipos de seguridad, esto centraliza la protección perimetral en CloudFront.
Sin embargo, este cambio introduce desafíos específicos en la gestión de estado y seguridad de la aplicación. CloudFront es, por diseño, un servicio de distribución de contenido. Su comportamiento predeterminado favorece el caching. Si una Web Function genera respuestas dinámicas que dependen de cookies de sesión o cabeceras de autenticación (como Authorization), una configuración ingenua de CloudFront podría cachear respuestas privadas para un usuario y servirlas a otro, resultando en una fuga de datos crítica.
Además, la protección DDoS de nivel 3/4 que ofrece CloudFront es robusta, pero la función Lambda sigue siendo susceptible a ataques de aplicación (Capa 7) si no se protege adecuadamente. La integración facilita la conexión con AWS WAF, pero no la configura automáticamente. Los administradores deben validar que las reglas de WAF estén activas y que las políticas de Origin Access Control (OAC) estén correctamente implementadas para evitar que un atacante acceda a la función Lambda directamente, saltándose CloudFront.
Detalles técnicos
La clave técnica de esta integración es el Origin Access Control (OAC). OAC es un mecanismo de autenticación mutua entre CloudFront y el origen. Al configurar una Lambda Web Function como origen, CloudFront firma las solicitudes entrantes con credenciales específicas que la función puede validar. Esto asegura que la función solo acepte tráfico que provenga de CloudFront.
Para que esto funcione, la función Lambda debe incluir lógica para verificar la firma de la solicitud o, en arquitecturas más simples, confiar en que el endpoint público de la función está restringido por políticas de recursos de IAM que solo permiten a CloudFront invocarla. Es crucial distinguir entre la URL pública de la función (si está expuesta) y el endpoint interno. Si la función tiene una URL de Invoke pública, un atacante podría intentar alcanzarla directamente, eludiendo CloudFront y, por tanto, el WAF y el DDoS protection.
La configuración implica definir el origen en el archivo de distribución de CloudFront. Un ejemplo conceptual de la configuración en el SDK o CloudFormation requiere especificar el ARN de la función y habilitar OAC.
# Ejemplo conceptual de configuración de origen en CloudFront (simplificado)
Origins:
Items:
– Id: LambdaWebFunctionOrigin
DomainName: your-lambda-url.execute-api.us-east-1.amazonaws.com
CustomOriginConfig:
OriginProtocolPolicy: https-only
OriginReadTimeout: 30
OriginKeepaliveTimeout: 5
OriginAccessControlId: oac-1234567890abcdef
# La función debe estar configurada para aceptar solo solicitudes firmadas por CloudFront
Los tiempos de conexión y latencia mejoran porque se elimina un salto de red (hop). CloudFront termina el TLS en el borde, estableciendo una conexión HTTP/2 o HTTP/3 con el cliente y una conexión HTTP/1.1 o HTTP/2 persistente con la función Lambda. Esto es crítico para aplicaciones web que requieren tiempos de respuesta bajos (TTFB).
Qué deberían hacer los administradores y equipos técnicos
Conclusión
La integración de Lambda Web Functions como origen de CloudFront representa un paso hacia arquitecturas más simples y seguras, eliminando intermediarios que añaden latencia y costos. Para los equipos de infraestructura, la oportunidad de reducir la complejidad operativa es significativa. Sin embargo, la seguridad no se automatiza sola. La efectividad de esta arquitectura depende críticamente de la correcta implementación de Origin Access Control y de una configuración consciente de las políticas de caché para proteger la integridad de las sesiones de usuario. Los administradores deben tratar esta migración no como un simple cambio de endpoint, sino como una revisión profunda de la postura de seguridad y rendimiento de sus aplicaciones web serverless.
Fuentes
https://aws.amazon.com/about-aws/whats-new/2026/10/cloudfront-lambda-web-functions-origin/