Terraform Best Practices for Multi-Cloud Infrastructure

Terraform best practices for multi-cloud infrastructure come down to three things: layered modules, small state files, and CI guardrails that catch cost before it reaches the bill. This guide covers the patterns that let a small platform team manage 1,400+ resources across AWS, Azure and GCP without the tooling becoming the bottleneck.

Most organisations do not choose multi-cloud. They acquire it — an ML team that wanted GPUs somewhere specific, a customer contract with a residency clause, a service that only one provider offers well. What arrives is not a strategy but sprawl, and Terraform becomes the control plane that makes it manageable.

Module Design: Three Layers

Flat module structures collapse as soon as more than a handful of people touch them. A three-tier layout scales:

The discipline that makes this work is versioning. Modules live in a private registry with semantic versions, and environments pin explicit versions. Without that, a change to a primitive quietly propagates into production the next time anyone runs apply.

State Management

State is where multi-cloud Terraform goes wrong first. A single large state file means every plan reads everything, every apply locks everything, and one corrupted state takes the whole estate with it.

Splitting into roughly 60 independent state files — one per deployment unit — changed the operating characteristics completely. Plans dropped from nine minutes to under 40 seconds, because each one reads only its own slice. Each state lives in its own cloud's native storage (S3 with DynamoDB locking, Azure Blob, GCS), which keeps credentials and blast radius aligned with the provider they manage.

CI/CD: The Guardrails

Local applies are banned. Everything runs through GitHub Actions with three properties that matter:

FinOps: Costs Visible Before the Bill

The change with the clearest return was running Infracost in CI so every pull request shows its monthly cost delta, paired with variable validation rules that block expensive resource classes without explicit approval.

A cost audit found $14,000 a month in GPU instances that had been provisioned for an experiment and never removed. The validation rules that followed — requiring sign-off before any GPU instance type can be declared — saved over $40,000 in the first quarter. Neither of those numbers came from optimisation. They came from making spend visible at the moment someone proposes it.

Cross-Cloud Networking

Lessons After 18 Months

This is the genuinely hard part, and no tool makes it pleasant. A hub-and-spoke VPN topology across AWS, Azure and GCP, with shared secrets held in HashiCorp Vault rather than in any single provider's secret store, was the arrangement that stayed comprehensible.

Expect this layer to need more care than everything else combined. Routing, MTU and asymmetric failure modes across three providers do not have a clean abstraction.

Eight platform engineers now manage the full estate. That ratio is only possible because the boring parts — state layout, module versions, CI guardrails — were settled before the resource count grew.

We build and operate multi-cloud infrastructure with these patterns in place. Explore our cloud and DevOps services or get in touch.