CloudFront CNAMEAlreadyExists: "One or More of the CNAMEs You Provided Are Already Associated With a Different Resource", Find the Owner and Move the Domain (Same Account, Cross-Account, Zero-Downtime Wildcard, Amplify, Terraform)

"One or more of the CNAMEs you provided are already associated with a different resource" (error code CNAMEAlreadyExists, HTTP 409) means the domain you are adding to a CloudFront distribution, such as www.example.com, is already listed as an alternate domain name on another distribution somewhere in CloudFront. That other distribution might be in your account, in a second account your company owns, in a deleted Amplify app, in an old hosting provider's account, or a duplicate your own Terraform created after its state file went missing. CloudFront allows each exact domain name on only one distribution worldwide, even when both distributions belong to you. The fix is to find the other distribution with aws cloudfront list-domain-conflicts, then move the name with aws cloudfront update-domain-association, which does it in one step without downtime when both are in the same account. The surprise that explains the cross-account cases: your DNS record does not decide which distribution answers. CloudFront routes a request by the name in it to whichever distribution holds that name, regardless of where your CNAME record points, which is why pointing DNS at the new distribution changes nothing until the name itself moves. This page covers finding the owner, the four ways to move the name (same account, other account, wildcard, AWS Support), the zero-downtime wildcard method, and the special cases: Amplify, Terraform, deleted distributions and apex domains.

Jake's repair shop moved its website to a new AWS account this month, on Ethan's advice: one account for the shop's site, one for experiments, so a test can never take the shop offline. Ethan built the new CloudFront distribution, added a certificate for www.jakesrepairs.example, typed the domain into the alternate domain name field, and got a red banner and a 409. Jake, reading the screen, asked the obvious question: "It's our domain. Who else can have it?" The answer was the old distribution in the old account, still running, still holding the name. This page is how Ethan moved it without taking the shop offline for a minute.

New to CloudFront and custom domains? Our step-by-step guide to putting your own domain on CloudFront with HTTPS covers certificates, alternate domain names and DNS from zero. You can follow this page without it.

What CNAMEAlreadyExists means: one name, one distribution

A CloudFront distribution answers on its own address, something like d111111abcdef8.cloudfront.net. To serve your site on www.example.com, you add that name to the distribution as an alternate domain name (CloudFront also calls it a CNAME or an alias), attach a certificate that covers it, and point your DNS at the distribution. Our plain-English CloudFront guide explains distributions if the word is new.

CloudFront is one global service shared by every AWS customer, and it has to know, for every request that arrives at an edge location, which distribution owns the name in it. So it enforces one rule without exceptions: an exact alternate domain name can be on only one distribution at a time. AWS's restriction reads that you cannot add a name that already exists in another distribution "even if your AWS account owns the other distribution." When you try, the console, the CLI, CloudFormation, Terraform or Amplify all relay the same refusal:

One or more of the CNAMEs you provided are already associated with a different resource.
(Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists)

Three details about the rule matter for the fix:

• Exact names collide; a wildcard can overlap. *.example.com can sit on one distribution while www.example.com sits on another. That overlap is what makes the zero-downtime move possible.
• Names are lowercase. CloudFront requires every alternate domain name in lowercase. WWW.Example.com is not a different name to dodge the rule; it is an invalid one.
• The certificate is the proof. To add a name, the distribution must have a trusted certificate whose subject alternative names cover it. That is how CloudFront knows you control the domain, and it is also the key to finding the other distribution.

Jake: "So it's like a shop sign. Only one shop on the street can hang 'Jake's Repairs.'"

Ethan: "Right, and our old shop is still open with the sign up. We have to take it down there before we can hang it here, or swap it in one move."

Who usually holds the name

Find the distribution that holds the name

Looking through your distributions in the console finds the same-account case. For everything else you need CloudFront to tell you, and it will, but only after you prove you control the domain. The proof is a distribution in your account with a certificate covering the name, so set that up first:

