Egress Fee Economics and Their Impact on Cloud Architecture Decisions

The invoice arrives on a Tuesday, usually during a quarterly budget review, and it has a line item nobody remembers approving. Egress works differently. It accumulates in the background across backup syncs, API responses, DR tests, and cross-region replication, and it stays invisible until someone finally pulls the itemized breakdown. By then the architecture is built, the traffic patterns are set, and the number is already large.

That asymmetry is not an accident of billing design. AWS, Azure, and GCP all make ingress free and meter egress per gigabyte from the first byte past a small monthly allowance, and all three hyperscalers apply that structure deliberately. Data flows in at no charge. Data flows out at a price, and the price is attached to the one direction that matters most when a customer wants to leave.

Egress also refuses to behave like compute at the volumes most mid-market teams actually run. Compute tends to get cheaper per unit as workloads scale, through reserved capacity, better utilization, committed-use discounts. Egress does not extend that courtesy: a workload that grows five times over produces egress that grows five times over, with no efficiency curve bending the line downward. There is no bulk discount for being popular.

And the price has a thin relationship to the underlying cost. Wholesale internet bandwidth in 2026 costs a tiny fraction of what providers charge per gigabyte of egress, with the gap between the two running roughly two orders of magnitude. Egress pricing is a billing mechanism with a second job: keeping data where it already lives.

The full egress cost surface, including the charges engineers rarely model upfront

Most teams build their budget around internet-bound egress and stop there, missing three other categories that compound at the same rate or faster.

Start with the rates themselves, because they vary enough to matter. AWS charges $0.09/GB for the first 10 TB of internet egress per month, tapering at higher volume tiers, with 100 GB free. Azure charges $0.087/GB for the first 10 TB, with a similar taper and the same 100 GB free allowance. GCP charges $0.12/GB for the first 1 TB, dropping to $0.08/GB between 1 and 10 TB, free within the same location and $0.01/GB between locations on the same continent. These numbers look manageable in isolation. They stop looking manageable once four or five traffic categories are drawing from the same meter simultaneously.

Cross-cloud transfers are the first trap. Moving data from one major provider to another is billed as ordinary internet egress, so a company evaluating a move off one provider pays egress on the sending side before a single service has been replatformed. The toll gets collected at the border crossing, not at the destination.

Then there's the rest of the networking stack that nobody files under "egress" but behaves exactly like it. Egress data transfer, public IPv4 addresses, and NAT Gateway processing together add up to what amounts to a hidden 18% tax on total cloud spend for organizations running multi-cloud or hybrid architectures. AWS has charged a per-address hourly fee for public IPv4 addresses since February 2024, and you pay it whether the address is actively serving traffic or just sitting there, reserved. An enterprise running hundreds of microservices can accumulate hundreds of these addresses without anyone treating address allocation as a cost decision, because for most of cloud history, it wasn't one.

Compounding Egress Costs at Scale

The trouble is not that any single egress rate is unreasonable. The trouble is that the architectural patterns considered best practice generate egress from several directions at once, and the bill is the sum of all of them.

Take the three-availability-zone deployment, which is the standard recommendation for high availability. It also generates significant cross-AZ fees annually for traffic that never leaves the cloud provider's own network, let alone touches the public internet. Resilience has a toll booth built into it.

Feature releases add an entirely separate growth vector, one that is disconnected from user growth. A single product decision can drive a meaningful egress increase within weeks, and nothing in the compute or storage dashboards will flag it, because compute and storage didn't change.

The scale of this adds up fast. A single terabyte of internet egress per day, at AWS standard rates, runs roughly $2,700 a month. A mid-market company running several applications that average a few hundred gigabytes of daily egress combined can cost tens of thousands per month in egress alone, before compute, storage, or support costs enter the conversation.

AI inference adds its own layer. A large FP16 model carries substantial weight, so if an inference server restarts daily and pulls those weights fresh from object storage each time, that single habit costs hundreds of dollars a month in egress, and it scales linearly with the number of inference workers running the pattern. Agentic workflows compound the problem further: agentic tools issue far more LLM calls than a simple chatbot does, and one workflow spawning dozens of subtasks can produce a bill nobody modeled, because nobody thought to model subtask sprawl as a network cost.

Uber offers the clearest illustration available. Sophisticated engineering shops are not immune to this. They adopt the tooling faster. That means they hit the wall faster.

A newer category has joined the list: AI crawler traffic increased substantially through 2025, and bandwidth costs from that crawler traffic now run into the thousands of dollars per month for mid-sized sites, a category that simply did not exist in the architectures built a few years earlier.

How Egress Pricing Warps Multi-Cloud Strategy

Multi-cloud sounds like a resilience strategy on a whiteboard and turns into a tax bracket in production. The architecture that looks safest on paper is often the one that gets taxed the hardest in practice.

That is not an accident of pricing. Free ingress paired with expensive egress functions as a vendor lock-in mechanism, because it makes extracting data financially impractical long after the technical work of extraction would otherwise be simple. The toll is on taking data back out, not on bringing it in.

This is where the thesis of this piece turns from observation into claim: egress fees do not just inflate a bill, they actively shape which architectures get built. Teams that want to minimize egress consolidate into a single availability zone, suppress multi-region replication, and avoid cross-cloud synchronization, and every one of those moves trades directly against availability, resilience, and compliance requirements. Teams that refuse to make that trade, because fault tolerance actually matters to them, pay the cross-AZ tax regardless of how carefully they design around it. There is no clean exit from this bind. There is only a choice about which cost to absorb.

