Route 53 Alias vs CNAME: Qual Usar para Apontar seu Domínio para um ALB?

Você acabou de provisionar um Application Load Balancer e precisa apontar example.com para ele. A primeira tentativa natural é criar um registro CNAME — e aí você descobre que o console do Route 53 simplesmente não deixa. Não é bug, não é permissão faltando: é uma limitação fundamental do protocolo DNS que existe desde 1987, e o registro Alias do Route 53 foi criado especificamente para contorná-la.

TL;DR — Alias vs CNAME no Route 53

Característica CNAME Alias (Route 53)
Funciona no zone apex (example.com) ❌ Não ✅ Sim
Aponta para ALB, CloudFront, S3 ✅ Sim (subdomínios) ✅ Sim (qualquer nível)
Cobrança por consulta DNS Sim Gratuito para destinos AWS suportados
Retorna endereço IP diretamente Não — retorna outro nome Sim — resolve para A/AAAA
Health check integrado Não nativo Sim, via Route 53 health checks
Padrão DNS (RFC) Sim (RFC 1034) Não — extensão proprietária AWS

Como o DNS Funciona na Prática — e Por Que o CNAME Falha no Apex

O RFC 1034 define que um registro CNAME não pode coexistir com nenhum outro registro no mesmo nome. O zone apex (example.com) sempre precisa ter registros SOA e NS. Logo, um CNAME no apex viola a especificação — qualquer servidor DNS autoritativo recusará essa configuração.

Isso não é uma limitação do Route 53. É uma restrição do protocolo. Tentar criar um CNAME para example.com apontando para um ALB é como tentar colocar dois inquilinos no mesmo apartamento com contratos exclusivos: o cartório não vai registrar.

Pense no zone apex como o endereço-sede de uma empresa. Ele já tem registros obrigatórios (SOA, NS) que não podem ser deslocados. O Alias é uma extensão que permite 'redirecionar' sem violar esses contratos preexistentes.

O registro Alias é uma extensão proprietária do Route 53. Externamente, ele se comporta como um registro A ou AAAA — o resolver recebe IPs diretamente. Internamente, o Route 53 resolve o nome de destino (ex: o DNS name do ALB) e retorna os IPs correspondentes, atualizando automaticamente quando o ALB escala ou troca de IPs.

