Route 53 Alias vs. CNAME Records: The Definitive Guide for Pointing Domains to an ALB

When you provision an Application Load Balancer on AWS, it gets a DNS name like my-alb-1234567890.us-east-1.elb.amazonaws.com — not an IP address. This immediately raises a critical question: how do you map your own domain to it, and does the answer change when your domain is the zone apex (example.com vs. www.example.com)?

TL;DR — Alias vs. CNAME at a Glance

Feature CNAME Record Route 53 Alias Record
Works at zone apex (example.com) ❌ No (RFC 1034 prohibits it) ✅ Yes
Target type Any hostname Specific AWS resource endpoints
Route 53 query charges Billed per query Free for supported AWS targets
Health check integration Not natively integrated Evaluates target health automatically
TTL control You set the TTL Route 53 manages TTL automatically
DNS resolution hops Two lookups (CNAME → A record) One lookup (returns A records directly)
Supported targets Any external hostname ALB, NLB, CloudFront, S3, API Gateway, Elastic Beanstalk, other Route 53 records

The Core Problem: Why CNAME Fails at the Zone Apex

DNS has a hard rule defined in RFC 1034: a CNAME record cannot coexist with any other record type at the same node. The zone apex (example.com) must have an SOA record and NS records. Therefore, placing a CNAME at example.com is a protocol violation — most DNS resolvers and registrars will reject it outright.

This means if you want example.com (not just www.example.com) to resolve to your ALB, a standard CNAME is not an option. Route 53 Alias records solve this problem entirely.

Analogy: Think of a CNAME as a postal forwarding slip — it tells the post office "this address has moved, go look up the new one." An Alias record is like the post office already knowing the final delivery address and writing it directly on the envelope. The recipient gets the letter faster, and you're not charged for the extra lookup trip.

How DNS Resolution Works: CNAME vs. Alias

The sequence diagrams below illustrate the resolution path for each record type when a client queries your domain.

CNAME Resolution Flow

sequenceDiagram participant C as "Client Resolver" participant R53 as "Route 53" participant ALBDNS as "AWS ELB DNS" C->>R53: Query: www.example.com (Type A)? R53-->>C: CNAME → my-alb-1234567890.us-east-1.elb.amazonaws.com Note over C: Must perform a second lookup C->>ALBDNS: Query: my-alb-1234567890.us-east-1.elb.amazonaws.com (Type A)? ALBDNS-->>C: A records: 54.x.x.x, 52.x.x.x Note over C,ALBDNS: Two DNS hops — two billable queries
  1. The client's resolver queries Route 53 for www.example.com.
  2. Route 53 returns the CNAME target: my-alb-1234567890.us-east-1.elb.amazonaws.com.
  3. The resolver must perform a second DNS query to resolve the ALB hostname to its current IP addresses.
  4. The ALB's DNS returns the IP addresses, and the resolver caches both results with their respective TTLs.
  5. This two-hop resolution adds latency and incurs two billable Route 53 queries.

Alias Record Resolution Flow

sequenceDiagram participant C as "Client Resolver" participant R53 as "Route 53" C->>R53: Query: example.com (Type A)? Note over R53: Internally resolves Alias target
(ALB DNS name → current IPs) R53-->>C: A records: 54.x.x.x, 52.x.x.x Note over C,R53: Single DNS hop — no charge for supported AWS targets
  1. The client's resolver queries Route 53 for example.com (zone apex).
  2. Route 53 internally resolves the Alias target (the ALB DNS name) and returns the final A records (IP addresses) directly in a single response.
  3. The resolver receives IP addresses immediately — no second lookup required.
  4. Route 53 does not charge for this query when the target is a supported AWS resource.
  5. If the ALB's IPs change (e.g., during scaling), Route 53 automatically reflects the updated addresses.

Deep Dive: What Makes Alias Records Special

1. Zone Apex Support

Route 53 Alias is a Route 53-proprietary extension to DNS. It is not a standard DNS record type — it exists only within Route 53's authoritative name servers. When Route 53 receives a query for an Alias record, it resolves the target internally and responds with the underlying A or AAAA records, making it appear to the outside world as a native A record. This is why it can legally coexist with SOA and NS records at the zone apex.

2. Automatic IP Tracking

ALBs are not backed by static IPs. AWS scales the underlying infrastructure, and the IP addresses associated with an ALB's DNS name can change. With a CNAME, your TTL controls how long resolvers cache the intermediate hostname — but you have no control over the ALB's own DNS TTL. With an Alias record, Route 53 manages this automatically, always reflecting the current state of the target resource.

3. Health Check Evaluation

