Definition
Egress cost is the fee a cloud provider charges when data leaves its network, moving out to the public internet, to a user's device, or to another cloud provider entirely. If a server in AWS sends a file to a customer's browser, that transfer is egress, and depending on volume and destination, AWS bills for it. The word itself just means an exit, and that is exactly what the fee is attached to, the moment data crosses the boundary out of the provider's network rather than staying inside it, no matter how briefly it existed there in the first place.
The fee exists because moving data across a network genuinely costs the provider money, in the physical infrastructure of routers, links, and peering arrangements with other networks, and providers have historically priced that cost onto customers rather than absorbing it. There is also a less charitable explanation that gets discussed constantly in cloud cost circles: egress fees are steep enough, and asymmetric enough compared to how cheap it is to bring data in, that they function as a real disincentive to moving your data to a competing provider once it already lives somewhere.
What distinguishes egress cost from just general bandwidth usage is the direction and the destination. Moving data between services inside the same cloud provider's network, especially within the same region, is often free or drastically cheaper than moving that same volume of data out to the internet or to another cloud. A naive view treats all data movement as roughly the same cost. The reality is a steep asymmetry, where staying inside one provider's walls is nearly free and leaving them is where the real charges show up on a bill.
By 2026, egress cost has become one of the most discussed and most criticized line items in cloud billing, enough that some providers now offer free egress in specific circumstances, like leaving a provider entirely if you are migrating away, following pressure from customers and, in some regions, from regulators concerned about vendor lock-in. It remains, for most workloads, one of the least intuitive parts of a cloud bill, since a team can build something that works perfectly and still get an unpleasant surprise the first month real user traffic starts pulling data out at scale.
This page covers how egress charges are actually calculated and billed, how egress compares to the ingress side of the ledger, and where the fee genuinely matters versus where it is a rounding error not worth architecting around. The idea worth keeping is that egress cost is a function of where your data goes, not just how much of it there is. Two workloads moving the same volume of data can end up with wildly different bills depending on whether that data stayed close to home or crossed out to the open internet.
Key Takeaways
- Egress cost is what a cloud provider charges when data leaves its network, typically to the internet or to another cloud provider.
- It exists partly because moving data really does cost infrastructure money, and partly because it discourages customers from leaving for another provider.
- Egress is priced asymmetrically to ingress: bringing data in is usually free or cheap, while sending it out is where charges concentrate.
- By 2026, egress fees are a well known pain point in cloud billing, with some providers waiving them in specific migration scenarios.
- The cost depends heavily on destination and volume, so identical amounts of data movement can produce very different bills depending on where the data actually goes.
How Egress Cost Works
Cloud providers meter data leaving their network at the point it crosses out, typically measured in gigabytes or terabytes per month, and bill it according to a tiered rate schedule where the per gigabyte price usually drops as volume climbs. A small application serving a modest amount of traffic might barely notice the charge, while an application serving large files, video, or heavy API responses to a wide audience can see egress become one of the largest line items on the entire bill.
Rates typically vary by destination as well as volume. Data moving to the public internet is usually the most expensive category, data moving to another region within the same provider often costs less, and data moving between services in the same region is frequently free entirely. Moving data to a specific named partner network or through a direct connection can carry its own separate pricing, which adds another layer a team has to actually look up rather than assume, and that lookup is easy to skip until the bill makes it unavoidable.
Content delivery networks change the picture somewhat, since serving cached content from a CDN edge location can be priced differently, and sometimes more favorably, than serving the same content straight from origin storage or a origin server, which is one reason CDNs get adopted for cost reasons as much as for speed. Some providers price CDN egress lower specifically to encourage using it, since a cached response served from the edge also means less origin traffic for the provider to carry across its own backbone.
The billing itself usually shows up as a distinct line item, separate from compute or storage, and it is metered continuously rather than something you can predict from a fixed configuration the way you might estimate compute cost from instance size. This makes egress one of the harder costs to forecast ahead of a launch, since it depends directly on how much real traffic shows up and where that traffic is actually located, both of which are genuinely hard to know precisely before something ships.
Egress Cost Compared to Ingress Cost
Ingress is data moving into a cloud provider's network, and the near universal practice among major providers is to make ingress free or nearly free, regardless of volume. Uploading a large dataset, backing up files, or sending logs into a cloud service typically does not show up as a meaningful charge on its own, which makes it easy for a team to build a mental model where moving data is generally cheap, right up until they start moving substantial volumes back out.
The asymmetry is deliberate rather than incidental. It costs a provider real infrastructure either direction, yet the pricing is structured so that getting data in is nearly frictionless while getting it out carries a real, sometimes significant cost. This is not a technical necessity so much as a business one, and it is the detail that turns cloud cost conversations from a purely technical topic into one that also involves negotiating leverage and vendor relationships that most engineers never sat down expecting to think about at all.
The practical effect is that architectures which pull a lot of data in and process it there, without needing to send large volumes back out, end up cheap in a way that surprises nobody, while architectures that ingest data cheaply and then need to serve or export a large share of it back out discover the real cost only once traffic is flowing. A batch analytics pipeline that ingests raw data and produces a small summary report barely touches egress. A media platform serving files directly to users lives or dies by it.
This asymmetry is also central to why cloud cost planning should never treat data movement as a single, symmetric cost. Estimating a workload's total data transfer bill by looking only at total volume moved, without separating what portion goes out versus what portion comes in, will produce a number that is close to meaningless, since the two directions are priced on completely different scales, and a plan built on that meaningless number tends to be wrong in exactly the direction that hurts.
What Makes Egress Cost Different From Bandwidth
Bandwidth is a technical measure of network capacity, the maximum rate at which data can move across a given link, usually expressed as some number of bits or bytes per second. It describes what a network connection is capable of carrying, independent of who is paying for what or in which direction the data happens to be moving at any given moment. A gigabit connection has a gigabit of bandwidth whether it is fully used or sitting completely idle at three in the morning.
Egress cost is a billing concept layered on top of that underlying capacity, charging for the volume of data that actually used some of that capacity to leave a provider's network over a period of time. You can have plenty of available bandwidth and still receive a large egress bill simply because a lot of data moved through it, and conversely a connection can be bandwidth constrained without that constraint having anything to do with how the resulting traffic gets billed.
People conflate the two because both terms describe aspects of the same underlying network activity, and casual conversation about a slow application or a high bill often uses them interchangeably. But a bandwidth problem is a performance issue, showing up as slow transfers or throttled connections, while an egress cost problem is a financial issue, showing up as a bigger invoice, and the fix for one is rarely the fix for the other. Upgrading bandwidth does not lower a bill, and lowering a bill does not by itself improve throughput.
Understanding the split matters because teams sometimes chase the wrong fix. A team surprised by a large data transfer bill does not need more bandwidth, since the pipe was clearly wide enough to carry the traffic that generated the charge. What it usually needs is a change to what data leaves the network at all, through caching, compression, or moving the destination closer to where the data already lives, none of which has anything to do with the size of the connection itself.
Where Egress Cost Matters and Where It Does Not
Egress cost matters a great deal for any workload that serves substantial content directly to end users over the open internet, such as video streaming, large file downloads, or an API that returns heavy payloads to a broad audience. It also matters for multi cloud or hybrid architectures that regularly move data between providers, since that kind of movement usually counts as egress on at least one end of the transfer and can quietly become one of the largest recurring costs in the whole setup.
It matters as well for any organization actively evaluating a move away from its current cloud provider, since the cost of exporting years of accumulated data can itself become a real obstacle to leaving, independent of how good the technical case for switching might be. This is exactly the dynamic that has drawn regulatory attention in some markets, precisely because the fee can function as a barrier to switching rather than a reflection of actual transfer cost, which is a distinction regulators have started to take seriously.
It matters far less for workloads that are mostly internal, processing data and producing small outputs, or for applications with a modest, well understood user base where total data volume never gets large enough for the per gigabyte rate to add up to anything noticeable. A backend service that ingests data, crunches it, and writes a summary to a database rarely needs anyone to think hard about egress at all, since almost nothing of consequence ever leaves that network in the first place.
It also matters less once a workload is entirely contained inside one provider's region and one provider's services, where most transfer between components is free or steeply discounted. The moment that changes, adding another region, another cloud, or a lot of direct traffic to end users, egress moves from an ignorable line item to something worth actually modeling before it shows up as a surprise on an invoice nobody was watching closely, especially once the growth compounds quarter over quarter.
How to Manage Egress Cost Well
Model your expected data transfer patterns before launch rather than after the first surprising bill, separating internal traffic that stays within a provider's network from traffic that will actually leave to reach end users or another cloud. A rough estimate based on expected user volume and typical payload size, done ahead of time, is far more useful than reacting to an invoice after the fact, once the pattern is already locked into how the system was built and much harder to unwind cheaply.
Use a content delivery network for anything served repeatedly to many users, since serving from a cache at the network edge both improves performance and often reduces the effective cost compared to serving every request straight from origin. This is one of the rare cases where a change made for speed and a change made for cost point in exactly the same direction, which makes it an easy recommendation to act on quickly rather than debate at length across several planning meetings.
Compress what you can before it leaves the network, whether that is images, video, or API responses, since a smaller payload moving the same route directly lowers the metered volume that egress pricing is based on. This is a fairly cheap engineering investment that pays back continuously for as long as the traffic keeps flowing, rather than a one time fix that stops mattering once it ships and everyone moves on to the next project on the roadmap without a second thought.
Keep frequently moved data close to where it is actually used, placing services and their data in the same region when possible so that routine internal traffic stays inside the free or heavily discounted tier rather than crossing a boundary that triggers a charge every time two components need to talk to each other over what should be a short, cheap hop rather than a costly, roundabout one that nobody designed on purpose in the first place and everyone ends up paying for regardless.
Watch multi cloud and cross region traffic specifically, since these transfers are the ones most likely to be egress in both directions and the ones teams are least likely to notice growing quietly over time. A regular look at the data transfer line item on the bill, broken down by direction and destination, tends to surface a cheap architectural fix long before the cost becomes painful enough to force an urgent, more expensive one instead of a planned improvement made calmly.
Best Practices
- Model expected data transfer patterns before launch, separating internal traffic from traffic that will actually leave the network.
- Serve frequently requested content through a CDN rather than straight from origin, which often helps cost and speed together.
- Compress payloads before they leave the network so the same content generates a smaller metered transfer volume.
- Keep services and the data they use in the same region so routine internal traffic avoids triggering egress charges.
- Review the data transfer line item on your bill regularly, broken down by direction and destination, rather than only after a spike.
Common Misconceptions
- Egress cost is not the same as bandwidth; bandwidth is network capacity, while egress cost is a bill for volume of data that actually left the network.
- Egress is not priced the same as ingress; providers typically make data coming in nearly free while charging real money for data going out.
- Egress cost is not only about total volume of data moved; destination matters just as much, since internal transfer is often free while transfer to the internet is not.
- A CDN does not eliminate egress cost entirely; it changes where and how the transfer is priced, and origin traffic still counts when the cache misses.
- Low egress spend today does not mean it will stay low; growth in either user traffic or multi cloud data movement can turn it into a major cost quickly.
