Route 53 Alias vs CNAME: Cuándo usar cada uno y por qué el Alias es obligatorio en el apex de zona

Estás configurando tu dominio raíz example.com para que apunte a un Application Load Balancer y Route 53 te ofrece dos opciones: CNAME o Alias. Si eliges CNAME, el registro simplemente no funcionará en el apex de zona — y Route 53 ni siquiera te lo permite. Este es uno de esos casos donde la restricción del DNS estándar obliga a usar una funcionalidad específica de AWS, y entender el porqué evita horas de depuración.

TL;DR: Alias vs CNAME en Route 53

Característica CNAME Alias (Route 53)
Funciona en apex de zona (example.com) ❌ No permitido por RFC ✅ Sí
Funciona en subdominios (www.example.com) ✅ Sí ✅ Sí
Coste de consultas DNS Se cobra por query Sin coste adicional para destinos AWS
Responde con IPs del destino No (devuelve el nombre) Sí (resolución directa)
Health check integrado No Sí (hereda el health del destino)
Destinos soportados Cualquier hostname Solo recursos AWS específicos

Cómo funciona el DNS en el apex de zona — la raíz del problema con CNAME

El apex de zona (también llamado 'zone apex' o 'naked domain') es el nombre de dominio sin prefijo: example.com. El RFC 1034 define que en el apex de zona deben existir registros SOA y NS. La restricción crítica es que un registro CNAME no puede coexistir con ningún otro tipo de registro en el mismo nombre. Como el apex siempre tiene SOA y NS, un CNAME en example.com violaría el estándar DNS — por eso los servidores DNS conformes al RFC lo prohíben.

Route 53 resuelve esto con los registros Alias, que son una extensión propietaria de AWS al protocolo DNS. Desde la perspectiva del cliente DNS, un registro Alias se comporta como un registro A o AAAA: devuelve directamente las direcciones IP del recurso destino. La resolución del nombre del ALB ocurre dentro de la infraestructura de Route 53, no en el cliente.

