How to disassociate CloudFront distribution from alias sub-domain?


We have the following scenario:

  1. We are using S3 and CloudFront.
  2. An engineer has created an S3 bucket and CloudFront Distribution under their personal account.
  3. They then associated the CloudFront to a sub-domain owned by the company.
  4. The company owns the domain.
  5. They left the company.

This is obviously an unacceptable practice and is probably one of the reasons the engineer is no longer working for the company. Unfortunately, we now have to sort it out.

Now to the issue at hand.

We've created a new S3 bucket and CloudFront distribution. But as you'd expect, we are unable to associate the new distribution ID with the same sub-domain and are getting the following error:

CNAMEAlreadyExists: One of more of the CNAMEs you provided are already associated with a different resource

We have already tracked down the conflicting CF distribution id:

$ aws-vault exec corp-dev -- aws cloudfront list-conflicting-aliases --alias dev.local.domain --distribution-id XYZ
    "ConflictingAliasesList": {
        "MaxItems": 100,
        "Quantity": 1,
        "Items": [
                "Alias": "dev.local.domain",
                "DistributionId": "******ECHOHUO",
                "AccountId": "******000000"

However, it is not entirely clear how to disassociate the subdomain from that distribution ID. The company is owns the domain and Route53.

Do we need to involve AWS support for this or is there a non-obvious way to force the disassociation, so the subdomain(s) can be re-used again?

2 Answers
Accepted Answer

This is definitely a case where engaging the support team is the right answer. Because the resource is owned by another account there's nothing that you can (directly) do here.

profile pictureAWS
answered a year ago
profile picture
reviewed 2 months ago
  • We have reached out to suppor and it does indeed seem like the only viable option in our case. Thank you for your help!


One thing I can think of is that the subdomain definition in the domain's hosted zone is still pointing to the former employee's Route 53, where he set up a hosted zone to control the subdomain. If that is the case, you should create your own hosted zone for that subdomain and then change the NS records for the subdomain in the hosted zone of the domain to NS records define in the subdomain's hosted zone. Then you can add the Aliased A records to the subdomain's hosted zone. Something like this:

Current Company Hosted Zone ( NS - NS1, NS2, NS3

Current Ex-Employee's Hosted Zone: NS - NS1, NS2, NS3 A (alias) - Employee CloudFront Distribution

To fix this:

New Company Hosted Zone ( NS - NS4, NS5, NS6 A (alias) - Company CloudFront Distribution

Modified Company Hosted zone ( NS - NS4, NS5, NS6
profile pictureAWS
answered a year ago
  • The setup we found is close to what you have mentioned in your answer. We did remove all DNS records pointing to the hosted subzone and created a new hosted zone in the appropriate sub account. We also created a completely new bucket, Cloudfront distribution and a Route53 A Alias record to point towards the new distribution. Unfortunately, no matter what you point to -- it always opens the old Cloudfront distribution. We suspect it might be related to the TLS certificates which were probably also created under the personal account.

    Any other ideas we can try? You must own the domain name, or have authorization to use it, which you verify by adding an SSL/TLS certificate.

  • As a troubleshooting step, I would change the value of the subdomain to a known value, like Then run a 'dig' against the subdomain to verify that you truly have control of the subdomain. If it does not return, you know something is still not correct with the DNS setup. You can also do a 'dig NS subdomain' to verify that the NS records.

  • Though the TLS certificate won't affect the routing, I would create a new one on ACM and use that in your CloudFront distribution.

  • Yes, we have tried troubleshooting the hosted zone the same way you suggested. The DNS records are indeed updated properly and point to the IP we define (i.e.

    $ dig +noall +answer +multiline dev.local.domain A
    dev.local.domain.        30 IN A

    But the moment we change it back to an A Alias record pointing to the new distribution id we end up in the same situation as previously mentioned.

    Of course we are also assigning the newly generated ACM certificates as well. Any further ideas?

  • Thank you for your suggestions!

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions