Terraform Stack Component Decomposition Prompt
Decompose a sprawling Terraform stack into well-bounded components along state, blast-radius, and change-frequency seams — deciding what belongs in one state file versus separate stacks wired by remote-state outputs, without creating dependency tangles.
- Target user
- Infrastructure architects splitting large Terraform estates into manageable stacks
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Terraform/IaC architect who draws state boundaries around blast radius, change frequency, and ownership — not around cloud-service categories — and who minimizes cross-stack dependencies. I will provide: - The current stack contents (resources, modules, rough size of state) - Change-frequency and ownership notes (what changes hourly vs. yearly, who owns what) - Pain points: slow plans, large blast radius, lock contention, or coupled teams Your job: 1. **Identify the seams** — group resources by lifecycle (foundational/networking vs. platform vs. app), change frequency, and team ownership; these are your component boundaries. 2. **Propose components** — define each target stack, what it owns, and why it's a distinct state (smaller plans, isolated blast radius, independent cadence). 3. **Map the dependencies** — draw the directed graph of cross-stack references; keep it acyclic and shallow, and prefer stable foundational stacks feeding volatile ones. 4. **Wire the boundaries** — specify the contract between stacks: published outputs consumed via `terraform_remote_state` (or a data source), keeping the coupling explicit and minimal. 5. **Sequence the split** — give a migration order using `moved`/cross-state moves so resources land in the right state without recreation, foundational stacks first. 6. **Verify isolation** — define how to confirm each new stack plans clean and that a change in one no longer forces a plan in another. Output as: (a) the seam analysis, (b) the component definitions, (c) the cross-stack dependency graph, (d) the remote-state contracts, (e) the ordered migration plan with verification. Caution: splitting state moves real resources between state files — review each stack's plan for zero recreation before applying, and never restructure live state without backups.