The Cost of Moving Packets
In a physical data center, a network cable is a sunk cost — once it's installed, you don't pay per packet. In the cloud, every network boundary has a tollbooth. The pricing model reflects the underlying infrastructure: traffic that stays within a single Availability Zone is essentially free; traffic that crosses AZ boundaries, region boundaries, or exits to the internet incurs per-GB charges.
Understanding these boundaries is not optional for senior engineers. A system that looks elegant on a whiteboard can generate thousands of dollars per month in unexpected data transfer costs the moment it goes to production.
The Four Network Boundaries (Cheapest to Most Expensive)
| Boundary | Direction | Typical Cost |
|---|---|---|
| Within the same AZ | Any | Free |
| Between AZs in the same Region | Both directions | ~$0.01/GB each way |
| Between AWS Regions | Outbound | ~$0.02–$0.08/GB |
| From AWS to the Internet | Outbound | ~$0.09/GB (first 10 TB) |
These numbers seem small. At scale, they are not. A service transferring 100 TB/month between AZs pays ~$1,000/month in transfer fees alone — for traffic that adds zero business value.
Architectural Pattern 1: Zone Affinity
The problem: You have an application tier in Zone A and a database in Zone B. Every database query crosses the AZ boundary and incurs a ~$0.01/GB charge in each direction.
The fix — Zone Affinity: Deploy database replicas in each AZ and configure your application to prefer the replica in its own AZ. Traffic stays local; the inter-AZ charge disappears.
Zone A: [App Server] ──(free)──► [DB Replica A]
Zone B: [App Server] ──(free)──► [DB Replica B]
Instead of:
Zone A: [App Server] ──($0.01/GB)──► [DB in Zone B]
Zone affinity requires your application or service mesh to be AZ-aware. In Kubernetes, this is implemented using Topology Spread Constraints and Service topology routing. In AWS, Application Load Balancers support Cross-Zone Load Balancing — disabling it (or using target group-level control) ensures traffic stays within its originating AZ.
Architectural Pattern 2: VPC Endpoints (Eliminating NAT Gateway Costs)
The problem: Your private EC2 instances need to access AWS services like S3 or DynamoDB. Without a VPC Endpoint, this traffic routes through a NAT Gateway — which charges both an hourly fee (~$0.045/hour = ~$32/month) and a per-GB processing fee (~$0.045/GB). For a service that reads 10 TB/month from S3, that's $450/month in NAT Gateway processing fees alone.
The fix — VPC Endpoints: A VPC Endpoint creates a private route from your VPC directly to the AWS service, bypassing the NAT Gateway entirely. Traffic never leaves the AWS network.
Without VPC Endpoint:
[EC2 in Private Subnet] → [NAT Gateway] → [Internet] → [S3]
Cost: $0.045/GB processing + $0.09/GB egress
With VPC Endpoint (Gateway type for S3/DynamoDB):
[EC2 in Private Subnet] → [VPC Endpoint] → [S3]
Cost: $0.00 (Gateway endpoints are free)
There are two types of VPC Endpoints:
- Gateway Endpoints: Free. Available only for S3 and DynamoDB. Implemented as a route table entry.
- Interface Endpoints (PrivateLink): Charged per hour + per GB. Available for most other AWS services (SQS, SNS, Secrets Manager, etc.). Still cheaper than NAT Gateway for high-volume traffic.
Architectural Pattern 3: Egress Optimization
Internet egress (data leaving AWS to end users or external systems) is the most expensive data transfer category. Strategies to reduce it:
- CloudFront (CDN): Cache static assets at edge locations. Users download from the nearest edge node; your origin only serves cache misses. CloudFront's egress pricing is lower than direct EC2/S3 egress, and the cache hit rate dramatically reduces origin traffic.
- Compression: Compress API responses (gzip/brotli). Reduces bytes transferred, directly reducing egress costs.
- Regional architecture: If your users are concentrated in one geography, deploying in the nearest region reduces latency and avoids cross-region transfer fees.
A common interview scenario: "Your AWS bill shows $50,000/month in data transfer costs. Walk me through how you'd diagnose and reduce it." Structure your answer around the four boundaries: (1) Check for inter-AZ traffic — enable zone affinity. (2) Check NAT Gateway processing fees — add VPC Endpoints for S3/DynamoDB. (3) Check internet egress — add CloudFront and compression. (4) Check cross-region replication — evaluate whether it's necessary. This structured approach demonstrates systematic thinking rather than guessing.