Introducción
Un equipo de infraestructura migró sus load balancers de ingreso público a TLS 1.3 para cumplir con una política de compliance. Los handshakes completaron sin errores, los servicios respondían con código 200, las métricas de CPU y latencia se mantuvieron planas. Cuarenta minutos después, una región completa había perdido el 100 % del tráfico de usuarios. Los dashboards internos no registraron ninguna alerta. El problema no estaba en el data plane: estaba en el control plane de Route 53, que no pudo completar el handshake TLS con los endpoints y los marcó como no saludables. Este incidente, documentado por Alexey Golev en InfoQ (octubre 2026), no es una rareza. Es la consecuencia directa de tratar la alta disponibilidad como si fuera resiliencia, cuando son dos problemas distintos con prerequisitos distintos.
Qué ocurrió
La política de compliance obligó al equipo a deshabilitar TLS 1.2 en los load balancers públicos y dejar únicamente TLS 1.3 disponible. Hasta ahí, el cambio parecía inocuo: los navegadores modernos soportan TLS 1.3, los handshakes internos funcionaban, y las pruebas de regresión sobre la aplicación no detectaron anomalías. Lo que el equipo no modeló fue el comportamiento del checker de Route 53. Los health checks HTTPS de Route 53 requieren que el endpoint destino soporte TLS 1.2. Si el endpoint solo ofrece TLS 1.3, el handshake del checker falla, Route 53 marca el endpoint como unhealthy y el CDN deja de enrutar tráfico hacia esa región.
Mientras tanto, dentro de la región afectada todo seguía operando con normalidad. Las instancias EC2 respondían, los ALB registraban conexiones exitosas, las bases de datos replicaban sin lag. La única señal observable era la ausencia de tráfico entrante. Los usuarios fueron reenviados de forma transparente a una región a miles de kilómetros, con un pico de latencia perceptible en las geografías afectadas. La región de failover, que nunca había sido provisionada para ese volumen, comenzó a escalar bajo una carga para la cual no tenía capacidad asignada. El diagnóstico completo tomó cuarenta minutos porque el problema no generaba señales en la telemetría interna: los servicios estaban «sanos», solo que nadie les enviaba requests.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El incidente ilustra una falla en el plano de control que la mayoría de las arquitecturas multi-región no contempla. Los equipos de SRE y plataforma diseñan redundancia a nivel de instancia (Auto Scaling Groups), zona (Multi-AZ) y región (Route 53 failover routing), pero rara vez validan que el mecanismo de enrutamiento entre regiones funcione cuando el endpoint destino cambia su comportamiento criptográfico. El impacto concreto: una región completa sin tráfico durante 40 minutos, degradación de latencia en usuarios de al menos una geografía, y una región de failover operando fuera de su perfil de capacidad.
Desde la perspectiva de seguridad, el incidente también expone un riesgo de governance. La política de TLS 1.3-only se aplicó como cambio de compliance sin una revisión de dependencia en el plano de control. Los equipos de seguridad definen requisitos criptográficos; los equipos de infraestructura los implementan; pero casi nadie verifica que el plano de control (Route 53, CloudFront, health checkers, service meshes) soporte el nuevo perfil. Esa brecha entre la política de seguridad y la operación del control plane es un vector de incidente recurrente en entornos multi-cloud.
Detalles técnicos
Route 53 realiza health checks HTTPS enviando una solicitud TLS al endpoint configurado. El protocolo de handshake que utiliza el checker no es negociable: requiere soporte TLS 1.2 en el servidor destino. Si el endpoint presenta únicamente TLS 1.3 (es decir, TLS 1.2 está explícitamente deshabilitado), el handshake no se completa y Route 53 registra un fallo. Tras N fallos consecutivos (configurables, por defecto 3 con intervalos de 30 segundos), el endpoint pasa a estado InService: false.
El efecto en cadena es el siguiente:
TLS 1.2 deshabilitado en ALB público
→ Route 53 HTTPS health check falla (handshake incompatibilidad)
→ Endpoint marcado como unhealthy (3 fallos × 30 s ≈ 90 s)
→ Route 53 failover policy reenvía tráfico a región secundaria
→ Región secundaria no provisionada para ese volumen
→ Latencia +400-800 ms en geografías primarias
Los health checks internos del ALB (target group health) no se ven afectados porque operan sobre el tráfico de aplicación, no sobre el handshake de Route 53. Por eso los dashboards internos mostraban verde: los target groups reportaban healthy, las instancias respondían, y las métricas de CloudWatch para la aplicación no registraban anomalías. Solo los health checks de Route 53 (visibles en el panel de DNS, no en los de EC2/ALB) registraban el fallo.
El incidente también toca una falla de correlación a nivel de software: un cambio de configuración (deshabilitar TLS 1.2) desplegado simultáneamente en todos los replicas de la región rompe el contrato de interoperabilidad con un componente externo (Route 53) que no está en el mismo scope de despliegue. La redundancia Multi-AZ no protege contra esto porque la dependencia corrupta (la política TLS) es compartida por todas las instancias de la región.
Qué deberían hacer los administradores y equipos técnicos
Primero, antes de cualquier cambio de política TLS en endpoints públicos, verificar la compatibilidad del plano de control. Para Route 53, confirmar que el endpoint destino mantiene soporte TLS 1.2 activo:
# Verificar perfiles TLS soportados en el listener del ALB
aws elbv2 describe-listeners \
–load-balancer-arn arn:aws:elbv2:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 \
–query ‘Listeners[].SslPolicy’ –output table
Si la política de compliance exige TLS 1.3, mantener TLS 1.2 habilitado como fallback exclusivamente para los health checks, o migrar a health checks TCP (que no requieren handshake TLS) y agregar una capa de validación criptográfica separada.
Segundo, separar la observabilidad del plano de control de la del plano de datos. Los dashboards de SRE que monitorean instancias, containers y servicios no detectan fallos en Route 53, CloudFront o service meshes. Agregar alertas específicas sobre el estado InService de los health checks de Route 53 y sobre la distribución de tráfico por región:
# CloudWatch alarm para health checks Route 53
– AlarmName: Route53-Endpoint-Unhealthy-us-east-1
MetricName: HealthCheckStatus
Namespace: AWS/Route53
Dimensions:
– Name: HealthCheckId
Value: «abc123-def456»
Statistic: Minimum
Period: 60
Threshold: 1
ComparisonOperator: LessThanThreshold
Tercero, ejecutar game days trimestrales donde se simule la pérdida de una región y se valide no solo que el failover enruta tráfico, sino que la región de destino absorbe la carga sin degradación. Un path de failover que nunca se ejercitó no es una estrategia de recuperación; es una suposición.
Cuarto, asignar un owner explícito de resiliencia, distinto del owner de disponibilidad. El on-call responde cuando un servicio cae. El owner de resiliencia mantiene los runbooks actualizados, verifica que las políticas IAM no hayan driftado, y audita trimestralmente que los contratos de interoperabilidad entre componentes del control plane sigan vigentes.
Conclusión
La alta disponibilidad protege contra fallos que el diseño ya contempló: una instancia que muere, una zona que desaparece, un timeout en una dependencia. La resiliencia protege contra lo que nadie modeló: un handshake TLS que cambia de versión y rompe silenciosamente el enrutamiento entre regiones. Los equipos cloud tienen herramientas maduras para la primera (Multi-AZ, ALB health checks, SLOs de uptime). Para la segunda, la madurez es mucho menor. El incidente de Route 53 y TLS 1.3 no requiere un bug en AWS ni una negligencia extrema. Solo requiere que dos equipos (compliance e infraestructura) cambien una política sin verificar que el plano de control la soporta. Si el runbook de recuperación tiene dos años, las políticas IAM han driftado y nadie ejercitó el failover desde que migraron a EKS, la redundancia es un seguro sin póliza vigente.
Fuentes
- https://www.infoq.com/articles/high-availability-not-resilience-cloud/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global