1. Request a certificate in us-east-1. CloudFront only uses certificates from AWS Certificate Manager in US East (N. Virginia), whatever Region the rest of your work is in. It must cover the exact name (www.example.com) or a wildcard at that level (*.example.com). If validation stalls, our ACM pending-validation guide covers the DNS record it needs.
2. Attach it to your new (target) distribution without adding the alternate domain name yet. A distribution can hold one certificate at a time.
3. Ask CloudFront who holds the name. Run this with credentials from the target distribution's account:

aws cloudfront list-domain-conflicts \
  --domain www.example.com \
  --domain-control-validation-resource DistributionId=E2TARGET1234567

The response lists every conflicting or overlapping name, the kind of resource holding it, and the resource and account IDs, partly masked:

{
  "DomainConflicts": [
    {
      "Domain": "www.example.com",
      "ResourceType": "distribution",
      "ResourceId": "***********OLD12345",
      "AccountId": "******112233"
    }
  ]
}

The masking is deliberate: you see enough to recognize a distribution and account that are yours (match the last digits against your accounts), and nothing that identifies someone else's. If the account digits match one of yours, you know where to go. If they match none, the name is on an account you do not control, which is the Support route. The command needs cloudfront:GetDistribution and cloudfront:ListDomainConflicts permissions; for SaaS Manager setups, pass DistributionTenantId= instead.

You may still find older guides using aws cloudfront list-conflicting-aliases --distribution-id E2TARGET1234567 --alias www.example.com. It works for standard distributions only; list-domain-conflicts is the current command and covers distribution tenants too. If it returns nothing but the add still fails, the conflict is usually an overlapping wildcard in another account or a distribution still finishing a delete; ask it about the wildcard as well (--domain "*.example.com").

Same account: move the name in one command

When the old and new distributions are in the same account, the move is a single call. It removes the name from the source and adds it to the target in one operation, so there is no gap where neither distribution answers, and it works for the apex domain (example.com) too:

aws cloudfront get-distribution --id E2TARGET1234567 --query ETag --output text

aws cloudfront update-domain-association \
  --domain www.example.com \
  --target-resource DistributionId=E2TARGET1234567 \
  --if-match E3UN6WX5ABC123

The --if-match value is the target distribution's current ETag from the first command; CloudFront uses it to refuse the change if someone else edited the distribution in between. The caller needs cloudfront:UpdateDomainAssociation and cloudfront:UpdateDistribution on the target. The response echoes the domain and the target's ID. Then:

1. Point DNS at the target. Update the CNAME (or the Route 53 alias record, for an apex) to the target's .cloudfront.net address. Traffic already reaches the target through CloudFront's own routing; this keeps the record honest for the day the old distribution is deleted. Our alias vs CNAME guide explains which record type to use where.
2. Wait for the target to deploy (Status Deployed), then test: curl -sI https://www.example.com and look for headers or content that only the new distribution returns.
3. Retire the old distribution when you are sure: disable, wait for it to deploy, delete.

The older command aws cloudfront associate-alias --target-distribution-id E2TARGET1234567 --alias www.example.com does the same job for standard distributions only. Either is fine; update-domain-association is the one to learn.

Why changing DNS does not move the traffic

This is the part that confuses nearly everyone moving a site between distributions, and it explains several of the "I did everything and it still serves the old site" reports. When a request arrives at a CloudFront edge location, CloudFront decides which distribution handles it by looking at the domain name in the request (the Host header and the TLS server name) and finding the distribution that holds that name. Your DNS record only decides that the request reaches CloudFront at all; every .cloudfront.net address lands on the same global edge network.

AWS's own rule for overlapping names states it plainly: CloudFront sends the request to the distribution with the more specific name match, "regardless of the distribution that the DNS record points to." So if the old distribution holds www.example.com and your DNS now points at the new one, the old one still answers. And if the new one holds *.example.com while the old one still holds www.example.com, the old one still answers, because the exact name is more specific than the wildcard. The traffic moves at the moment the name moves, not the moment DNS changes.

