CloudFront ALIAS vs CNAME at the Zone Apex: Why Root Domains Need Route 53 ALIAS Records (And Save on DNS Queries)
Here's the rule in one sentence: at the zone apex (the bare domain, like example.com with nothing in front of it), you cannot use a CNAME record to point at CloudFront — you have to use a Route 53 ALIAS record instead, because a CNAME is not legally allowed to share the top node of a DNS zone with anything else. The counterintuitive part is what an ALIAS record actually is once it leaves Route 53's building: it isn't a real DNS record type at all. Run a dig against it and the answer comes back labeled A or AAAA, not ALIAS — Route 53 is quietly impersonating an IP address record so that DNS software everywhere else on the internet, which has never heard of "ALIAS" and never will, has no idea anything unusual happened.
Jake found this out the expensive way. He'd finally gotten his shop's site — a little catalog of trade-in phone prices — moved onto CloudFront so it would load fast for customers standing in the shop comparing prices on their own phones. He typed a CNAME record into Route 53 for his bare domain, the way he'd typed a hundred CNAMEs before for subdomains, and Route 53 threw an error he didn't understand. He called Ethan, who runs the small AWS consulting practice two doors down from the shop and has bailed Jake out of exactly this kind of thing before.
"Read me the error," Ethan said. Jake read it. Ethan didn't laugh, which Jake appreciated, because he'd half expected to be laughed at. "Okay," Ethan said, "that's not a bug and it's not you being bad at this. That error is DNS itself telling you no, and it would've told anyone no. Let me explain why, because once you see it you'll never forget it."
♂️ Jake's Reality Check
"I've made CNAME records a hundred times. It worked for shop.jakesphones.com. Why does jakesphones.com — the exact same domain, minus the subdomain part — throw an error? It's the same company, the same domain, the same target. What's different about the front door?"
Ethan's answer. "Think of your DNS zone like the filing cabinet for your business. Every folder in that cabinet is labeled with a name — 'shop,' 'mail,' whatever. But there's one folder that isn't labeled with anything extra, the one filed right under the cabinet's own name. That folder already has to hold two pieces of paperwork the whole cabinet depends on: who's legally in charge of it, and which servers are allowed to answer questions about it. A CNAME record's entire job is to say 'don't read anything else in this folder — go read a different folder instead.' You can't put that instruction in the one folder that's required to hold the cabinet's own paperwork. It's not a CloudFront rule. It's not even an AWS rule. It's older than AWS."
What "the Route 53 rule" actually is
When people say "the Route 53 rule" about ALIAS versus CNAME, they're usually compressing two separate things into one sentence, and untangling them is most of what makes this topic click.
The first thing is a plain DNS rule that has nothing to do with AWS: a CNAME record can never be the only record — or any record at all — at a name that also needs other record types, and it can never exist at the zone apex, because the apex already has to carry SOA (start of authority) and NS (name server) records. A CNAME says "for this exact name, don't look at any other record — go ask about this other name instead." DNS software takes that literally. If example.com had a CNAME pointing somewhere else, and example.com also needs an SOA record and NS records for the zone to function, you'd have two contradictory instructions sitting on the same name. So the CNAME rule isn't an AWS restriction Amazon invented to sell you something — it's baked into how DNS resolvers have worked since long before CloudFront existed.
The second thing is what Amazon built to get around that limitation for its own customers: the ALIAS record type, which exists only inside Route 53. Route 53's own developer guide describes it plainly — an alias record is a Route 53 extension to DNS, similar to a CNAME record, but you can create an alias record both for the root domain, such as example.com, and for subdomains, such as www.example.com, whereas you can create CNAME records only for subdomains. Put those two facts together and "the rule" reads like this: DNS forbids a CNAME at the apex, full stop, on every DNS server everywhere — and Route 53's answer to that, exclusive to Route 53, is a record type that behaves like a CNAME (points somewhere else, follows changes automatically) but is legally allowed to sit at the apex because, technically, it isn't a CNAME.
✅ Why this is the one to use
For a CloudFront apex domain, don't spend time hunting for a workaround CNAME trick — there isn't a legitimate one inside Route 53, and there doesn't need to be. The ALIAS record is free, purpose-built for exactly this, and it's the default choice for every AWS resource, not just CloudFront.
Why DNS won't let a CNAME live at the apex
The plain-English version of "zone apex"
A zone is the DNS namespace you control — everything under example.com. The apex is that zone's own root name, with nothing in front of it: not www, not shop, not anything. Two records are mandatory at every zone's apex for the zone to function at all. The SOA record states who's authoritative for the zone and how long other DNS servers should cache negative answers before re-checking. The NS records list which name servers are allowed to answer questions about this zone in the first place — these are the records your registrar points at when you set your zone's nameservers. A DNS resolver reads NS records to figure out who to ask, and reads SOA to understand caching behavior; both have to exist unambiguously at the apex.
A CNAME record's entire function is redirection: it tells a resolver "stop looking here, go look at this other name instead," for every single record type — A, AAAA, MX, TXT, all of it. If the apex had a CNAME, a resolver trying to find the zone's own NS records would be told to go look somewhere else for them, which breaks the fundamental mechanism by which the zone is discoverable at all. That's not a policy choice CloudFront or Route 53 made — it's why this restriction is universal across every DNS implementation, not just AWS's.
This isn't just about the apex, either
The same "a CNAME can't share a name with anything else" rule shows up one level down too, and it trips people up on subdomains just as often. If shop.example.com already has a CNAME record, you can't also add an MX, A, or TXT record for that exact name — Route 53 will reject it. This matters for CloudFront setups more than people expect, because it's common to want a TXT record at the same name for domain verification (an ACM DNS validation record, for instance) alongside your CloudFront CNAME. If you hit that wall, the fix is usually to alias the record instead of CNAME-ing it, since alias records don't carry the same "nothing else can live here" restriction for unrelated types the way a CNAME does — though a CNAME and an alias record still can't coexist at the identical name and type either.
⚠️ What this actually breaks
If you already have a CNAME at a subdomain and you try to add an unrelated record type at that same exact name, Route 53 won't quietly merge them — it will reject the whole change batch. This is the single most common cause of a failed Terraform apply or CloudFormation deploy for teams migrating a subdomain onto CloudFront: an old CNAME from a previous DNS provider is still sitting there, and the new alias record can't be created until it's removed.
What an ALIAS record actually is, mechanically
This is the part that catches even people who've set one up a dozen times, because Route 53's console hides it well. An ALIAS record isn't a fourth kind of DNS record sitting alongside A, AAAA, and CNAME. When you create one, you're still creating an A record (or an AAAA record, for IPv6) — you're just telling Route 53, at creation time, to resolve that A record's value dynamically by looking up the target resource every time a query comes in, instead of storing a fixed IP address. Route 53's own documentation is direct about this: in the response to a dig or nslookup query, an alias record is listed as the record type that you specified when you created the record, such as A or AAAA — the alias property is visible only in the Route 53 console or in the response to a programmatic request, such as an AWS CLI list-resource-record-sets command. A CNAME record, by contrast, shows up as a CNAME in every tool that asks.
That's the counterintuitive reveal from the opening: outside of Route 53's own console and API, an ALIAS record is invisible as a concept. Every resolver on the internet, every dig command your teammate runs, every uptime monitor pinging your site — all of them just see an ordinary A record with an IP address in it. The "alias-ness" is entirely a Route 53 bookkeeping detail that determines how Route 53 computes the answer before handing it out, not something that travels with the DNS response itself. If you ever debug a CloudFront apex issue by running dig example.com and someone insists "that can't be your alias record, it says type A" — it is. That's what an alias record always says.
Why that matters in practice
Because the alias resolves at query time by checking the current state of the target resource, it automatically tracks changes without you touching DNS again. If CloudFront's edge network reassigns the IP addresses behind your distribution's domain name — which happens routinely and is entirely normal — your alias record's answers update on their own. A hardcoded A record pointing at a specific CloudFront IP would go stale the moment CloudFront rotated that address, which is one more reason nobody manually points a domain at CloudFront's raw IPs even when it's technically possible.
It also explains a billing quirk that surprises people the first time they notice it: Route 53 doesn't charge for alias queries to CloudFront distributions or other AWS resources. A CNAME record, or a plain A record with a fixed IP, is billed as a normal DNS query. Route 53 waives the query charge specifically because resolving an alias means Route 53 is doing an internal lookup against another AWS service on your behalf, not serving a static answer from disk — and Amazon doesn't want to charge you extra to use their own recommended pattern.
♂️ Jake's Reality Check
"Wait, so when my customer's phone looks up jakesphones.com, it never even sees the word 'alias' anywhere? It just thinks it got a normal answer?"
Ethan's answer. "Exactly. The phone's DNS resolver asks Route 53 'what's the A record for jakesphones.com,' Route 53 quietly goes and checks what CloudFront is currently answering with, and hands that back labeled as a totally ordinary A record. The phone has no idea any of that happened. That's the whole trick — and it's also why this only works if Route 53 is the one answering the question. Nobody else knows how to do that lookup."
| Property | ALIAS record | CNAME record |
|---|---|---|
| Allowed at zone apex (example.com) | Yes | No — never, on any DNS provider |
| Only works on Route 53 | Yes — it's a Route 53-only extension | No — CNAME is a standard DNS type everywhere |
| TTL | Can't be set manually — inherits the target resource's TTL | You set the TTL yourself |
| Query cost against a CloudFront target | Free | Billed as a standard query |
| How it appears to dig/nslookup | As a plain A or AAAA record | As a CNAME record, visibly |
| Evaluate Target Health for CloudFront | Can't be set to Yes for a CloudFront target | Not applicable — no health evaluation concept |
Setting up the apex ALIAS record for CloudFront, start to finish
Before touching Route 53, two things have to already exist, and skipping either one is the reason most "my alias record isn't working" tickets don't actually have anything wrong with the DNS record at all.
First, your CloudFront distribution needs your apex domain added as an alternate domain name — CloudFront's console still labels this field with the word "CNAMEs" in places, a naming leftover that trips people up, but functionally it just means "which domain names am I allowed to answer for." Your distribution must include an alternate domain name that matches the name of the record — for example, if the name of the record is acme.example.com, your CloudFront distribution must include acme.example.com as one of the alternate domain names. Second, you need a valid SSL/TLS certificate attached to that distribution covering the apex domain, and it has a strict location requirement: to use an ACM certificate with CloudFront, you must request or import the certificate in the US East (N. Virginia) Region — us-east-1 — regardless of which region your users, your origin, or the rest of your infrastructure live in. That single-region requirement is one of the most-missed steps in the entire setup, because it's the one region choice that doesn't match wherever you normally deploy.
- Find your distribution's domain name. In the CloudFront console, open your distribution and, on the General tab, copy the value of "Distribution domain name" — it looks like
d111111abcdef8.cloudfront.net. While you're there, check whether IPv6 is turned on for the distribution; you'll need that answer in a moment. - Open Route 53 and go to your hosted zone. The hosted zone has to be the one that's actually authoritative for your domain — the one whose name servers your registrar is pointed at.
- Create a new record and leave the name field blank. For an apex record, Route 53's own instructions say to leave the record name empty rather than typing anything, since the apex record simply takes the hosted zone's own name.
- Set the record type to A — IPv4 address. This is true even though you're routing to CloudFront, not to a raw IP — the alias mechanism is what makes an A record point somewhere dynamic.
- Turn on Alias, then choose "Alias to CloudFront distribution." Route 53 will offer you a picker of your own distributions in the same account; select the one from step 1, or paste its domain name manually if it belongs to a different AWS account than the one you're logged into.
- Leave Evaluate Target Health set to No. This isn't a placeholder default you're meant to change later — Route 53's AliasTarget documentation states outright that you can't set EvaluateTargetHealth to true when the alias target is a CloudFront distribution. The option exists in the UI because the same screen is reused for other resource types.
- If IPv6 is enabled on the distribution, repeat steps 3–6 with record type AAAA — IPv6 address. Skipping this step doesn't break anything for IPv4 users, but any visitor whose ISP prefers IPv6 will silently fail to resolve your apex domain at all, which is a hard one to diagnose after the fact because it only affects a slice of your traffic.
- Save, then wait roughly a minute before testing. Route 53 propagates changes to all of its own servers in around 60 seconds — that's Route 53 internally, not the wider internet's resolver caches, which can lag longer depending on what was cached before your change.
The one field almost everyone gets wrong via CLI or infrastructure-as-code
If you're setting this up through the AWS CLI, CloudFormation, or Terraform instead of the console, there's a value you need that the console fills in for you silently: the alias target's hosted zone ID. For any CloudFront distribution, in any AWS region, that value is always the same fixed string — Z2FDTNDATAQYW2 — regardless of which region you or your users are in. This isn't the hosted zone ID of your own domain; it's a constant Amazon assigns to CloudFront distributions as a category. A CloudFormation snippet for the apex record looks like this:
RecordSets:
- Name: example.com.
Type: A
AliasTarget:
HostedZoneId: Z2FDTNDATAQYW2
DNSName: !GetAtt MyDistribution.DomainName
EvaluateTargetHealth: false
Get that hosted zone ID wrong — teams sometimes paste in the hosted zone ID of their own domain instead — and the change batch fails validation before it ever reaches CloudFront, with an error that doesn't obviously point back at that one field. Worth noting too: alias resource record sets for CloudFront can't be created in a private hosted zone at all, which surprises teams who've set up a VPC-internal DNS strategy and expect the same alias pattern to work there. CloudFront is a public, internet-facing service, so an alias record pointing at it only makes sense in a public hosted zone.
Do you need www.example.com too, or is the apex enough?
Most sites want both example.com and www.example.com to work, with one of the two redirecting to the other so search engines and browser history don't split traffic between what looks like two different sites. Both names need to be listed as alternate domain names on the CloudFront distribution (or on separate distributions, if you're redirecting rather than serving from the same one), and both need their own Route 53 record.
For www.example.com, you genuinely have a choice — it's a subdomain, so a CNAME record is legal there and will work correctly. Most teams alias it anyway rather than mixing record types across their two front-door names, simply because it's free and behaves identically to an A record for every downstream tool. There's no meaningful downside to aliasing a subdomain that a CNAME would have handled just fine — it's a case where "the recommended default" and "the only option" happen to be the same answer at the apex, but only a preference at the subdomain.
♂️ Jake's Reality Check
"So for www I could've just left the CNAME and it would've worked? I only aliased it because you told me to."
Ethan's answer. "Correct — for www it was never a requirement. My rule of thumb is boring on purpose: alias everything you can, because it's free and it means one less record type to remember when you're troubleshooting at midnight. But understand the difference — only the apex actually forces your hand. Everything else is me being tidy, not DNS being strict."
The decision, laid out plainly
| Situation | What to use | Why |
|---|---|---|
| example.com → CloudFront, on Route 53 | A record, Alias on | CNAME isn't legal at the apex; alias is the only apex-capable option |
| www.example.com → CloudFront, on Route 53 | A record, Alias on (recommended) or CNAME (also legal) | Both work; alias is free and consistent with the apex record |
| example.com → CloudFront, DNS hosted elsewhere | Your provider's own apex-forwarding feature, or move DNS to Route 53 | ALIAS is a Route 53-only mechanism — it doesn't exist for other DNS hosts |
| Aliasing to another record in the same hosted zone | Alias, but only if the target record isn't itself a CNAME | An alias record can't reference a CNAME record, at the apex or anywhere else |
| You need to point traffic at a CloudFront distribution in a different AWS account | A record, Alias on, target entered manually as the raw *.cloudfront.net domain name | The console's distribution picker only lists distributions in your own account, but alias records can still target any CloudFront domain name you type in |
| Internal-only DNS in a VPC private hosted zone | Not applicable to CloudFront | Alias records for CloudFront can't be created in a private hosted zone at all |
What it looks like when you get the wrong record type — and how to read the error
Nobody in this conversation has been able to reproduce these errors on live hardware to confirm the exact wording — but the messages below are documented directly by AWS as the standard failure text for these exact mistakes, so treat them as reliable diagnostic signatures rather than something to just paraphrase and hope matches.
"RRSet of type CNAME ... is not permitted at apex in zone ..."
This is the one Jake hit. This error occurs because you can't create a CNAME record for your domain's zone apex — for example, if your domain is example.com, then you can't create a CNAME record for example.com, though you can create CNAME records for www.example.com or newproduct.example.com. The fix is exactly what this article has been walking through: delete the CNAME attempt and create an A record with Alias turned on instead.
"RRSet of type X ... conflicts with other records with the same DNS name"
You receive this message when you have a CNAME resource record set for a subdomain name that also needs an MX, A, or TXT record — the fix is to create your MX, A, or TXT record in a different record set in the same hosted zone, or convert the existing CNAME to an alias record if the resource supports it. This is the trap mentioned earlier — a validation TXT record for a certificate sitting at the same name as a CNAME you're trying to convert to an alias. It also shows up when you try to UPSERT a CNAME record directly into a different record type; the UPSERT operation only succeeds cleanly when you're replacing a CNAME with another CNAME, so switching types at an existing name generally needs an explicit delete-then-create rather than an in-place update.
"CNAMEAlreadyExists" — but from CloudFront, not Route 53
This one isn't a Route 53 error at all, and it's easy to mistake for a DNS problem when it's actually CloudFront rejecting the distribution configuration before the DNS record even matters. You can't use the same alternate domain name for more than one CloudFront distribution — when the domain you're trying to add is already associated with another distribution, you receive an error stating that one or more of the CNAMEs you provided are already associated with a different resource, with error code CNAMEAlreadyExists and status code 409. To find out which distribution is holding the domain, run the ListConflictingAliases AWS CLI command to get partial information about the conflicting distribution and the account ID that owns it. If that distribution is yours, use AssociateAlias to move the domain over; if it belongs to a different AWS account entirely — a common surprise when a domain changes hands or a former employee's personal account still has an old distribution configured — you'll need to complete a cross-account move, which requires contacting AWS Support if you can't get the source distribution deactivated yourself.
| Where it happens | Error signature | Real cause |
|---|---|---|
| Route 53 | InvalidChangeBatch — "not permitted at apex" | CNAME attempted on the bare domain name |
| Route 53 | InvalidChangeBatch — "conflicts with other records" | A CNAME and another record type both aimed at the same exact name |
| CloudFront | CNAMEAlreadyExists (HTTP 409) | The domain is already an alternate domain name on a different distribution |
| CloudFront / browser | SSL certificate name mismatch / 502 | DNS is correct, but the ACM certificate wasn't requested in us-east-1 or doesn't cover this exact name |
The hard cases: when the domain doesn't live on Route 53
Everything above assumes your DNS is hosted on Route 53. That's a real assumption a lot of readers don't meet — plenty of businesses register through one company and keep DNS with a different provider entirely, or inherited a domain from a previous owner and never migrated it. This is the one popular piece of advice worth pushing back on directly: some guides imply that "just use an alias" is a universal apex fix for CloudFront, when it's really a Route 53-only fix. If your nameservers point somewhere other than Route 53, the ALIAS mechanism described in this entire post simply doesn't exist for you, because it's a feature of Route 53's own resolution engine, not a DNS standard.
You have two honest paths from here, and neither is a shortcut:
Path 1 — check whether your current DNS provider has its own apex-forwarding feature.
Many third-party DNS providers built their own version of what Route 53 does, usually under a name like ANAME or "CNAME flattening." Functionally these solve the same DNS-level contradiction the same way — by resolving the target and presenting an A/AAAA record to the outside world — but the feature name, behavior, and TTL handling vary by provider, and this document has no vendor documentation to draw from for any provider besides Route 53, so it can't tell you the exact steps for yours. Check your provider's own documentation for "apex," "root domain," or "ANAME" before assuming the feature exists.
Path 2 — move DNS hosting to Route 53. This means changing your domain's nameservers at your registrar to point at a Route 53 hosted zone, which is a separate step from where your domain is registered. Registration and DNS hosting are two different services and don't have to be with the same company.
⚠️ What we can't tell you
If you don't control DNS for the domain at all — you're not the account owner and don't have access to make nameserver changes — nothing in this article gets you to a working apex record. That's not a workaround gap; it's a hard requirement of how domain ownership and DNS delegation work. Someone with that access has to make the change, or you have to gain it first.
Health checks, TTL, and the settings that don't behave like you'd expect
Two settings on the alias record screen exist and are technically clickable, but don't do what people expect for a CloudFront target, and it's worth naming both plainly so nobody spends an afternoon debugging behavior that was never going to happen.
Evaluate Target Health. This toggle exists because alias records can point at several different AWS resource types, and for some of them — like an Application Load Balancer — Route 53 can check whether the target is actually healthy and stop routing to it if it isn't. For CloudFront, that concept simply isn't wired up. As noted earlier, you can't set it to true for a CloudFront target, and even if it were toggleable, CloudFront's globally distributed edge network doesn't map to a single health state the way a load balancer's backend fleet does.
TTL. With a CNAME record, you pick a TTL — how long resolvers are allowed to cache the answer before asking again. With an alias record, that field disappears entirely, because Route 53 uses the TTL of whatever it's aliasing to instead of a value you set. For a CloudFront target, that means you're relying on CloudFront's own default TTL behavior for how the record itself gets cached upstream, which is a separate concept from the cache-control settings on your content inside CloudFront — changing your CloudFront cache-control headers does not change how long a resolver caches your DNS answer.
♂️ Jake's Reality Check
"I wanted to turn on health checking so if my origin goes down, DNS fails over to a backup page automatically. That's not possible here?"
Ethan's answer. "Not through this alias record's Evaluate Target Health setting — not for CloudFront, no matter how badly you want it to. That kind of failover, if you actually need it, gets built one layer down, inside CloudFront itself, with an origin group that has a primary and a secondary origin. Or with a separate Route 53 health check tied to a non-alias record somewhere else in the design. Don't go looking for it on this screen — it isn't there, and it was never going to be."
Doing this with the CLI instead of clicking through the console
For anyone scripting this — standing up new environments repeatedly, or managing dozens of domains — the console workflow above translates directly into an AWS CLI change batch. The shape is the same regardless of whether you're calling the API directly, wrapping it in a shell script, or generating it from a template engine.
- Get the distribution's domain name.
aws cloudfront get-distribution --id YOUR_DISTRIBUTION_IDreturns it underDomainNamein the response. - Build a change-batch JSON file containing an UPSERT (create-or-update) action for an A record, with
AliasTargetset toHostedZoneId: Z2FDTNDATAQYW2andDNSNamepointing at the value from step 1, plusEvaluateTargetHealth: false. - Submit it with
aws route53 change-resource-record-sets --hosted-zone-id YOUR_ZONE_ID --change-batch file://your-file.json, using the hosted zone ID for your own domain here — not the CloudFront constant, which only belongs inside theAliasTargetblock. - Poll the change status with the change ID the API returns, using
get-change, until it reports INSYNC — that confirms the update has propagated across Route 53's own servers, which typically takes under a minute.
If you're on Terraform, the equivalent resource uses an alias block instead of a records list, and the same rule bites people migrating existing infrastructure: an apex record originally written as a plain CNAME resource type won't apply — Terraform will report it as invalid the same way the console and CLI do, because the underlying constraint is identical no matter which tool is issuing the API call. If your state file was imported from an old configuration that predates the migration to CloudFront, it's worth diffing the plan carefully before applying — a plan that shows Terraform trying to destroy and recreate the apex record is normal here, since a CNAME resource and an alias resource are structurally different types under the hood, not a like-for-like edit.
Verifying it actually worked
Whichever tool created the record, the verification step is the same and doesn't require any AWS-specific tooling: run dig example.com A +short from a terminal and confirm you get back IP addresses rather than an empty response or an error. Because of what was covered earlier, you will never see the word "alias" in that output — a correctly configured apex alias record and a plain A record look identical to dig. What you're really checking is that an answer comes back at all, and that a browser hitting https://example.com gets a valid certificate rather than a name-mismatch warning, which confirms the ACM certificate and the alternate domain name on the distribution are both configured correctly too, not just the DNS record in isolation.
Frequently asked questions
What's the actual difference between an ALIAS record and a CNAME record in Route 53?
A CNAME is a standard DNS record type that says "for this name, go look up this other name instead" — it works everywhere in DNS, but it can never share a name with any other record, and it's banned at the zone apex. An ALIAS record is a Route 53-only construct that looks like a CNAME functionally (it points at a target and updates automatically) but is technically stored and served as an A or AAAA record, which is what lets it legally exist at the apex.
Can I use a CNAME record for my root domain with CloudFront?
No, not on Route 53 or any other DNS provider. This isn't a CloudFront-specific limitation — it's a DNS standard that predates CloudFront, because the zone apex already has to hold your SOA and NS records, and a CNAME can't coexist with anything else at the same name.
Why does Route 53 give me an InvalidChangeBatch error when I try to add a CNAME at the apex?
Route 53 is enforcing the same DNS-standard restriction described above at request time, before it ever writes the record. The error text explicitly says a CNAME record isn't permitted at the apex of that zone, and the fix is to delete the attempted CNAME and create an A record with Alias enabled instead, targeting your CloudFront distribution.
Do ALIAS records cost more than CNAME records?
The opposite — Route 53 doesn't charge for alias queries routed to a CloudFront distribution or other AWS resource, while a CNAME record is billed as a standard DNS query like any other record type.
Can I set a custom TTL on an ALIAS record?
No. An alias record doesn't expose a TTL field for you to set — it inherits the TTL of the resource it's pointing at, which for a CloudFront distribution means CloudFront's own TTL behavior applies rather than a value you configure in Route 53.
What's the Route 53 hosted zone ID I use for a CloudFront alias target?
It's always Z2FDTNDATAQYW2, regardless of which AWS region your distribution or your account is associated with. This value only goes in the AliasTarget.HostedZoneId field — the hosted zone ID for the record itself is still the ID of your own domain's hosted zone.
Should I set Evaluate Target Health to Yes for a CloudFront alias?
You can't — Route 53 doesn't allow Evaluate Target Health to be set to true when the alias target is a CloudFront distribution, so the setting has no meaningful use here regardless of preference.
Do I need both an A and an AAAA alias record for CloudFront?
Only if IPv6 is enabled on your distribution. Check that setting on the distribution's General tab; if it's on, you need a separate AAAA alias record in addition to the A record, or IPv6-preferring visitors won't be able to resolve your domain at all.
My domain isn't hosted on Route 53 — can I still point my apex to CloudFront?
The ALIAS mechanism this article describes doesn't exist outside Route 53, so it can't help you directly. Check whether your DNS provider has its own equivalent apex-forwarding feature, often called ANAME or CNAME flattening, or move your domain's DNS hosting to Route 53 to use this exact process.
Do I need www.example.com as well as example.com, or just one?
That's a product decision, not a technical requirement — CloudFront and Route 53 will happily serve just the apex, just www, or both with a redirect between them. If you want both to work, both need to be listed as alternate domain names on the distribution and both need their own Route 53 record, though www can legally use either a CNAME or an alias.
Why do I get a CNAMEAlreadyExists error when adding my domain to CloudFront?
This means your domain is already listed as an alternate domain name on a different CloudFront distribution — possibly one you forgot about, possibly one in a different AWS account entirely. Use the ListConflictingAliases CLI command to identify the conflicting distribution and account, then either move the alias yourself with AssociateAlias or contact AWS Support if it's a different account you don't control.
Can an ALIAS record point to a CNAME record in the same hosted zone?
No — Route 53's own documentation is explicit that creating a CNAME record for the zone apex isn't supported even through an alias record, because the alias record has to match the type of what it's pointing at, and routing an apex alias to a CNAME would recreate the exact conflict the alias mechanism exists to avoid.
Does the ACM certificate need to be in a specific region for CloudFront?
Yes, and this trips people up constantly because it's the one region choice on this checklist that has nothing to do with where the rest of your infrastructure lives. To use an ACM certificate to require HTTPS between viewers and CloudFront, it must be requested or imported in the US East (N. Virginia) Region — us-east-1 — no matter where your distribution's origin or your other AWS resources are located.
What happens if I delete my CloudFront distribution but the alias record still exists?
The alias record will stop resolving correctly, since it's pointing at a domain name that no longer belongs to an active distribution. Clean up the Route 53 record when you retire a distribution rather than leaving it dangling — an orphaned alias pointing at a deleted CloudFront domain is also a known pattern that's been exploited for subdomain takeover in other contexts, so it's worth treating as a real cleanup step, not just tidiness.
Can I use Route 53 alias records with a CloudFront distribution in a different AWS account?
Yes — the alias target just needs the distribution's domain name, which isn't account-restricted information. The console's built-in picker only lists distributions in your currently logged-in account, so for a cross-account setup you'll typically need to type or paste the target CloudFront domain name manually rather than selecting it from the dropdown.
Is an ALIAS record the same thing as an ANAME record from other DNS providers?
They solve the same underlying problem — getting apex-domain flexibility despite the CNAME restriction — but they aren't the same thing and aren't interchangeable. ALIAS is specific to Route 53's own resolution engine; ANAME (and similarly named features like CNAME flattening) are separate implementations built by other DNS providers, with their own behavior and their own documentation, none of which this article has researched, so don't assume Route 53's exact rules apply to another provider's version.
Jake got his apex record sorted that afternoon — the whole fix took about four minutes once he understood what he was actually clicking. He still tells the story to other small-business owners who ask him about their websites, usually with the filing-cabinet line, because it's the one part that actually stuck.
Revision note. Written September 2026. This will need a fresh look if AWS changes how cross-account alias moves or Evaluate Target Health work for CloudFront targets specifically. If you landed here at 11pm staring at an InvalidChangeBatch error with a launch waiting on it, you're not missing something obvious — this rule catches people at every experience level, and the fix really is as small as it looks once you see it.