For teams managing Terraform in production, how do you organize state within each environment? Do you keep networking, DNS, Kubernetes clusters, databases, and applications in one state, or separate them into independently managed layers such as dev/01-networking, dev/02-dns, dev/03-eks, and dev/04-database? I'm especially interested in how you balance modularity, ownership, state-lock contention, plan speed, and blast radius.
4 Answers
Separate states are especially helpful when different parts of the platform have different access requirements or execution environments. For example, foundational networking and secrets may be handled by one workflow, while private runners manage a Kubernetes cluster. Splitting those concerns can also make plans faster and reduce lock contention, but it adds dependency and coordination overhead.
I’d generally separate networking, clusters, and databases from frequently changing application resources. That reduces the blast radius of plans and keeps unrelated changes from competing over the same state lock. Just avoid splitting things so finely that every routine change requires coordinating several layers.
A useful rule is to group resources that are provisioned and removed together in the same state. If they have different lifecycles, owners, or failure domains, separating them usually makes more sense. There isn’t one universal layout, so keep the boundaries aligned with how the infrastructure is operated.
Organizing state by stack or application can work better than organizing strictly by resource category. For example, a landing zone can own shared foundation resources while separate application stacks manage their own services. The important parts are clear ownership, small and reviewable changes, and keeping dependencies between states manageable.
Exactly. The split should follow ownership and operational boundaries rather than simply numbering folders by resource type.