Record Types & Alias Records

Most of Route 53 is a handful of record types you will write over and over, plus one Route 53-only construct - the alias record - that solves a problem plain DNS cannot. This page covers both: the everyday types and when to reach for an alias instead of a CNAME.

The dividing line is simple. If you are pointing at an IP or an external hostname, use a standard record. If you are pointing at an AWS resource - especially at the zone apex - use an alias.

Recipe

Standard records all share the same shape through ChangeResourceRecordSets: a Name, a Type, a TTL, and a ResourceRecords list of values. Here are the five you reach for most.

# --- Python (boto3) ---
import boto3
 
r53 = boto3.client("route53")
r53.change_resource_record_sets(
    HostedZoneId="Z1234567890ABC",
    ChangeBatch={"Changes": [
        {"Action": "UPSERT", "ResourceRecordSet": {
            "Name": "app.example.com", "Type": "A", "TTL": 300,
            "ResourceRecords": [{"Value": "203.0.113.25"}]}},
        {"Action": "UPSERT", "ResourceRecordSet": {
            "Name": "app.example.com", "Type": "AAAA", "TTL": 300,
            "ResourceRecords": [{"Value": "2001:db8::25"}]}},
        {"Action": "UPSERT", "ResourceRecordSet": {
            "Name": "example.com", "Type": "MX", "TTL": 3600,
            "ResourceRecords": [{"Value": "10 mail.example.com"}]}},
        {"Action": "UPSERT", "ResourceRecordSet": {
            "Name": "example.com", "Type": "TXT", "TTL": 3600,
            "ResourceRecords": [{"Value": "\"v=spf1 include:amazonses.com -all\""}]}},
    ]},
)

// --- TypeScript (AWS SDK v3) ---
import { Route53Client, ChangeResourceRecordSetsCommand } from "@aws-sdk/client-route-53";
 
const r53 = new Route53Client({ region: "us-east-1" });
await r53.send(new ChangeResourceRecordSetsCommand({
  HostedZoneId: "Z1234567890ABC",
  ChangeBatch: { Changes: [
    { Action: "UPSERT", ResourceRecordSet: {
        Name: "app.example.com", Type: "A", TTL: 300,
        ResourceRecords: [{ Value: "203.0.113.25" }] } },
    { Action: "UPSERT", ResourceRecordSet: {
        Name: "app.example.com", Type: "AAAA", TTL: 300,
        ResourceRecords: [{ Value: "2001:db8::25" }] } },
    { Action: "UPSERT", ResourceRecordSet: {
        Name: "example.com", Type: "MX", TTL: 3600,
        ResourceRecords: [{ Value: "10 mail.example.com" }] } },
    { Action: "UPSERT", ResourceRecordSet: {
        Name: "example.com", Type: "TXT", TTL: 3600,
        ResourceRecords: [{ Value: '"v=spf1 include:amazonses.com -all"' }] } },
  ]},
}));

Note the details that trip people up: MX values put the priority number and the mail host in one string ("10 mail.example.com"), and TXT values must be wrapped in literal double quotes inside the string. A is IPv4, AAAA is IPv6, and both can point the same name at both address families.

Working Example

A CNAME aliases one hostname to another, but it has two hard limits: it cannot exist at the zone apex, and it cannot share a name with any other record type. When you need the apex (example.com with no subdomain) to point at an AWS resource, a CNAME simply will not work. That is what the alias record is for.

An alias record has no TTL and no ResourceRecords. Instead it carries an AliasTarget with three fields: the target's canonical hosted zone id, the target's DNS name, and EvaluateTargetHealth. Here is the apex of a domain pointed at an Application Load Balancer.

