Cloud strategy · 11 min read

Should your company use multi-cloud?

Multi-cloud can reduce a specific concentration risk or meet a real product requirement, but it also multiplies identity, networking, monitoring, security, cost, and skills complexity. It should solve a concrete business or technical problem—not merely sound resilient.

Making provider boundaries explicit

Two provider blocks show separate platforms, not an architecture or a resilience strategy. The surrounding design and operations work still matter.

# Separate provider configurations make the boundary explicit
provider "aws" { region = "ap-southeast-1" }
provider "azurerm" { features {} }

When multi-cloud can be justified

It can be appropriate for regulatory needs, acquisition realities, customer deployment requirements, specialised data or AI services, or a well-defined resilience strategy. The business reason should be specific enough to measure.

Even then, not every workload needs to run everywhere. A focused boundary can be more reliable than duplicating an entire platform.

The hidden operational cost

Each provider brings its own identity model, networking, quotas, security controls, billing, incident procedures, and service behaviours. The organisation must retain enough knowledge to operate all of them under pressure.

Terraform can give one language for configuration, but it does not make provider services identical. Application portability, data replication, monitoring, and recovery still need design and testing.

A more useful alternative

Many teams get the benefits they need from a strong single-cloud architecture: multiple regions where justified, tested backups, portable application components, and clear exit plans for critical services.

Start with the smallest strategy that addresses the real risk. Expand only when the operational investment has an owner and a measurable return.

Put it into practice

Write the exact risk multi-cloud would solve for a small web application. Then list the identity, data, monitoring, and recovery work it would add.

  1. Define the risk or requirement multi-cloud is meant to solve.
  2. Calculate the operational ownership needed for each platform.
  3. Choose deliberate integration boundaries.
  4. Test failover claims rather than assuming portability.