Struggling with a “CNAMEAlreadyExists” error after deleting a CloudFront distribution? This guide explains the frustrating root cause of this global DNS issue and provides three practical solutions, from quick CLI checks to the permanent infrastructure-as-code fix.

That “Global CloudFront Issue” Isn’t Global, It’s DNS. And It’s Personal.

I remember it vividly. It was 2 AM, and my phone was buzzing with a PagerDuty alert: “PROD – cdn.techresolve.io – Unreachable”. My heart sank. We had just done a blue-green deployment, which involved tearing down the old CloudFront distribution and spinning up a new one under the same CNAME. Everything had looked perfect in staging. But now, half our users were getting a nasty “404 Not Found” from a ghost distribution that didn’t even exist anymore. This wasn’t a global AWS outage; it was a self-inflicted wound, and it all came down to a fundamental misunderstanding of how CloudFront and DNS play together on a global scale.

So, What’s Actually Happening Under the Hood?

Let’s get one thing straight: when you delete a CloudFront distribution, it doesn’t just vanish from the internet instantly. Think of it like this: CloudFront has thousands of edge locations, and each one has its own set of DNS resolvers and caches. When you point your custom domain (e.g., assets.my-app.com) to a CloudFront endpoint (e.g., d123abc456def.cloudfront.net), DNS resolvers all over the world cache that connection.

The problem arises when you delete the CloudFront distribution in the AWS console or via your IaC tool like Terraform. You’ve told AWS it’s gone, but the world’s DNS resolvers haven’t gotten the memo yet. They’re still holding onto the old record, happily directing traffic to a black hole. When you try to immediately create a new distribution with the same custom domain, AWS’s control plane sees that the CNAME is still technically “in use” somewhere in its massive, distributed system. The result? The infamous CNAMEAlreadyExists error. It’s not a bug; it’s a race condition on a global scale.

The Fixes: From a Band-Aid to a Blueprint

Alright, you’re in the thick of it. Users are complaining, and your boss is asking for an ETA. Let’s walk through how to handle this, from the immediate triage to making sure it never happens again.

1. The Quick Fix: The CLI Sanity Check

First, don’t panic. Your immediate goal is to confirm what’s happening. Is the old distribution truly gone from AWS’s perspective? You can use the AWS CLI to check. If you try to get the details of the distribution you *think* you deleted, you should get a NoSuchDistribution error. That’s actually good news.

# Replace E123OLDDISTROID with the ID of the distribution you deleted
aws cloudfront get-distribution --id E123OLDDISTROID

If you get that error, it confirms AWS has processed the deletion. The issue is purely DNS propagation. You can use a tool like dig to query different public DNS servers and see the old record slowly disappear. At this point, the “fix” is often to wait. It can take minutes, or in worst-case scenarios, hours. It’s a terrible answer to give your manager, but it’s the reality.

Pro Tip: This is a “hacky” but sometimes effective trick. Try to create the new distribution but with a temporary, nonsensical CNAME like temp-assets.my-app.com. Once it’s fully deployed, go in and edit the CNAMEs to add the real one (assets.my-app.com). Sometimes this can bypass the initial validation check while the old DNS record is still dying out.

2. The Permanent Fix: The Two-Stage IaC Takedown

The best way to fix a problem is to prevent it. In your infrastructure-as-code (we use Terraform at TechResolve), you should never just run a terraform destroy on a stack with an active CloudFront distribution. You need to perform a two-stage takedown.

Stage 1: Disable the Distribution. First, modify your CloudFront resource to set enabled = false and apply the change. This tells CloudFront to begin the process of gracefully removing your configuration from all its edge locations. This is the crucial step everyone misses.

resource "aws_cloudfront_distribution" "prod_cdn" {
  # ... all your other settings: origin, viewer_certificate, etc.

  comment = "PROD CDN - Disabling before deletion"
  enabled = false # <-- THIS IS THE MAGIC KEY

  # ...
}

Stage 2: Wait, Then Destroy. After applying that change, wait. Give it a solid 15-20 minutes. Let the disabling propagate. Once you’ve given it time, you can safely run your terraform destroy command (or simply remove the resource from your code). The CNAME will have been disassociated cleanly, and you’ll be able to re-use it immediately without errors.

3. The ‘Nuclear’ Option: The AWS Support Ticket

Sometimes, things get really, really stuck. You’ve waited hours, you’ve confirmed the old distribution is gone, but AWS still gives you the CNAMEAlreadyExists error. This can happen if the CNAME gets “orphaned” in some internal AWS DNS layer. You cannot fix this yourself.

This is when you have to bite the bullet and contact AWS Support. It’s not glamorous, but it’s your only path forward.

Create a “Technical Support” ticket with the following information:

• Service: CloudFront
• Category: General Guidance and troubleshooting
• Subject: Urgent – Unable to reuse CNAME – CNAMEAlreadyExists
• Body: Clearly state the CNAME you are trying to use (e.g., assets.my-app.com) and confirm the ID of the old distribution that used it. Explain that you have already deleted the old distribution and waited for propagation, but the CNAME appears to be stuck.

A Hard Truth: This is where having a Business or Enterprise support plan pays for itself ten times over. If you’re on the Basic plan, you could be waiting a long time for a resolution. Don’t let a production-down CNAME issue be the reason you finally decide to upgrade your support plan.

Ultimately, this issue is a rite of passage for any cloud engineer. It’s a painful lesson in how distributed systems work. But by understanding the “why” and adopting a disciplined, two-stage approach to your infrastructure changes, you can turn a frantic 2 AM fire drill into a boring, predictable deployment. And boring is what we aim for in production.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions