Failover en Route 53 para arquitectura activo-pasiva

Curso de AWS Certified Solutions Architect Associate

Contenido del curso

Fundamentos de AWS

Identidad, Acceso y Gobernanza Multicuenta

Servicios de Computo en AWS

Contenedores en AWS

Redes en AWS

Escalamiento y balanceo en AWS

Almacenamiento en AWS

Bases de datos en AWS

Migración en AWS

Monitoreo y Auditoria en AWS

DNS y CDN en AWS

Servicios de Seguridad

Serverless

Servicios de Datos en AWS

Servicios de AI y ML em AWS

64
Servicios de IA y ML en AWS
04:09 min

Servicios de Backup y Recuperación ante desastres

Architect Solutions Certificate

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:05

Failover en Route 53 para arquitectura activo-pasiva

Curso de AWS Certified Solutions Architect Associate

Clase 51 de 69

Clase 51 / 69

Recursos

Configurar Amazon Route 53 para una aplicación web alojada en instancias EC2 detrás de Elastic Load Balancers en varias regiones, con esquema activo-pasivo, requiere entender cómo este servicio traduce dominios como nexiabank.com a direcciones IP y qué políticas de enrutamiento aplican mejor. Esta guía te muestra cómo funciona Route 53, qué políticas existen y cuándo usar cada una, pensada para arquitectos cloud y desarrolladores que diseñan infraestructura en AWS.

¿Qué es Route 53 y cómo funciona la resolución DNS?

Route 53 es el servicio de DNS administrado de AWS. Funciona como traductor entre direcciones IP, que usan los servidores, y dominios legibles para humanos como nexiabank.com [01:00].

El flujo de una consulta DNS sigue un orden claro:

Tu equipo local consulta nexiabank.com.
La petición llega al servidor DNS local de tu empresa o ISP.
Si no tiene la respuesta, consulta al servidor DNS raíz, ubicado en varias regiones del mundo.
El raíz delega al servidor del dominio .com.
Este redirige al servidor DNS final de la empresa, donde Route 53 actúa como autoridad.
La IP regresa al servidor local y luego a tu máquina.

¿Qué hace exactamente Route 53? Actúa como el servidor DNS autoritativo de tu empresa en AWS, respondiendo qué IP corresponde a cada dominio configurado en tu VPC.

Al ser un servicio totalmente administrado, no necesitas preocuparte por autoescalado ni alta disponibilidad: AWS lo resuelve por ti [02:30].

¿Cómo se integra Route 53 con otros servicios de AWS?

La arquitectura típica conecta a los usuarios finales con tus recursos a través de varias capas. Cuando la consulta llega al resolver de Route 53, este se comunica con los servicios que tengas conectados.

Las integraciones nativas más comunes incluyen:

AWS CloudWatch para logs y monitoreo continuo de las resoluciones.
Healthchecks para evitar enrutar tráfico a instancias caídas.
API y consola web de AWS para administrar la configuración.
Conexión directa con EC2, Lambda, ELB y ALB.

Si el healthcheck pasa correctamente, la petición llega a la instancia o servicio configurado [03:45].

¿Qué políticas de enrutamiento ofrece Route 53?

Route 53 permite definir cómo se distribuye el tráfico de tus dominios hacia los servicios. Cada política responde a un caso de uso distinto.

¿Cuándo usar enrutamiento simple o failover?

La política simple es la predeterminada: resuelve un nombre de dominio a una IP de una instancia o servicio interno.

La política de failover combina un recurso principal con uno de respaldo. Mientras el healthcheck confirme que el principal responde, todo el tráfico va ahí. Si falla, Route 53 redirige automáticamente al recurso secundario. Esta es la opción natural para una arquitectura activo-pasiva entre regiones, como la del caso de nexiabank.com [04:30].

¿Qué política aplica para una arquitectura activo-pasiva multi-región? La política de failover con healthchecks, porque enruta al recurso principal mientras esté sano y conmuta al pasivo cuando deja de responder.

