| Provider | Monthly free egress tier | Standard rate beyond free tier | Notable 2026 change |
|---|---|---|---|
| AWS | 100 GB | ~$0.09/GB (first 10 TB) | Waives egress fees for customers closing their account and moving all data out |
| Azure | 100 GB | ~$0.087/GB | Matched AWS/GCP in waiving full-exit egress charges since 2024 |
| Google Cloud | Free-egress program expanded to 100 TB/month | ~$0.12/GB (first 1 TB) beyond the program | Free-egress allowance grew from 2 TB/month (2024) to 100 TB/month |
What Egress Fees Actually Charge You For
Cloud providers price compute and storage aggressively — often near or below cost — because the real margin has historically come from the asymmetry between getting data in and getting data out. Ingress (data moving into a cloud provider’s network) is free on every major platform. Egress (data leaving that network to the public internet, to another provider, or in some cases even between regions) is metered and billed, typically per gigabyte, on a tiered schedule that gets cheaper at higher volumes but never reaches zero for a typical workload.
The economic logic is straightforward: the moment your data starts flowing out at scale, you’re usually either serving end users directly (which egress fees capture as pure margin) or preparing to move workloads to a competitor (which egress fees discourage by making the move itself expensive). This is why egress pricing has historically been the least transparent, least negotiable line item on a cloud bill, and why it draws far more regulatory attention than compute or storage pricing.
It’s worth separating three distinct charges that often get lumped together under “egress”: data transfer to the public internet, cross-region transfer within the same provider, and cross-availability-zone transfer within a single region. Each is priced differently, and architectures that ignore the distinction often get surprised by cross-AZ charges that accumulate silently inside what looks like a single-region deployment.
How AWS, Azure, and Google Cloud Price Data Leaving Their Network
Pricing structures are broadly similar in shape — a small free tier, then declining per-gigabyte rates as volume grows — but the specifics diverge enough to matter for architecture decisions. As of 2026, AWS and Azure both offer roughly 100 GB of free monthly egress before charging in the $0.087–$0.09/GB range for the next tier, declining further at higher volumes. Google Cloud priced its first tier higher per gigabyte historically, but dramatically expanded its free-egress allowance — from 2 TB per month in 2024 to 100 TB per month in 2026 — which changes the calculus for workloads with moderate, steady egress rather than for genuinely massive transfers.
The bigger shift has been regulatory, not competitive. In March 2024, AWS followed Google Cloud in waiving data-transfer-out charges specifically for customers who are closing their account and moving all remaining data to another provider or on-premises infrastructure — a direct response to pressure building around the EU’s Data Act. Azure made equivalent commitments. This waiver only applies to full exits within a defined transition window (commonly 60 days after approval), not to routine day-to-day egress from an active workload, which remains fully billed at standard rates. For background on how this fits into a broader architectural strategy, see our companion piece on designing a cloud exit strategy from day one.
Comparing storage classes matters just as much as comparing raw egress rates, since the cheapest storage tier is sometimes attached to the least favorable retrieval and transfer terms — a pattern covered in more detail when comparing AWS S3, Google Cloud Storage, and Azure Blob side by side.
Figure 1: The Egress Cost Curve
A line chart with monthly data volume (GB) on the x-axis and cumulative egress cost on the y-axis, plotting three lines for AWS, Azure, and Google Cloud. All three lines start at zero through each provider’s free tier, then rise in a series of flattening steps as volume-based discount tiers kick in. The Google Cloud line stays flat far longer than the other two before its curve begins climbing, reflecting its much larger 100 TB/month free-egress allowance, while AWS and Azure’s curves begin climbing almost immediately past 100 GB.
Free-tier size, not the marginal per-gigabyte rate, is often the bigger driver of real-world egress bills for small and mid-sized workloads.
Data Gravity: Why Your Workloads Are Already Stuck
The term “data gravity” was coined by engineer Dave McCrory in 2010, using a direct physics analogy: just as mass attracts mass, data attracts applications, analytics tools, and additional data. The larger a dataset grows, the more services get built to query it, the more compliance and access processes wrap around it, and the more expensive and disruptive it becomes to move — not because moving the bytes themselves is impossible, but because everything that has grown up around those bytes has to move too, or be rebuilt elsewhere.
McCrory draws a useful distinction between natural and artificial data gravity. Natural data gravity is the organic accumulation described above — more data breeds more applications, which breeds more data. Artificial data gravity is imposed externally: egress pricing, data residency law, and contractual terms that make moving data expensive or illegal regardless of the dataset’s actual size. Egress fees are the clearest example of artificial data gravity in the cloud market — a deliberate pricing structure that reinforces the natural stickiness data already has.
The practical consequence for architects is that data gravity compounds silently. A dataset that costs $200 a month to fully export today might cost $20,000 a month in two years, not because per-gigabyte pricing changed, but because the dataset itself grew tenfold while a dozen new services quietly started depending on its being co-located with compute. This is precisely why organizations standardizing on portable, multi-region Kubernetes deployments treat data placement as a first-class design decision rather than an afterthought — once a dataset has enough gravity, redesigning around it is far more expensive than designing around it from the start.
Figure 2: The Data Gravity Well
A concentric-circle diagram with a large dataset icon at the center. Surrounding rings, drawn progressively closer to the center as their dependency grows, represent an analytics dashboard, a machine learning pipeline, a compliance/audit process, and a customer-facing application — each connected to the center by a line whose thickness represents data volume moved per day. A dotted outer boundary labeled “artificial gravity” surrounds the whole diagram, annotated with “egress pricing + data residency law,” showing these external forces compressing the whole system further inward over time.
Natural data gravity (the inner rings) and artificial data gravity (the outer boundary) reinforce each other, making mature datasets progressively harder to relocate.
Architectural Patterns That Minimize Egress Costs
Egress cost is largely a function of architecture, not just data volume — the same dataset can generate wildly different egress bills depending on where compute sits relative to data, and how aggressively responses are cached before they ever have to leave the provider’s network.
Caching and CDN placement remain the single highest-leverage pattern. Every request served from a cache or edge location at the CDN layer is a request that never generates origin egress at all. Tuning cache-hit ratio, setting sensible time-to-live values, and routing static and semi-static content through a content delivery network — as detailed in our step-by-step guide to implementing a CDN on cloud platforms — routinely cuts origin egress by 60–90% for content-heavy applications. Teams just getting started on a major cloud platform should build this in from the first deployment rather than retrofitting it, a pattern also covered in our guide to launching a first cloud application on AWS.
Data locality and regional processing is the second major lever: instead of centralizing all data in one region and shipping it to compute wherever that happens to run, process data as close as possible to where it’s generated and stored, and only move smaller, aggregated results across regions or providers. This inverts the usual pattern of moving raw data to centralized compute, and can reduce cross-region egress dramatically for analytics and IoT-style workloads. It’s also the architectural pattern most directly relevant to the broader shift toward multi-cloud and hybrid deployment that most enterprises now report running in some form.
Compression and format efficiency is the least glamorous but most immediately actionable lever: switching from verbose JSON or uncompressed formats to compressed, columnar formats (Parquet, ORC) for bulk data movement routinely cuts egress-billed bytes by 60–80% with no architectural change at all, only a format change in the export pipeline.
Read replicas and edge caching layers for databases reduce the need to repeatedly ship the same query results across a network boundary, particularly for read-heavy, geographically distributed user bases.
| Pattern | Mechanism | Typical egress reduction |
|---|---|---|
| CDN / edge caching | Serves repeat requests from edge nodes instead of the origin | 60–90% for content-heavy apps |
| Data locality / regional processing | Moves compute to data instead of shipping raw data to compute | Highly variable; largest for analytics and IoT workloads |
| Compression / columnar formats | Reduces bytes transferred per export or replication job | 60–80% on bulk transfers |
| Read replicas near users | Avoids repeated cross-region query traffic | Moderate; scales with read volume |
- Step 1 — Measure first:Break down current egress spend by service, destination, and traffic type before changing anything; you cannot optimize what you haven’t measured.
- Step 2 — Cache aggressively at the edge:Push static and semi-static content to a CDN and tune cache-hit ratio as the primary lever, not an afterthought.
- Step 3 — Localize processing:Move compute to where data already lives instead of shipping raw data to centralized compute.
- Step 4 — Compress before you transfer:Use columnar, compressed formats for any bulk export or cross-region replication job.
- Step 5 — Re-measure and set budgets:Set a per-service egress budget and alert on it, the same way compute and storage budgets are already tracked.
Figure 3: Where Caching Breaks the Egress Loop
A simple request-flow diagram showing a user request arriving at a CDN edge node. A branching arrow labeled “cache hit (no origin egress)” points to a direct response back to the user, while a second branch labeled “cache miss” travels to the origin server, incurs origin-to-edge egress cost, and is then cached for subsequent requests. A running counter beside the diagram shows cache-hit ratio climbing from 40% to 85% across three iterations, with a corresponding origin egress cost bar shrinking at each step.
Each percentage point of cache-hit ratio improvement directly and proportionally reduces billed origin egress.
The Regulatory Shift: The EU Data Act and the End of Exit Egress Fees
Regulation has moved faster than most architects expected. The EU Data Act entered into force in January 2024 and became applicable in September 2025, and its Article 23 specifically targets “obstacles to effective switching,” including data egress charges levied when a customer moves to a different provider. Article 25 sets a transitional period during which reasonable switching fees may still apply, but mandates that providers serving EU customers stop charging any switching-related fees — egress included — entirely from January 2027 onward. This is a direct regulatory attack on artificial data gravity: lawmakers explicitly identified egress pricing as an anticompetitive lock-in mechanism, not merely a cost-recovery measure.
The practical effect for architects outside the EU is still significant, because AWS, Azure, and Google Cloud have generally chosen to implement exit-egress waivers globally rather than build region-specific billing logic — meaning the 2024 waivers for full-account closures already apply well beyond EU customers in practice. But the waiver only covers the act of leaving, not ongoing operational egress, which remains a live architectural cost that the patterns above are designed to address.
Common Mistakes When Architecting Around Egress
Common mistakes
Optimizing storage cost while ignoring egress terms. Choosing the cheapest storage class without checking its retrieval and transfer pricing often produces a bill that’s higher overall than a slightly more expensive tier with better egress terms.
Treating cross-region traffic as free because it’s “internal.” Cross-region and even cross-AZ transfer within the same provider is billed, just at lower rates than internet egress — architectures that replicate data across regions without accounting for this routinely underestimate cost.
Assuming the 2024 egress waivers cover ongoing usage. The waivers apply specifically to full-account exits within a defined window, not to routine day-to-day data movement from an active workload.
Under-investing in CDN and cache tuning. Teams often treat caching as a performance feature only, missing that it is usually the single largest lever available for reducing egress cost.
Ignoring data gravity until a migration is already underway. By the time a migration is planned, natural data gravity has often already made the dataset the single most expensive part of the move — waiting to address it is the most common planning failure.
In Practice: How Experienced Teams Architect Around the Egress Tax
In practice
Teams that manage egress cost well treat it as a first-class metric in their FinOps dashboards, tracked per service and per destination alongside compute and storage spend, rather than discovering it as a surprise line item at the end of the month. They set egress budgets the same way they set compute budgets, with alerts that fire when a service’s transfer volume deviates from its historical baseline — often the first sign of a misconfigured replication job or an accidental full-table export.
On the data gravity side, experienced teams make data placement decisions with the same rigor as compute placement decisions, explicitly documenting which datasets are expected to grow large enough to become gravity wells, and deliberately keeping compute co-located with those datasets from the start rather than centralizing everything by default. When cross-region or cross-provider access is genuinely required, they favor replicating smaller, aggregated, or pre-processed views rather than shipping raw data repeatedly — a pattern that keeps egress cost proportional to the value extracted rather than to the size of the underlying dataset.
Finally, mature teams re-evaluate their CDN and caching configuration on a recurring schedule, not just at initial launch, since cache-hit ratio degrades naturally as content and traffic patterns evolve — an unmonitored CDN configuration from eighteen months ago is a common, quietly expensive source of avoidable egress.
Glossary
- Egress fee
- A per-gigabyte charge applied by a cloud provider when data leaves its network to the public internet, another provider, or in some cases another region.
- Data gravity
- The tendency of applications, analytics, and additional data to accumulate around a large existing dataset, making that dataset progressively harder and more expensive to move.
- Artificial data gravity
- Externally imposed factors — such as egress pricing or data residency law — that increase the cost or difficulty of moving data, distinct from the natural accumulation of dependent applications.
- Ingress
- Data transferred into a cloud provider’s network, which is free on essentially all major platforms.
- Cross-region transfer
- Data movement between two geographic regions within the same cloud provider, billed separately from internet egress, typically at a lower rate.
- Cache-hit ratio
- The percentage of requests served directly from a cache or CDN edge node rather than the origin server, directly affecting billed egress volume.
- Data locality
- An architectural pattern that processes data as close as possible to where it is generated or stored, minimizing the need to transfer raw data across network boundaries.
- EU Data Act
- European Union regulation, applicable from September 2025, that restricts obstacles to cloud switching, including egress charges, with a full ban on switching fees from January 2027.
Key Takeaways
- Egress fees exist because ingress is free and egress is metered — the asymmetry funds cloud margins and discourages moving data to competitors.
- AWS, Azure, and Google Cloud all offer roughly 100 GB of free monthly egress, but Google Cloud’s expanded 100 TB/month free-egress program changes the math for moderate-volume workloads.
- Since March 2024, major providers waive egress fees specifically for full-account exits, and the EU Data Act bans all switching fees, egress included, from January 2027 — but ongoing operational egress remains fully billed.
- Data gravity, coined by Dave McCrory in 2010, describes how applications and analytics naturally accumulate around large datasets, compounding the cost of moving them over time.
- Artificial data gravity — egress pricing and data residency law — reinforces natural data gravity, and regulators now explicitly treat it as an anticompetitive lock-in mechanism.
- Caching, CDN placement, data locality, and compression are the four highest-leverage architectural patterns for reducing egress cost without changing what the application actually does.
- Egress and data gravity should be tracked as first-class FinOps metrics, with per-service budgets and alerts, not discovered as a surprise at the end of the billing cycle.
FAQs
Why do cloud providers charge for egress but not ingress?
Free ingress encourages customers to move data in and start using compute and storage services, which are the primary revenue drivers. Metered egress both captures margin on data serving and creates a practical disincentive against migrating workloads to a competing provider.
Do the 2024 egress fee waivers apply to all customers, or only during a full migration?
They apply specifically to customers who are closing their account and moving all remaining data to another provider or on-premises infrastructure, generally within a defined transition window such as 60 days. Routine, ongoing egress from an active workload is not covered and remains fully billed.
What’s the difference between natural and artificial data gravity?
Natural data gravity is the organic accumulation of applications and analytics around a large dataset simply because it’s valuable and convenient to build near it. Artificial data gravity is imposed externally, through mechanisms like egress pricing or data residency law that make moving the data expensive or illegal regardless of its size.
Which architectural change has the biggest impact on reducing egress costs?
For most content-serving applications, improving CDN cache-hit ratio delivers the largest single reduction, often cutting origin egress by 60-90%. For data-heavy analytics workloads, relocating compute closer to the data (data locality) typically has the larger impact.
Does the EU Data Act affect cloud customers outside the European Union?
Indirectly, yes. Because AWS, Azure, and Google Cloud generally chose to implement their 2024 exit-egress waivers as global policies rather than EU-specific billing rules, customers outside the EU already benefit from the same full-exit fee waivers, even though the underlying regulation targets EU switching specifically.
Is cross-region data transfer within the same provider considered egress?
It’s billed as a distinct category from internet egress, usually at a lower per-gigabyte rate, but it is still a metered charge. Architectures that replicate data across regions without accounting for this frequently underestimate their total transfer costs.
How does compression reduce egress costs in practice?
Switching bulk data exports from verbose, uncompressed formats to compressed, columnar formats like Parquet or ORC can reduce the actual bytes transferred by 60-80%, directly lowering the billed egress volume without any change to the underlying data or architecture.
Should egress cost be tracked separately from general cloud spend?
Yes. Because egress cost is driven by architecture decisions (caching, data placement, replication patterns) rather than raw compute or storage sizing, it needs its own budget, its own alerts, and its own owner within a FinOps practice to be managed effectively.
References
- The Register. “Amazon Agrees to Waive Egress Fees for Disgruntled Users.” March 5, 2024. https://www.theregister.com/2024/03/05/aws_data_egress/
- SiliconANGLE. “AWS Follows Google Cloud in Canceling Egress Fees, Allowing Customers to Leave Its Cloud Platform for Free.” March 2024. https://siliconangle.com/2024/03/05/aws-follows-google-cloud-canceling-egress-fees-allowing-customers-leave-cloud-platform-free/
- EU Data Act. “Article 23, Removing Obstacles to Effective Switching.” https://www.eu-data-act.com/Data_Act_Article_23.html
- EU Data Act. “Article 25, Contractual Terms Concerning Switching.” https://www.eu-data-act.com/Data_Act_Article_25.html
- Digital Realty. “Data Gravity Index: As Trade Flows, Data Flows.” https://www.digitalrealty.com/resources/reports/data-gravity-index
- Google Cloud. “VPC Network Pricing.” https://cloud.google.com/vpc/network-pricing
- Microsoft Azure. “Bandwidth Pricing.” https://azure.microsoft.com/en-us/pricing/details/bandwidth/
