CloudFormation stacks/exports are account-blind — is that intentional long-term, or worth per-account scoping?

[sam-fakhreddine]

@pgermosen — tagging you since this is a design-conversation question about CFN architecture, not urgent, no rush.

Found while triaging an old internal fork branch that predates the current main — a local branch had implemented account-scoped stacks/exports, and I wanted to check whether the gap it closes is still worth a real design conversation, rather than just quietly discard the idea.

Current design (confirmed in code)

CloudFormationService.java:75 states it plainly: CloudFormation storage is account-blind, keyed by stack name + region under one fixed namespace, not per-account.

The gap

Two concrete cases where that can bite an org-wide multi-account setup:

1. Same stack name across accounts. A CDK bootstrap stack (or any stack name a deployment tool reuses per-account, e.g. CDKToolkit) collides in the shared namespace if two accounts both provision it — last write wins, or whichever account "gets there first" silently owns the record other accounts think they're managing independently.
2. Fn::ImportValue isn't per-account either. An export from account A's stack is visible (or shadows/collides with) an identically-named export from account B, when real CloudFormation exports are account+region scoped.

Neither is hypothetical — they show up in real multi-account CDK/Organizations-style deployments where the same stack name is reused deliberately per-account.

Not proposing a specific implementation

I don't want to presume the fix — just flagging that this seems like a real fidelity gap against how real AWS CloudFormation actually scopes stacks and exports (per-account, per-region), and asking whether it's worth tracking as a real issue/roadmap item, or whether there's a reason the current account-blind model is intentional beyond simplicity (e.g. a storage-migration cost that isn't worth it yet).

Happy to help investigate further or take a pass at an implementation if there's appetite for it — wanted to raise it as a discussion first rather than show up with an uninvited PR reversing an explicit design choice.

[sam-fakhreddine]

Thought about this more and want to propose something more concrete: an opt-in flag, off by default, rather than asking to flip the current behavior for everyone.

Proposal

A config flag — something like floci.services.cloudformation.account-scoped-stacks (env FLOCI_SERVICES_CLOUDFORMATION_ACCOUNT_SCOPED_STACKS), defaulting to false.

• Off (default, current behavior unchanged): stacks/exports stay keyed the way they are today — one fixed namespace, account-blind. Zero behavior change for anyone not opting in.
• On: stack storage keys on (accountId, stackName, region) instead of just (stackName, region), and Fn::ImportValue only resolves exports from stacks in the same account — matching real CloudFormation's actual per-account/per-region export scoping.

This sidesteps the "is account-blind intentional" question entirely — it can stay the default, and anyone who's hit the same-stack-name-across-accounts or cross-account-ImportValue-collision issue (org-wide CDK bootstrap being the common trigger) can turn it on.

Worth noting: the storage-layer primitives for this already exist elsewhere in the codebase (account-scoped get/put helpers, a full-scan-across-accounts helper) — CloudFormation's storage would just need wiring to the existing account-aware path behind the flag, not a new storage layer from scratch. So the implementation cost looks smaller than "add per-account CFN storage from zero."

Happy to take a pass at this if it sounds like the right shape — wanted to check the flag-based framing lands better than my first pass before writing code.

[hectorvent]

Thanks for raising this so carefully, @sam-fakhreddine, and sorry it sat without an answer. It turned out to be worth doing, and it has landed: #3185 scopes CloudFormation stacks and exports by account and region, and it shipped in 2.1.0. It is the default behaviour rather than a flag, since it is what real CloudFormation does. The same stack name (a CDKToolkit bootstrap in each account, say) no longer collides, ListStacks and ListExports only show the caller's account, and Fn::ImportValue resolves only exports from the stack's own account and region. Stacks persisted before the change are attributed to the default account on load.

If you get a chance to try your multi-account CDK setup on 2.1.0, a confirmation would be great, and I'll mark this answered. One thing still open if you want it: an integration test that drives Fn::ImportValue across two accounts end to end.