Every major cloud provider makes it cheap, often free, to move data in. Uploads don’t cost you anything. Compute is billed by the hour or the invocation, storage by the gigabyte-month. But try to move a large dataset out, to another cloud, to your own data center, or even just across regions, and you’ll hit a line item called egress. It’s often the most expensive byte you’ll ever pay for, and it’s not an accident.

What Egress Fees Actually Are

Egress is the charge for data leaving a cloud provider’s network. Ingress is almost always free. This asymmetry isn’t really about the cost of moving bits, network transit is genuinely cheap at cloud scale. It’s a business decision. Free ingress lowers the friction of adopting a platform. Expensive egress raises the friction of leaving it.

For a small app, egress costs are background noise. For a company moving terabytes of logs, backups, or media out for analytics elsewhere, replication to a second cloud, or a full migration, the bill can run into the hundreds of thousands of dollars. That number alone is often enough to kill a migration project before it starts.

Data Gravity

The underlying idea is sometimes called data gravity: the more data you accumulate in one place, the harder it becomes to move, and the more other services (compute, analytics, ML pipelines) get built next to it rather than elsewhere. Egress pricing accelerates this. Once petabytes of data live in one provider’s storage, the cost of relocating them can exceed the cost of just building new infrastructure around them in place.

This is why “multi-cloud” strategies, in practice, often mean running different workloads on different clouds rather than freely shuffling the same data between them. Architects design around the fee, not through it. Data pipelines get built to keep large datasets stationary while compute is layered on top wherever it’s cheapest or fastest, which is itself a workaround for a pricing structure that discourages movement.

The Pushback

Egress fees have drawn enough attention that they’ve become a recurring topic in antitrust and competition discussions, particularly in the EU, where regulators have scrutinized cloud switching costs as a barrier to competition. Some providers have introduced free-egress programs for customers who are leaving their platform entirely, a concession that only exists because the friction was recognized as a real problem. These programs tend to be narrow and conditional, but their existence is itself an admission that egress pricing functions as a retention tool, not just a cost-recovery mechanism.

Independent object storage providers have also used low or zero egress fees as a competitive differentiator, betting that customers will pay a premium elsewhere for the freedom to move data without penalty. It’s a bet that data portability is worth paying for directly, rather than being subsidized by lock-in.

What It Means for Architecture

For teams designing systems today, egress economics are a real constraint, not a footnote. A few practical implications show up repeatedly:

• Keeping compute close to data (running analytics in the same cloud/region as the storage) isn’t just a latency optimization, it’s a cost one.
• Backup and disaster recovery plans that assume you can freely replicate to a second provider need to account for egress in the budget, not just the storage cost.
• Contract negotiations with cloud vendors increasingly include egress terms explicitly, especially for large enterprise deals, because the fee is a known lever.

None of this makes cloud computing a bad deal. It does mean that the sticker price of “storage per gigabyte” is only part of the real cost of where your data lives. The exit cost is a design parameter, and increasingly, a negotiating one.