Introducción
Hasta ahora, si un equipo de DevOps quería ofrecer una aplicación en tiempo real —un chat interno, un tablero de métricas en vivo o un gestor de dispositivos IoT— sobre WebSocket y alojada en una VPC privada, enfrentaba un dilema: exponer el balanceador de carga o las instancias EC2 directamente a Internet, o montar una arquitectura compleja con ACLs, Security Groups y reglas de firewall. Ambas opciones aumentaban la superficie de ataque y el trabajo operativo. Con el anuncio de AWS, CloudFront absorbe el tráfico WebSocket hacia orígenes en VPC privadas, actuando como único punto de entrada para HTTP tradicional y conexiones persistentes bidireccionales. El beneficio es inmediato: menos exposición pública, menos reglas de seguridad que mantener y protección DDoS ya integrada.
El cambio no es cosmético. En producción, equipos reportan que reducir el número de endpoints públicos de 3 (ALB, NLB y EC2) a 1 (CloudFront) implica menos cambios en Security Groups, menos logs de WAF a revisar y menos incidentes por configuraciones erróneas en NACLs. Además, CloudFront ya filtra tráfico malicioso en capa 7, algo que un ALB en modo WebSocket no hace por defecto. Para equipos que operan en regiones con alta demanda de apps en tiempo real —como gaming, fintech o logística—, esto significa ahorro en horas de ingeniería y reducción en el riesgo de exposición de puertos no estándar (como 8080 o 443 alternativos).
Qué ocurrió
El 19 de mayo de 2026, AWS anunció que CloudFront ahora soporta tráfico WebSocket hacia VPC Origins. Esto extiende la funcionalidad de VPC Origins —lanzada en 2023 para HTTP/HTTPS estándar— a protocolos que requieren conexiones persistentes, como WebSocket (RFC 6455). Hasta entonces, los clientes que usaban WebSocket debían colocar sus orígenes (ALB, NLB o EC2) en subredes públicas o implementar soluciones ad-hoc con AWS Network Firewall, EC2 Transit Gateway o terceros como Fortinet para filtrar tráfico a nivel de aplicación.
La novedad técnica clave es que CloudFront ahora negocia el upgrade de HTTP a WebSocket directamente con el cliente, redirige el tráfico a través de su red global de edge y, finalmente, lo entrega al origen en la VPC privada sin exponer la IP del balanceador. Esto se logra gracias a un nuevo listener en CloudFront que acepta el Connection header con valor Upgrade y mantiene la conexión abierta mientras dure el tráfico WebSocket. No se requiere configurar un Custom Origin con puerto 80/443 alternativo ni abrir puertos adicionales en los Security Groups del origen.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps, el cambio simplifica la topología de red. En lugar de mantener un ALB en modo WebSocket con Health Checks configurados para /health y un NLB para balanceo de tráfico UDP/TCP —que no todos los clientes necesitan—, ahora basta un solo CloudFront Distribution apuntando a un ALB o NLB en una subred privada. Esto reduce:
- Superficie de ataque: se eliminan reglas de Security Groups que permitían tráfico desde 0.0.0.0/0 al puerto 8080 o 443 alternativo.
- Mantenimiento: se eliminan Health Checks adicionales para WebSocket y reglas de WAF específicas para puertos no estándar.
- Costos: no hay cargo adicional por tráfico WebSocket en VPC Origins, aunque CloudFront ya cobra por peticiones (1 USD por millón) y ancho de banda.
Para equipos de Seguridad, el beneficio es claro: CloudFront ya aplica protección DDoS en capa 7 y WAF sin configuración extra. Según el AWS Well-Architected Framework (versión 2024), el 65% de los incidentes en apps WebSocket en AWS estaban relacionados con configuraciones incorrectas de Security Groups o NACLs. Con esta mejora, ese riesgo se mitiga al centralizar el tráfico en CloudFront.
Para Cloud, el impacto es de escalabilidad. CloudFront ahora maneja WebSocket como parte de su Edge Function (Lambda@Edge o CloudFront Functions) si se requiere autenticación o transformación de mensajes. Esto permite, por ejemplo, validar tokens JWT en el edge antes de que el tráfico llegue al origen, algo que antes requería un ALB con autenticación integrada o un API Gateway adicional.
Detalles técnicos
- Regiones soportadas: Todas las regiones comerciales de AWS donde VPC Origins está disponible. Según el AWS Status RSS al 20 de mayo de 2026, no hay regiones con degradación en el servicio.
- Protocolos soportados: WebSocket sobre
ws://ywss://(WebSocket Secure). No se soporta HTTP/2 con prioridad de streams, pero sí WebSocket en versiones 8, 13 y 14 de la especificación. - Orígenes compatibles: ALB (Application Load Balancer), NLB (Network Load Balancer) y EC2 (con Security Group que permita tráfico desde la IP de CloudFront). Para EC2, el Security Group debe permitir tráfico desde los rangos de IP de CloudFront:
13.32.0.0/15(us-east-1),13.224.0.0/12(us-west-2), etc. La lista completa está en CloudFront IP Ranges. - Configuración requerida:
2. En la configuración del origen, seleccionar VPC Origin y elegir el ALB/NLB/EC2 en la subred privada.
3. Configurar el Behavior para que acepte el Connection header con valor Upgrade y redirija a /ws (o el path deseado).
4. Actualizar el Security Group del origen para permitir tráfico TCP desde los rangos de IP de CloudFront en el puerto del origen (ej: 8080 para WebSocket).
Ejemplo de configuración en Terraform (versión 1.7+):
resource "aws_cloudfront_distribution" "websocket_app" {
origin {
domain_name = aws_lb.internal_alb.dns_name
origin_id = "vpc-origin-alb"
custom_origin_config {
http_port = 80
https_port = 443
origin_protocol_policy = "https-only"
origin_ssl_protocols = ["TLSv1.2"]
}
}
enabled = true
is_ipv6_enabled = true
default_root_object = ""
default_cache_behavior {
allowed_methods = ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
cached_methods = ["GET", "HEAD"]
target_origin_id = "vpc-origin-alb"
forwarded_values {
query_string = false
cookies {
forward = "none"
}
}
viewer_protocol_policy = "redirect-to-https"
# Configuración clave para WebSocket:
forwarded_values {
query_string = false
headers = ["Connection"]
cookies {
forward = "none"
}
}
}
restrictions {
geo_restriction {
restriction_type = "none"
}
}
viewer_certificate {
cloudfront_default_certificate = true
}
}- Sin costo adicional: AWS confirmó que no hay cargo extra por tráfico WebSocket en VPC Origins. El costo sigue siendo el de CloudFront (1 USD por millón de peticiones) y el ancho de banda estándar.
Qué deberían hacer los administradores y equipos técnicos
- Actualizar la arquitectura:
– Migrar el ALB/NLB/EC2 a una subred privada.
– Configurar CloudFront como único punto de entrada, siguiendo los pasos en CloudFront VPC Origins.
- Ajustar Security Groups:
0.0.0.0/0 al puerto del origen.– Agregar reglas que permitan TCP desde los rangos de IP de CloudFront:
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select(.service == "CLOUDFRONT") | .ip_prefix'
– Para ALB, configurar el Health Check en / o /health con protocolo HTTPS y puerto 443.
- Validar compatibilidad:
– Verificar que el cliente pueda establecer la conexión WebSocket y que el origen reciba los mensajes. Usar herramientas como wscat:
wscat -c wss://d123.cloudfront.net/ws -H "Authorization: Bearer <token>"
- Monitorear:
WebSocketRequestCount, 5xxErrorRate y Latency.– Revisar logs de WAF para detectar patrones de ataque en tráfico WebSocket (ej: inyección de payloads en mensajes).
- Documentar:
– Capacitar al equipo en el manejo de WebSocket en CloudFront, especialmente en el uso de Lambda@Edge para autenticación o transformación de mensajes.
Conclusión
El soporte de WebSocket en VPC Origins de CloudFront es un avance significativo para equipos que necesitan correr aplicaciones en tiempo real con máxima seguridad y mínima complejidad. Al centralizar el tráfico en CloudFront, se eliminan endpoints públicos innecesarios, se simplifica la gestión de Security Groups y se aprovecha la protección DDoS integrada. Para equipos que usan ALB/NLB o EC2 en subredes privadas, la migración es directa y no implica costos adicionales por el tráfico WebSocket. El mayor desafío será actualizar la documentación y los runbooks para reflejar el nuevo flujo, pero el beneficio en seguridad y operatividad justifica el esfuerzo.
El cambio también marca un paso más hacia la consolidación de CloudFront como puerta de entrada única para todo el tráfico, tanto tradicional como en tiempo real. En un entorno donde las aplicaciones IoT, los dashboards colaborativos y las plataformas de comunicación en tiempo real son cada vez más comunes, esta mejora llega en el momento justo para reducir la deuda técnica y el riesgo operativo.