Taming a multi-cloud Terraform estate: modules, state, secrets and a paved road

The situation

A company had grown partly through acquisitions, and each acquired team had brought its own cloud and its own way of using Terraform. The result was infrastructure across AWS, Azure and GCP, described by hundreds of folders. Modules had been copied rather than shared, so fixes landed in one place and not the others. Some state files described entire environments, so a careless plan could touch hundreds of resources. Database passwords and keys sat in state, readable by anyone with access to the bucket.

Engineers had learned to avoid infrastructure changes. That was the real cost: features waited on a handful of people brave enough to run apply.

What had to be true

• Small, composable modules per cloud, versioned and shared, rather than copies.
• Small blast radius: no single plan able to damage unrelated systems.
• No plaintext secrets in state, and narrow access to state that remains.
• Every change through a pipeline, with plan review and policy checks; no laptop applies to production.
• Teams self-serve common infrastructure through a paved road, with the platform team owning the road, not every change.

Architecture

The data flow, end to end

The hard part: resisting the universal module

The first instinct was a set of cloud-agnostic modules: one "database" module that worked on all three clouds. It would have hidden the features that made each managed service worth using and created a large abstraction nobody could debug. HashiCorp's guidance favours composition instead: a root module assembling small building blocks and passing dependencies between them as inputs and outputs¹.

• Building blocks were provider-specific, thin and opinionated about security defaults.
• Shared interfaces covered what really is common: naming, tagging, ownership labels and output shapes.
• Templates composed blocks into patterns teams actually use, such as "service with database and queue".
• Each block had examples and tests, and was released with semantic versions.

Secrets were the other urgent fix. Terraform 1.10 introduced ephemeral values that are not persisted in plan or state, and 1.11 added write-only arguments on managed resources, so secrets can flow from a secrets manager into resources without landing in state²³. Every secret that had ever been in state was rotated as part of the move. The checklist is in keeping secrets out of Terraform state.

How it ran

Key decisions and trade-offs

The tooling question came up early. OpenTofu was forked from Terraform under the Linux Foundation after HashiCorp's 2023 licence change⁴. Rather than let that decision block the refactor, modules were kept compatible with both while legal and procurement reached a view; the trade-offs are in OpenTofu or Terraform in 2026.

What I'd do again, and differently

Again: put pipelines, policy and state boundaries in place before migrating anything, and rotate every secret that touched state. Differently: publish the module interface conventions (names, tags and outputs) in the first week. Teams started writing new stacks immediately, and every one written before the conventions existed needed rework. More on structure in Terraform module design for multi-cloud.

If your infrastructure code has become something people avoid touching, my fractional CTO work covers estates like this, or analyse your challenge and bring the result to a call.