¿Cómo funcionan las políticas por geoproximidad y latencia?

La política de geoproximidad responde con un servidor distinto según la región del planeta donde se origina la petición. Por ejemplo:

Peticiones desde América responden desde Estados Unidos.
Peticiones desde Europa responden desde Londres.
Peticiones desde Asia responden desde Japón.

Esto reduce latencia y entrega respuestas localizadas.

La política basada en latencia es distinta: AWS decide internamente, sin depender de la ubicación geográfica, qué servidor responde más rápido. A veces, desde Latinoamérica un servidor en Estados Unidos responde mejor que uno geográficamente más cercano [06:00].

¿Qué características avanzadas tiene Route 53?

Más allá de las políticas, Route 53 incorpora funcionalidades que potencian casos de uso específicos.

Entre las más útiles están:

Registros tipo alias, que conectan directamente con servicios nativos de AWS y son más rápidos que los tradicionales A, AAAA o CNAME.
Protocolo DNSSEC para reforzar la seguridad de las peticiones DNS.
Hosted zones públicas y privadas: las privadas solo resuelven dentro de tu VPC, las públicas responden a internet abierto.
Healthchecks configurables para mover tráfico cuando un recurso deja de responder.

¿Qué es un registro alias en Route 53? Es un tipo de registro propio de AWS que apunta directamente a servicios como ELB, CloudFront o S3, sin necesidad de resolver una IP intermedia.

Con estas piezas en mente, revisa los recursos de la clase, identifica las dos opciones que mejor resuelven el caso de nexiabank.com y déjalas en los comentarios para discutirlas.

Resumen

¿Qué es Route 53 y cómo funciona la resolución DNS?

Route 53 es el servicio de DNS administrado de AWS. Funciona como traductor entre direcciones IP, que usan los servidores, y dominios legibles para humanos como nexiabank.com [01:00].

El flujo de una consulta DNS sigue un orden claro:

Tu equipo local consulta nexiabank.com.
La petición llega al servidor DNS local de tu empresa o ISP.
Si no tiene la respuesta, consulta al servidor DNS raíz, ubicado en varias regiones del mundo.
El raíz delega al servidor del dominio .com.
Este redirige al servidor DNS final de la empresa, donde Route 53 actúa como autoridad.
La IP regresa al servidor local y luego a tu máquina.

¿Qué hace exactamente Route 53? Actúa como el servidor DNS autoritativo de tu empresa en AWS, respondiendo qué IP corresponde a cada dominio configurado en tu VPC.

Al ser un servicio totalmente administrado, no necesitas preocuparte por autoescalado ni alta disponibilidad: AWS lo resuelve por ti [02:30].

¿Cómo se integra Route 53 con otros servicios de AWS?

Las integraciones nativas más comunes incluyen:

AWS CloudWatch para logs y monitoreo continuo de las resoluciones.
Healthchecks para evitar enrutar tráfico a instancias caídas.
API y consola web de AWS para administrar la configuración.
Conexión directa con EC2, Lambda, ELB y ALB.

Si el healthcheck pasa correctamente, la petición llega a la instancia o servicio configurado [03:45].

¿Qué políticas de enrutamiento ofrece Route 53?

Route 53 permite definir cómo se distribuye el tráfico de tus dominios hacia los servicios. Cada política responde a un caso de uso distinto.

¿Cuándo usar enrutamiento simple o failover?

La política simple es la predeterminada: resuelve un nombre de dominio a una IP de una instancia o servicio interno.

¿Qué política aplica para una arquitectura activo-pasiva multi-región? La política de failover con healthchecks, porque enruta al recurso principal mientras esté sano y conmuta al pasivo cuando deja de responder.

¿Cómo funcionan las políticas por geoproximidad y latencia?

La política de geoproximidad responde con un servidor distinto según la región del planeta donde se origina la petición. Por ejemplo:

