DistributionAlreadyExists
AWS DistributionAlreadyExists means the CallerReference is already associated with another CloudFront distribution request (HTTP 409).
Last reviewed: March 2, 2026|Editorial standard: source-backed technical guidance
What Does Distribution Already Exists Mean?
CloudFront rejected the create request due to CallerReference idempotency collision, so new distribution creation cannot continue until caller-reference semantics are corrected.
Common Causes
- -CreateDistribution reuses an existing CallerReference already bound to another distribution request.
- -Retries replay the same create payload without checking previous distribution result.
- -Parallel deployment jobs generate duplicate caller references.
- -State drift loses created distribution ID and reissues create instead of update/adopt.
How to Fix Distribution Already Exists
- 1Treat CallerReference as idempotency key and reuse it only for true replay semantics.
- 2Lookup existing distribution associated with the caller reference before new create calls.
- 3Generate globally unique caller references for independent create operations.
- 4Switch duplicate create paths to update/adopt existing distribution state.
Step-by-Step Diagnosis for Distribution Already Exists
- 1Capture failing CallerReference and request ID from CloudFront response.
- 2List existing distributions and locate the distribution already bound to that CallerReference.
- 3Trace retries/parallel jobs that may be reusing the same caller reference.
- 4Decide whether workflow should adopt existing distribution instead of issuing a new create.
CallerReference Idempotency Validation
- -Trace caller-reference generation source for uniqueness guarantees (example: timestamp granularity collision across parallel jobs).
- -Map failing CallerReference to existing distribution and intent (example: retry path should adopt prior create result instead of issuing a new create).
Create Workflow Concurrency Controls
- -Audit deployment runners for duplicated create submissions (example: rollback + forward deploy both execute create with same caller reference).
- -Persist create-attempt ledger keyed by CallerReference (example: repeated API call should fetch existing distribution ID from ledger).
How to Verify the Fix
- -Repeat create workflow and confirm no CallerReference conflict is returned.
- -Verify each new create intent uses a unique caller reference.
- -Confirm idempotent retries now resolve to existing distribution instead of failing.
How to Prevent Recurrence
- -Generate globally unique CallerReference values for every new distribution intent.
- -Persist CallerReference-to-distribution mapping for safe idempotent retries.
- -Block parallel create jobs from sharing caller-reference generation state.
Pro Tip
- -store a durable CallerReference-to-distribution map so retries stay idempotent and never issue duplicate create intents.
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.