The Egress Bill Nobody Budgeted: What Cloud Repatriation Really Saved Three Teams

The line item that starts a repatriation conversation is almost never compute. Compute is visible, it has a unit price everyone recognises, and finance has already argued about it. Data transfer is different: it is metered in bytes against an architecture that engineers reason about in requests, it is spread across a dozen usage-type codes on the invoice, and it arrives a month after the design decision that caused it.

Three engineering teams shared their numbers for this piece on condition of anonymity. All three moved production workloads off a hyperscaler between roughly mid-2024 and early 2026. Two report ongoing savings. One reversed the move inside a year and paid for two migrations. Every figure below is as reported by the team in question; invoices were not audited, and none of these numbers should be read as an industry benchmark.

What follows is the billing mechanism that surprised them, the cost lines that did not appear in anyone's business case, and a way of deciding whether your workload shape makes repatriation a genuine saving or an expensive lateral move.

How egress is actually billed

Internet data transfer out is metered per gigabyte at the boundary of the provider network, in volume bands that step down as you use more. Published list rates from North American and European regions start around eight to nine cents per gigabyte after a free monthly allowance of 100 GB aggregated across services, with higher rates from South America, Asia Pacific and the Middle East. Inbound transfer is free. That asymmetry is the whole design: it costs nothing to put data in and real money to take it out.

The surprise is rarely the headline rate. It is the number of separate meters a byte passes through. Traffic between availability zones is charged in both directions at a per-GB rate, typically around a cent each way. A NAT gateway adds a data processing charge on top of the egress charge for the same bytes. Load balancers bill processed bytes independently. Cross-region replication is billed as egress. Retrieval from cold object storage tiers carries a per-GB retrieval fee that is a different line item from the transfer itself. A request entering through a gateway, crossing a zone boundary to reach a service, and reading from a replica in a third zone can be metered three or four times before a single byte reaches the user.

The comparison that makes repatriation look attractive is not network cost versus network cost, it is billing model versus billing model. Transit and colocation bandwidth are sold as committed megabits per second with 95th percentile burst billing, so you pay for sustained capacity rather than accumulated volume. One gigabit per second run flat out for a month moves roughly 324 TB. At list egress rates that same volume prices at something close to thirty thousand dollars. At commit-level transit pricing in a competitive metro it is a small fraction of that. Both of those are illustrative list comparisons rather than quotes, and real cloud bills are discounted, but the order-of-magnitude gap is why the conversation starts at all.

The comparison that makes repatriation look attractive is not network cost versus network cost, it is billing model versus billing model.

Team A: heavy bytes, flat demand, clean exit

Team A runs a media asset delivery product: customers upload large files, the platform transcodes them and serves the results. Roughly 700 TB a month leaves the platform, and the team reports that data transfer and associated processing accounted for about 38,000 dollars of a monthly bill in the mid-60,000s. Compute was a minority of the invoice.

They moved object storage and the delivery tier into two colocation racks in separate metros, kept the control plane and CI in the cloud, and fronted everything with a commercial CDN so that origin egress was a function of cache miss ratio rather than total traffic. Reported steady state: about 9,000 dollars a month in colocation, power and transit, roughly 340,000 dollars of hardware amortised over four years, and one additional full-time infrastructure engineer. They put net savings at around 21,000 dollars a month once the first year settled, with payback somewhere near fourteen months.

Two details did most of the work. Their traffic had a peak-to-mean ratio under 2:1, so committed bandwidth was efficient rather than wasted. And their state was simple: immutable objects with a clear replication story, not a transactional database with managed failover they would have had to rebuild.

Team B: a partial move, and a new cost line

Team B operates an internal analytics platform. Their transfer problem was not the internet at all. On a bill they report in the region of 90,000 dollars a month, roughly 11,000 was inter-zone traffic and NAT gateway data processing generated by shuffle-heavy batch jobs and by log shipping to a third-party observability vendor.

They moved the storage and batch execution tier onto owned hardware in a colocation facility and left identity, orchestration, secrets management and the customer-facing API in the cloud. The reported gross infrastructure saving was around 40 percent on the affected workloads. Net of half an FTE and an expanded on-call rotation, they put the real figure closer to 18 percent.

The hybrid shape created a cost line they had not modelled: the interconnect between colocation and cloud became a permanent dependency with its own port fees, its own failure modes and its own capacity planning. They also note, honestly, that a meaningful share of the saving came from work they could have done without moving anything, including zone-affinity for shuffle traffic, private service endpoints in place of NAT, and turning down log verbosity. If you have never separated those wins from the move itself, your business case is measuring two things at once.

Team C: the one that went back

Team C moved a latency-sensitive, multi-region API to owned hardware on a projected 30 percent saving. They reversed it in month eleven. The cost model was not wrong; everything around it was.

