Every cloud provider charges to move data out of their network. The structure has been the same since the early days of AWS: ingress is free, egress is metered. AWS internet egress runs $0.09 per gigabyte for the first 10 terabytes per month after a 100 GB free tier. Cross-availability-zone transfer is $0.01 per gigabyte per direction. Cross-region runs $0.02 and up. None of these numbers looks alarming on its own. None of them looks like a strategic variable in the architecture review.
That is the point. Egress pricing is designed to be small enough per unit that it disappears in early architecture discussions, and large enough at scale that it shapes the economics of every system that has to move data at scale. By the time a workload's egress bill is large enough to attract attention, the architecture is built around the assumption that egress is cheap, and changing that assumption requires re-architecting the system.
The right way to think about egress is not as a billing line. It is as a strategic variable — a pricing lever the cloud providers have used deliberately to shape customer behavior, and one that has produced predictable patterns in where customers' data lives, where it flows, and how hard it is to move.
What the pricing actually does
The asymmetry between free ingress and metered egress is not an accident. It is a calibrated mechanism that produces data gravity. Once a meaningful volume of data lives in a cloud provider's storage, the cost of moving it elsewhere is significant — and, more importantly, known to the customer in a way that affects every subsequent architectural choice. New workloads get built where the data already is, because moving the data is expensive. Analytic tools get chosen from the provider's own catalog, because pulling data into a third-party tool means egress. Backup strategies favor the same region, because cross-region replication doubles the data transfer bill.
This is rational from the provider's perspective and entirely predictable as a strategic outcome. The interesting question isn't whether the pricing is fair — it's market pricing in a competitive industry — but what enterprises should do about it given that the pricing exists and is unlikely to change in fundamentals.
A few signals suggest the dynamic is shifting at the margins. In 2024, AWS introduced free egress for customers migrating entirely off the platform, with conditions, in response to the EU Data Act's data portability requirements. Google made a similar move. These changes are real, and they matter, but they do not change the day-to-day economics of operating a production workload. They change the cost of leaving, which is a different and narrower question than the cost of running.
Where egress hides in architecture
Egress costs surface predictably in a few patterns, and each one has architectural implications that go beyond the immediate bill.
Multi-region deployments. A workload running in two regions for disaster recovery doubles its data-replication traffic, and that replication crosses regions at $0.02+ per GB in each direction. For a multi-terabyte database, this is a meaningful monthly line item that nobody priced when the resilience requirement was set. Two-region DR is the right call for many workloads; it just isn't free, and the cost should be in the comparison against alternative architectures (longer RPO with backup-and-restore, single-region with multi-AZ, active-passive with snapshot replication).
Multi-cloud strategies. The strategic argument for multi-cloud — vendor diversification, regional coverage, price competition — runs into the egress wall the moment a workload spans providers. Data moving between AWS and Azure is metered going out and metered coming in, with no peering relationship that makes it free. The economics of running a single workload across two clouds rarely pencil out at scale, which is one reason most "multi-cloud" enterprises run different workloads in different clouds rather than the same workload in both. The egress pricing is doing real work in producing this pattern.
CDN and edge architectures. Pushing static content to a CDN edge cuts egress costs from the origin and is one of the few areas where the math works clearly in the customer's favor. CloudFront's own egress pricing is generally lower than direct origin egress, and the first terabyte per month from CloudFront is free. For media-heavy or globally distributed workloads, the architectural choice between serving from origin and serving from edge has a significant egress component that is often the deciding factor at any meaningful scale.
API integrations with external services. Every external API call that returns substantial data — a third-party payment service that returns receipts, a SaaS analytics tool that exports query results, a partner integration that streams events — generates ingress that is free and outbound responses that may or may not be. The egress cost of being highly integrated with external services accumulates quietly. For workloads where the data exchange is significant, this is worth modeling explicitly rather than discovering on the bill.
Caching strategies. The cost of not caching, expressed in egress, is often higher than the cost of caching infrastructure. A workload that fetches the same data from S3 to compute repeatedly is paying internal data transfer on every fetch. A workload that caches in front of S3 — using ElastiCache, or an in-instance cache — pays for the cache infrastructure and then pays nothing for repeated reads. The breakeven is workload-dependent but usually favorable to caching at any meaningful repeat-read pattern.
The TCO model error
Most cloud-versus-on-premises TCO models handle egress badly, in one of two ways.
The first error is ignoring it entirely. Egress is rolled into a vague "network costs" line, sized based on a percentage of compute spend, and never separately validated. The actual egress costs of the workload are typically larger than this estimate by a factor of two to ten, depending on the architecture. The error is consistent enough to be predictable.
The second error is modeling egress at the wrong granularity. The model uses average $/GB across all data transfer, when the actual cost mix includes a small amount of high-cost internet egress, a larger amount of cheap cross-AZ traffic, and a variable amount of cross-region replication. The blended rate is meaningless because the cost composition is not uniform; the relevant question is what each category of transfer costs and what the workload's transfer mix is.
A defensible model treats egress as four separate line items: internet egress (the most expensive), cross-region (significant), cross-AZ (small per GB but easily large in aggregate for chatty distributed systems), and intra-AZ private-IP traffic (free). Each line item has different drivers and different optimization paths. Treating them as one number invites the kind of TCO surprise that gets a CIO summoned to explain why the cloud bill is double what the migration case projected.
What rational handling looks like
Three practices separate organizations that treat egress as a strategic variable from those that discover it as a billing event.
Make egress visible in the architecture review. Every new system or significant change should have an estimated monthly egress cost as part of its design documentation. The estimate doesn't have to be precise — order of magnitude is sufficient — but it has to be made explicitly. The act of estimating surfaces architectural choices that would otherwise be invisible: where the data lives, where the compute is, what calls cross what boundaries. Most of the worst egress surprises come from systems where nobody asked the question at design time.
Treat data placement as a strategic decision. Where data sits determines what it can be used for cheaply, and what it can be used for expensively. A data lake in one provider's storage is not really portable in any practical sense at scale. The choice of where to keep data — and which data to keep at the edge, in cold storage, or replicated for resilience — is one of the longest-lived architectural decisions an enterprise makes, and it deserves a level of deliberation that "we'll put it in S3" usually doesn't get.
Periodically run the leave-cost calculation. What would it cost, today, to move our data off this provider? Not as a migration project — that has its own cost — but specifically the egress component. The number matters not because most enterprises will leave, but because the leave cost is a measure of how much optionality the data placement decisions have surrendered. Watching the leave cost grow over time is watching the abandonment option (see Article #1) being progressively sold. The new AWS migration-egress waiver changes this calculation at the bottom — but only for full exits, and only under specific conditions.
The deeper point
Egress is a small example of a general pattern. Pricing mechanisms that look like billing details are often strategic levers when viewed at scale. The cloud providers' egress pricing has shaped architecture decisions, vendor relationships, and data strategies across the industry for fifteen years. It will continue to do so, in modified forms, as the market matures and regulatory pressure shifts the constraints at the margins.
The enterprises that consistently get good outcomes on cloud cost are the ones that treat pricing as a variable they architect against, rather than as a fact they receive at the end of the month. Egress is the easiest line item on which to demonstrate the difference. The harder line items — committed-use deals, AI inference pricing, SaaS renewal cycles — follow the same logic. Pricing is engineering input. Architecture decides what the bill looks like. The egress invoice is just the most legible example of that broader truth.
Independent. No sponsorships. Unsubscribe anytime.