🚨 AWS CDK Error Guide: 'There is already a Construct with name' — Fix Duplicate Construct IDs

Overview

Every construct in the AWS CDK is created with a scope and an ID, and that ID must be unique among its siblings under the same scope. When two constructs share a parent and an ID, synthesis throws before any CloudFormation is produced:

Error: There is already a Construct with name 'MyBucket' in MyStack [Stack]
    at Node.addChild (node_modules/constructs/lib/construct.js:...)

The construct tree cannot have two children with the same path segment under one parent, so cdk synth/cdk deploy stops immediately.

Symptoms

• cdk synth or cdk deploy fails with There is already a Construct with name '<id>' in <Scope>.
• The error names the duplicated ID and the scope (a Stack or a parent construct).
• It commonly appears after copy-pasting a resource block or introducing a loop that reuses a static ID.
• No CloudFormation template is emitted; the failure is in the constructs library, before synthesis completes.

Common Root Causes

• Copy-paste with the same ID — two new s3.Bucket(this, 'MyBucket', ...) calls under the same scope.
• Loop reusing a static ID — creating N resources in a for/map while passing the same literal ID each iteration.
• Two resources, one intended — a merge or refactor left a stale definition alongside the new one.
• Helper/factory called twice with the same ID argument.
• Nested construct collision — a custom construct hardcodes a child ID and is instantiated twice under the same parent.

Diagnostic Workflow

Reproduce and read the full construct path in the stack trace:

npx cdk synth 2>&1 | head -40

Search the app for every use of the duplicated ID:

grep -rn "'MyBucket'" lib/ bin/
grep -rnE "new [A-Za-z.]+\((this|scope), *'MyBucket'" lib/

Inspect the construct tree to see where IDs collide (after a successful synth of a sibling stack, or via the manifest):

npx cdk synth --json | jq '.. | .["aws:cdk:path"]? // empty' | sort | uniq -d

For loop-generated resources, print the IDs you are about to use to confirm they are unique:

node -e "['a','a','b'].forEach((x,i)=>console.log('Item'+x))"   # reveals 'Itema' twice

Example Root Cause Analysis

A stack created one bucket per environment name by iterating a list:

['data', 'data', 'logs'].forEach(name => {
  new s3.Bucket(this, `Bucket${name}`, {});
});

Synthesis failed with There is already a Construct with name 'Bucketdata' in MyStack. The input list contained a duplicate (data twice) from a config merge, and the ID was derived solely from name, so the second data produced the same construct ID Bucketdata under the same stack scope.

Two things were wrong: the source data had an accidental duplicate, and the ID scheme was not guaranteed unique. The fix deduplicated the input ([...new Set(names)]) and made the ID robust by incorporating the loop index (Bucket-${i}-${name}), so even legitimately repeated names would not collide. Synthesis then succeeded and produced distinct logical IDs per bucket.

Prevention Best Practices

• Give every sibling construct a unique, human-meaningful ID; do not copy-paste resource blocks without changing the ID.
• When creating constructs in a loop, derive the ID from a value guaranteed unique (index or a de-duplicated key), not a possibly-repeated name.
• De-duplicate input collections before iterating.
• Prefer scoping related resources under distinct parent constructs so ID uniqueness is easy to reason about.
• Run cdk synth in CI so collisions fail the pipeline, not a manual deploy.

Quick Command Reference

npx cdk synth                                          # reproduce the error
grep -rnE "new [A-Za-z.]+\((this|scope), *'ID'" lib/   # find duplicate ID usage
npx cdk synth --json | jq '.. | .["aws:cdk:path"]? // empty' | sort | uniq -d
cdk ls                                                 # list stacks in the app

Conclusion

There is already a Construct with name is a construct-tree uniqueness violation: two siblings share an ID under the same scope. Find both call sites, and either rename one or — for loop-generated resources — build IDs from a value that is guaranteed unique and de-duplicate your inputs. Enforcing cdk synth in CI turns this into a fast, local failure instead of a surprise mid-deploy.