Data gravity makes the bind worse over time. Gravity, in this sense, describes how switching costs accrue silently in the background, the same way the egress bill itself does.

Regulators have taken notice of the pattern. Competition authorities in both the UK and the EU have flagged egress fees as potentially anti-competitive, but the practical relief available to a normal cloud customer running ongoing operations stays limited. Scrutiny has arrived. Relief at the register has not, at least not yet, and that gap sets up the question the next section has to answer honestly.

What the EU Data Act actually changes, and what it deliberately leaves alone

The EU Data Act targets one specific event: a full provider exit. It leaves the ongoing operational costs that make up the overwhelming majority of a typical egress bill completely untouched.

The shape becomes clear when the regulation is read for what it does not cover. Egress between availability zones, egress between regions, egress to the internet, egress to monitoring and logging platforms, and egress to a second provider in a running multi-cloud setup all remain fully billable under the Data Act. The steady-state bill, the one driving the compounding described in the sections above, does not move.

Regulation also cannot untangle a data landscape that took years to lock itself into proprietary services. The deepest lock-in most organizations carry comes from dependency on proprietary services built up over time, not from egress pricing in isolation, and no switching-fee ban rewires that dependency after the fact. The access-by-design obligation under the Data Act applies to connected products placed on the EU market after 12 September 2026. New workloads designed after that date face a meaningfully different regulatory environment than the estate already running in production today.

Teams planning architecture now cannot lean on regulatory relief for the egress costs they will pay while their systems are live and operating. The January 2027 deadline governs what happens at exit. It says nothing about what happens at design time, and design time is when the costs described in this piece actually get locked in.

Modeling Egress Costs Before They Shape Architecture

Egress forecasting deserves its own modeling discipline, separate from the usual compute and storage planning, and the teams that treat it as a first-class input end up building fundamentally different systems than the teams that don't.

Start by pulling twelve months of egress charges broken out by service, separate from compute and storage.

From there, estimate steady-state egress per workload using average daily gigabytes transferred, multiplied by 30, multiplied by the relevant provider tier rate. Add inter-region and replication overhead as its own line rather than folding it into the general total: continuous replication for multi-region failover often accounts for half the egress bill at companies that never bothered to track it as a separate category.

For AI workloads, model weight loading is a recurring event that carries its own ongoing egress cost. The number of inference workers, multiplied by restart frequency, multiplied by model size, produces a baseline egress cost that exists before a single user query gets served. For agentic workflows, apply the token and API call multiplier, which runs many times higher than a standard chatbot, and translate that multiplier directly into egress wherever the LLM provider charges for outbound responses or the orchestration layer crosses a network boundary on every tool call.

Once the modeled number exists, compare it against real architectural alternatives before committing to a design: colocation for high-bandwidth applications, keeping compute next to the storage it reads from to eliminate inter-AZ chatter, and routing internet-bound traffic through a CDN. Each of these choices changes the cost surface in a measurable way, and each should be priced out before the architecture diagram gets finalized, not after.

Architectural patterns that reduce egress exposure without trading away resilience

The most effective reductions work by changing where traffic terminates, not by suppressing the traffic itself. Some of the highest-leverage moves live at the network edge.

CDN offloading changes the accounting structure. When a CDN absorbs internet-bound traffic, the charge shifts from per-gigabyte origin egress to CDN pricing, which is structured differently and typically carries volume-based economics the origin pricing never offered. For media-heavy and content-heavy workloads, this single change often cuts cost more than anything else available.

Logging and monitoring egress is controllable in a way few teams treat it as being. Where an external SIEM is a hard requirement, aggregating and compressing the data before export reduces volume without sacrificing the fidelity a security team needs.

Running security and traffic inspection at the network edge, rather than at the origin server, changes the calculus for DDoS and bot traffic specifically. One stopped at the edge generates neither.

For AI inference, caching model weights at the inference layer rather than re-pulling them from object storage on every restart converts a recurring egress charge into a one-time load.

And if a team runs several point solutions stitched together, a unified network platform that handles security, CDN, and compute as one system removes the inter-vendor traffic that a fragmented stack generates by its own structure. Every service boundary in a multi-vendor architecture is a potential egress event. Collapsing those boundaries onto a single network removes the charge at the source.

Treating egress as a first-order constraint in 2026 architecture decisions

Egress belongs alongside compute and latency as a first-order constraint on architecture, not a line item to reconcile after the design is already locked. Teams that model it only after deployment accept a cost structure someone else built for them.

The EU Data Act's January 2027 deadline changes what it costs to leave a provider. It does not change the economics of running a workload day to day, and the ongoing architectural discipline described throughout this piece remains necessary regardless of which jurisdiction a company operates in.

AI and agentic workloads raise the stakes. Infrastructure decisions that looked fine at chatbot-scale can become prohibitively expensive at agentic-scale, because token consumption and API call frequency multiply the egress surface by an order of magnitude, often within a single budget cycle.

Egress modeling belongs in the architecture review, not the finance review. Data gravity builds up when architectural decisions get deferred long enough to calcify, and teams that treat provider placement as a first-class design variable, priced out before deployment, keep options that teams defaulting to convenience lose for good.

The question that cuts through all of it is simple to state and hard to keep asking: for every major data flow in the system, where does the traffic terminate, and who gets billed for that termination? Answering that question at design time, for each significant flow, separates teams paying for the architecture they chose from teams paying for the architecture they inherited.