graph TD subgraph CNAME_Flow ["Flujo CNAME — www.example.com"] C1["Cliente DNS"] -->|"1. Query: www.example.com"| C2["Route 53"] C2 -->|"2. Respuesta: CNAME → alb.us-east-1.elb.amazonaws.com"| C1 C1 -->|"3. Segunda query: alb.us-east-1.elb.amazonaws.com"| C3["Resolver externo"] C3 -->|"4. Respuesta: IPs del ALB"| C1 end subgraph Alias_Flow ["Flujo Alias — example.com"] A1["Cliente DNS"] -->|"1. Query: example.com"| A2["Route 53"] A2 -->|"Resolución interna del ALB"| A3["ALB DNS interno"] A3 -->|"IPs actuales"| A2 A2 -->|"2. Respuesta directa: IPs del ALB"| A1 end subgraph Blocked ["CNAME en Apex — BLOQUEADO"] B1["example.com"] -->|"SOA + NS ya existen"| B2["❌ CNAME no permitido
Viola RFC 1034"] end
  1. CNAME en subdominio: El cliente recibe el hostname del ALB y debe hacer una segunda consulta DNS para resolver las IPs. Dos round-trips.
  2. Alias en apex: Route 53 resuelve internamente el hostname del ALB y devuelve las IPs directamente al cliente. Un solo round-trip, sin violar el RFC.
  3. CNAME en apex: Bloqueado. Route 53 no permite crear este registro.

Cuándo usar Alias vs CNAME — guía de decisión

graph TD Start(["¿Qué tipo de registro necesito?"]) Start --> Q1{"¿Es el apex de zona?
ej: example.com sin prefijo"} Q1 -->|"Sí"| Q2{"¿El destino es un
recurso AWS soportado?"} Q1 -->|"No — es subdominio
ej: www.example.com"| Q3{"¿El destino es un
recurso AWS soportado?"} Q2 -->|"Sí"| R1["✅ Usa registro ALIAS
Obligatorio en apex"] Q2 -->|"No — destino externo"| R2["⚠️ Problema arquitectural
CNAME no válido en apex
Revisar diseño DNS"] Q3 -->|"Sí — ALB, CloudFront, etc."| R3["✅ Usa registro ALIAS
Recomendado: IPs auto-actualizadas
y health check integrado"] Q3 -->|"No — servicio externo"| R4["✅ Usa CNAME
Configura TTL apropiado"]

Configurar un registro Alias hacia un ALB en Route 53

Cuando creas un registro Alias, necesitas el nombre DNS del ALB y su Hosted Zone ID. Estos dos valores son distintos: el nombre DNS es el hostname del balanceador, y el Hosted Zone ID es el identificador de la zona hospedada de Route 53 del ALB — no el de tu zona hospedada. AWS publica estos Hosted Zone IDs por región en su documentación oficial.

Con la CLI, crear el registro Alias en el apex de zona se hace mediante un change-resource-record-sets con un bloque AliasTarget:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-alb-1234567890.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

El campo HostedZoneId dentro de AliasTarget corresponde al Hosted Zone ID del ALB en la región donde está desplegado, no al ID de tu zona hospedada. El valor Z35SXDOTRQ7X7K del ejemplo es el Hosted Zone ID documentado por AWS para ALBs en us-east-1 — verifica siempre el valor correcto para tu región en la documentación oficial de Route 53.

Para obtener el nombre DNS y el Hosted Zone ID de tu ALB directamente:

aws elbv2 describe-load-balancers \
  --names my-alb \
  --query 'LoadBalancers[0].{DNSName:DNSName,CanonicalHostedZoneId:CanonicalHostedZoneId}' \
  --output table

El campo CanonicalHostedZoneId de la respuesta es exactamente el valor que necesitas en AliasTarget.HostedZoneId.

EvaluateTargetHealth: el parámetro que la mayoría ignora

El campo EvaluateTargetHealth en el bloque AliasTarget controla si Route 53 evalúa el estado de salud del recurso destino antes de responder consultas DNS. Cuando se establece en true, Route 53 deja de devolver el registro si el destino está marcado como no saludable.

Esto es especialmente relevante en configuraciones de failover: si tienes un registro Alias primario apuntando a un ALB y un registro secundario de respaldo, EvaluateTargetHealth: true es lo que activa el failover automático. Sin él, Route 53 sigue respondiendo con las IPs del ALB aunque todos sus targets estén caídos.

Piensa en EvaluateTargetHealth como el interruptor que conecta la inteligencia de Route 53 con el estado real de tu infraestructura. Sin él, el DNS no sabe que el ALB está caído — solo sabe que existe.

Verifica el estado actual de un registro con health check habilitado:

aws route53 list-resource-record-sets \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --query "ResourceRecordSets[?Name=='example.com.']" \
  --output json

Configurar un registro CNAME para subdominios

Para subdominios como www.example.com, un CNAME es perfectamente válido y en algunos casos preferible si el destino no es un recurso AWS — por ejemplo, un servicio SaaS externo. La sintaxis es más directa:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "www.example.com",
          "Type": "CNAME",
          "TTL": 300,
          "ResourceRecords": [
            {
              "Value": "my-alb-1234567890.us-east-1.elb.amazonaws.com"
            }
          ]
        }
      }
    ]
  }'

A diferencia del Alias, el CNAME tiene un TTL configurable que controla cuánto tiempo los resolvers cachean la respuesta. Los registros Alias no tienen TTL configurable — Route 53 gestiona el TTL internamente basándose en el recurso destino.

El error que todos cometen al migrar de CNAME a Alias

Escenario real: tienes www.example.com apuntando al ALB con un CNAME y decides mover también el apex example.com. Creas el registro Alias en el apex, verificas que resuelve, y asumes que todo está correcto. Tres días después empiezan a llegar reportes de usuarios que no pueden acceder.

El problema no estaba en el Alias — estaba en que el registro CNAME de www seguía activo con un TTL de 3600 segundos, y algunos resolvers tenían cacheado un hostname del ALB que AWS había reemplazado durante un evento de mantenimiento. El CNAME apuntaba al hostname correcto, pero el hostname ya no resolvía a IPs activas.

Con un registro Alias, esto no habría ocurrido: Route 53 actualiza la resolución interna automáticamente cuando AWS cambia las IPs del ALB. El CNAME delega esa responsabilidad al resolver del cliente, que puede tener una entrada obsoleta en caché.

La lección operacional: cuando migras de CNAME a Alias para subdominios que apuntan a recursos AWS, reduce el TTL del CNAME a 60 segundos al menos 24 horas antes de hacer el cambio. Así el tiempo de propagación es predecible.

