Logical-ID Permanence When Extending

The framework goes to great lengths to keep its own CloudFormation logical IDs frozen (see Logical-ID Permanence). When you extend Axis, that discipline becomes yours — CloudFormation replaces, not renames, a resource whose logical ID changes, and for stateful resources that means data loss.

The rule

The second argument to new Construct(this, "THIS_ID") can never change after you’ve deployed it. Renaming it in production destroys the stateful resource and recreates an empty one.

Where this bites in your code

• Your own constructs — declare logical IDs as named constants, not inline string literals, so a rename is a visible, reviewable change.
• AtfDynamo tables — the table’s constructId is its logical ID (user-controlled by design). Renaming a table’s constructId replaces the table. See DynamoDB Tables.
• Custom stacks — the same rule applies to every construct in a sibling stack you add.

How the framework enforces its own

Axis IDs are single-sourced in construct-ids.ts and gated by check-construct-ids.js plus snapshot tests on every PR. You can borrow the same discipline in your project: keep IDs in one place, and treat a snapshot diff as the question “did I mean to change deployed infrastructure?”

Where to go next

• Logical-ID Permanence for the framework-side mechanism.
• Add Your Own Stack for where your IDs live.