# --- Python (boto3) ---
r53.change_resource_record_sets(
    HostedZoneId="Z1234567890ABC",
    ChangeBatch={"Changes": [{
        "Action": "UPSERT",
        "ResourceRecordSet": {
            "Name": "example.com",            # the zone apex
            "Type": "A",                      # A alias -> IPv4 target
            "AliasTarget": {
                "HostedZoneId": "Z35SXDOTRQ7X7K",   # the ALB's canonical zone id
                "DNSName": "my-alb-1234567890.us-east-1.elb.amazonaws.com",
                "EvaluateTargetHealth": True,
            },
        },
    }]},
)

// --- TypeScript (AWS SDK v3) ---
await r53.send(new ChangeResourceRecordSetsCommand({
  HostedZoneId: "Z1234567890ABC",
  ChangeBatch: { Changes: [{
    Action: "UPSERT",
    ResourceRecordSet: {
      Name: "example.com",             // the zone apex
      Type: "A",                       // A alias -> IPv4 target
      AliasTarget: {
        HostedZoneId: "Z35SXDOTRQ7X7K",     // the ALB's canonical zone id
        DNSName: "my-alb-1234567890.us-east-1.elb.amazonaws.com",
        EvaluateTargetHealth: true,
      },
    },
  }]},
}));

The HostedZoneId inside AliasTarget is not your zone's id - it is the canonical zone id that AWS assigns to that class of target. For an ALB it is the load balancer's region-specific zone id (from DescribeLoadBalancers). CloudFront always uses Z2FDTNDATAQYW2. An S3 website endpoint has a per-region zone id. Getting this field wrong is the most common alias mistake.

Deep Dive

Which Zone Id Goes in AliasTarget

Each alias target type has a different source for its canonical zone id.

Because the ALB and S3 values are region- or resource-specific, resolve them at runtime rather than hardcoding. For CloudFront the constant is safe to inline.

EvaluateTargetHealth

Setting EvaluateTargetHealth: true ties the alias to the target's own health. For an ALB alias, Route 53 stops returning the record if the load balancer has no healthy targets. This is health checking you get for free, without creating a separate Route 53 health check - useful in failover setups covered on the health-checks page.

Alias vs CNAME Trade-offs

Aliases win at the apex and cost nothing to resolve (Route 53 does not charge for alias queries to AWS targets), and they have no TTL to tune - Route 53 manages freshness against the target. A CNAME is the right tool only when the target is not an AWS alias-eligible resource, such as an external SaaS hostname. When both would work below the apex, prefer the alias for AWS targets.

Gotchas

• CNAME at the apex. Route 53 rejects a CNAME on the zone apex. Use an alias A/AAAA record instead.
• Wrong AliasTarget HostedZoneId. Using your own zone id instead of the target's canonical id is the classic error. Pull the ALB/S3 value at runtime; CloudFront is always Z2FDTNDATAQYW2.
• Putting a TTL on an alias. Alias records have no TTL field; Route 53 manages caching against the target. Including TTL with AliasTarget is invalid.
• Unquoted TXT values. A TXT value must contain literal double quotes inside the string, or SPF/DKIM verification will silently fail.
• CNAME sharing a name. A CNAME cannot coexist with any other record type on the same name; Route 53 rejects the change batch.
• MX priority in the wrong place. The priority is part of the value string ("10 mail.example.com"), not a separate field.

Alternatives

• A CNAME record for pointing a subdomain at an external, non-AWS hostname where an alias is not available.
• IaC (CloudFormation, CDK, Terraform) to declare records alongside the resources they target, so the canonical zone id is wired automatically.
• AWS Global Accelerator when you want a static anycast IP in front of your endpoints instead of DNS-level pointing.
• Multivalue answer records for simple client-side load spreading across several healthy IPs without a full routing policy.

Use standard records for IPs and external names, and aliases for AWS resources - especially anything at the zone apex.

FAQs

Related

• Route 53 via SDK Basics - creating the zone and writing your first records.
• Routing Policies: Weighted, Latency & Failover - layering traffic shaping onto these record types.
• Health Checks & DNS Failover - what EvaluateTargetHealth and health checks add.
• Route 53's DNS & Traffic-Shaping Model - where records and aliases sit in the resource model.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).