Peticiones desde América responden desde Estados Unidos.
Peticiones desde Europa responden desde Londres.
Peticiones desde Asia responden desde Japón.

Esto reduce latencia y entrega respuestas localizadas.

¿Qué características avanzadas tiene Route 53?

Más allá de las políticas, Route 53 incorpora funcionalidades que potencian casos de uso específicos.

Entre las más útiles están:

Registros tipo alias, que conectan directamente con servicios nativos de AWS y son más rápidos que los tradicionales A, AAAA o CNAME.
Protocolo DNSSEC para reforzar la seguridad de las peticiones DNS.
Hosted zones públicas y privadas: las privadas solo resuelven dentro de tu VPC, las públicas responden a internet abierto.
Healthchecks configurables para mover tráfico cuando un recurso deja de responder.

¿Qué es un registro alias en Route 53? Es un tipo de registro propio de AWS que apunta directamente a servicios como ELB, CloudFront o S3, sin necesidad de resolver una IP intermedia.

Con estas piezas en mente, revisa los recursos de la clase, identifica las dos opciones que mejor resuelven el caso de nexiabank.com y déjalas en los comentarios para discutirlas.

Miguel Angel Reyes Moreno

Hace 10 meses

Las dos opciones correctas para configurar AWS Route 53 para una aplicación web activa/pasiva en varias regiones con Elastic Load Balancers (ELB) son:

a. Utilizar una política de enrutamiento de conmutación por error
d. Conectar los ELB mediante registros de alias

🛠️ Detalles de la Configuración

1. Política de Enrutamiento de Conmutación por Error (Failover)

El modelo de disponibilidad activo/pasivo (active/passive) se implementa con la política de enrutamiento de conmutación por error (Failover Routing Policy).

Se configura un conjunto de registros de recursos principal (Primary) para apuntar a la región activa (por ejemplo, el ELB en la Región A).
Se configura un conjunto de registros de recursos secundario (Secondary) para apuntar a la región pasiva (por ejemplo, el ELB en la Región B).
Route 53 dirige el tráfico al registro principal siempre que la comprobación de estado asociada (health check) sea satisfactoria.
Si la comprobación de estado del registro principal falla, Route 53 automáticamente conmuta el tráfico al registro secundario.

2. Conectar los ELB mediante Registros de Alias

Para apuntar el nombre de dominio raíz de su sitio web (nexiiabank.com) a un Elastic Load Balancer (ELB) en Route 53, debe utilizar un Registro de Alias (Alias Record).

Los registros de alias son una extensión de Route 53 de los registros A (Address records) tradicionales.
Permiten mapear un nombre de dominio (incluido el dominio raíz) directamente a recursos de AWS, como ELB, distribuciones de CloudFront o Buckets S3, y se benefician de las comprobaciones de estado.
Los registros CNAME (Canonical Name) no se pueden utilizar para el dominio raíz (zona apex o naked domain), solo para subdominios (por ejemplo, ). Además, los registros de alias en Route 53 son gratuitos y se integran mejor con las políticas de enrutamiento avanzadas como Failover.

❌ Opciones Incorrectas

b. Seleccionar "No" para evaluar la politica de health para el servidor principal: Esto es incorrecto. El éxito del enrutamiento de conmutación por error depende de que la comprobación de estado (health check) esté habilitada y sea evaluada. Si no se evalúa el estado del servidor principal, Route 53 no sabrá cuándo conmutar a la región secundaria.
c. Utilizar una política de enrutamiento ponderado (Weighted): Esta política se usa para distribuir el tráfico según pesos especificados (por ejemplo, 80% a Región A, 20% a Región B) o para pruebas A/B. No implementa un modelo estricto de activo/pasivo (es más adecuado para activo/activo).
e. Conectar los ELB mediante registros CNAME: Los CNAME no se pueden utilizar para el dominio raíz (nexiiabank.com) y los registros de alias son la práctica recomendada para apuntar a un ELB.

Fundamentos de AWS

