Cloud egress costs arrive as a billing surprise. They appear across dozens of line items that nobody owns, growing steadily month over month in a way that makes attribution difficult and root cause harder to establish. The standard response is a FinOps review, compression middleware, and a CDN deployment. These reduce the symptom. They do not remove the cause. By the time egress is large enough to appear on a cost report worth escalating, the architectural decisions generating it are typically months old, in production, and too expensive to revisit cleanly. Managing egress at the billing layer is the cloud equivalent of treating engine noise with better soundproofing.
The scale is consistently underestimated. Data egress accounts for 6-12% of typical cloud bills and, in distributed architectures spanning multiple availability zones or regions, that share can reach 30-40% of total spend. What makes it difficult to see is that it never appears as a single charge. Internet egress, cross-AZ transfer, NAT Gateway processing, cross-region replication, and managed service data movement are separate line items, each individually modest, each growing proportionally with request volume rather than with time. The aggregate is invisible until someone specifically goes looking. Architectural patterns generating the largest egress bills are not misconfigurations; they are correct decisions, made without egress as a design input, whose cost compounds as the system scales. Fan-out patterns, active-active replication for high availability, and logging pipelines draining to centralised observability platforms all generate ongoing data movement that was never costed at design time.
The cross-AZ category is the most pervasive and the least discussed. Availability zones within the same region are not free to communicate. AWS charges $0.01 per GB in each direction for cross-AZ data transfer, making every inter-service call that crosses a zone boundary a billable event in a multi-AZ microservices deployment, which is the correct architectural choice for high availability. A moderately busy EKS cluster with ten terabytes per month of inter-AZ traffic pays around $200 per month in pure network fees, from an architectural constraint that was never modelled as a cost. The resilience patterns explored in our guide to multi-region cloud architecture address RTO and RPO with precision. They rarely model what the data movement those patterns imply costs at production volume. Teams measure availability metrics carefully; almost none have measured the egress contribution of their availability architecture.
The Locality Principle
The tactical responses to a large egress bill are not wrong. Compression halves payload sizes on high-volume JSON APIs. VPC endpoints eliminate NAT Gateway processing fees for S3 and DynamoDB traffic. CDN deployment shifts internet egress to cheaper edge rates with cache-hit economics. But these are interventions on a system that moves too much data, applied after the architecture has already been built. The more durable fix is locality: designing computation to happen where the data already lives, rather than pulling data to where computation runs. A data pipeline that copies datasets between storage tiers at each processing stage, a training job that reads from a remote bucket on every epoch, or an analytics workload that exports query results to a third-party platform rather than querying in place are all generating egress that reflects a design choice. Serverless query engines, Athena and BigQuery among them, exist precisely because running compute adjacent to data is cheaper than moving the data. The egress cost of a workload is a function of where that workload runs relative to its data, a constraint that belongs in the unit economics model as described in our cloud unit economics guide.
The teams that keep egress under control are not the ones running the most rigorous FinOps reviews. They are the ones who modelled data movement as a design constraint before the architecture was approved, not after the first meaningful invoice arrived. The question “what does this data transfer cost at ten times current volume?” asked during an architecture review prevents the entire category of problem that FinOps audits address retrospectively. Cross-region egress thresholds can be alertable conditions, set at deployment, that surface violations from scheduled jobs and background replication processes that nobody has reconsidered since they were first configured. Making egress a first-class constraint in architecture review documentation means the decision is recorded, the volume is modelled, and the trade-off between data movement cost and architectural correctness is explicit rather than invisible.
The bill is a lagging indicator. The architecture decision is the leading one. Getting egress costs under control means modelling data movement before the architecture is approved, not auditing line items after the invoice arrives. Most egress surprises are not the result of bad architectural decisions. They are the result of good architectural decisions made without egress as one of the inputs. That gap, between correct design and cost-modelled design, is where most of the problem lives.
