Route 53

Clase 55 de 72 • Curso de AWS Certified Solutions Architect Associate

Clase anteriorSiguiente clase

Route 53: Gestión de DNS y Estrategias de Enrutamiento en AWS

Durante una campaña nacional de Nexia Bank para el lanzamiento de su nueva cuenta digital con cashback, el tráfico en su plataforma digital se disparó inesperadamente: millones de usuarios intentaron ingresar al mismo tiempo para abrir cuentas y aprovechar la promoción.

Gracias a su arquitectura basada en Amazon Route 53, con políticas de enrutamiento por latencia y geolocalización, Nexia Bank pudo distribuir automáticamente las solicitudes de acceso entre múltiples regiones de AWS. Esta estrategia garantizó tiempos de respuesta óptimos y evitó caídas del servicio incluso durante el pico de tráfico más alto, asegurando una experiencia confiable para los nuevos clientes y manteniendo su reputación de banco digital ágil y robusto.

Fundamentos de Route 53

Amazon Route 53 es un servicio de Sistema de Nombres de Dominio (DNS) altamente disponible y escalable. Proporciona registro de dominios, resolución DNS y verificación de estado de recursos, todo integrado con la infraestructura de AWS.

Route 53 funciona como un sistema de traducción entre nombres de dominio fáciles de recordar (como ejemplo.com) y direcciones IP numéricas (como 192.0.2.1) que las computadoras utilizan para identificarse entre sí. Su arquitectura distribuida globalmente garantiza alta disponibilidad con un SLA del 100%.

Screenshot (52).png

Políticas de Enrutamiento DNS

Route 53 ofrece diversas políticas de enrutamiento que permiten controlar cómo se dirige el tráfico a los recursos:

1. Enrutamiento Simple

El enrutamiento simple es la política más básica, donde se asocia un nombre de dominio con un recurso específico.

{
  "ResourceRecordSets": [
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.1"
        }
      ]
    }
  ]
}

Casos de uso:

  • Sitios web con un solo servidor
  • Redirecciones simples
  • Entornos de desarrollo/prueba

2. Enrutamiento Ponderado (Weighted)

Permite distribuir el tráfico entre múltiples recursos en proporciones definidas.

{
  "ResourceRecordSets": [
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "Servidor1",
      "Weight": 70,
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.1"
        }
      ]
    },
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "Servidor2",
      "Weight": 30,
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.2"
        }
      ]
    }
  ]
}

Casos de uso:

  • Pruebas A/B
  • Despliegues canary (blue/green)
  • Distribución de carga entre regiones

3. Enrutamiento por Latencia

Dirige a los usuarios al recurso con menor latencia desde su ubicación.

{
  "ResourceRecordSets": [
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "us-east-1",
      "Region": "us-east-1",
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.1"
        }
      ]
    },
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "eu-west-1",
      "Region": "eu-west-1",
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.2"
        }
      ]
    }
  ]
}

Casos de uso:

  • Aplicaciones globales sensibles a la latencia
  • Juegos en línea
  • Streaming de contenido

4. Enrutamiento por Geolocalización

Dirige el tráfico basado en la ubicación geográfica de los usuarios.

{
  "ResourceRecordSets": [
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "Europa",
      "GeoLocation": {
        "ContinentCode": "EU"
      },
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.1"
        }
      ]
    },
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "México",
      "GeoLocation": {
        "CountryCode": "MX"
      },
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.2"
        }
      ]
    }
  ]
}

Casos de uso:

  • Cumplimiento de requisitos regulatorios regionales
  • Distribución de contenido localizado
  • Restricción geográfica de servicios

5. Enrutamiento por Failover

Permite configurar respaldos para recuperación de desastres, redirigiendo automáticamente a un recurso secundario cuando el primario no está disponible.

{
  "ResourceRecordSets": [
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "Primario",
      "Failover": "PRIMARY",
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.1"
        }
      ],
      "HealthCheckId": "abcdef11-2222-3333-4444-555555fedcba"
    },
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "SetIdentifier": "Secundario",
      "Failover": "SECONDARY",
      "TTL": 300,
      "ResourceRecords": [
        {
          "Value": "192.0.2.2"
        }
      ]
    }
  ]
}

Casos de uso:

  • Recuperación de desastres (DR)
  • Alta disponibilidad entre regiones
  • Mantenimiento con cero tiempo de inactividad

Políticas Adicionales

  • Enrutamiento basado en IP: Dirige el tráfico basado en la dirección IP de origen
  • Enrutamiento de respuesta con valores múltiples: Devuelve múltiples valores (como direcciones IP) en respuesta a consultas DNS
  • Enrutamiento de geoproximidad: Dirige el tráfico basado en la ubicación geográfica de los recursos y opcionalmente en un valor de bias

