The line item nobody put in the model
Here is the scene that should keep you up at night. A B2B software roll-up I sat with had the integration plan mapped to the day. Platform company ran natively on AWS. The bolt-on they'd just bought ran heavily on Google Cloud. To give customers a clean "Day 1" experience, the engineers wired up continuous, real-time database replication between the two clouds so records stayed in sync. Elegant. Fast. And in month two of the hold period it quietly added $228,000 to the cloud bill that appeared in exactly zero line items of the deal model.
That money didn't go to compute. It didn't serve a single web page or process a single transaction. It paid for the privilege of moving bytes out of one cloud and into another — the toll every hyperscaler charges the moment data crosses its perimeter. I call it the Egress Tax because that's what it functions as: a per-gigabyte levy on the act of integration itself, invisible until it lands on a P&L.
This is not an edge case. Across acquired tech stacks, cloud runtime costs routinely jump in the first months post-close, and the jump almost never tracks customer growth. It tracks orphaned staging environments left running, federated APIs chattering across cloud boundaries, and duplicate data pipelines that nobody turned off because nobody owned the bill. For scale-up software companies, public cloud can eat up to half of total cost of revenue — and per due-diligence research on cloud infrastructure, over $100 billion of public-software market value is currently suppressed purely by the margin drag of bloated, unoptimized cloud spend. If you're an operating partner, that's not an engineering footnote. That's your multiple.
Do the egress math before the wire goes live
The cross-cloud sync that burned $228K wasn't expensive because the clouds are pricey. It was expensive because the team never priced the wire. So price it. Per the 2026 ZeonEdge cost benchmarks, moving data out to the open internet — or to a different cloud — runs roughly $0.09/GB on AWS, $0.087/GB on Azure, and $0.12/GB on GCP's Premium tier for the first 10TB a month. Pennies. Now scale them to integration reality: a target syncing 100TB of customer records across clouds every month burns about $9,216 in AWS egress alone, before a single byte does any actual work. On GCP's Premium networking, that same 100TB is meaningfully worse. The synergy you underwrote is leaking out a pipe you forgot to put on the diagram.
The direction of the migration matters as much as the volume. If your thesis leans on stitching legacy microservices together through API federation, every federated call that crosses a cloud boundary is a metered event. A "lightweight" integration layer that fans out thousands of cross-cloud reads per minute can cost more in transfer than the compute it's supposedly orchestrating. The mistake teams make is treating egress as a rounding error because the unit price is small — it's a volume game, and integration is exactly the phase that spikes volume.
Compute pricing cuts the other way and rewards homework. Azure is genuinely attractive for a Microsoft-heavy target: the Azure Hybrid Benefit can knock up to 40% off Windows Server and SQL Server workloads — though its instance pricing flexes with regional demand, so the discount you model isn't always the discount you get. GCP hands out automatic sustained-use discounts (up to roughly 30% after 25% monthly usage), which makes steady-state, monolithic workloads pleasantly predictable. AWS charges the premium for raw breadth and flexibility — one recent benchmark counted nearly 200 separate monthly price changes across GPU and non-GPU instances. None of that helps if a real-time sync is quietly hemorrhaging transfer fees underneath it.
Why this is now table stakes: the Flexera 2026 State of the Cloud Report finds 76% of large enterprises now spend over $5 million a month on public cloud, and — more tellingly — a 12-point year-over-year jump in organizations tracking "value delivered to business units" instead of raw cost. Mature buyers stopped asking "is the bill big?" and started asking "what is this byte buying me?" Your newly merged engineering org needs to be asking that on day one, not at the next board meeting.
The first 120 days, in the order that actually saves money
A "wait and see" posture on inherited cloud architecture is how a $228K surprise becomes a recurring run-rate. Left alone, the acquired team will spin up redundant staging environments to test integrations and silently double your compute footprint inside a week. I've rebuilt this exact playbook for mid-market sponsors more than once, and the sequence that works is boring on purpose.
Week one is about seeing the bill before you touch the architecture. Centralize billing into a single view across both clouds. You cannot optimize what you cannot see, and the cross-cloud transfer line is invisible until it's all on one screen. Tag the egress specifically — separate "data moving because customers need it" from "data moving because we wired a convenience sync." That second bucket is usually most of the bleed.
Weeks two to four kill the avoidable transit, then down-tier storage. The real-time cross-cloud replication is the first thing to interrogate — does the business genuinely need sub-second sync, or did engineering reach for it because it was elegant? Batching, caching at the edge, or scoping the sync to only the records that change usually cuts the egress dramatically. In parallel, audit storage: it's common to find a large share of an acquired company's data sitting in expensive high-performance tiers (AWS S3 Standard, GCP Standard) when it's stale and untouched. Down-tiering cold objects to infrequent-access or archive classes is close to risk-free and can take 60% off those specific line items. Use the week-by-week sequence in the 120-day IT integration roadmap so this doesn't become a one-time cleanup that re-bloats by quarter's end.
By day 90, decide whether the two clouds should stay two clouds. If the standing cost of egress plus inter-cloud API latency between a GCP bolt-on and an AWS platform structurally breaks the combined unit economics, stop optimizing around it and migrate to one cloud. Run that call deliberately — the diagnostic in the consolidate-or-separate framework is built for exactly this fork: when to force the stacks together and when to leave them running in their native homes. Either answer is fine. Drifting between them on a metered wire is the one that quietly evaporates the deal.
Treat cloud runtime as a hyper-variable liability, not a fixed cost of doing business. Model the wire, govern the transit, and the synergy you underwrote actually shows up in the bank. Skip it, and it shows up in the cloud bill instead.