graph TD Client["Cliente DNS"] R53["Route 53"] ALB_DNS["DNS Name do ALB
(gerenciado pela AWS)"] IP["IP do ALB"] APEX["example.com
(Zone Apex)"] SUB["www.example.com
(Subdomínio)"] subgraph Alias_Apex["Alias no Apex — Permitido"] APEX -->|"Alias Record (tipo A)"| R53 R53 -->|"Resolve internamente"| ALB_DNS ALB_DNS -->|"Retorna IP"| IP end subgraph CNAME_Sub["CNAME no Subdomínio — Permitido"] SUB -->|"CNAME"| ALB_DNS ALB_DNS -->|"Segunda consulta"| IP end subgraph CNAME_Apex["CNAME no Apex — Bloqueado"] APEX2["example.com"] -->|"❌ RFC 1034 proíbe"| BLOCKED["ERRO: CNAME não pode
coexistir com SOA/NS"] end
  1. CNAME no subdomínio: o resolver recebe outro nome (ex: o DNS name do ALB) e precisa fazer uma segunda consulta para obter o IP. Funciona, mas adiciona uma resolução extra.
  2. Alias no apex: o Route 53 resolve internamente e retorna o IP diretamente ao cliente — sem round-trip adicional visível externamente.
  3. CNAME no apex: bloqueado pelo protocolo DNS. O Route 53 não permite criar esse registro.

Alias Records no Route 53 — Destinos Suportados

O registro Alias não funciona para qualquer destino. Ele é suportado apenas para recursos AWS específicos. Antes de configurar, verifique se o destino está na lista oficial:

  • Application Load Balancer, Network Load Balancer, Classic Load Balancer
  • Distribuições CloudFront
  • Endpoints do API Gateway (Regional e Edge-Optimized)
  • Buckets S3 configurados para website hosting
  • Ambientes Elastic Beanstalk
  • Aceleradores AWS Global Accelerator
  • Outros registros Route 53 na mesma hosted zone

Você não pode usar um Alias para apontar para um servidor externo, um IP on-premises, ou um nome DNS fora do ecossistema AWS listado acima. Para esses casos, CNAME (em subdomínios) ou registro A com IP fixo são as únicas opções.

Configurando um Alias Record para ALB via AWS CLI

O fluxo exige dois dados do ALB: o DNS name e o Hosted Zone ID do load balancer (diferente do Hosted Zone ID da sua zona Route 53). Esses valores estão disponíveis via CLI:

# Obtém o DNS name e o CanonicalHostedZoneId do ALB
aws elbv2 describe-load-balancers \
  --names meu-alb \
  --query 'LoadBalancers[0].{DNSName:DNSName,CanonicalHostedZoneId:CanonicalHostedZoneId}' \
  --output json

Com esses valores em mãos, crie o registro Alias. O campo HostedZoneId dentro de AliasTarget é o Hosted Zone ID do ALB — não o da sua zona DNS:

# Substitua os valores pelos seus dados reais
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "meu-alb-123456789.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

O valor Z35SXDOTRQ7X7K no exemplo acima é o Hosted Zone ID para ALBs na região us-east-1. Cada serviço AWS e cada região têm seu próprio Hosted Zone ID — sempre use o valor retornado pelo comando describe-load-balancers para garantir precisão.

EvaluateTargetHealth — O Detalhe que Muda o Comportamento de Failover

Quando EvaluateTargetHealth está definido como true, o Route 53 considera o estado de saúde do destino ao responder consultas DNS. Se o ALB estiver com todos os targets unhealthy, o Route 53 pode parar de retornar aquele registro — dependendo da configuração de roteamento da sua hosted zone.

O comportamento exato depende de como os registros estão configurados (failover, weighted, latency-based). Com um único registro Alias sem política de roteamento, o Route 53 retorna SERVFAIL se o target estiver unhealthy e EvaluateTargetHealth estiver ativo. Isso pode parecer uma falha DNS para o cliente, mas é o comportamento esperado — o Route 53 está recusando resolver para um endpoint que sabe estar fora do ar.

Se você tem apenas um ALB e não tem um failover configurado, avalie se EvaluateTargetHealth: false faz mais sentido operacionalmente — o DNS vai resolver normalmente e o ALB retornará os erros HTTP diretamente ao cliente, o que pode ser mais fácil de debugar.

graph LR Query["Consulta DNS
example.com"] R53["Route 53"] EvalTrue{"EvaluateTargetHealth
= true?"} HealthCheck["Verifica saúde
do ALB"] Healthy{"ALB
saudável?"} ReturnIP["Retorna IPs do ALB"] ServFail["Retorna SERVFAIL"] EvalFalse["Retorna IPs
sem verificar saúde"] Query --> R53 R53 --> EvalTrue EvalTrue -->|"Sim"| HealthCheck EvalTrue -->|"Não"| EvalFalse HealthCheck --> Healthy Healthy -->|"Sim"| ReturnIP Healthy -->|"Não"| ServFail
  1. EvaluateTargetHealth: true + ALB saudável: Route 53 resolve normalmente, cliente recebe IPs do ALB.
  2. EvaluateTargetHealth: true + ALB unhealthy: Route 53 retorna SERVFAIL — o DNS em si falha, não o HTTP.
  3. EvaluateTargetHealth: false: Route 53 sempre resolve, independente do estado do ALB. Erros chegam como HTTP 5xx.

Diagnóstico: Por Que Meu Alias Record Não Está Resolvendo?

Esse é o cenário clássico: você criou o registro Alias, o console mostra tudo verde, mas dig example.com retorna NXDOMAIN ou SERVFAIL. Antes de abrir ticket no suporte, percorra esses pontos.

1. Confirme que o registro foi criado corretamente

O console às vezes demora para refletir o estado real. Use a CLI para verificar diretamente o que está na hosted zone — isso elimina qualquer ambiguidade de cache de UI:

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

Confirme que o campo AliasTarget.DNSName está correto e que o tipo é A (ou AAAA para IPv6).

2. Verifique se o CanonicalHostedZoneId do ALB está correto

Usar o Hosted Zone ID errado no AliasTarget é a causa mais comum de falha silenciosa. O Route 53 aceita o registro sem erro, mas a resolução falha. O ID correto vem do próprio recurso:

aws elbv2 describe-load-balancers \
  --names meu-alb \
  --query 'LoadBalancers[0].CanonicalHostedZoneId' \
  --output text

3. Teste a resolução DNS diretamente nos name servers autoritativos

Caches de resolvers intermediários podem mascarar o estado real. Consulte diretamente os name servers da sua hosted zone para ver o que o Route 53 está servindo agora:

# Primeiro, obtenha os name servers da sua hosted zone
aws route53 get-hosted-zone \
  --id Z0123456789ABCDEFGHIJ \
  --query 'DelegationSet.NameServers' \
  --output text

# Depois, consulte diretamente um deles
dig @ns-123.awsdns-45.com example.com A

4. Verifique o estado de saúde se EvaluateTargetHealth estiver ativo

Se o registro foi criado com EvaluateTargetHealth: true e o ALB está com targets unhealthy, o Route 53 vai retornar SERVFAIL intencionalmente. Isso não é um problema de configuração DNS — é o health check funcionando. Verifique o estado dos targets:

aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/meu-tg/1234567890abcdef

Alias vs CNAME — Quando Cada Um Faz Sentido

A resposta curta: use Alias sempre que o destino for um recurso AWS suportado. A resposta longa envolve alguns casos onde CNAME ainda é a única opção.

Se você precisa apontar api.example.com para um serviço externo (não AWS), um CDN de terceiro, ou qualquer nome DNS fora da lista de destinos Alias, o CNAME é o caminho. Nesse caso, você perde a resolução direta para IP e paga por cada consulta DNS, mas não há alternativa dentro do protocolo padrão.

Para subdomínios apontando para recursos AWS, Alias e CNAME funcionam — mas Alias é preferível por três razões concretas: sem custo por consulta para destinos suportados, resolução em um único round-trip, e integração com health checks do Route 53.

Próximos Passos e Documentação Oficial

Se você está configurando roteamento de tráfego com múltiplos ALBs ou regiões, os registros Alias são a base para políticas de roteamento avançadas no Route 53 — latency-based routing, weighted routing, e failover ativo-passivo. Todos dependem de Alias records para funcionar corretamente com recursos AWS.

Glossário — Termos Essenciais

Termo Definição
Zone Apex O domínio raiz de uma zona DNS (ex: example.com), sem subdomínio. Também chamado de 'naked domain' ou 'root domain'.
CNAME (Canonical Name) Registro DNS padrão (RFC 1034) que mapeia um nome para outro nome. Não pode coexistir com outros registros no mesmo nome.
Alias Record Extensão proprietária do Route 53 que funciona como um registro A/AAAA, mas aponta para um nome DNS de recurso AWS. Resolve internamente sem expor o CNAME ao cliente.
CanonicalHostedZoneId Hosted Zone ID associado ao recurso AWS de destino (ex: ALB). Diferente do Hosted Zone ID da sua zona DNS privada ou pública.
EvaluateTargetHealth Parâmetro do Alias record que instrui o Route 53 a considerar o estado de saúde do recurso de destino ao responder consultas DNS.

Comentários

Postar um comentário

Postagens mais visitadas deste blog

EC2 SSH Connection Timeout: Quais Regras do Security Group Verificar

Você acabou de lançar uma instância EC2, tenta conectar via SSH e recebe ssh: connect to host X.X.X.X port 22: Connection timed out . Esse erro específico — timeout, não recusa — quase sempre aponta para bloqueio de rede antes mesmo do pacote chegar ao sistema operacional. O culpado mais comum é o Security Group, mas não é o único. TL;DR — EC2 SSH Connection Timeout: O Que Verificar Camada O Que Verificar Impacto se Errado Security Group Regra inbound TCP/22 com source correto Pacote descartado silenciosamente Network ACL Regra allow na porta 22 e portas efêmeras no outbound Timeout sem log de erro Rota da Subnet Internet Gateway associado à route table Pacote sem caminho de retorno IP Público / EIP Instância tem endereço IP público atribuído Destino inalcançável Firewall do SO iptables / firewalld bloqueando porta 22 Conexão recusada ou timeout Como o Tráfego SSH Chega à Instância EC2 Antes d...
Leia mais

EC2 Sem Acesso à Internet em VPC Customizada: Como Configurar Internet Gateway e Route Table

Você criou uma VPC do zero, subiu uma instância EC2 em uma subnet pública e tentou um simples ping google.com — sem resposta. Esse é um dos problemas mais comuns ao trabalhar com VPCs customizadas no AWS, e a causa quase sempre está na ausência de um Internet Gateway associado ou em uma Route Table que não sabe para onde mandar o tráfego de saída. TL;DR — EC2 Sem Acesso à Internet em VPC Customizada Componente O que precisa estar configurado Internet Gateway (IGW) Criado e anexado à VPC Route Table Rota 0.0.0.0/0 apontando para o IGW Subnet Associada à Route Table com a rota para o IGW IP Público Instância com Elastic IP ou auto-assign de IP público habilitado Security Group Regra de saída permitindo o tráfego desejado Network ACL Regras de entrada e saída permitindo o tráfego (stateless) Como o Roteamento de Internet Funciona em uma VPC Customizada Quando a AWS cria a VPC padrão da su...
Leia mais

S3 Access Denied: Por que 'Bloquear Acesso Público' impede seu objeto mesmo após torná-lo público

Você fez upload de uma imagem no S3, marcou o objeto como público, copiou a URL e abriu no navegador — e recebeu um 403 Access Denied . A configuração de ACL do objeto está correta, mas o acesso público continua bloqueado. O culpado quase sempre é o Block Public Access no nível do bucket, uma camada de controle que opera acima das ACLs e políticas de objeto e que muita gente ignora até levar o primeiro 403 em produção. TL;DR — S3 Access Denied com objeto público Camada O que controla O que verificar Block Public Access (bucket) Bloqueia ACLs e políticas públicas no bucket inteiro aws s3api get-public-access-block --bucket NOME ACL do objeto Permissão pública no objeto individual aws s3api get-object-acl --bucket NOME --key CHAVE Bucket Policy Permissões baseadas em política no bucket aws s3api get-bucket-policy --bucket NOME Object Ownership Controla se ACLs são respeitadas ou ignoradas aws s3api get-buc...
Leia mais