Health Checks y Failover

Los health checks de Route 53 monitorean la disponibilidad y el rendimiento de los recursos, permitiendo la implementación de estrategias de failover automático.

Tipos de Health Checks

  1. Endpoint HTTP/HTTPS/TCP: Verifica la disponibilidad de un servidor web o aplicación
  2. Monitoreo de otras comprobaciones: Combina resultados de múltiples health checks
  3. Estado de alarmas de CloudWatch: Utiliza métricas de CloudWatch para determinar el estado
# Ejemplo de configuración de Health Check en CloudFormation
Resources:
  MyHealthCheck:
    Type: AWS::Route53::HealthCheck
    Properties:
      HealthCheckConfig:
        Port: 80
        Type: HTTP
        ResourcePath: /health
        FullyQualifiedDomainName: example.com
        RequestInterval: 30
        FailureThreshold: 3
      HealthCheckTags:
        - Key: Name
          Value: WebServerHealthCheck

Configuración de Failover

El enrutamiento por failover utiliza health checks para dirigir automáticamente el tráfico al recurso secundario cuando el primario falla:

  1. Se configura un health check para el recurso primario
  2. Se crean dos registros DNS con el mismo nombre pero diferentes destinos
  3. El registro primario se asocia con el health check
  4. Cuando el health check falla, Route 53 responde con el registro secundario

Este mecanismo es fundamental para implementar estrategias de recuperación de desastres (DR) y alta disponibilidad.

Gestión de Dominios con Route 53

Route 53 funciona como registrador de dominios, permitiendo registrar nuevos dominios o transferir dominios existentes.

Proceso de Registro de Dominio

  1. Verificación de disponibilidad del dominio
  2. Proporción de información de contacto
  3. Pago de la tarifa de registro
  4. Configuración automática de servidores de nombres

Integración con Dominios Existentes

Para dominios registrados con otros proveedores, existen dos opciones:

  1. Transferencia completa: Mover el registro del dominio a Route 53
  2. Uso parcial: Mantener el registro con el proveedor actual pero usar Route 53 como servicio DNS
# Ejemplo de configuración de servidores de nombres para un dominio existente
# (Estos valores se configurarían en el panel del registrador actual)
ns-1234.awsdns-12.org
ns-567.awsdns-34.com
ns-890.awsdns-56.net
ns-1234.awsdns-78.co.uk

Alias vs. CNAME

Route 53 ofrece registros Alias, que son una alternativa mejorada a los registros CNAME tradicionales para recursos de AWS.

Diferencias Clave

CaracterísticaAliasCNAME
Puede crearse en el apex del dominio (zona raíz)SíNo
CostoSin costo adicionalSe cobra por consulta
ResoluciónAWS resuelve automáticamente a la IP actualRequiere una resolución DNS adicional
Compatibilidad con servicios AWSIntegración nativaLimitada

Servicios AWS compatibles con Alias

  • Elastic Load Balancers (ALB, NLB, CLB)
  • CloudFront distributions
  • API Gateway
  • Elastic Beanstalk environments
  • S3 websites
  • VPC endpoints
  • Global Accelerator
// Ejemplo de registro Alias para un ALB
{
  "ResourceRecordSets": [
    {
      "Name": "www.ejemplo.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z2P70J7EXAMPLE",
        "DNSName": "my-load-balancer-1234567890.us-east-1.elb.amazonaws.com",
        "EvaluateTargetHealth": true
      }
    }
  ]
}

Route 53 en Arquitecturas de Alta Disponibilidad y DR

Route 53 juega un papel crucial en la implementación de estrategias de alta disponibilidad y recuperación de desastres.

Arquitectura Multi-región

                    ┌─────────────────┐
                    │    Route 53     │
                    └────────┬────────┘
                             │
           ┌─────────────────┴─────────────────┐
           ▼                                   ▼
┌─────────────────────┐             ┌─────────────────────┐
│  Región Primaria    │             │  Región Secundaria  │
│  (us-east-1)        │             │  (us-west-2)        │
│                     │             │                     │
│  ┌───────────────┐  │             │  ┌───────────────┐  │
│  │      ALB      │  │             │  │      ALB      │  │
│  └───────┬───────┘  │             │  └───────┬───────┘  │
│          │          │             │          │          │
│  ┌───────┴───────┐  │             │  ┌───────┴───────┐  │
│  │   EC2/ECS/    │  │             │  │   EC2/ECS/    │  │
│  │   Lambda      │  │             │  │   Lambda      │  │
│  └───────┬───────┘  │             │  └───────┬───────┘  │
│          │          │             │          │          │
│  ┌───────┴───────┐  │             │  ┌───────┴───────┐  │
│  │  Base de      │  │◄──Replica──►│  │  Base de      │  │
│  │  Datos        │  │             │  │  Datos        │  │
│  └───────────────┘  │             │  └───────────────┘  │
└─────────────────────┘             └─────────────────────┘

