Multi-cloud - strategy, management, and costs

Before we get into the detail - a key distinction. The industry uses these terms interchangeably, but they mean different things:

Multi-cloud ≠ hybrid ≠ multi-region. Each carries different operational complexity and different costs.

When multi-cloud makes business sense - 4 scenarios

1. Best-of-breed: the best service from each provider

The most common scenario. An ML team chooses BigQuery + Vertex AI (GCP) for analytics while the rest of the infrastructure runs on AWS (EKS, RDS, Lambda). Or the data team uses Snowflake (hosted on Azure) while the production application sits on AWS.

When it works: Services are loosely coupled (data flows in one direction - batch or streaming) and the team has competence in both ecosystems.

When it doesn’t: Services require real-time communication with low latency between providers. Data transfer between clouds costs $0.08-0.12/GB - at 10 TB/month that’s $800-1,200 in egress alone.

2. Regulation and data residency

European regulations (DORA, NIS2) may require financial data to reside in the EU while simultaneously requiring geographically separated DR (Disaster Recovery). Solution: production data on AWS eu-central-1 (Frankfurt), DR on Azure West Europe (Amsterdam) or GCP europe-west4 (Netherlands).

Another variant: a defence-sector client requires provider separation for different data classifications.

When it works: Regulations explicitly require provider separation or physical infrastructure separation.

When it doesn’t: Most regulations (ISO 27001, SOC 2, PCI DSS) do not require multiple providers. Multi-region with a single provider usually suffices. Don’t build multi-cloud “because compliance” without legal confirmation.

3. M&A - mergers and acquisitions

Company A runs on AWS. It acquires Company B, which runs on GCP. Migration from GCP to AWS would take 12-18 months and cost hundreds of thousands. For that period (and often permanently) you maintain both environments.

When it works: Always - this isn’t a choice, it’s a fact. The question is: how quickly do you consolidate vs. how long do you maintain both.

When it doesn’t: N/A - this isn’t an architectural decision, it’s a business situation.

4. Strategic avoidance of vendor lock-in

An orchestration layer (Kubernetes) + IaC layer (Terraform) create an abstraction layer that enables moving workload between providers in weeks, not months.

When it works: Organisations of 500+ employees with a mature platform engineering team that negotiate large contracts with providers and need real negotiating leverage (“we can leave”).

When it doesn’t: Small and medium businesses where the cost of maintaining an abstraction layer exceeds negotiation savings. Terraform + Kubernetes don’t automatically mean portability - an application using DynamoDB, SQS, and Cognito won’t move to GCP without rewriting parts of the application.

When multi-cloud does NOT make sense

I’ll be direct: in 60-70% of cases we see in consulting engagements, multi-cloud is complexity without proportional business value. Here are the three most common anti-patterns:

Anti-pattern 1: “Multi-cloud for resilience”

Myth: “if AWS goes down, we have GCP as backup”. Reality: full multi-cloud DR requires:

• Real-time data replication ($$$)
• Two sets of CI/CD pipelines
• Two IAM, networking, and monitoring configurations
• Regular failover testing

Cost: 1.8-2.5x the operational budget. For comparison, multi-region DR with a single provider costs 1.2-1.4x.

If the goal is purely availability - multi-region with a single provider (e.g. AWS eu-central-1 + eu-west-1) delivers 99.99% SLA at a fraction of multi-cloud DR complexity.

Anti-pattern 2: “Multi-cloud because teams know different clouds”

Team A knows AWS, Team B knows Azure. Instead of training on one platform, they each run on their own provider.

Result: two monitoring toolsets, two security models, two budgets that are difficult to compare, no shared services (common SSO, centralised logging, unified security policy).

Solution: Choose one provider as primary and invest in training. The cost of training 5 engineers (€15-25K) is many times lower than the annual cost of maintaining two ecosystems.

Anti-pattern 3: Small team (<10 people) with a “multi-cloud strategy”

Each additional provider is an operational complexity multiplier:

A team of 5-10 can be sufficient to fully cover one provider. With two providers, that’s no longer a given.

Multi-cloud management architecture

If after analysing the scenarios above multi-cloud is justified for you, you need a management layer. There’s no “easy multi-cloud”. But there are proven patterns.

IaC layer: Terraform as lingua franca

Terraform and OpenTofu are the only serious IaC tools supporting multiple providers with a uniform syntax. Alternatives (Pulumi, Crossplane) exist, but Terraform’s ecosystem (providers, modules, community) is disproportionately larger.

# Example: VPC module on AWS + VPC Network on GCP
# managed from a single Terraform repo

module "aws_vpc" {
  source  = "./modules/aws-vpc"
  cidr    = "10.0.0.0/16"
  region  = "eu-central-1"
}

module "gcp_vpc" {
  source  = "./modules/gcp-vpc"
  cidr    = "10.1.0.0/16"
  region  = "europe-west3"
}

# Cross-provider connectivity
module "interconnect" {
  source      = "./modules/cross-cloud-vpn"
  aws_vpc_id  = module.aws_vpc.vpc_id
  gcp_network = module.gcp_vpc.network_name
}

We cover a detailed Terraform comparison in Terraform vs Pulumi - which tool to choose.

Orchestration layer: Kubernetes as an abstraction layer

Kubernetes on both providers (EKS + GKE, or EKS + AKS) gives a common deployment model. But note - this is not automatic portability between providers:

• Common: Pod spec, Deployment, Service, Ingress (with ingress-nginx/Traefik)
• Different: Storage classes, Load Balancer annotations, IAM integration (IRSA vs Workload Identity), node pools/groups
• Dangerous: Assuming a Helm chart works identically on EKS and GKE without testing

