Guía completa de Amazon Route 53: aprender el diseño de “DNS y control de tráfico” mediante comparaciones con Google Cloud DNS y Azure DNS / Traffic Manager
Introducción
Amazon Route 53 es un servicio centrado en el DNS autoritativo de AWS, que también maneja registro de dominios, health checks, failover DNS y varias políticas de enrutamiento. La documentación oficial de AWS explica que Route 53 proporciona no solo servicios DNS, sino también funciones como health checks y VPC Resolver, y que sus políticas de enrutamiento pueden distribuir tráfico en función de la ubicación del usuario, la ubicación del recurso, la latencia, la dirección IP y los health checks.
En GCP, el servicio central más cercano es Cloud DNS, mientras que en Azure el equivalente es Azure DNS. Sin embargo, funciones de Route 53 como “DNS failover” y “enrutamiento basado en latencia/rendimiento” se comparan de forma más natural en Azure no solo con Azure DNS, sino en combinación con Azure Traffic Manager. Cloud DNS utiliza un modelo de precios simple basado en zonas y consultas, Azure DNS también se cobra principalmente por zonas y consultas, y Traffic Manager se cobra principalmente por consultas DNS y health checks.
En este artículo, organizaré Route 53 no como “simplemente un servicio de resolución de nombres”, sino como un objetivo de diseño que incluye DNS público, DNS interno, diseño de disponibilidad, conmutación multirregión y optimización de costos.
1. ¿Qué es Route 53?
Route 53 es el servicio DNS totalmente gestionado de AWS. Puede utilizarse no solo como base para la resolución de nombres, sino también para gestionar conjuntamente el registro de dominios, zonas alojadas públicas, zonas alojadas privadas, health checks y varias políticas de enrutamiento. La guía oficial también muestra que Route 53 proporciona servicios DNS además de health checks, DNS failover y VPC Resolver.
Dicho de forma simple, Route 53 es fuerte porque puede encargarse conjuntamente de las siguientes tres cosas:
- DNS orientado a Internet
- DNS interno para VPCs
- Control de tráfico diseñado en torno a disponibilidad, geografía y latencia
En particular, una vez que empiezas a usar múltiples regiones, múltiples Availability Zones y múltiples endpoints en AWS, empieza a ser importante diseñar no solo la gestión del DNS, sino también a dónde debe enviarse el tráfico. Ahí es donde el valor de Route 53 aumenta drásticamente.
2. Correspondencia con servicios equivalentes en GCP y Azure
GCP: Cloud DNS
Cloud DNS es el servicio DNS gestionado de Google Cloud. Según la página oficial de precios, la facturación se basa principalmente en el número de zonas y en el número de consultas, y no hay capa gratuita. Su función es bastante cercana a la parte de DNS autoritativo de Route 53, pero funciones como el failover vinculado a health checks y las ricas políticas de enrutamiento de Route 53 no se reflejan directamente en un único servicio de la misma manera.
Azure: Azure DNS + Traffic Manager
Azure DNS es el servicio responsable del alojamiento de DNS autoritativo. Traffic Manager, por otro lado, es un servicio de distribución de tráfico basado en DNS que proporciona enrutamiento como performance-based routing, failover y round robin, junto con health checks. En otras palabras, en Azure es más fácil entender que algunas funciones de Route 53 están divididas entre Azure DNS y Traffic Manager.
Esta diferencia afecta al diseño.
En AWS, es fácil colocar tanto el “DNS como el enrutamiento” dentro de Route 53. En Azure, en cambio, es más sencillo pensar en términos de separación de roles: “nombres en Azure DNS, enrutamiento en Traffic Manager”. GCP tiende a mantener el propio DNS relativamente simple, dejando la distribución de nivel superior a otros servicios o a decisiones arquitectónicas.
3. La estructura básica de Route 53
Hosted Zones
El concepto central en Route 53 es la hosted zone.
- Una public hosted zone es para uso orientado a Internet
- Una private hosted zone es para resolución interna de nombres dentro de una VPC
Esta separación se convierte en la primera bifurcación del diseño operativo. Es más fácil gestionar permisos y reducir el riesgo de accidentes cuando los nombres visibles desde Internet y los nombres destinados a resolverse solo dentro de la empresa o de la VPC no se mezclan. Algunas políticas de enrutamiento de Route 53 también pueden usarse con private hosted zones.
Records
Los propios registros DNS utilizan conceptos comunes como A, AAAA y CNAME, pero una gran característica de Route 53 es que, al crear un registro, eliges qué política de enrutamiento utilizar. Aquí es donde la diferencia entre un servicio DNS simple y Route 53 se vuelve más evidente.
Health Checks
Los health checks de Route 53 pueden monitorizar un endpoint especificado, otro health check o el estado de una alarma de CloudWatch. Como los resultados de los health checks pueden incorporarse al DNS failover, resulta fácil diseñar un sistema que no devuelva endpoints caídos.
4. Las políticas de enrutamiento son el verdadero núcleo de Route 53
El verdadero valor de Route 53 no está tanto en que pueda almacenar registros DNS, sino en que puede controlar cómo se devuelven las respuestas. La documentación oficial explica que, al crear un registro, eliges una política de enrutamiento y determinas cómo deben gestionarse las respuestas. Entre las políticas principales están simple, failover, geolocation y latency-based routing.
4.1 Simple Routing
Esto es para un único recurso o para resolución básica de nombres. A menudo es suficiente para un entorno inicial, pero una vez que empiezas a pensar en disponibilidad o distribución geográfica, sus límites aparecen rápidamente.
4.2 Failover Routing
Está orientado a configuraciones active/passive. Permite el tipo más claro de diseño de alta disponibilidad a nivel DNS: si el primario falla, cambiar al secundario. Cuando se combina con health checks, se hace posible la conmutación automática ante fallos del endpoint.
4.3 Latency-Based Routing
Esto devuelve la región con menor latencia para la persona usuaria. Es útil en arquitecturas multirregión cuando se quiere dirigir a la persona usuaria al sitio más cercano. Es especialmente eficaz para servicios globales.
4.4 Geolocation Routing
Esto cambia el destino de respuesta según la ubicación geográfica de la persona usuaria. Es fácil de usar para regulaciones, contenido específico por región y conmutación internacional.
4.5 Weighted Routing
Esto es muy adecuado para cutovers en producción, pruebas A/B y despliegues graduales. Por ejemplo, es fácil usarlo para enviar el 90% del tráfico al entorno antiguo y el 10% al nuevo.
En la práctica, en lugar de memorizar todo esto en detalle, resulta mucho más fácil organizarlo en cuatro categorías:
- Resolución simple de nombres
- Conmutación/failover
- Geografía/latencia
- Despliegue gradual
5. Health Checks y DNS Failover
Los health checks de Route 53 son la función que convierte al DNS de “resolución estática de nombres” en “gestión de tráfico basada en el estado actual”. AWS explica oficialmente que los health checks pueden monitorizar recursos como servidores web, otros health checks o alarmas de CloudWatch, y que pueden utilizarse para DNS failover.
Ejemplos típicos donde esto resulta útil son:
- Si falla el frontend en la región de Tokio, cambiar a Osaka
- Si falla la API primaria, mover el tráfico al sitio de DR
- Detectar métricas anómalas de la aplicación mediante una alarma de CloudWatch y reflejar ese estado en el DNS
Como esto opera en la capa DNS, no ofrece el mismo control fino que un balanceador L7, pero esa simplicidad lo hace muy adecuado para grandes conmutaciones entre regiones.
6. Cómo pensar en los precios
Los precios de Route 53 se dividen principalmente en:
- Hosted zones
- Consultas DNS
- Health checks
- Registro de dominios
La página oficial de precios también muestra que los health checks se facturan mensualmente, y que hay una capa gratuita para health checks básicos contra endpoints de AWS.
GCP Cloud DNS cobra por zona más el número de consultas, sin capa gratuita. Azure DNS también se basa en zonas y consultas. Traffic Manager se cobra principalmente por consultas DNS y por health checks por endpoint.
Esto hace más fácil estimar los costos si lo piensas de forma aproximada así:
- Route 53 / Cloud DNS / Azure DNS
- Los costos crecen con “cuántos nombres tienes” y “con qué frecuencia se consultan”
- Route 53 health checks / Azure Traffic Manager
- Los costos crecen con “cuántas cosas monitorizas” y “si usas monitorización de alta frecuencia”
En otras palabras, si estás haciendo alojamiento DNS simple, el precio es relativamente sencillo. Pero una vez que incorporas diseño de alta disponibilidad al DNS, aparecen costos adicionales relacionados con health checks. El punto de decisión es si puedes justificar eso como “seguro de alta disponibilidad”.
7. Patrones de diseño prácticos
7.1 Un sitio web simple
- Public hosted zone
- Apuntar
www.example.coma un CDN o a un balanceador de carga - Empezar con simple routing
Para un sitio de pequeña escala, esto suele ser suficiente. Es importante no complicarlo demasiado desde el principio.
7.2 API multirregión
- Usar latency-based routing o failover routing para
api.example.com - Distribuir tráfico a APIs en cada región
- Usar health checks para failover en caso de problemas
Esto es adecuado cuando tienes una API global o requisitos de DR. Como la conmutación sucede en la capa DNS, la clave es entender que esto no es perfectamente en tiempo real.
7.3 DNS interno para uso empresarial
- Private hosted zone
- Nombres internos como
db.internal.example.local - Resolución por VPC
El simple hecho de evitar direcciones IP hardcodeadas en la configuración de la aplicación puede aumentar mucho la flexibilidad durante cambios de configuración y DR. Route 53 también es fuerte como este tipo de “base de DNS interno”.
7.4 Despliegue gradual
- Mantener entornos antiguo y nuevo en paralelo con weighted routing
- Aumentar el tráfico hacia el nuevo entorno de 5% → 20% → 50% → 100%
Esto es más adecuado para transiciones de infraestructura y migraciones a gran escala que para pruebas A/B a nivel de aplicación.
8. Resumen de la comparación con GCP y Azure
AWS Route 53
Route 53 se caracteriza porque puede reunir en un único servicio DNS autoritativo, health checks, failover y varias políticas de enrutamiento. Funciona muy bien con diseños multirregión nativos de AWS.
GCP Cloud DNS
Cloud DNS es un servicio de DNS autoritativo simple y fácil de entender. El precio también es fácil de leer, basado en zonas y consultas, pero no está diseñado para completar dentro de un único servicio funciones ricas de failover DNS y enrutamiento como las de Route 53.
Azure DNS + Traffic Manager
En Azure, DNS y distribución de tráfico están separados.
- Azure DNS: DNS autoritativo
- Traffic Manager: distribución basada en DNS, health checks y failover
A primera vista, esta separación puede parecer más compleja, pero también puede hacer más clara la separación de responsabilidades.
9. Errores comunes
9.1 Confundir los roles de DNS y de los balanceadores de carga
Route 53 controla el tráfico en la capa DNS. El enrutamiento fino petición por petición o el control basado en headers de aplicación pertenecen a otra capa. Confundir estos roles hace que la arquitectura sea innecesariamente compleja.
9.2 Añadir demasiadas políticas de enrutamiento desde el principio
Si incluyes todo, acabas con una configuración DNS que solo entiende quien la opera.
Es más seguro empezar con simple routing, luego pasar a failover y solo después añadir latencia o geolocalización si realmente es necesario.
9.3 Dejar poco claro qué significan los health checks
Si añades health checks sin decidir qué significa realmente “saludable”, corres el riesgo de falsos positivos o de conmutar con demasiada frecuencia.
Decide primero si basta una simple respuesta HTTP 200, si quieres comprobar conectividad completa de la aplicación, o si quieres usar integración con alarmas de CloudWatch.
10. Conclusión
Amazon Route 53 es tanto un servicio de gestión de DNS como un servicio que respalda el “diseño del punto de entrada” de la disponibilidad y la entrega global. La documentación oficial organiza claramente funciones que van más allá del DNS simple, como políticas de enrutamiento, health checks y VPC Resolver.
Si entiendes GCP Cloud DNS como un servicio de DNS autoritativo simple y directo, y Azure como un entorno similar a Route 53 creado mediante la combinación de Azure DNS y Traffic Manager, entonces es menos probable que tus decisiones arquitectónicas se desvíen incluso en un entorno multicloud.
Como primer paso práctico, recomiendo:
- Consolidar el DNS orientado al exterior en Route 53
- Adjuntar health checks a endpoints importantes
- Probar solo una configuración de failover
El DNS es discreto, pero si lo diseñas con cuidado, la respuesta ante incidentes, la arquitectura multirregión, las migraciones y los despliegues graduales se vuelven un poco más fáciles.