Their demand had a peak-to-mean ratio above 5:1, driven by seasonal events. Buying for peak meant most of the fleet idled most of the time, which ate the projected saving down to a reported 9 percent in practice. When an event exceeded forecast, they could not add capacity in the timeframe that mattered, and hardware lead times measured in months meant the answer to a capacity problem was a purchase order rather than an API call. A disk firmware fault took a storage node out for a week. Then the one engineer who genuinely understood the build left, and the bus factor went to zero.

They moved back, paid a second migration, and describe the episode as an expensive lesson in what repatriation actually is: a bet that demand stays predictable and that the specific people who can operate the estate stay employed. Neither of those is an infrastructure question.

Repatriation is a bet that demand stays predictable and that the specific people who can operate the estate stay employed.

The costs that were not in anyone's spreadsheet

Across all three teams the same items were missing from the original model. They are not exotic; they are just not on a cloud invoice, so nobody thinks to subtract them.

• Headcount. A humane on-call rotation needs at least five or six people, not one hero. A fully loaded infrastructure hire in a major market costs well over 15,000 dollars a month, which sets a floor: if the projected saving does not clearly exceed one loaded FTE, the move is a lateral one with more pager duty. That threshold is illustrative and varies by market.
• Hardware refresh and spares. Four-year amortisation is the easy part. Spares inventory, DOA and RMA cycles, and the engineering time to handle them are the part people forget.
• Rebuilding what was free at the point of use. Managed Kubernetes control planes, IAM, key management, automated backups and database failover are all line items you stop paying and start staffing.
• Capacity risk. You buy for peak, and lead times mean you buy months ahead of needing it. That is working capital and forecasting risk moving onto your balance sheet.
• Compliance re-work. Certifications and audit evidence that inherited controls from the provider need to be rebuilt against your own facility and processes.

A framework for deciding by workload shape

Repatriation is not a strategy, it is a property of specific workloads. Three measurements decide it, and all three can be taken before anyone talks to a colocation salesperson.

First, the transfer ratio. Add internet egress, inter-zone transfer, NAT and load balancer data processing, and cross-region replication, then express it as a share of total spend for the workload. Below roughly 20 percent, the move is unlikely to pay for the operational overhead. Above 30 percent with volumes in the hundreds of terabytes a month, it is worth a real model. Those bands are a rule of thumb from these three cases, not a benchmark.

Second, peak-to-mean ratio, measured from flow or CDN logs rather than monthly totals. Committed bandwidth and owned hardware both price on peak. Under 2:1 you capture nearly all of the theoretical saving. Above 4:1 you are buying idle capacity, which is precisely the cost structure the cloud exists to absorb.

Third, state complexity and managed-service depth. Immutable objects, batch pipelines and stateless serving move well. Transactional databases with managed multi-region failover, event streaming with managed durability guarantees, and anything whose recovery story is currently somebody else's SLA move badly. Count the managed services you would have to reimplement and staff; if the list runs past three or four, the saving is being spent on rebuilding commodity plumbing.

What to do on Monday

None of the following requires a decision about moving. All of it improves your position either way, which is the point.

If the numbers survive all of that, keep the move reversible for at least twelve months: portable data formats, infrastructure-as-code that still describes a cloud landing zone, and a documented path back that someone other than the author has read. Team C's second migration was expensive largely because nobody had planned for one. The teams that came out ahead were the ones whose workloads were boring in exactly the right way, and who counted the people cost before, rather than after, the racks arrived.

• Pull twelve months of billing at line-item granularity with usage type codes, and split transfer charges into internet egress, inter-zone, data processing and retrieval. Most teams cannot currently do this in under an hour, which is itself the finding.
• Compute 95th percentile Mbps from flow or CDN logs. Monthly gigabyte totals tell you nothing about what colocation bandwidth would cost you.
• Get a committed-use discount quote and a private interconnect quote from your current provider first. The negotiated price is the baseline a repatriation has to beat, and list price comparisons flatter the move by a wide margin.
• Fix the topology problems you would have fixed anyway: zone affinity for chatty paths, private service endpoints instead of NAT for provider API traffic, compaction before transfer, and honest log verbosity. Measure again afterwards.
• If you operate in the EU, check where your provider stands on switching charges under the Data Act before budgeting exit egress as a capital cost. The migration arithmetic and the steady-state arithmetic are separate questions.
• Write down the headcount plan, including the rotation, before the hardware quote. If you cannot name five people, you do not have an on-call rotation, you have a single point of failure with a phone.

Sources and further reading

• Amazon EC2 On-Demand Pricing (data transfer rates and free allowance)
• Microsoft Azure Bandwidth Pricing Details
• Google Cloud VPC Network Pricing
• Total cost of ownership and evaluation of Google cloud resources for the ATLAS experiment at the LHC (arXiv:2405.13695)
• NIST Special Publication 800-145: The NIST Definition of Cloud Computing

How this article was produced

Written by Ethan Vaughn and edited to the Techtrendery.com editorial policy. Figures described as illustrative are exactly that and are labelled in the text. If you find an error, tell us through the contact page — corrections are published in place with a dated note.