Real portability requires:

1. Abstraction over differences (e.g. External Secrets Operator instead of native secrets)
2. CI/CD capable of delivering to both clusters (GitHub Actions + ArgoCD with multiple destinations)
3. Testing on both environments

Networking layer: connectivity between providers

Three approaches, depending on scale:

We cover detailed comparisons, configurations, and our implementation experience in our multi-cloud networking article.

Monitoring layer: a single view of everything

This is often the most neglected element. Two providers mean two native monitoring systems (CloudWatch + Cloud Monitoring). You need an aggregation layer:

• Metrics: Grafana Cloud, Datadog, or self-hosted Prometheus with federation
• Logs: Grafana Loki, Datadog, or ELK with centralised log collection
• Traces: Grafana Tempo, Jaeger, Datadog APM with OpenTelemetry Collector on both sides
• Costs: Kubecost / OpenCost (multi-cluster), plus each provider’s native tools

Key principle: one dashboard, all clouds. If you need to log into two consoles to understand an incident, you have an organisational problem, not a technical one.

FinOps layer: multi-cloud cost control

Each provider has a different pricing model, different discount tools, different reporting. Multi-cloud FinOps requires:

1. Unified tagging - the same tags (team, environment, service) across both providers
2. Centralised reporting - a tool aggregating costs (Kubecost, CloudHealth, Apptio)
3. Separate egress budgeting - inter-cloud transfer as its own budget line item
4. Egress monitoring - transfer between providers ($0.08-0.12/GB) can catch you off guard

More on cost control strategies in our showback model implementation guide.

What multi-cloud actually costs - a realistic calculation

Below is an estimate of operational overhead for a typical organisation (20 engineers, 50 microservices, 2 cloud providers):

Estimated multi-cloud overhead: €3,000-5,000/mo for an organisation of this scale. This isn’t an argument against multi-cloud - it’s the information needed for an ROI calculation. If multi-cloud delivers €10K/mo in business value (better tools, reduced risk, negotiating leverage) - it’s worth it.

Checklist: are you ready for multi-cloud?

Before making the decision, answer these questions honestly:

• Do we have a concrete business reason (not technical) for a second provider?
• Does the team have ≥10 engineers with capacity to specialise?
• Do we have Terraform (or equivalent IaC) covering 100% of infrastructure?
• Do we have centralised monitoring capable of aggregating data from multiple providers?
• Do we understand egress costs and have budget for them?
• Do we have shared CI/CD capable of delivering to both environments?
• Do we have a documented strategy (not “let’s see how it goes”)?

If ≥5 answers are “yes” - multi-cloud is feasible. If <5 - focus on one provider and address those gaps first.

You have the business reason but lack the team? There’s a third way

We frequently see this situation: the business requires multi-cloud (M&A, best-of-breed, regulation), but the team is 5-8 people without experience on the second provider. Two common mistakes in this position:

1. Hiring 3-5 specialists for the second cloud - takes 6-12 months, costs €200-400K annually in salaries alone, and the project stalls
2. Abandoning multi-cloud - you give up the business advantage (better tools, negotiating position, regulatory requirement) because the team isn’t ready

The third way: an external operational partner that covers the competency gap. Not as a one-off project, but as strategic support - short, medium, or long-term.

What this looks like in practice

Key principle: an external partner should build competence within your team, not create dependency. A good partner documents, trains, and transfers knowledge - gradually reducing their involvement if that’s the goal.

At Devopsity we support organisations on each of these models. We hold active business and technical partnerships with all three major cloud providers (AWS, Google Cloud, Microsoft Azure) - which in practice translates to access to dedicated technical support, discount programmes for clients, and shared reference architectures. If your team isn’t yet ready for multi-cloud but the business demands it - let’s talk strategy.

Cloud consolidation - when to simplify the architecture

The opposite of multi-cloud: a situation where you have 2-3 providers but no good reason for it. Typical symptoms:

• Bills from three providers, none exceeding $2,000/mo
• Monitoring scattered across CloudWatch, Cloud Monitoring, and Azure Monitor - nobody sees the full picture
• Each team chose “their” provider with no shared IaC standards
• AWS/GCP/Azure accounts created “for testing” and never closed
• No clarity on who pays for what (zero tagging, zero showback)

This isn’t multi-cloud - it’s cloud sprawl (uncontrolled growth of cloud infrastructure). The difference: multi-cloud is a deliberate architectural decision, cloud sprawl is chaos.

When to consolidate

• The operational cost of maintaining multiple providers exceeds the business value of having them
• The team lacks competence to properly manage more than one provider
• No shared management layer (IaC, monitoring, CI/CD, IAM)
• Workloads across providers don’t differ in character - you’re not using best-of-breed

How to consolidate - step by step

1. Inventory - what runs where, what the dependencies are, what traffic flows between them
2. Cost analysis - how much each provider costs (infrastructure + ops + training)
3. Choose the target provider - based on team competence, cost, and technical requirements
4. Migration plan - prioritise workloads to move, set timelines and budget
5. Execute - in stages, with validation after each migration

Consolidation is in practice a migration from one cloud to another - with the difference that the source is another public provider, not on-premise infrastructure.

Our perspective

At Devopsity we’ve managed multi-cloud environments since 2020. We’ve implemented AWS+GCP, AWS+Azure, and three-provider configurations. We know from experience that the biggest cost of multi-cloud isn’t the technology - it’s the lack of a coherent strategy leading to two poorly managed clouds instead of one well-managed one.

If you’re considering multi-cloud or you’re already in it and fighting the complexity - book a free consultation. We’ll help assess whether multi-cloud is justified in your case and design a management architecture that won’t spiral out of control.