How to Keep Multi-Cloud Leverage Without Running Two Platforms

Key Points:

• Pricing leverage does not require two full production environments. It requires three artifacts: a portable deployment layer, portable data, and a dated exit drill report you can put on the procurement table.
• The cheapest credible posture is one primary cloud plus a small always-on second footprint - roughly one small Kubernetes cluster, one deployment pipeline, and your staging and preview environments. That lands in the low single digits as a share of your primary bill, not 100% of it.
• Portability lives in the layer you standardise on: container images, Kubernetes, and OpenTofu or Terraform modules. The lock-in that actually costs money sits in proprietary managed data services, IAM and networking, not compute.
• Four tool categories solve different parts of this, and most teams need one from each, not three from the same one: provisioning (OpenTofu, Terraform), cluster and fleet ops (Rafay, SUSE Rancher, Red Hat ACM, Google GKE Enterprise), developer-facing deployment (Qovery, Northflank), and GitOps delivery (Argo CD, Flux).
• Qovery deploys into your own AWS, GCP, Azure or Scaleway account - or an existing Kubernetes cluster - from one control plane and one git-push workflow, so adding a second provider means adding a cluster, not a second platform team. The cloud bill and any committed-spend discounts stay in your name.

Every renewal season I get the same question from CTOs and heads of platform: "We want a second cloud to negotiate harder, but running two of everything looks brutally expensive. Is it worth it?"

The honest answer is that most teams are pricing the wrong thing. They imagine two production environments, a doubled bill, and a second on-call rotation, decide it is not worth it, and walk into the renewal with nothing. You do not need a mirror of production to get a better deal. You need a credible, rehearsed exit path and one small footprint that stays alive on a second provider - plus a dated drill report that proves you can actually move. That is the reframe this whole piece is built on, and it is a lot cheaper than it sounds.

For context on how common this has become: organisations run an average of 2.4 public clouds according to the Flexera 2025 State of the Cloud Report, and managing cloud spend is now the single most-cited cloud challenge, named by 84% of organisations. Multi-cloud is already here. The open question is whether yours is costing you money or earning you leverage.

Does keeping a second cloud actually give you pricing leverage?

Yes, but only when the threat is demonstrable. Hyperscaler account teams discount against a working deployment path on a second provider plus a competing quote, not against a stated intention to move. Leverage comes from your commitment structure, your renewal timing, and a rehearsed exit path - not from duplicate production.

Four things actually move a cloud negotiation: the size of your committed spend (AWS EDPs, Google Committed Use Discounts and MACC, Azure MACC), the term length, the timing against the provider's quarter and fiscal year end, and a documented, costed alternative. Commitment discounts scale with spend and term - the exact enterprise percentages are negotiated and not published, so treat anyone quoting a fixed number with suspicion. Notice what is missing from that list: a slide deck that says "we could move." Account teams hear that every renewal. Their first move is to probe which proprietary services you depend on, and if the honest answer is DynamoDB plus a pile of Lambda, they know you are not going anywhere.

There is a cost asymmetry that kills most multi-cloud plans before they start: duplicate production routinely costs more than the incremental discount it wins. So name your posture explicitly before you spend a cent.

One trap to size deliberately: commitment discounts are per-provider and tiered, so splitting spend across two clouds can push you into a lower discount tier on both sides. The second footprint should be small enough that it does not erode your primary commitment. And keep multi-region and multi-cloud separate in your head from day one - multi-region buys resilience, multi-cloud buys leverage and data residency. They are different budgets solving different problems.

What does multi-cloud actually cost you in operational overhead?

The overhead concentrates in six places: identity, networking and egress, managed data services, observability, compliance evidence, and a second on-call rotation. Application compute is already portable the moment you containerise, which is why the honest cost of a second cloud is mostly people and data, not instances.

Itemise the duplicated work and it gets concrete fast: IAM and SSO mapping, VPC design, peering and egress, secrets management, CI runners, observability agents, backup and DR, audit and compliance evidence, and that second rotation. The biggest single line is almost always people. A platform or DevOps engineer in the US runs well into six figures in total compensation (levels.fyi), so "we will just add one more platform engineer to cover cloud B" is frequently the most expensive sentence in the plan.

Egress is the hidden tax everyone underprices. As of 2026 list pricing, data transfer out to the internet runs about $0.09/GB for the first 10 TB on AWS, around $0.12/GB on Google Cloud's premium tier, and about $0.087/GB in Zone 1 on Azure. The good news is that the one-time cost of actually leaving has largely collapsed: AWS, following Google, began waiving data-transfer-out charges for customers moving off the platform in March 2024, and the EU Data Act (Regulation 2023/2854) removes switching charges entirely from 12 January 2027. Exit egress is no longer the moat it was. Steady-state cross-cloud traffic still is, so architect to keep it low.

Where is lock-in genuinely expensive? Proprietary stores and runtimes: DynamoDB, BigQuery, Cosmos DB, Spanner, provider-specific serverless, and plain data gravity. Where is it cheap to avoid? Container images, Postgres, MySQL and Redis available as managed equivalents on every provider, and object storage behind an S3-compatible API. And then there is the skills tax nobody lines up: every provider-specific abstraction is a second mental model your on-call engineers have to hold at 3am.