Destinos soportados por registros Alias en Route 53

Los registros Alias solo funcionan con un conjunto específico de recursos AWS. No puedes usar un Alias para apuntar a un servidor externo o a un hostname arbitrario. Los destinos documentados incluyen:

  • Application Load Balancers, Network Load Balancers y Classic Load Balancers
  • Distribuciones de CloudFront
  • Entornos de Elastic Beanstalk
  • Buckets de S3 configurados como sitios web estáticos
  • Aceleradores de AWS Global Accelerator
  • Registros de la misma zona hospedada de Route 53
  • Endpoints de Amazon API Gateway
  • Endpoints de Amazon VPC Interface

Si tu destino no está en esta lista, CNAME es tu única opción — y si necesitas usarlo en el apex de zona con un servicio externo, tendrás que reevaluar tu arquitectura DNS.

IAM: permisos necesarios para gestionar registros Route 53

Para crear o modificar registros en Route 53 desde CLI o código, la identidad IAM necesita al menos estos permisos:

🔽 Ver política IAM mínima para gestión de registros Route 53 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets",
        "route53:GetHostedZone"
      ],
      "Resource": "arn:aws:route53:::hostedzone/Z1PA6795UKMFR9"
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:GetChange"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "elasticloadbalancing:DescribeLoadBalancers"
      ],
      "Resource": "*"
    }
  ]
}

Las acciones ListHostedZones y GetChange requieren Resource: * porque no admiten restricción a nivel de recurso específico según la Service Authorization Reference de AWS. Verifica siempre los permisos actuales en esa referencia antes de aplicar restricciones de ARN.

Verificar la resolución DNS del registro Alias

Una vez creado el registro, verifica que resuelve correctamente usando dig o nslookup. Un registro Alias bien configurado devuelve directamente registros A con las IPs del ALB, no un CNAME intermedio:

dig example.com A +short

Si ves una respuesta con IPs directamente (sin un CNAME en la cadena de resolución), el Alias está funcionando correctamente. Si ves un CNAME en la respuesta, probablemente creaste un registro CNAME en lugar de un Alias, o hay un registro conflictivo en la zona.

Para confirmar el estado del cambio en Route 53 (los cambios son asíncronos y pasan por estados PENDING → INSYNC):

aws route53 get-change \
  --id /change/C2682N5HXP0BZ4

Reemplaza el ID con el valor Id devuelto por change-resource-record-sets. El registro está activo cuando el estado es INSYNC.

Conclusión y próximos pasos con Route 53 Alias

El registro Alias de Route 53 no es solo una alternativa al CNAME — es la única opción válida para apuntar el apex de zona a un ALB, CloudFront u otros recursos AWS. Para subdominios que apuntan a recursos AWS, el Alias también es preferible por la resolución automática de IPs y la integración con health checks.

Pasos recomendados:

  • Audita tus zonas hospedadas existentes: aws route53 list-resource-record-sets --hosted-zone-id <ID> y busca CNAMEs apuntando a hostnames *.elb.amazonaws.com o *.cloudfront.net — son candidatos a migrar a Alias.
  • Habilita EvaluateTargetHealth: true en todos los registros Alias que participen en configuraciones de failover.
  • Consulta la documentación oficial de Route 53 para la lista actualizada de Hosted Zone IDs por región para ALBs y otros recursos.
  • Revisa la documentación de políticas de enrutamiento de Route 53 si necesitas combinar Alias con Weighted, Latency o Failover routing.

Glosario de términos clave

Término Definición
Apex de zona El nombre de dominio raíz sin prefijo (ej: example.com). Siempre contiene registros SOA y NS por definición del RFC.
Registro Alias Extensión propietaria de Route 53 que se comporta como un registro A/AAAA pero resuelve internamente el hostname de un recurso AWS destino.
CNAME Registro DNS estándar que mapea un nombre a otro nombre. No puede coexistir con otros registros en el mismo nombre, lo que lo hace incompatible con el apex de zona.
EvaluateTargetHealth Parámetro del bloque AliasTarget que indica a Route 53 si debe considerar el estado de salud del recurso destino al responder consultas DNS.
Hosted Zone ID (ALB) Identificador de la zona hospedada de Route 53 asociada al ALB, específico por región. Distinto al Hosted Zone ID de tu propia zona hospedada.

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más