Certificación AWS Solutions Architect Associate: Fundamentos y Preparación

Preparación para certificación AWS Arquitecto de Soluciones

Configuración de presupuestos en AWS para controlar costos

Los 6 pilares del Well-Architected Framework

Identidad, Acceso y Gobernanza Multicuenta

Cómo evitar brechas de seguridad con IAM

Creación de usuarios administrador y practicante en AWS IAM

Gestión de cuentas con AWS Organizations

Detecta recursos AWS expuestos con Access Analyzer

Cómo gestionar múltiples cuentas AWS

Servicios de Computo en AWS

Servicios de cómputo AWS: EC2, procesadores Graviton y AMIs

Compute Savings Plan para EC2 y Lambda

Cómo lanzar tu primera instancia EC2

Optimizar latencia en EC2 con tenencia dedicada

Cómo consultar metadatos de EC2 con IMDSv2

AWS Outposts: ejecutar AWS en tu data center

Despliegue de app web en Elastic Beanstalk

Contenedores en AWS

Contenedores en AWS: ECS, EKS y ECR

Gestión de imágenes de contenedores con ECR y Fargate

Configuración de clusters, tareas y servicios en Amazon ECS

Redes en AWS

Direccionamiento IP y bloques CIDR para redes AWS

NAT Gateway para subredes privadas en AWS

Configuración de instancias públicas y privadas con NAT Gateway

NACL y Security Groups en AWS

Cómo reparar un Security Group en EC2

Conectividad híbrida en AWS: VPC Peering, Transit Gateway y Endpoints

Escalamiento y balanceo en AWS

Tipos de balanceadores de carga en AWS

Configuración de balanceadores de carga en AWS para alta disponibilidad

Autoescalamiento en EC2 con Auto Scaling Groups

Cómo crear un Auto Scaling Group en EC2

Almacenamiento en AWS

Tipos de almacenamiento en AWS: EBS, EFS y S3

Instance Store vs EBS en AWS

EFS vs FSx para compartir archivos en AWS

Creación y configuración de volúmenes EBS en AWS

Transfer Acceleration para datos globales en S3

Configuración de EFS para compartir almacenamiento entre instancias

Recuperar objetos borrados en Amazon S3

Bases de datos en AWS

Bases de datos relacionales vs no relacionales en AWS

Cómo funciona DynamoDB en AWS

Creación y configuración de bases de datos Dynamo en AWS

Elasticache y DAX

RDS vs Aurora: réplicas y alta disponibilidad

Cómo configurar Aurora con alta disponibilidad en RDS

Migración en AWS

Estrategias de migración AWS: las 6 R para trasladar aplicaciones

Cómo migramos 500 TB a AWS sin downtime

Migración de datos con AWS Snow Family: opciones y características

DMS y SCT para migrar bases de datos en AWS

Monitoreo y Auditoria en AWS

CloudTrail y EventBridge en arquitecturas AWS

Monitoreo de AWS con CloudWatch

DNS y CDN en AWS

Zonas locales y de borde en AWS

CloudFront vs Global Accelerator en AWS

Failover en Route 53 para arquitectura activo-pasiva

Configuración de políticas de geoproximidad en AWS Route 53

Servicios de Seguridad

KMS vs CloudHSM para datos regulados

AWS Shield y WAF contra ataques DDoS

Servicios AWS para detectar vulnerabilidades

GuardDuty y Trusted Advisor para detectar amenazas en AWS

Serverless

API Gateway y Lambda en arquitecturas serverless

Creación y configuración de funciones Lambda para automatización

AWS SQS: Tipos de filas y configuración para arquitecturas serverless

AWS SNS y Step Functions para comunicación y workflows visuales

Servicios de Datos en AWS

Servicios de datos en AWS para tu examen

Kinesis, EMR, Glue

Casos de uso de Amazon Redshift en AWS

Servicios de AI y ML em AWS

Servicios de IA y ML en AWS

Servicios de Backup y Recuperación ante desastres