The case for a second cloud is usually made on the cheaper published rate of a workload, but that comparison ignores the costs a two cloud estate actually carries. Moving or splitting workloads across providers generates cross cloud egress and networking charges, drops your committed volume below the tiers that discount the rest of your spend, and forces you to run and staff two control planes instead of one. Each of those is real money, and together they often exceed the compute saving that justified the split. That does not mean two clouds are always wrong, because resilience, a required service, or data residency can make a second cloud worth the cost, but it does mean the decision should rest on total economics rather than a rate card. Run two clouds on purpose, not by accident.
Here are the hidden costs in detail, a worked example of how they erase a paper saving, and the cases where a second cloud genuinely earns its keep.
Where do the hidden costs come from?
Four sources account for most of the surprise. Cross cloud data movement is the largest and the quietest: any workload on one cloud that reads data on another pays egress to pull it across, continuously, and egress is a quiet budget eater even within a single cloud. Split commitments are the next: AWS Savings Plans and Reserved Instances, Azure Reservations and the Azure Savings Plan, GCP Committed Use Discounts, and OCI Universal Credits all reward concentrated volume, so spreading spend across two providers can drop you below the coverage and tier that were discounting your primary estate, raising the effective rate on the workloads you did not move. Duplicated operations is the third: two clouds mean two sets of tooling, two billing models, two security postures, and more surface for waste to hide. And the fourth is human: maintaining real expertise in two platforms costs engineering time and slows every decision.
How do these costs erase a paper saving?
The trap is to compare compute rates and stop there. Suppose a workload looks cheaper on a second cloud on compute alone. If that workload reads from data that stays on the first cloud, you now pay continuous egress to feed it, plus a one time transfer to seed it. The volume you removed from the first cloud may push your remaining estate below a commitment tier, so the rate on everything you kept ticks up. And you now operate, monitor, and secure a second platform. By the time those are counted, the workload that looked cheaper on the rate card is frequently more expensive in total, and the saving was a mirage created by comparing one line of a four line bill.
A European SaaS company planned to move part of its analytics tier to a second cloud that quoted compute roughly 15 percent cheaper. Modelling the full picture changed the decision. The analytics tier read from a primary data store of several hundred terabytes that would stay on the incumbent cloud, so the move meant continuous cross cloud egress plus a large one time transfer. Removing that volume from the primary cloud dropped the estate below its commitment coverage tier, raising the effective rate on the workloads that stayed. Adding a second monitoring and security stack on top, the two cloud option came out around 12 percent more expensive overall. The company kept the tier on one cloud and found the saving instead through rightsizing and tighter commitment coverage, which left the estate materially lighter. Figures are verified against billing data and anonymised.
When is a second cloud actually worth it?
Plenty of times, when the reason is something price alone cannot capture. Resilience is one: a genuinely independent second cloud can protect against a provider wide failure, though true independence is harder and costlier than most designs assume. A required service is another: if only one provider offers a managed capability your product needs, that workload belongs there regardless of the general rate. Data residency and sovereignty can mandate a specific provider or region. And a large, isolated workload with little data gravity, such as an egress light batch job, can have decisive economics on a cheaper cloud, where OCI egress being materially cheaper than the hyperscalers, for instance, can tip the maths. The common thread is a specific, defensible reason beyond a lower sticker rate.
How do you keep a two cloud estate honest?
If you do run two clouds, manage the hidden costs deliberately. Place data and the workloads that use it together to minimise cross cloud egress. Concentrate commitment volume enough on each cloud to hold the discount tiers that matter, rather than splitting thinly. Normalize cost data across providers so you see one comparable number and can spot the duplicated spend. And keep tooling consolidated where you can, so two clouds do not become two of everything. The goal is a two cloud estate that exists for a reason and is run as tightly as a single cloud, not one that accreted by accident and leaks money at every boundary.
Frequently asked questions
What are the hidden costs of a two cloud estate?
Does running two clouds save money?
When is a second cloud worth the cost?
Decide your cloud strategy on total economics
Our cloud cost optimization playbook covers how to model a multicloud estate on full economics across AWS, Azure, GCP, and OCI, including the hidden costs that a rate comparison misses. We are an independent buyer side advisory with zero provider commissions, and our guarantee is simple: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.