When you configure an Alias record pointing to an ALB, Route 53 can evaluate the health of the ALB target. If you enable "Evaluate Target Health" on the Alias record, Route 53 will not return the Alias target in DNS responses if the target is unhealthy. This is a critical feature for high-availability architectures using Route 53 routing policies (e.g., failover, weighted, latency-based).

4. No Query Charges

Route 53 does not charge for DNS queries to Alias records that resolve to the following AWS targets: Elastic Load Balancers, CloudFront distributions, AWS Elastic Beanstalk environments, API Gateway endpoints, VPC interface endpoints, and S3 website endpoints. Always verify current pricing at the official Route 53 pricing page.

Architecture: Pointing Your Domain to an ALB

graph LR User(["👤 End User"]) subgraph Route53["Route 53 Hosted Zone: example.com"] Apex["A (Alias)
example.com
→ ALB DNS"] WWW["A (Alias)
www.example.com
→ ALB DNS"] end subgraph ALBLayer["Application Load Balancer"] ALB["ALB
my-alb-1234567890
.us-east-1.elb.amazonaws.com"] TG1["Target Group
(HTTPS :443)"] end subgraph Compute["Compute Layer"] EC2A["EC2 Instance A"] EC2B["EC2 Instance B"] end User -->|"DNS query: example.com"| Apex User -->|"DNS query: www.example.com"| WWW Apex -->|"Alias resolves to"| ALB WWW -->|"Alias resolves to"| ALB ALB --> TG1 TG1 --> EC2A TG1 --> EC2B
  1. Zone Apex (example.com): Must use an Alias record. Route 53 resolves it internally to the ALB's current IP addresses and returns them as A records.
  2. Subdomain (www.example.com): Can use either a CNAME or an Alias record. Alias is still preferred for the performance and cost benefits described above.
  3. ALB: Receives traffic on port 443 (HTTPS). The ALB's DNS name is the Alias target.
  4. Target Groups: The ALB routes requests to registered EC2 instances, ECS tasks, or Lambda functions based on listener rules.

Implementation: Creating an Alias Record via AWS CLI

The following command creates an Alias A record for the zone apex pointing to an ALB. Replace the placeholder values with your actual Hosted Zone ID, ALB DNS name, and ALB Hosted Zone ID.

🔽 [Click to expand] — AWS CLI: Create Alias Record for Zone Apex 
# Step 1: Get your Hosted Zone ID
aws route53 list-hosted-zones-by-name \
  --dns-name "example.com" \
  --query "HostedZones[0].Id" \
  --output text

# Step 2: Get your ALB's DNS name and Hosted Zone ID
# The ALB Hosted Zone ID is region-specific and documented by AWS.
# Example for us-east-1: Z35SXDOTRQ7X7K
# Always verify at: https://docs.aws.amazon.com/general/latest/gr/elb.html
aws elbv2 describe-load-balancers \
  --names "my-application-lb" \
  --query "LoadBalancers[0].{DNSName:DNSName,CanonicalHostedZoneId:CanonicalHostedZoneId}" \
  --output table

# Step 3: Create the Alias record using a change batch
aws route53 change-resource-record-sets \
  --hosted-zone-id "Z0123456789ABCDEFGHIJ" \
  --change-batch '{
    "Comment": "Create Alias A record for zone apex pointing to ALB",
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-alb-1234567890.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'
🔽 [Click to expand] — AWS CLI: Create Alias Record for Subdomain (www) 
aws route53 change-resource-record-sets \
  --hosted-zone-id "Z0123456789ABCDEFGHIJ" \
  --change-batch '{
    "Comment": "Create Alias A record for www subdomain pointing to ALB",
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "www.example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-alb-1234567890.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

Key parameter notes:

  • AliasTarget.HostedZoneId: This is the ALB's hosted zone ID, not your Route 53 hosted zone ID. Each AWS region has a specific hosted zone ID for ELB. Find the correct value in the AWS General Reference for ELB endpoints.
  • EvaluateTargetHealth: true: Strongly recommended. Route 53 will suppress DNS responses for unhealthy targets.
  • No TTL field: Alias records do not accept a TTL — Route 53 manages it automatically.

IAM Permissions for Route 53 Record Management

Apply least privilege. The following policy grants only the permissions required to manage records within a specific hosted zone:

🔽 [Click to expand] — IAM Policy: Least Privilege for Route 53 Record Changes 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRoute53RecordChanges",
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets"
      ],
      "Resource": "arn:aws:route53:::hostedzone/Z0123456789ABCDEFGHIJ"
    },
    {
      "Sid": "AllowRoute53ListZones",
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:ListHostedZonesByName",
        "route53:GetChange"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowDescribeALB",
      "Effect": "Allow",
      "Action": [
        "elasticloadbalancing:DescribeLoadBalancers"
      ],
      "Resource": "*"
    }
  ]
}

