The cloud's biggest cost surprise is rarely the compute. It is the egress traffic — data leaving the cloud or moving between regions, between availability zones, or between accounts. The unit prices look small ($0.02/GB) until you multiply by terabytes per month and discover that your "compute bill" is half network charges.
This post is the egress patterns that produce surprise charges and the architectural choices that mitigate them.
Where Egress Costs Show Up
Major sources of egress costs on AWS (other clouds have similar pricing):
- Internet egress. Anything leaving AWS to the public internet. $0.09/GB for the first 10 TB, declining tiers.
- Inter-region. Data moving between AWS regions. $0.02/GB.
- Cross-AZ. Data moving between availability zones in the same region. $0.01/GB each way.
- Cross-account. Data moving between AWS accounts (even in the same region). Standard egress.
- NAT Gateway data processing. $0.045/GB for data going through a NAT Gateway, plus $0.045/hour for the NAT itself.
Each of these is a small per-GB number. At scale, they compound into significant bills.
Common Surprise Sources
Cross-AZ traffic on internal services. A service running in three AZs that talks to itself heavily. Each cross-AZ hop is charged. A chatty microservice mesh can produce thousands in monthly costs from internal traffic.
NAT Gateway charges. Workloads in private subnets routing all egress through a NAT Gateway. Each GB through the NAT costs $0.045 in data processing alone. A workload that downloads 1 TB of container images per day costs $1,350/month in NAT data processing.
S3 cross-region replication. Replicating S3 buckets across regions for disaster recovery. The replication transfers are billed as inter-region egress.
CloudFront origin pulls. When CloudFront has a cache miss, it pulls from origin. Origin egress to CloudFront is free, but if your origin is in a different region than expected, you might pay.
External services. Calls to third-party APIs (Stripe, Twilio, etc.) often involve egress to the internet. Heavy API users accumulate egress bills.
Database backups to a different region. Cross-region snapshot copy is egress.
VPC Endpoints
The single highest-leverage optimization for many workloads: VPC Endpoints (also called PrivateLink endpoints).
A VPC Endpoint is a private path from your VPC to a specific AWS service. Without it, traffic to S3 goes out to the public internet and back; with it, traffic stays inside AWS's network.
Without VPC Endpoint:
EC2 → NAT Gateway → Internet Gateway → public S3 endpoint → S3
(NAT charges + bandwidth)
With VPC Endpoint:
EC2 → VPC Endpoint → S3
(no NAT, no bandwidth charges)
Each service that supports VPC endpoints (S3, DynamoDB, KMS, ECR, many others) is a potential cost saving. The endpoint itself costs a small hourly fee, but the data savings dwarf it.
For S3: a Gateway VPC Endpoint is free. Use it. There is no reason not to.
For other services: Interface VPC Endpoints cost $0.01/hour each, plus $0.01/GB data processing. Still cheaper than NAT for high-volume workloads.
Cross-AZ Strategy
For internal traffic that moves a lot of data between AZs:
Reduce AZ count. Running in two AZs instead of three cuts some cross-AZ traffic. Tradeoff with availability.
AZ-aware load balancing. AWS ALB has "AZ-affinity" mode that prefers same-AZ targets. Reduces cross-AZ hops.
Co-locate chatty services. If service A and service B exchange GB of data, run them in the same AZ if possible.
Reduce the actual data volume. Compress payloads, use gRPC over HTTP, reduce unnecessary chatter.
For most workloads cross-AZ is acceptable. For specific high-volume internal data flows, it is worth designing around.
NAT Gateway Optimization
NAT Gateways are convenient and expensive. Patterns to reduce NAT cost:
Use VPC Endpoints for AWS services. As above, this is the biggest win.
Pull container images from a private registry that uses VPC endpoints. Docker Hub pulls go through NAT; ECR with VPC endpoint does not.
Set up an outbound proxy. Especially for static external services, an in-VPC proxy can cache common requests, reducing NAT traffic.
Consider VPC Lattice or Service Connect. For service-to-service traffic across accounts, these can be cheaper than NAT.
For high-traffic workloads: even multiple NAT Gateways become noticeable. Reduce dependence on the NAT path where possible.
S3 Patterns
S3 traffic is a common cost sink, especially when patterns are inefficient.
Same-region. Reads and writes within the same region are free (just request costs). Good.
Cross-region replication. Inter-region egress charges. Only replicate what is necessary for the disaster recovery story.
Egress to internet. S3 to the public internet is regular egress pricing. CloudFront in front of S3 reduces this dramatically.
Lifecycle policies. Moving data to cheaper storage classes (Glacier, IA) reduces storage cost. The egress from these tiers is more expensive — make sure the data is actually cold.
CDN Strategy
CloudFront and other CDNs are simultaneously a cost saver and a cost source.
Saver: CDN caches reduce origin egress. Origin to CloudFront edge is sometimes free; CloudFront to user is cheaper than origin to user.
Source: cache misses cause origin pulls. A poorly configured CDN with high miss rate increases origin egress.
The goal is high cache hit ratio. Track it; it directly correlates to egress cost.
Multi-Account and Cross-Account Egress
AWS multi-account architectures often have surprise egress: traffic between accounts in the same region is billed as if it were leaving the region.
Patterns to reduce:
- VPC peering. Direct VPC-to-VPC connections within a region avoid the egress charge.
- Transit Gateway. For larger architectures with many VPCs. Adds hourly cost; saves egress.
- VPC Lattice. Newer service for cross-VPC and cross-account services without the network-layer complexity.
For small setups, simple solutions are fine. For organizations with dozens of accounts, network architecture meaningfully affects egress cost.
Cross-Region Egress
When workloads span regions:
- DR replication. Necessary cost. Calculate based on data size and acceptable lag.
- Latency-driven multi-region. If users in Asia need fast response, you pay for the data that goes to Asia. This is a real cost of going multi-region.
- Mistake-driven multi-region. A service in us-east-1 talking to a database in us-west-2 because nobody noticed. Expensive and slow.
The third one is the surprise. Audit cross-region traffic patterns for unexpected dependencies.
Inter-Cloud and Hybrid Egress
For workloads that span clouds or include on-premises:
- AWS to GCP: AWS egress + GCP ingress (GCP ingress is usually free). Cheaper than AWS-to-internet.
- AWS to your data center via Direct Connect: lower per-GB egress, but hourly Direct Connect fees.
- AWS to your data center via VPN: standard egress prices.
For sustained high-volume traffic to on-prem: Direct Connect (or equivalents on other clouds) usually pays back.
Monitoring Egress
Cost dashboards alone are not enough. You want to know which traffic flow is producing the bill.
- VPC Flow Logs. Capture every flow. Analyze to identify high-bandwidth sources and destinations.
- AWS Cost Explorer with usage types. Filter by
DataTransfer-Out-Bytes,NatGateway-Bytes, etc. - Service-level monitoring. Each service should know how much data it sends. Surface in observability.
A monthly review of egress costs alongside the compute review surfaces problems before they become surprises.
A Practical Reduction Project
For a team noticing high egress costs:
- Enable VPC Endpoints for every service you use. S3 first (free), then DynamoDB and ECR.
- Audit NAT Gateway traffic. Identify high-volume sources.
- Identify cross-AZ chatter. Reduce or co-locate.
- Audit cross-region flows. Eliminate accidental cross-region dependencies.
- Check CDN cache hit rate. Improve if low.
- Compress data where it crosses cost boundaries. Gzip, Brotli, gRPC instead of JSON over HTTP.
This effort typically reduces egress 30-50%. It is engineering work, not configuration; budget it accordingly.
The Strategic Reality
Egress costs are not going to zero. They are the cloud's structural advantage — providers charge for the most valuable resource (network capacity off their backbone) the most.
The discipline is:
- Know what your egress costs are
- Identify the biggest sources
- Apply the optimizations that pay back the effort
- Accept the rest as a cost of doing business on the cloud
The teams that handle this well treat network architecture as a real engineering concern, not an afterthought. The ones that do not get reminded by the bill every month.
Looking at a cloud bill where the egress charges are bigger than the compute? We help teams identify the high-leverage optimizations that actually reduce the bill. scopeforged.com