Imagen destacada del artículo: Route 53 en producción: patrones reales, errores comunes y decisiones de SRE

Route 53 en producción: patrones reales, errores comunes y decisiones de SRE

Fecha de publicación:

Cuando todo funciona, nadie piensa en el DNS. Cuando algo falla, todo el mundo lo sufre. En producción, Route 53 no es un servicio “de apoyo”, es una pieza crítica de resiliencia que puede salvarte un incidente… o alargarlo innecesariamente.

Este artículo no va de definiciones técnicas que puedes encontrar en la documentación oficial. Va de lo que realmente pasa cuando el tráfico es real, los usuarios están esperando y los errores cuestan dinero.

TTL: el detalle que casi siempre se decide mal

El TTL (Time To Live) suele configurarse una vez y olvidarse. Error clásico que he visto repetirse en demasiados equipos.

En producción, el TTL define cuánto tiempo tardas en reaccionar ante un problema. Punto. No es un parámetro técnico abstracto, es tiempo real de indisponibilidad.

Ejemplo muy común

Imagina que tienes un failover configurado correctamente, los health checks funcionan perfectamente… pero el TTL es de 300 segundos. La región principal cae y el tráfico sigue yendo allí durante cinco minutos completos.

Técnicamente todo está bien configurado. Operativamente, es un desastre y tus usuarios lo están sufriendo.

En entornos críticos tienes que decidir:

  • TTL alto = Menos consultas DNS, menor coste, pero reacción lenta ante problemas
  • TTL bajo = Más coste y tráfico DNS, pero agilidad real cuando necesitas cambiar algo

No hay un valor mágico. Hay decisiones conscientes basadas en tu SLA y en cuánto te puedes permitir esperar durante un incidente. En sistemas con requisitos de alta disponibilidad, un TTL bajo (60-120 segundos) es parte del diseño, no un capricho.

Consejo práctico: En mis proyectos críticos uso TTL de 60 segundos. Sí, pagas más consultas DNS, pero cuando necesitas cambiar algo urgentemente, esos minutos de diferencia marcan la experiencia del usuario.

Health checks: qué miden realmente (y qué no)

Otro error habitual es pensar que los health checks de Route 53 “vigilan la aplicación”. No lo hacen y es importante entender esa diferencia.

Su función es simple pero crítica: decidir si un endpoint debe recibir tráfico o no. Nada más, nada menos.

Problema típico que verás

El endpoint responde con HTTP 200, pero internamente la aplicación está devolviendo errores a los usuarios. Para Route 53 está sano y sigue mandando tráfico. Para el negocio, no lo está.

He visto este escenario demasiadas veces: todo “verde” en Route 53 mientras los usuarios reportan errores.

Buenas prácticas reales basadas en la experiencia:

  1. Health checks simples y rápidos - Deben responder en milisegundos, no segundos
  2. Endpoints dedicados - Crea /health o /status específicos para health checks
  3. Lógica mínima - Sin dependencias externas pesadas (bases de datos, APIs de terceros)
  4. Valida lo esencial - Solo comprueba que el servicio pueda atender tráfico, no toda la lógica de negocio
# Ejemplo de endpoint health simple
GET /health
Response: 200 OK
{
  "status": "healthy",
  "timestamp": "2025-05-24T10:30:00Z"
}

Importante: Route 53 no sustituye tu observabilidad (Prometheus, DataDog, CloudWatch…). La complementa en el punto exacto donde decide el routing. Son herramientas complementarias, no excluyentes.

Failover DNS: potente, pero no instantáneo

El failover vía DNS funciona bien, pero no es magia. Y es crucial entender sus limitaciones reales.

El tiempo de failover depende de:

  • Frecuencia del health check (30 segundos por defecto)
  • Número de fallos consecutivos requeridos (típicamente 3)
  • TTL configurado en el registro
  • Caché del resolver DNS del cliente

Sumando todo esto, en el mejor de los casos estás hablando de 1-2 minutos. En el peor, pueden ser 5-10 minutos.

Hecho importante que aprendí de la forma difícil

No todos los clientes respetan el TTL como deberían. Algunos ISPs cachean más tiempo del indicado. Algunos navegadores tienen su propia caché interna. Y no puedes hacer nada al respecto.

Por eso el DNS nunca debe ser tu única estrategia de resiliencia, sino la última capa de defensa.

Usa Route 53 failover para:

✅ Caídas completas de región
✅ Incidentes graves de infraestructura
✅ Mantenimientos planificados con cambio de región

No lo uses para:

❌ Microcortes de segundos
❌ Balanceo de carga dinámico
❌ Ajustes automáticos de capacidad

Para esos casos tienes ALB/NLB, Auto Scaling y otras herramientas más apropiadas.

Weighted routing como herramienta de despliegue

Uno de los usos más infravalorados de Route 53 es como mecanismo de despliegue controlado. Y es brutalmente efectivo.

Caso real que uso en producción

Imagina que tienes una nueva versión de tu aplicación y quieres desplegarla con cautela:

  1. Despliegas la nueva versión en paralelo (misma URL, diferente Target Group o región)
  2. Configuras weighted routing:
    • 95% del tráfico → versión estable
    • 5% del tráfico → versión nueva
  3. Observas métricas durante 1-2 horas
  4. Si todo va bien: aumentas progresivamente (20%, 50%, 100%)
  5. Si algo falla: cambias los pesos y el rollback es inmediato

Sin tocar el ALB. Sin feature flags complejos. Sin lógica extra en el código.

# Ejemplo conceptual de configuración
- Type: A
  Name: api.midominio.com
  SetIdentifier: "version-stable"
  Weight: 95
  ResourceRecords:
    - 10.0.1.100

- Type: A
  Name: api.midominio.com
  SetIdentifier: "version-new"
  Weight: 5
  ResourceRecords:
    - 10.0.2.100

Si algo falla, cambias los pesos en Route 53 y el rollback es cuestión de minutos (más el TTL). Esto convierte al DNS en una herramienta operativa, no solo de red.

Mi experiencia: He usado esto para despliegues de API críticas donde el blue/green tradicional era demasiado arriesgado. El weighted routing te da control granular sin complejidad adicional.

Multi-región sin volverte loco

En arquitecturas multi-región, Route 53 es el pegamento que une todo. Y es increíblemente elegante cuando lo haces bien.

Patrón típico que funciona

Aplicación desplegada en dos regiones (por ejemplo, eu-west-1 y us-east-1):

  1. Latency-based routing para tráfico normal

    • Route 53 envía cada usuario a la región más cercana
    • Mejora la latencia percibida significativamente

  2. Failover preparado para caídas completas

    • Si una región cae, el tráfico va automáticamente a la otra
    • Los health checks detectan la caída y redirigen

  3. Geo-routing opcional para cumplimiento normativo

    • Datos europeos se quedan en Europa (GDPR)
    • Datos de otras regiones pueden ir a US
┌──────────────┐
│  Route 53    │
│  (Global)    │
└──────┬───────┘
       │
   ┌───┴────┐
   │        │
┌──▼───┐ ┌─▼────┐
│EU-W-1│ │US-E-1│
│ ALB  │ │ ALB  │
└──────┘ └──────┘

El error frecuente

Intentar resolver la multi-región solo con load balancers. El problema es que los ALB solo ven su región. No pueden enrutar inteligentemente tráfico global.

Route 53 sí. Tiene visión global y toma decisiones basadas en:

  • Latencia real medida
  • Salud de los endpoints
  • Ubicación geográfica del usuario

Es la herramienta correcta para el problema correcto.

DNS y despliegues de emergencia

En incidentes graves, cuando todo está en llamas, el DNS suele ser la única palanca que sigue funcionando.

Ejemplo claro de un incidente real

  • 00:05 - Se detecta bug crítico en nueva versión
  • 00:07 - El rollback a nivel de Kubernetes va lento
  • 00:08 - El tráfico sigue entrando y los errores se acumulan
  • 00:10 - Cambias el registro DNS apuntando a la versión antigua
  • 00:12 - El tráfico empieza a fluir correctamente (según el TTL)

Con Route 53 puedes redirigir tráfico lejos del problema mientras el equipo arregla el fondo. No es elegante, no es la solución perfecta, pero es efectivo. Y en producción, eso importa más que la pureza arquitectónica.

He usado esto en producción más veces de las que me gustaría admitir. Y cada vez me alegro de tener Route 53 correctamente configurado como última línea de defensa.

Requisitos para que funcione

  1. TTL bajo - Si tienes TTL de 3600 segundos, esto no te sirve
  2. Infraestructura paralela - Necesitas tener algo a donde apuntar
  3. Permisos de emergencia - Acceso rápido sin 5 niveles de aprobación
  4. Runbooks claros - No es momento de pensar, es momento de ejecutar

Entornos, cuentas y delegación DNS

En organizaciones medianas o grandes aparece otro problema organizativo: ¿quién controla el DNS?