Decision Framework: When to Use Which

graph TD Start(["You need to point
a domain to an ALB"]) Q1{"Is it the
zone apex?
(example.com)"} Q2{"Is the target
an AWS-supported
Alias resource?"} UseAlias["✅ Use Route 53
Alias Record
(Mandatory)"] UseAliasOpt["✅ Use Route 53
Alias Record
(Recommended)"] UseCNAME["⚠️ Use CNAME
(Only option for
non-AWS targets)"] Start --> Q1 Q1 -->|"Yes"| UseAlias Q1 -->|"No (subdomain)"| Q2 Q2 -->|"Yes (ALB, CloudFront,
S3, API GW, etc.)"| UseAliasOpt Q2 -->|"No (external hostname)"| UseCNAME

Glossary

Term Definition
Zone Apex The root domain itself (e.g., example.com), as opposed to a subdomain. Also called the "naked domain" or "root apex."
CNAME (Canonical Name) A standard DNS record type that maps one hostname to another hostname. Cannot be used at the zone apex.
Alias Record A Route 53-proprietary DNS extension that maps a hostname directly to an AWS resource, resolving to A/AAAA records transparently.
Evaluate Target Health A Route 53 Alias record setting that causes Route 53 to check the health of the Alias target and suppress DNS responses for unhealthy resources.
ALB Canonical Hosted Zone ID The AWS-assigned hosted zone ID for an ALB, required when creating an Alias record. It is region-specific and distinct from your Route 53 hosted zone ID.

Wrap-Up & Next Steps

The rule is straightforward: always use a Route 53 Alias record when pointing any domain — especially the zone apex — to an AWS resource like an ALB. It eliminates the RFC 1034 zone apex restriction, reduces DNS resolution latency, removes per-query charges, and integrates natively with Route 53 health checks for resilient routing policies.

Reserve CNAME records for cases where your target is a non-AWS hostname that Route 53 Alias does not support.

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Fix Internet Gateway and Route Table

EC2 no internet access in a custom VPC is one of the most common launch-day failures — the instance is running, but outbound connectivity is completely silent. TL;DR: EC2 No Internet Access — Fix Checklist Step What to Do Why It Matters Complexity 1 Create and attach an Internet Gateway to the VPC Without an IGW, the VPC has no path to the public internet Low 2 Add a default route (0.0.0.0/0) pointing to the IGW in the subnet's route table The IGW exists but traffic has no route to reach it Low 3 Assign a public IP or Elastic IP to the instance Private IPs are not routable on the public internet Low 4 Verify Security Group allows outbound traffic A restrictive outbound rule silently drops all egress Low 5 Verify Network ...
Read more

EC2 SSH Connection Timeout: Which Security Group Rules to Check

An EC2 SSH connection timeout is one of the most common blockers when launching a new instance — the fix is almost always a missing or misconfigured inbound rule in your Security Group. TL;DR — Diagnostic Steps at a Glance Step What to Check Common Fix 1 Security Group inbound rules Add SSH (TCP 22) from your IP 2 Subnet route table Ensure 0.0.0.0/0 routes to an Internet Gateway 3 Network ACL rules Allow inbound TCP 22 and ephemeral return ports 4 Instance public IP / Elastic IP Confirm a public IP is assigned 5 Key pair and SSH username Use correct private key and AMI-specific username Why SSH Times Out Instead of Refusing A connection refused error means the TCP handshake reached the host but nothing is listening. A connection timed out error means packets never arrived — or replies never returned. On EC2, that silence is almost always a network-layer block, not an OS-level problem. The Se...
Read more

Difference Between IAM User and IAM Role: Which One Should Your EC2 Use?

Understanding the difference between IAM User and IAM Role is critical — choosing wrong means either hardcoded credentials in your app or a silent security exposure you won't catch until an audit. TL;DR: IAM User vs IAM Role at a Glance Dimension IAM User IAM Role Identity type Permanent, named human or service identity Assumable identity with temporary credentials Credential type Long-lived access keys or password Short-lived STS tokens (auto-rotated) Attached to EC2? No native attachment — keys must be embedded Yes — via Instance Profile, injected automatically Rotation required? Manual — your responsibility Automatic — AWS STS handles it Recommended for EC2 → S3? No Yes — always Cross-account access Requires separate user per account Native — assume role across accounts Audit trail Tied to user identity Tied to role + session name in CloudTrail What IAM User and IAM Role Actual...
Read more