Data egress and cross-zone transfer charges are shaping an architecture's cost. What design decisions actually reduce them, and what is commonly done that does not help?

Why egress shapes architecture

Egress pricing is asymmetric: inbound is typically free, outbound to the internet is expensive, and cross-region and cross-zone transfer sit in between. That asymmetry creates data gravity — data attracts compute, because moving compute to data is free and moving data to compute is not.

The architectural consequence is that processing should happen where the data already is, and designs that casually move large volumes across boundaries carry a cost that grows with success.

What actually reduces it

• Compress everything, which is the highest-value, lowest-effort change and is frequently partially implemented. Modern algorithms reduce typical API and log payloads substantially, and the compute cost is trivially small relative to the transfer saving.
• Cache at the edge. A CDN serves from the edge at a lower price than origin egress, and the cache hit ratio is directly a cost metric, not only a performance one.
• Process data where it lives. Aggregate, filter and summarise at the source rather than transferring raw data to be reduced elsewhere. The most common expensive mistake is exporting raw data across a boundary to compute a small result.
• Co-locate chatty services in the same zone, with cross-zone replication only for redundancy rather than for every internal call. Multi-AZ designs incur cross-zone transfer on a large fraction of internal traffic by default, and zone-aware routing that prefers a local instance while retaining cross-zone failover is usually a substantial saving.
• Private connectivity for high-volume partner traffic, which is priced far below internet egress.
• Reduce payload sizes — field selection, pagination, binary encodings, avoiding over-fetching. An API that returns whole objects when clients need three fields is an egress cost multiplied by every call.
• Eliminate redundant transfers: the same data fetched repeatedly instead of cached, or replicated to regions that never read it.

What is commonly done and does not help

• Moving to a cheaper region. Egress pricing varies little and the migration cost is large.
• Negotiating a discount without changing the volume, which reduces the rate and leaves the growth curve intact.
• Removing multi-AZ redundancy to save cross-zone transfer, which trades a large availability loss for a modest saving — almost always the wrong trade, and the fix is zone-aware routing rather than fewer zones.
• Micro-optimising small payloads while a single batch export job dominates the bill. Attribute first; the distribution is usually extreme.
• Multi-cloud for negotiating leverage, which introduces cross-cloud transfer at the highest prices available and typically increases the total.

The measurement that must exist

Egress attributed by source, destination and workload. Without it, the conversation is guesswork, and the usual finding is that a small number of flows — a replication job, a log shipping pipeline, an analytics export, one chatty service pair across zones — account for the majority. That is a targeted fix rather than an architecture-wide efficiency campaign, and it is far cheaper.