Estrategias de Implementación

1. Activo/Pasivo (Failover)

  • Región primaria maneja todo el tráfico
  • Región secundaria en espera
  • Route 53 detecta fallos y redirige automáticamente
# Ejemplo de configuración de política de failover
Resources:
  PrimaryRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: Z1PA6795EXAMPLE
      Name: api.ejemplo.com
      Type: A
      SetIdentifier: Primary
      Failover: PRIMARY
      AliasTarget:
        HostedZoneId: Z32O12XQLNTSW2
        DNSName: primary-alb.us-east-1.elb.amazonaws.com
        EvaluateTargetHealth: true
      HealthCheckId: !Ref PrimaryHealthCheck

  SecondaryRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: Z1PA6795EXAMPLE
      Name: api.ejemplo.com
      Type: A
      SetIdentifier: Secondary
      Failover: SECONDARY
      AliasTarget:
        HostedZoneId: Z32O12XQLNTSW2
        DNSName: secondary-alb.us-west-2.elb.amazonaws.com
        EvaluateTargetHealth: true

2. Activo/Activo (Weighted o Latency)

  • Múltiples regiones manejan tráfico simultáneamente
  • Distribución basada en pesos o latencia
  • Mayor utilización de recursos y mejor rendimiento
# Ejemplo de configuración de política por latencia
Resources:
  USEastRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: Z1PA6795EXAMPLE
      Name: api.ejemplo.com
      Type: A
      SetIdentifier: USEast
      Region: us-east-1
      AliasTarget:
        HostedZoneId: Z32O12XQLNTSW2
        DNSName: us-east-alb.us-east-1.elb.amazonaws.com
        EvaluateTargetHealth: true

  EUWestRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: Z1PA6795EXAMPLE
      Name: api.ejemplo.com
      Type: A
      SetIdentifier: EUWest
      Region: eu-west-1
      AliasTarget:
        HostedZoneId: Z32O12XQLNTSW2
        DNSName: eu-west-alb.eu-west-1.elb.amazonaws.com
        EvaluateTargetHealth: true

3. Estrategia Híbrida

  • Combinación de políticas de enrutamiento
  • Por ejemplo: geolocalización para cumplimiento normativo + latencia para rendimiento
  • Implementación mediante políticas de enrutamiento anidadas

Consideraciones para DR

  1. RPO (Recovery Point Objective): Determina la estrategia de replicación de datos
  2. RTO (Recovery Time Objective): Influye en la configuración de health checks y TTL
  3. Costos: Balance entre disponibilidad y costos de infraestructura redundante
  4. Complejidad operativa: Automatización de failover y failback

Buenas Prácticas

  1. TTL apropiados: Valores más bajos permiten cambios más rápidos pero aumentan la carga en Route 53

    # Recomendaciones de TTL
Registros críticos para failover: 60 segundos o menos
Registros estándar: 300-3600 segundos
Registros que cambian raramente: 86400 segundos (1 día)

  2. Monitoreo y alertas: Configurar alarmas para health checks

    # Ejemplo de alarma CloudWatch para health check
Resources:
  HealthCheckAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: HealthCheckFailureAlarm
      AlarmDescription: Alarm if health check fails
      MetricName: HealthCheckStatus
      Namespace: AWS/Route53
      Statistic: Minimum
      Period: 60
      EvaluationPeriods: 1
      Threshold: 1
      ComparisonOperator: LessThanThreshold
      Dimensions:
        - Name: HealthCheckId
          Value: !Ref MyHealthCheck
      AlarmActions:
        - !Ref SNSTopic

  3. Pruebas regulares: Simular fallos para verificar que las políticas de failover funcionan correctamente

  4. Documentación: Mantener diagramas actualizados de la arquitectura DNS y políticas de enrutamiento

  5. Seguridad: Utilizar DNSSEC para proteger contra ataques de envenenamiento de caché DNS

Route 53 es mucho más que un simple servicio DNS; es una pieza fundamental en la arquitectura de aplicaciones modernas en AWS. Su capacidad para implementar estrategias sofisticadas de enrutamiento, combinada con health checks robustos, lo convierte en una herramienta esencial para construir sistemas altamente disponibles y resilientes. Al aprovechar las políticas de enrutamiento adecuadas y la integración nativa con otros servicios de AWS, podemos crear arquitecturas que no solo sean resistentes a fallos, sino que también ofrezcan un rendimiento óptimo a usuarios en cualquier parte del mundo.