That is bad news if you expected a DNS change to be your switch, and very good news for a zero-downtime move: it means you can prepare the new distribution completely, point DNS at it, and flip the traffic with one change to the alternate domain names, without waiting for DNS caches to expire.

Jake: "So the street sign doesn't matter, the shop sign does?"

Ethan: "Exactly. CloudFront is one giant mall. The directory sends everyone to the mall; inside, whoever has our name on the door gets the customer."

Different accounts: verify with a TXT record, then move

Moving a name between accounts adds one safeguard: you prove you control the domain's DNS, so nobody can pull a name out of your account just by holding a certificate. The proof is a TXT record whose value is the target distribution's .cloudfront.net address:

; a subdomain: underscore + the name
_www.example.com.   300  IN  TXT  "d222222target.cloudfront.net"

; the apex: underscore + dot + the name
_.example.com.      300  IN  TXT  "d222222target.cloudfront.net"

; a wildcard
_*.example.com.     300  IN  TXT  "d222222target.cloudfront.net"

Check it is visible before you go on: dig +short TXT _www.example.com should print the target's address. Then you have three ways to finish, depending on what you can touch:

For the disable route: disabling is not instant (wait for the source's status to show Deployed again), and the move call is the same update-domain-association as above, run in the target account. Across accounts, the source must be disabled before the move call will succeed. Know what disabling costs before you click: a disabled distribution stops accepting traffic for its names, even if another distribution has a wildcard that would match them. Your site is down from the moment the disable deploys until the move deploys, which is why the wildcard method exists.

The zero-downtime wildcard method

This uses the overlap rule from the DNS section: the exact name on the old distribution wins until it is removed, at which point the wildcard on the new distribution catches the traffic instantly. Wait for each distribution to finish deploying before the next step.

1. Add *.example.com to the target distribution. Its certificate must cover the wildcard. The old distribution keeps serving www.example.com, because the exact name is more specific.
2. Point DNS at the target. Change the www CNAME to the target's .cloudfront.net address. Nothing changes for visitors yet; the old distribution still holds the exact name.
3. Remove www.example.com from the old distribution. As this deploys, requests for www match only the wildcard, so the new distribution serves them, with no gap.
4. Add www.example.com to the target, so it holds the exact name and not just the wildcard. Remove the wildcard later if you do not need it.
5. Check: dig +short CNAME www.example.com shows the target's address, and the site serves the new distribution's content.

Two limits. It does not work for the apex (example.com), because a wildcard never covers the bare domain. And it needs you to be able to edit the old distribution, at least to remove one name. If another account already holds a wildcard that overlaps, adding yours fails too; list-domain-conflicts with the wildcard as the domain shows it.

That is how Jake's shop moved: wildcard on the new distribution, DNS repointed in the afternoon, the exact name removed from the old one in the evening, and the order page never went down.

Amplify: CNAMEAlreadyExistsException

Amplify Hosting runs its own CloudFront distributions, so connecting a custom domain to an Amplify app goes through the same rule, and the error arrives as CNAMEAlreadyExistsException. Amplify's own checklist, in order:

• A CloudFront distribution of yours holds the name (same or another account). Remove the name from its alternate domain names, or move it as above.
• Another Amplify app uses the same hostname. Each hostname can be on one app; use a different subdomain for the second app, or disconnect the domain from the first.
• The domain was on an app you deleted in the last hour. Wait at least an hour and try again; if it still fails after six hours, Amplify's guidance is to contact Support.
• Old Route 53 records pointing at the previous distribution should be cleaned up, then remove the custom domain from the Amplify app and connect it again from the start.

Moving a site from Amplify to your own CloudFront distribution (or the reverse) is a cross-account move in practice, because Amplify's distributions are not ones you can edit directly. Disconnect the domain in Amplify first, then add it to the new home. If the new Amplify site then serves 404s on deep links, that is a separate rewrite-rule issue covered in our Amplify 404 guide.

Terraform, CloudFormation and CDK: a duplicate you created

A very common source of the error is your own infrastructure code creating a second distribution with the same name while the first still exists. The classic case: Terraform's state was lost or not migrated (a backend switched from local to S3 without copying the state), so the next terraform apply believes no distribution exists and tries to create one, with the same aliases, and CloudFront refuses.

• Do not delete the live distribution to make the apply pass. Bring the existing one back under management instead: terraform import aws_cloudfront_distribution.site E1EXISTING12345 (or an import block in Terraform 1.5 and later), then plan again. The plan should show changes, not a create.
• Replacements: a change that forces Terraform to replace a distribution with create_before_destroy builds the new one first, with the same names, and fails. Either remove the alias in one apply and add it to the new resource in a second, or do the replacement without create_before_destroy and accept the gap.
• CloudFormation and CDK: a replacement of an AWS::CloudFront::Distribution follows the same create-then-delete order and hits the same wall. Deploying the same stack under a new name (a second environment that copied the real domain into its config) is the other usual cause; give non-production stacks their own subdomains.

If the state problem is a lock rather than a missing file, our guide to Terraform's "Error acquiring the state lock" covers that side.

"I deleted the old distribution and it still says the name exists"

A distribution holds its names until it is fully deleted, and deleting takes more steps than it looks:

1. Disable it and wait until it finishes deploying; the Last modified time updates when it is done.
2. Delete it. Only a disabled, deployed distribution can be deleted. If it is subscribed to a CloudFront flat-rate pricing plan, the delete is refused until you cancel the plan and the current billing cycle ends.
3. Multi-tenant (SaaS Manager) distributions need their distribution tenants deleted first; a tenant can hold the domain even when the parent looks idle.

If all of that is done and the add still fails, run list-domain-conflicts again: the holder is often a second distribution you forgot, or one in another account, or a wildcard. For Amplify-deleted apps, the one-hour wait above applies.

Apex domains (example.com), and when to contact AWS Support

The bare domain is the hardest case. A wildcard never covers it, so the zero-downtime wildcard method cannot move it between accounts, and the TXT record for it takes the form _.example.com. Within one account, update-domain-association moves an apex like any other name. Across accounts, you either disable the source and move it (with the downtime that implies) or ask AWS Support.

Support is also the route when the name sits on an account you cannot reach: a previous hosting provider, an agency that built the site, a closed account. What helps the case: the TXT record already published with your target distribution's address (proof you control DNS), the target distribution already set up with a certificate covering the name, and the output of list-domain-conflicts showing the conflict. Without access to the other account, there is no self-service way to remove a name from it, and that is by design: it is the same protection that stops anyone from taking yours.

The ten-minute fix order

1. Request (or reuse) a us-east-1 ACM certificate that covers the name, and attach it to the new distribution.
2. Run list-domain-conflicts from the new distribution's account to find the holder and its account.
3. Same account: update-domain-association, then repoint DNS and retire the old distribution.
4. Different account, subdomain: publish the _name TXT record and use the wildcard method for zero downtime.
5. Different account, apex or no access: TXT record, then disable-and-move or AWS Support.
6. Tooling duplicate: import the existing distribution into Terraform or the stack instead of creating a new one.

Fixes by symptom

Frequently asked questions about CloudFront CNAMEAlreadyExists

By the end of the day, Jake's shop was answering from the new account, the old distribution was disabled, and nobody who placed an order that afternoon noticed anything. Jake asked why the error had been so unhelpful. "It wasn't," said Ethan. "It told us the truth in one sentence: someone already has the sign. We just had to find out the someone was us."

Revision note. Written October 16, 2026, with every command checked against the current AWS CLI. "Possession is nine-tenths of the law," the old saying goes; in CloudFront, it is all ten.