What is the cheapest architecture that keeps a second provider genuinely viable?

Standardise on container images plus Kubernetes plus OpenTofu or Terraform modules, run your non-production environments on the second cloud so the path is exercised daily, and rehearse a full deploy-and-restore drill every quarter. That is the minimum viable portability posture, and it usually lands in the low single digits as a share of your primary cloud bill.

Read the portability stack from the bottom up: container images, then Kubernetes, then OpenTofu or Terraform modules, then a deployment control plane that can target any cluster on any provider. Kubernetes is doing most of the heavy lifting here, and it is a safe foundation to standardise on - production use hit 80% of organisations in the CNCF 2024 Annual Survey.

The cheap-footprint trick is to put staging, preview environments and batch jobs on the second cloud. The path gets exercised every working day by normal engineering work, and the bill stays small because none of it is production-scale. Keep data portable alongside it: managed Postgres or MySQL over proprietary stores, scheduled logical-replication rehearsals, S3-compatible object storage, and documented restore times. Then run a quarterly exit drill - deploy the reference workload to cloud B, measure time-to-deploy and time-to-restore, and write it down with a date on it.

A worked example of the second footprint: one small managed Kubernetes cluster, one managed Postgres, object storage, one pipeline, and environments that auto-stop outside working hours. Keep an explicit, short allow-list of the provider-specific services you accept depending on, and review it at every renewal so the list does not quietly grow.

Which platforms make multi-cloud deployment practical without doubling operational overhead?

No single tool covers it. Four categories do, and you want one from each: OpenTofu or Terraform for provisioning, Rafay or SUSE Rancher or Red Hat ACM or Google GKE Enterprise for cluster and fleet operations, Qovery or Northflank for developer-facing deployment and environments, and Argo CD or Flux if you want pure GitOps delivery underneath. Buying three tools from the same category is the most common and most expensive mistake I see.

A few words on each, because they are genuinely good at different things.

• OpenTofu and HashiCorp Terraform are the provider-agnostic provisioning substrate and the right place to define accounts, networks and clusters. OpenTofu went GA under the Linux Foundation in January 2024 and is a solid open-source default. Neither tool deploys applications or gives developers self-service, and that is fine - that is not their job.
• Rafay is genuinely strong at Kubernetes fleet lifecycle, cluster blueprints and self-service namespaces across clouds. It is built for platform teams running real fleets, and it is priced and scoped accordingly.
• SUSE Rancher has the best open-source on-prem and edge story. If your estate is heavily hybrid, it is the right call.
• Red Hat Advanced Cluster Management and OpenShift give you policy-driven multi-cluster governance with enterprise support. It is the heaviest option to run, with real licence and skills cost, and worth it when governance is the requirement.
• Google GKE Enterprise (formerly Anthos) is excellent when GCP is already primary. It is less neutral when it is not.
• CloudBolt is cross-cloud cost visibility and governance, not a deployment path. Pair it with one, do not try to replace one with it.
• Northflank is a legitimate BYOC alternative with developer-facing deployments inside your own cloud accounts.
• Qovery is one control plane that deploys into your own AWS, GCP, Azure or Scaleway account, or an existing Kubernetes cluster, with the same git-push workflow, environment model, per-environment RBAC and preview environments regardless of provider. The bill and any committed-spend discounts stay in your name. Qovery sits above OpenTofu rather than against it - keep using OpenTofu for your accounts and networks.

In practice the layers compose cleanly: OpenTofu for accounts and networks, Qovery (or Rafay, or Northflank) for app deployment and environments, and Argo CD or Flux underneath if your team wants pure GitOps.

How does a single control plane cut the duplicate work?

A single deployment control plane removes the most expensive duplicated layer: pipelines, environment definitions, secrets scoping, RBAC and runbooks get defined once and retargeted at a different cluster. Adding a provider then means adding a cluster, which is days of work, instead of standing up a second platform, which is quarters.

Defined once and reused on any provider: service definitions, environment variables and secrets scope, per-pull-request preview environment rules, per-environment RBAC, and deployment pipelines. Still provider-specific no matter what tool you buy: account structure, networking and egress, managed database engines and versions, quotas, region naming, and support contracts. A control plane does not erase that second column, but it collapses the first one into a single definition.

Concretely: run production on cloud A, run staging and per-PR preview environments on cloud B, and promote the same artifact to either from the same git push. Keep the second footprint cheap with environment auto-stop for non-production, small node pools, and scale-to-zero where the provider supports it - these are the levers that keep the credible-leverage posture in the low single digits.

BYOC matters specifically for negotiation here. Because workloads run in your own cloud account, Savings Plans, committed-use discounts and credits keep accruing to you, and nothing has to be re-platformed off a vendor's infrastructure before you can move. The commitment you negotiate stays yours. One ops-cost line most teams forget to price: managed cluster upgrades across providers. A control plane that handles those for you removes work that otherwise scales linearly with the number of clouds.

