Architecture/Fundamentals/data-transfer-and-egress-costs

Data Transfer and Egress Costs

Concept

Cloud providers price compute and storage visibly and predictably, but data transfer — specifically egress, data leaving the provider's network — is billed separately and is where cost estimates most often go wrong. The pricing asymmetry is deliberate: data moving into a cloud provider (ingress) is free on every major provider, while data moving out to the public internet is billed per GB, and the rate escalates further for cross-region and cross-provider transfer. This isn't an accident of infrastructure cost — free ingress and metered egress is a well-documented strategy that makes it cheap to move data in and expensive to move it back out, which shapes real architecture decisions about where compute should live relative to data.

The cost adds up in less obvious places than "downloading a file to a user." Cross-AZ traffic within a region is typically billed (a service in us-east-1a calling a service in us-east-1b pays a per-GB charge on both directions), cross-region replication for disaster recovery or multi-region reads is billed at the higher inter-region rate, and CDN/edge-serving traffic is priced differently again (often cheaper than direct origin egress, which is one of the practical reasons a CDN pays for itself beyond just latency). A multi-cloud or hybrid design that moves large datasets between providers — replicating a data lake from one cloud to another for analytics, for instance — can turn transfer fees into the single largest line item on the bill, dwarfing the compute cost of the analytics job itself.

Tradeoffs

Traffic path	Typical cost	Common trigger
Ingress (into the cloud)	Free on all major providers	Uploading data, client requests inbound
Intra-AZ traffic	Free	Services co-located in the same availability zone
Cross-AZ, same region	Billed, low per-GB rate	Multi-AZ deployments for resilience — the tradeoff is deliberate: pay for cross-AZ traffic to gain availability
Cross-region	Billed, higher per-GB rate	Multi-region DR replication, geo-distributed reads
Egress to public internet	Billed, highest per-GB rate, often tiered	Serving end users, exporting data to another provider
Egress via CDN	Billed, but typically cheaper than direct origin egress	Content delivery, static asset serving

The tradeoff isn't "avoid cross-AZ/region traffic entirely" — multi-AZ resilience and multi-region DR are architecturally necessary in most serious systems, and their transfer cost is the deliberate price of that resilience (see Disaster Recovery Strategies). The real tradeoff is where compute runs relative to the data it processes: co-locating compute with its data (running the analytics job in the same region as the data lake, rather than pulling the data cross-region to a compute cluster elsewhere) is often the highest-leverage cost lever available, because it eliminates a cost category entirely rather than optimizing it.

When to use / when not to

Architect for data locality by default — put compute in the same region (ideally the same AZ, where the resilience tradeoff allows) as the data it reads most frequently, rather than centralizing compute and pulling data to it repeatedly.
Use a CDN for anything served repeatedly to end users over the public internet — it's cheaper egress than direct origin serving in nearly every provider's pricing, on top of the latency benefit.
Batch and compress cross-region or cross-provider transfers rather than making many small transfers — per-request overhead aside, the billed volume is the same, so compression directly reduces the bill.
Don't design a multi-cloud architecture that routinely moves large datasets between providers without pricing out the egress cost first — it's a common case where the "avoid vendor lock-in" motivation quietly loses to a transfer bill that exceeds the savings it was meant to protect.
Don't treat cross-AZ egress avoidance as a reason to run single-AZ — that trades a real, ongoing, usually modest cost for a resilience posture that's expensive in a very different currency (downtime) when the AZ fails.

Common pitfall

Sizing a multi-region or multi-cloud architecture's cost purely on compute and storage, and discovering the real number only after the data-transfer bill arrives. Egress pricing is usually a smaller line item on the pricing page than compute and storage, which makes it easy to underweight during design — but for any workload that moves meaningful data volume across AZ, region, or provider boundaries repeatedly (not once), the transfer cost compounds with usage in a way compute and storage costs, which scale more predictably with the workload's actual size, often don't.

Principal Engineer Lens

Egress cost is one of the few line items that directly rewards a specific architectural choice (data locality) rather than a purely operational one (right-sizing instances, reserved capacity) — which makes it a good architecture-review question: "where does this data live relative to where it's processed, and what does that cost per GB moved." It's also one of the more visible ways vendor pricing strategy shapes system design in practice — free ingress and metered egress is a real lock-in mechanism, and being able to name that tradeoff explicitly (rather than discovering it via a surprise bill) is exactly the kind of cost-pillar fluency that reads as Principal-level judgment in a cloud-spend review, in Fintech/BigTech data platform work as much as anywhere else.