Y más importante: ¿cómo evitas que alguien rompa producción editando un registro “sin querer”?

Mal patrón (muy común)

❌ Todo el DNS en una sola cuenta AWS
❌ Cambios manuales vía consola
❌ Sin auditoría clara de quién cambió qué
❌ Permisos amplios para “facilitar el trabajo”

Resultado: Tarde o temprano alguien edita producción pensando que está en desarrollo.

Buen patrón (basado en experiencia)

✅ Zona principal delega subzonas

miempresa.com (cuenta principal)
  ├── dev.miempresa.com (cuenta dev)
  ├── staging.miempresa.com (cuenta staging)
  └── api.miempresa.com (cuenta producción)

✅ Cada entorno gestiona su subzona de forma independiente
✅ Cambios versionados como infraestructura (Terraform, CloudFormation)
✅ Pipeline de aprobación para cambios en producción
✅ Auditoría completa vía CloudTrail

Esto reduce drásticamente los errores humanos y los conflictos entre equipos. El DNS también necesita gobernanza, no solo permisos IAM.

Errores comunes que cuestan horas (o días)

Después de años trabajando con Route 53, estos son los errores clásicos que veo repetirse:

1. Cambiar registros sin entender la caché

Cambias un registro de A a B, pero sigues viendo tráfico a A durante horas. ¿Por qué? El TTL anterior era de 86400 segundos (24 horas). Ahora tienes que esperar.

Solución: Antes de cambiar algo crítico, baja el TTL con anticipación (24-48h antes).

2. Mezclar Route 53 con DNS externos sin estrategia

Algunos registros en Route 53, otros en Cloudflare, otros en el proveedor de dominio. Nadie sabe dónde está cada cosa.

Solución: Migra todo a Route 53 o documenta claramente qué vive dónde y por qué.

3. No documentar decisiones de routing

“¿Por qué este registro tiene geolocation configurado?” - Nadie lo sabe. El que lo configuró ya no está en la empresa.

Solución: Documenta en el mismo IaC (Terraform/CloudFormation) el “por qué” de cada configuración compleja.

# Geolocation configurado para cumplir GDPR
# Usuarios europeos DEBEN ir a eu-west-1
# Ticket: INFRA-1234
resource "aws_route53_record" "api_eu" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.miempresa.com"
  type    = "A"
  
  geolocation_routing_policy {
    continent = "EU"
  }
  
  alias {
    name                   = aws_lb.eu_west_1.dns_name
    zone_id                = aws_lb.eu_west_1.zone_id
    evaluate_target_health = true
  }
}

4. TTLs altos “porque siempre ha sido así”

Herencias de configuraciones antiguas sin cuestionarse si siguen teniendo sentido.

Solución: Revisa tus TTLs anualmente. Las decisiones de hace 3 años pueden no aplicar hoy.

El problema del DNS

El DNS no avisa cuando falla. No hay errores en pantalla. Simplemente responde mal… durante mucho tiempo. Y cuando te das cuenta, el daño ya está hecho.

Route 53 desde la mirada SRE

Como SRE, no veo Route 53 simplemente como “donde vive el dominio”. Es mucho más que eso.

Es tu:

🎯 Punto de control global - La única herramienta que ve todo tu tráfico mundial
🛡️ Herramienta de mitigación - Cuando todo falla, el DNS sigue funcionando
🚨 Última defensa - Ante fallos grandes, es tu última línea de acción

Checklist SRE para Route 53

  • TTL documentados y justificados
  • Health checks monitorizados (alertas si fallan)
  • Failover testeado regularmente (no esperes al incidente)
  • Cambios de DNS versionados en Git
  • Runbooks para escenarios de emergencia
  • Costes de DNS revisados mensualmente
  • Delegación de zonas correctamente implementada

Route 53 no sustituye una buena arquitectura. No va a arreglar un diseño malo ni va a resolver problemas de código.

Pero refuerza tu arquitectura cuando más falta hace. En ese momento crítico donde necesitas cambiar el tráfico globalmente, tener Route 53 bien configurado marca la diferencia entre un incidente de 5 minutos y uno de 2 horas.

Route 53 es una herramienta increíblemente potente cuando entiendes sus limitaciones y fortalezas. No es solo un servicio DNS más, es una pieza fundamental en tu estrategia de resiliencia.

Las lecciones que compartí aquí vienen de incidentes reales, errores cometidos y soluciones que funcionaron. Espero que te ayuden a evitar algunos de los problemas que yo tuve que aprender de la forma difícil.

Recursos adicionales