10

I am trying to host a websit with only static pages on BitBucket.com using its Add-On Aerobatic. While registering the domain on Aerobatic, its giving me the following error:

CNAME already registered with CloudFront
AWS is reporting that this domain is already registered with a different CloudFront distribution. In order to complete the registration process, you'll first need to disable that distribution.

I never registered the domain with AWS CloudFront and hence can't figure out what is going on.

Any clue to this problem would be greatly appreciated.

Thanks,
Sourin

Sourin K Sen
  • 137
  • 1
  • 7
  • Is it a new domain name? It could be that it was previously registered or the Engineer before you had registered the domain (with CloudFront) if it's a company domain name. It's on you to do some diggin' up unfortunately :-) –  Jan 09 '17 at 11:20
  • It's a brand new domain that I recently purchased from GoDaddy.com myself. I have all the rights for the domain and have even made the whois info private. Still, somehow the CloudFront says that it already has a distribution associated with it. – Sourin K Sen Jan 09 '17 at 12:39
  • @SourinKSen I am currently having the exactly same issue. I'm wondering if you have sorted it out? – olo Jan 12 '17 at 02:21

3 Answers3

13

This issue can have several possible causes.

CloudFront treats alternate domain names (which they also call "CNAMEs" even though this doesn't imply that actual CNAME records necessarily exist in DNS) as a single global namespace.

No two CloudFront distributions can have the same alternate domain name, whether in the same AWS account or in different accounts.

Additionally, no two CloudFront distributions can have ambiguous alternate domain names, unless they are owned by the same AWS account. An example of ambiguous names would be *.example.com and www.example.com. This is ambiguous because *.example.com also matches www.example.com. This configuration is accepted and works correctly, but only if both distributions are in the same account.

Additionally, API Gateway edge-optimized APIs use the CloudFront network, so their custom hostnames are part of the globally-unique CloudFront namespace mentioned above, with the additional caveat that ambiguous mappings are not supported when API Gateway edge optimization is used.

Not all of the possible conditions here are directly applicable to the exact circumstances in the question above, but here is a list of some possibilities to consider:

  • another AWS customer who formerly owned the domain still has a CloudFront distribution configured with this hostname, or
  • there may be someone who has configured it on one of their CloudFront distributions by mistake, such as mistakenly creating an alternate domain name value of example.com (your domain) when the intended value should have been example.org (their domain), or
  • you created an API Gateway edge-optimized deployment using this domain. This is not applicable to regional deployments, only edge-optimized.

If you're certain that none of the above conditions are applicable in such a way that you can fix this yourself (i.e. it's not already configured in one of your CloudFront distributions in any of your AWS accounts or in API Gateway) then see How do I resolve the error CNAMEAlreadyExists when setting up a CNAME alias for my Amazon CloudFront distribution? in the AWS Support Knowledge Base for the process to get CloudFront to unlock the domain, using a special TXT record in DNS, followed by an AWS support request.

If you don't have a paid technical support plan, this should also be possible by submitting an account support request, since you are asking them to fix the setup of your account, not fix or troubleshoot your systems or code, etc.

C-Otto
  • 5,615
  • 3
  • 29
  • 62
Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427
  • I am having the same issue, but I wonder if someone is able to bind a certain domain without verifying from Cloudfront end? Thanks – olo Jan 14 '17 at 08:38
  • 1
    @olo it's unclear what you're asking. There is no initial verification process. You can bind any domain you want, but if it isn't your domain, you won't have control of the DNS, so you'll have no way to send traffic to CloudFront. This issue comes up if someone else has already associated your domain with a CloudFront distribution, since there can only be a 1:1 mapping. – Michael - sqlbot Jan 14 '17 at 15:05
  • I confirm that you DO NOT have to have a paid technical account. I did though have to refer my AWS person to this stackoverflow question for their clarification. – andyw May 24 '18 at 09:13
  • I wonder what is the rationale behind that, I don't see why preventing two or more distributions to handle the same alternate domain name. Say I have a domain "app.example.com", I want it to route to Distribution A (origin ELB in region A), with a healthcheck for ELB and failover to Distribution B (origin ELB in region B). Normally you could just use origin groups, but if the app requires POST requests then you can't use it. – Alisson Reinaldo Silva Jul 30 '23 at 11:04
  • @AlissonReinaldoSilva the rationale is straightforward -- If this were allowed, CloudFront would not have a way of knowing which distribution should handle the traffic when it arrived. A CloudFront distribution does not have any dedicated hardware or IP addresses so each hostname is one distro. To do what you are describing, you use Route 53 to handle the origin domain name *behind* CloudFront and let Route 53, based on health checks, return the desired IP for the target origin each time CloudFront resolves the origin domain name. The TTL of the backend DNS record is honored by CloudFront. – Michael - sqlbot Jul 31 '23 at 18:02
  • 1
    @Michael-sqlbot that's the solution I found in an AWS blog post, it worked well. So instead of having two separate distributions handling the same origin to different ELBs, I have one CloudFront use a Route53 domain as origin (e.g. cdn.global.example.com), and have Route53 with two failover records with HealthChecks pointing towards the two ELBs (in different regions). Thanks for sharing this. – Alisson Reinaldo Silva Jul 31 '23 at 22:46
1

I had the same problem when creating a distribution from scratch with an alternate domain name from the beginning.

Nothing of what Michael described helped in my case.

What helped is to:

  1. Create a distribution without an alternate domain name
  2. Create Route53 alias record to the distribution
  3. Set the alternate domain name in distribution back
Vlad Holubiev
  • 4,876
  • 7
  • 44
  • 59
0

I had the same problem and resolved it by:

  1. Deleting the DNS CNAME
  2. Updating the alternative domain to my subdomain app.example.com
  3. Add CNAME again with the new cloudfront endpoint: enter image description here
Lucia Clifford
  • 136
  • 1
  • 6