Why does hybrid cloud egress cost so much?

What actually gets charged?

Data leaving the provider's network is billed per gigabyte, and data arriving is generally free. That asymmetry is the whole shape of the problem: the platform is cheap to fill and costly to drain, so any design that repeatedly pulls data back out is paying a toll that a design keeping the processing inside does not.

The charge is not only for the internet. Traffic between availability zones inside one region is billed in both directions on AWS and Google Cloud, at 0.01 USD per gigabyte each way, though Azure removed its inter-availability-zone charge in 2024 and now carries that traffic inside a region at no cost. Traffic between regions is billed everywhere, Azure included from 0.02 USD per gigabyte, and traffic passing through certain managed components is billed for the processing as well as the transfer. A byte can therefore be charged more than once on a single journey.

For hybrid specifically there is a second rate to know about. Data leaving over a dedicated private circuit is priced lower per gigabyte than data leaving over the internet, which is one of the genuine financial arguments for ordering one. Whether the discount clears the port fee is arithmetic on your own traffic, not a rule of thumb.

Where do the surprises come from?

Rarely from the thing that was budgeted. Teams model the obvious flow, the nightly extract or the API responses, and are then caught by charges generated by infrastructure choices that nobody thought of as data transfer at all.

The most common of these is chatter between availability zones, on AWS and Google Cloud. Spreading a cluster across zones for resilience is correct, and on those two platforms it means every internal call between components has a good chance of crossing a zone boundary and being metered. A busy internal service can therefore generate more billable transfer talking to itself than the application generates talking to your data centre. On Azure this category does not exist any more, because inter-availability-zone transfer within a region became free in 2024.

The second is the managed network address translation gateway, which charges for every gigabyte processed on top of the transfer charge, so private subnets reaching an external service pay twice. The third is disaster recovery: replication runs continuously and quietly, and the first full restore test produces a bill large enough that some organisations stop testing, which is the worst possible outcome of a pricing model.

Why does a chatty design cost more than one big transfer?

Because the charge follows total bytes, and chatty designs move the same bytes repeatedly. A service that fetches a full customer record every time it needs one field pays for the whole record on every call, and does so all day, whereas a single nightly synchronisation moves each record once.

Protocol overhead compounds it in a way that is easy to overlook. Verbose formats, uncompressed responses and headers repeated on every request all add bytes that carry no information for you but are metered exactly like the ones that do. Enabling compression on responses crossing the boundary is one of the few genuinely free improvements available.

The practical consequence is that egress optimisation and latency optimisation point the same way. Coarser endpoints, caching, and batching reduce both the round trip count and the transfer volume, which means the work you would do for performance also flattens the bill and does not need a separate business case.

How do you reduce it without redesigning everything?

Start with compression and caching, because both are configuration rather than architecture. Compressing responses that leave the provider network reduces the metered volume directly, and a cache on the on-premise side removes repeat requests for data that has not changed.

Then look at placement of the noisiest pair. Egress bills are usually dominated by one or two conversations, not spread evenly, so identifying the top talkers and moving one component to the other side of the boundary often removes most of the charge with a single change. This is a much smaller intervention than a general redesign and it is available to almost everyone.

After that, the structural options: keep the high-volume leg inside one availability zone where resilience allows, replace continuous replication with scheduled synchronisation where the freshness requirement permits, and move the private circuit conversation from a networking decision to a financial one once you know the sustained volume. Each of these has an operational cost, which is why they come after the free changes rather than before.

Does egress cost justify staying on-premise?

Only when the volume leaving is genuinely large and sustained, which is a narrower situation than the discussion suggests. Media distribution, large scientific datasets and continuous export of raw telemetry can reach volumes where the transfer charge dominates everything else. Most business applications do not come close.

The more honest framing is that egress pricing shapes the architecture rather than the location. It penalises designs that treat the cloud as a place to hold data that something else keeps reading, and rewards designs that process where the data already is and move only conclusions. That is a design constraint, and it is the same constraint data gravity describes from the other direction.

There is also a lock-in argument that is distinct from the cost argument and worth keeping separate, and it has changed. The old concern was that the price of leaving scaled with how much you had accumulated, so an exit got more expensive the longer it was deferred. That is no longer true of the transfer charge for a full exit: since early 2024 all three major providers waive it for customers leaving entirely, Google Cloud from January 2024 through its Cloud Exit form, AWS from 5 March 2024 for accounts in good standing moving all their data off, and Microsoft Azure on notifying it of a start date and a volume. Each gives about 60 days to complete the migration, and Azure expects all subscriptions to be cancelled at the end of it. The EU Data Act, Regulation (EU) 2023/2854, then removes switching charges including egress altogether from 12 January 2027.

So the thing to plan for is not a bill that grows with your stored volume, it is time, coordination and meeting the conditions those exit programmes set. Ongoing egress for a workload you are still running is unaffected and continues to be billed normally, which is why the operational figure and the exit figure should never be quoted as the same number.

How do you forecast it before committing?

Measure the traffic you already have. Flow records from your existing firewall or router will tell you how many bytes per day pass between the systems you intend to split, and that figure multiplied by the published per-gigabyte rate is a defensible first estimate rather than a guess. Most organisations have this data and have never queried it.

Then add the parts the flow records cannot see: the cross-zone traffic your future cloud deployment will generate internally, the replication you intend to run, and the restore test you will need to perform. These are the components that break forecasts, and they are estimable from the intended topology rather than from measurement.

Finally, set a billing alert on the transfer categories specifically, not just on the total. A total budget alarm fires after the surprise has happened and tells you nothing about which conversation caused it. A per-category alert in the first month of a hybrid deployment is the cheapest insurance available, and it turns a bill you have to explain into a change you catch in a week.