CNAMEAlreadyExists
CloudFront returns `CNAMEAlreadyExists` when an alternate domain name is already attached to another distribution, so the alias cannot be assigned again. CloudFront returns HTTP 409 for this conflict.
Last reviewed: February 9, 2026|Editorial standard: source-backed technical guidance
What Does CNAME Already Exists Mean?
CloudFront rejected alias assignment because the CNAME is already attached to another distribution, so cutover cannot proceed until alias ownership is transferred safely.
Common Causes
- -Requested CNAME alias is already attached to another CloudFront distribution.
- -Cutover workflow attempts to assign alias before detaching it from current distribution.
- -Parallel deployment paths race to claim the same alias simultaneously.
- -DNS/distribution ownership inventory is stale during migration operations.
How to Fix CNAME Already Exists
- 1Identify where the alias is already configured in CloudFront before attempting another attach.
- 2Detach the alias from the current distribution, wait for deployment completion, then attach it to the target.
- 3For minimal-downtime transfers, use CloudFront alias-move workflows (
AssociateAliasorUpdateDomainAssociation) with explicit sequencing. - 4Validate certificate SAN coverage and DNS records for the target distribution after alias handoff.
Step-by-Step Diagnosis for CNAME Already Exists
- 1Capture failing alias and CloudFront request ID from API response.
- 2List distributions to locate current alias attachment owner.
- 3Trace deployment timeline to confirm detach and attach ordering.
- 4Verify no parallel automation is reattaching alias to old distribution.
Alias Ownership and Attachment Checks
- -Identify the current distribution owning the alias from CloudFront inventory (example: legacy distribution still holds
www.example.com). - -Validate target distribution certificate and alias readiness before transfer (example: ACM certificate on target does not include the alias SAN).
Alias Cutover Sequencing Controls
- -Sequence detach-and-attach with deployment wait states (example: attach attempted before source distribution finished alias-removal deployment).
- -Prevent concurrent alias mutation jobs (example: two pipelines race to claim the same CNAME in the same release window).
How to Verify the Fix
- -Repeat alias transfer and confirm CNAME attachment succeeds on target distribution.
- -Verify source distribution no longer lists the transferred alias.
- -Confirm DNS and certificate behavior is healthy after cutover.
How to Prevent Recurrence
- -Design alias migration flows with deterministic detach-then-attach sequencing.
- -Enforce single-writer ownership for alias mutations in automation.
- -Monitor alias conflict rates and track ownership inventory continuously.
Pro Tip
- -maintain a centralized alias registry with current distribution owner and planned cutover window so pipelines can preflight ownership conflicts before API calls.
Decision Support
Compare Guide
409 Conflict vs 412 Precondition Failed: When to Use Each
Choose 412 when If-Match or If-Unmodified-Since checks fail; choose 409 for state conflicts without failed precondition headers during concurrent updates.
Playbook
Conflict and Concurrency Playbook (409 / 412 / OptimisticLock)
Use this playbook to separate true write conflicts from stale precondition failures, then apply safe re-fetch, optimistic-lock, and retry choices.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.