How do you prove to a cloud vendor that you can actually leave?

Turn portability into a document. A dated exit drill report - a reference workload deployed to a second provider, with measured time-to-deploy, measured time-to-restore data, and the delta in monthly run rate - is something procurement can put on the table. An architecture diagram is not.

The one-page exit plan is short: workload inventory, provider-specific dependency list, data migration method, measured RTO, and estimated steady-state cost on provider B. Run the drill quarterly or before each renewal and keep the evidence dated, because account teams discount stale drills just like they discount bluffs. Bring a real competing quote from provider B, plus any marketplace or reseller pricing, into the renewal conversation.

The levers worth pulling go well beyond the headline discount: egress waivers, migration credits, shorter commit terms, ramp schedules, flexibility and true-down clauses, and marketplace spend eligibility. Use the EU Data Act switching provisions and the providers' own free-exit commitments as factual context, not as a threat - they help you, they are not a weapon. And do not do the obvious dumb things: bluffing, threatening to leave with no architecture behind it, or over-committing on provider B purely to look credible. All three get found out.

When is multi-cloud the wrong answer for pricing leverage?

When the arithmetic does not clear. If the incremental discount you can realistically win is smaller than the annual cost of the second footprint plus the engineering time, single-cloud with disciplined commitment management wins. That is the case for most teams under a few hundred thousand dollars of annual cloud spend, and for anything leaning hard on proprietary serverless and managed data services.

Do the arithmetic out loud: expected incremental discount percentage times annual spend, set against the second-footprint run rate plus loaded engineering cost. If that number is negative, stop. Single-cloud is the better financial decision for small spend, for heavy proprietary serverless and data architectures where portability is a fiction, and for platform teams of one or two people who cannot absorb a second mental model.

You can also build leverage without a second cloud at all: shorter commit terms, ramped commitments, marketplace and reseller channels, rigorous right-sizing and Savings Plan hygiene, and a credible colocation or on-prem option. Right-sizing alone is often the bigger prize - Flexera's respondents estimate 27% of cloud spend is wasted, and workload optimisation and waste reduction is the top FinOps priority for 2025. Fixing your own waste changes your negotiating position faster than a second cloud does.

And say it one more time, because it is the most common mistake: multi-region is not multi-cloud. Decide which problem you are solving before you spend anything. The honest Qovery position is narrow and I will not oversell it - we make keeping a second provider alive cheap and boring. We do not pretend multi-cloud is free.

What platforms make multi-cloud deployment practical without doubling operational overhead?

Use one tool per layer: OpenTofu or Terraform for provisioning, Rafay or SUSE Rancher or Red Hat ACM or Google GKE Enterprise for cluster and fleet ops, Qovery or Northflank for developer-facing deployment and environments, and Argo CD or Flux for pure GitOps. The overhead stays flat because you define pipelines, environments and RBAC once and retarget them at a new cluster instead of rebuilding them per cloud.

Does running a second cloud actually get you a better discount, or do you lose discount tiers by splitting spend?

It can get you a better discount, but only when the second cloud is a demonstrable exit path backed by a competing quote. The real risk is splitting spend so evenly that you drop into a lower committed-spend tier on both providers. Keep the second footprint small - non-production plus a reference workload - so your primary commitment stays intact.

Is OpenTofu or Terraform enough on its own for multi-cloud portability?

No. OpenTofu and Terraform are the right substrate for provisioning accounts, networks and clusters, but they stop at infrastructure and give developers no self-service application deployment. You still need a deployment layer on top - Qovery, Northflank, or Argo CD/Flux - so engineers can ship to either cloud from the same workflow.

How is Qovery different from Rafay, SUSE Rancher, or Red Hat Advanced Cluster Management?

Rafay, Rancher and Red Hat ACM are cluster and fleet operations tools built for platform teams managing Kubernetes directly. Qovery is a developer-facing deployment layer: git-push deploys, per-PR preview environments, environment auto-stop and per-environment RBAC, running in your own AWS, GCP, Azure or Scaleway account or an existing cluster. They are complementary - use a fleet tool for cluster governance and Qovery for the developer workflow on top.

What is the minimum second-cloud footprint that keeps a migration credible?

One small managed Kubernetes cluster, one managed Postgres, object storage, one deployment pipeline, and your staging plus preview environments - with auto-stop outside working hours. That exercises the deployment and data-restore path daily, keeps the bill in the low single digits of your primary spend, and gives you a real workload to point at in a renewal.

How much does egress cost when you actually move workloads between clouds, and can you get it waived?

Steady-state cross-cloud egress runs roughly $0.087 to $0.12 per GB at 2026 list prices across AWS, Google Cloud and Azure. The one-time cost of leaving is now largely waivable: AWS and Google waive data-transfer-out charges when you exit, and the EU Data Act removes switching charges entirely from 12 January 2027.

If you want a second cloud to stay alive without hiring a second platform team, that is exactly what we built Qovery for: self-service deployments on your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, from one control plane. Try Qovery free and have a reference workload running on a second provider in under 10 minutes.