Networking
Network performance and cost
Task statements 3.4 and 4.4 ask you to design networks that are fast and cheap. Most of this comes down to knowing where AWS charges for data transfer, and which features increase network performance.
Where data transfer costs money
| Traffic | Typical charge |
|---|---|
| Internet → AWS (inbound) | Free |
| Within the same AZ using private IPs | Free |
| Between AZs in the same Region | Charged (per GB, in each direction) |
| Between Regions | Charged |
| AWS → internet (outbound) | Charged, tiered |
| Through a NAT gateway | Hourly + per GB processed |
| Via gateway endpoints (S3, DynamoDB) | Free |
| Via interface endpoints | Hourly + per GB (often cheaper than NAT processing) |
| CloudFront to users | Usually cheaper than serving directly from origin; origin → CloudFront transfer is free from AWS origins |
| Direct Connect | Lower data transfer out rates than internet |
Key idea
Common cost wins: use gateway endpoints for S3/DynamoDB instead of NAT; serve content through CloudFront; keep chatty components in the same AZ where availability allows; avoid unnecessary cross-Region replication.
NAT gateway design trade-off
| Design | Pros | Cons |
|---|---|---|
| One NAT gateway per AZ | Highly available; no cross-AZ traffic | More hourly cost |
| One shared NAT gateway | Cheaper for dev/test | Single point of failure; cross-AZ charges |
Production → one per AZ. Non-production → a shared one is often acceptable (the exam guide explicitly tests this choice).
Choosing connectivity on cost and bandwidth
| Option | Bandwidth | Cost profile |
|---|---|---|
| Internet | Variable | No fixed cost; standard egress rates |
| Site-to-Site VPN | Up to ~1.25 Gbps per tunnel; more with multiple VPNs + ECMP on Transit Gateway | Low hourly cost |
| Direct Connect | 1/10/100 Gbps dedicated; hosted from 50 Mbps | Port-hour charges; cheaper egress for large volumes |
Performance features
For EC2
- Enhanced networking (Elastic Network Adapter, ENA) — higher bandwidth, lower latency, more packets per second; on by default with current instance types.
- Elastic Fabric Adapter (EFA) — for HPC and ML training needing very low-latency inter-node communication.
- Instance size matters — network bandwidth scales with instance type and size.
- Placement groups:
| Type | Layout | Use |
|---|---|---|
| Cluster | Packed close together in one AZ | Lowest latency, highest throughput between instances (HPC) — but a single rack/AZ risk |
| Spread | Each instance on distinct hardware (max 7 running instances per AZ per group) | Small numbers of critical instances that must not fail together |
| Partition | Groups of instances in separate partitions (racks), up to 7 partitions per AZ | Large distributed systems (HDFS, Cassandra, Kafka) |
At the edge
- CloudFront for content, Global Accelerator for TCP/UDP apps, Route 53 latency routing for multi-Region.
For APIs: throttling
- API Gateway throttles requests (account-level default limits, plus per-stage/method and usage plans with API keys per customer).
- SQS in front of a backend absorbs bursts so it isn't overwhelmed.
- WAF rate-based rules limit abusive clients.
Placing resources
- Put compute near data (same Region, ideally same AZ for chatty traffic).
- Use Local Zones or Wavelength for single-digit-millisecond latency to specific metro or mobile users.
- Use Outposts when processing must stay on-premises.
Exam patterns
- "Reduce NAT gateway costs for heavy S3 traffic from private subnets" → S3 gateway endpoint.
- "HPC nodes need the lowest possible latency between them" → cluster placement group (+ EFA).
- "A Kafka cluster must survive rack failures" → partition placement group.
- "Reduce data transfer costs for a global static website" → CloudFront.
- "Protect a backend from traffic spikes from API clients" → API Gateway throttling/usage plans, SQS buffering.
Written by Bipin Singh
Work with meSenior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.