When is more than one cloud worth it?

A second cloud helps when one provider is a failure you cannot accept. It also adds a bill and a network between them. I only recommend it for that reason.

How do you handle security on both clouds?

The same idea for access on both sides, encryption between them, and one place that sees both.

What if the path between clouds is slow?

I measure the path that crosses clouds. If that hop is the slow part, the split was the wrong shape.

How do you read two bills?

One view of both bills, and a reason each workload sits where it sits.

How do you keep data in sync across clouds?

I name what has to be copied, how fresh it has to be, and what you do when the copy falls behind.

Which tools do you use for more than one cloud?

Terraform for both sides, and Prometheus or Grafana if you want one set of graphs. Kubernetes only if you're already running it.

Multi-Cloud Architecture

A setup that uses more than one cloud, when AWS alone isn't the whole answer.

Back to Services

What I do

Only when one cloud isn't enough

I split the work across clouds only when one provider is not the whole answer.

How the two sides talk

The two sides need a clear way to talk, and a failure on one side shouldn't take the other down silently.

One place to see both

One place to see both clouds. Two consoles and no alarm is how these setups rot.

What you get

AWS, and the cloud you already use

I work mostly on AWS, and I use Azure or Google Cloud when the project already lives there.

A reason for the second cloud

If AWS is enough, I say so. A second cloud has to solve a failure you cannot accept.

What fails together

I name what still fails together after the split. A second logo is not a backup.

The bill

I compare the bill on both sides. Cheap on one cloud and expensive to connect is not a win.

How the work goes

The failure you cannot accept

I start from the failure you cannot accept, then decide if a second cloud helps.

What lives where

You get a diagram of what lives where, and how the two sides talk.

Both sides in code

I put both sides in code, so the split isn't a pile of console clicks.

Which cloud failed

I leave one dashboard and an alarm that names which cloud failed.

Tools I use

These show up when they fit the job.

Amazon Web Services

Microsoft Azure

Google Cloud Platform

Kubernetes

Terraform

Docker

Ansible

HashiCorp Vault

Prometheus

Grafana

Amazon Web Services

Microsoft Azure

Google Cloud Platform

Kubernetes

Terraform

Docker

Ansible

HashiCorp Vault

Prometheus

Grafana

Situations I get called in for

A contract asks for a second provider

A customer or a regulator says one provider is a risk. I find out what they actually need. Sometimes a tested backup in another cloud answers it. Sometimes it means running live on both.

Two teams, two clouds

Your company merged with a team that runs on Azure or Google Cloud. I decide what stays where, what talks across, and what moves. Moving nothing is a valid answer.

One service lives on another cloud

The team wants BigQuery or another managed service while the app stays on AWS. Before that, I look at how much data has to leave AWS to reach it, and what that transfer costs.

A second cloud nobody has tested

A second cloud was set up for failover, and nobody has failed over since. I check if it would actually take traffic. If it wouldn't, and nobody needs it, I tell you to shut it down.

What I check first

Egress between clouds

Every byte that leaves a cloud is billed as data transfer out. A chatty service split across two providers can cost more in transfer than in compute.

How each side proves who it is

I prefer OIDC workload identity federation over long-lived keys copied into the other cloud's secret store. AWS IAM, Azure, and Google Cloud all support it.

The network path

Site-to-site VPN or a dedicated interconnect, overlapping CIDR ranges on the two sides, and where each side resolves the other's DNS names.

What still fails together

One DNS provider, one identity provider, one CI system, or one Terraform state bucket can take both clouds down at once. Two providers don't fix that.

Whether failover has ever run

A runbook nobody has followed is a guess. I want to see one failover done, with the data lag measured, before anyone counts on it.