AWS Networking Best Practices: VPC, CloudFront, and Connectivity Guide

Technical TL;DR

Networking = Foundation of Cloud. Wrong design = costly re-architecture.

Key takeaways:

---

1. VPC Design Best Practices

1.1 VPC Architecture: Multi-AZ by Default

All production VPCs must span multiple Availability Zones.

Standard VPC Architecture:

```yaml

VPC CIDR: 10.0.0.0/16 (65,536 IPs)

Subnets per AZ:

- Public: 10.0.{AZ}.0/24 (256 IPs)

- Private: 10.0.{AZ+10}.0/24 (256 IPs)

- Isolated: 10.0.{AZ+20}.0/24 (256 IPs)

Example (us-east-1):

- Public-1A: 10.0.1.0/24 (ALBs, NAT Gateway)

- Public-1B: 10.0.2.0/24 (ALBs, NAT Gateway)

- Private-1A: 10.0.11.0/24 (EC2, RDS, ECS)

- Private-1B: 10.0.12.0/24 (EC2, RDS, ECS)

- Isolated-1A: 10.0.21.0/24 (RDS, ElastiCache)

- Isolated-1B: 10.0.22.0/24 (RDS, ElastiCache)

```

1.2 CIDR Block Planning

Plan CIDR blocks to avoid IP exhaustion and enable VPC peering.

CIDR Selection Guidelines:

```yaml

Production: 10.0.0.0/16 (65K IPs) - sufficient for most

Staging: 10.1.0.0/16 (65K IPs)

Development: 10.2.0.0/16 (65K IPs)

VPC Peering Considerations:

- Non-overlapping CIDRs required

- Plan for future peering (use /16, not /20)

- Document CIDR allocation spreadsheet

Avoid:

❌ 172.31.0.0/16 (EC2-Classic default, conflicts)

❌ Overlapping CIDRs across accounts

```

1.3 Subnet Sizing Strategy

Subnet sizing depends on use case and future growth.

| Subnet Type | CIDR Size | Max IPs | Use Case |

|-------------|-----------|---------|----------|

| **Public** | /24 | 256 | ALBs, NAT Gateways (rarely need more) |

| **Private** | /22 or /23 | 1,024 or 512 | EC2, ECS, EKS (room for growth) |

| **Isolated** | /26 or /27 | 64 or 32 | RDS, ElastiCache (few resources needed) |

Sizing Formula:

```yaml

Required IPs = (Resources × 2) + Buffer

Example: 50 EC2 instances per AZ

→ 50 instances × 2 = 100 (for HA + growth)

→ /25 subnet (128 IPs) or /24 (256 IPs for safety)

```

1.4 Route Tables: Explicit Routing

Route tables control subnet traffic flow.

Public Subnet Route Table:

```yaml

Destination | Target

---------------|-----------------------

10.0.0.0/16 | Local

0.0.0.0/0 | Internet Gateway

```

Private Subnet Route Table:

```yaml

Destination | Target

---------------|-----------------------

10.0.0.0/16 | Local

0.0.0.0/0 | NAT Gateway

```

Isolated Subnet Route Table:

```yaml

Destination | Target

---------------|-----------------------

10.0.0.0/16 | Local

(No internet route)

```

1.5 NAT Gateway: Cost and Redundancy

NAT Gateways enable outbound internet from private subnets.

NAT Gateway Architecture:

```yaml

One NAT Gateway per AZ (required for AZ-level redundancy)

Cost: $0.045/hour = ~$32/month per NAT Gateway

+ Data processing: $0.045/GB

Example: 2 AZs = 2 NAT Gateways = $64/month + data costs

```

Cost Optimization:

```yaml

Option 1: NAT Gateway (recommended for production)

- High availability (AZ-level redundancy)

- Managed service (AWS handles maintenance)

- Cost: $32/month per NAT Gateway

Option 2: NAT Instance (cost-sensitive workloads)

- EC2 instance running NAT AMI

- Cost: ~$5-15/month (t3.nano/t3.micro)

- Trade-off: Manual management, single point of failure

Option 3: VPC Endpoints (preferred for AWS service access)

- No NAT Gateway required for S3, DynamoDB, etc.

- Cost: $0.01/endpoint/hour (offsets NAT Gateway costs)

```

---

2. VPC Peering and Connectivity

2.1 VPC Peering: Same Region

VPC peering connects two VPCs as if they were one network.

Use Cases:

```yaml

☐ Multi-account environments (prod, staging, dev in separate accounts)

☐ Microservices (different services in separate VPCs)

☐ Migrations (gradual VPC transition)

☐ Environment isolation (dev, test, prod separation)

```

Peering Configuration:

```yaml

Prerequisites:

- Non-overlapping CIDR blocks

- One-way peering request (accepter accepts)

- Route table updates (both VPCs)

- Security group updates (allow peered CIDR)

Limitations:

- No transitive peering (A-B-C requires A-C peering)

- Same region only (use Cross-Region VPC Peering for inter-region)

```

2.2 Transit Gateway: Multi-VPC Hub

Transit Gateway acts as a hub for many VPCs.

When to Use Transit Gateway:

```yaml

✓ 3+ VPCs requiring connectivity

✓ Hub-and-spoke topology (centralized security, inspection)

✓ Hybrid connectivity (on-prem + AWS)

✓ Multi-region connectivity (via inter-Region attachments)

```

Cost Calculation:

```yaml

Transit Gateway: $0.05/hour (~$36/month)

Attachment: $0.05/hour per attachment (~$36/month each)

Data transfer: Per-GB rates

Example: 1 TGW + 5 VPC attachments

→ $36 + (5 × $36) = $216/month before data transfer

```

2.3 PrivateLink: Private Service Access

PrivateLink exposes services to other VPCs privately.

Use Cases:

```yaml

☐ Third-party service access (without internet)

☐ Service exposure across accounts (secure, private)

☐ SaaS integration (private connectivity vs. public internet)

☐ API gateway private access

```

Benefits:

```yaml

☐ No internet gateway required

☐ No VPN required

☐ No VPC peering required

☐ Traffic stays within AWS network

```

---

3. CloudFront: Global Content Delivery

3.1 CloudFront Architecture

CloudFront is AWS's CDN. 400+ points of presence globally.

How It Works:

```yaml

User → CloudFront Edge Location (cache hit)

↓

Origin (S3, ALB, or custom origin)

If Cache Hit:

- Response from edge location (milliseconds latency)

- No load on origin

If Cache Miss:

- CloudFront fetches from origin

- Caches for future requests

```

3.2 CloudFront Distributions

Two types of distributions:

| Distribution Type | Use Case | Features |

|------------------|----------|----------|

| **Web** | HTTP/HTTPS content | Custom SSL, multiple origins, cache behaviors |

| **RTMP** | Media streaming | Adobe Flash media (legacy) |

Web Distribution Configuration:

```yaml

Origin Settings:

- Origin Domain: S3 bucket, ALB, or custom domain

- Origin Protocol Policy: HTTPS only (security)

- Origin Access Control: Restrict S3 access (OAI or OAC)

Default Cache Behavior:

- Allowed HTTP Methods: GET, HEAD (read-only)

- Cached Methods: GET, HEAD (cache these)

- Viewer Protocol Policy: Redirect HTTP to HTTPS

- TTL: 86400 seconds (1 day default)

Behaviors:

- Default: /* (all content)

- Custom: /api/* (bypass cache for dynamic content)

- Custom: /images/* (longer TTL for static assets)

```

3.3 Cache Policies: Optimize Performance

Cache policies control what gets cached and for how long.

Cache Policy Settings:

```yaml

Managed Cache Policies:

- CachingDisabled: No caching (API, dynamic content)

- CachingOptimized: Cache everything (static assets)

- Amplify: For Amplify deployments

Custom Cache Policy:

- Cache key: Include/exclude headers, cookies, query strings

- TTL: Minimum, Maximum, Default

Example Cache Policy (Static Assets):

- TTL: 31536000 seconds (1 year)

- Cache key: None (ignore headers, cookies, query strings)

- Compress: Yes (automatic GZIP/Brotli)

```

3.4 Origin Access Control: Secure S3 Access

OAC restricts S3 bucket access to CloudFront only.

Configuration:

```yaml

1. Create Origin Access Control in CloudFront

2. Set Origin Access Control on distribution origin

3. Update S3 bucket policy (auto-generated by AWS)

4. S3 bucket now only accessible via CloudFront

Result: No public S3 access required

```

Benefits:

```yaml

☐ S3 bucket not publicly accessible

☐ CloudFront signed URLs/cookies for additional security

☐ DDoS protection via CloudFront (Shield Standard included)

☐ Geographic restrictions via CloudFront

```

---

4. Route 53: DNS and Traffic Management

4.1 Hosted Zones: Public and Private

Route 53 manages DNS domains.

| Hosted Zone Type | Use Case |

|------------------|----------|

| **Public** | Internet-facing domains (example.com) |

| **Private** | VPC-internal DNS (internal.example.com) |

Public Hosted Zone Configuration:

```yaml

1. Register domain (via Route 53 or external registrar)

2. Create hosted zone (example.com)

3. Configure NS records at registrar (point to Route 53)

4. Add records (A, AAAA, CNAME, MX, etc.)

```

4.2 Routing Policies: Traffic Management

Route 53 offers multiple routing policies.

| Routing Policy | Use Case | Latency |

|----------------|----------|---------|

| **Simple** | Single resource (ALB, EC2, S3) | N/A |

| **Failover** | Active-passive DR | Automatic failover |

| **Geolocation** | Country-based routing | User location |

| **Geoproximity** | Latency-based with bias | User proximity |

| **Latency** | Lowest latency region | Automatic detection |

| **Weighted** | Canary, A/B testing | % split |

| **Multivalue** | Multiple resources (return up to 8) | Random selection |

Failover Configuration:

```yaml

Primary Record:

- Type: A

- Alias: Yes (to ALB us-east-1)

- Health Check: Yes (primary-health-check)

- Failover: Primary

Secondary Record:

- Type: A

- Alias: Yes (to ALB us-west-2)

- Health Check: Yes (secondary-health-check)

- Failover: Secondary

Behavior:

- Route to primary if healthy

- Failover to secondary if primary unhealthy

```

4.3 Health Checks: Proactive Monitoring

Health checks monitor endpoint health.

Health Check Configuration:

```yaml

Endpoint: HTTP/HTTPS endpoint to monitor

- Protocol: HTTPS

- Port: 443

- Path: /health

- Request interval: 30 seconds

- Failure threshold: 3 health checks

Health Check Types:

- Endpoint: Monitor HTTP/HTTPS/TCP endpoint

- Calculated: Monitor other health checks (child health checks)

- State: Monitor CloudWatch alarm (e.g., CPU > 80%)

Alerting:

- Configure SNS notifications for health check failures

- CloudWatch alarms for health check status

```

---

5. Direct Connect: Hybrid Networking

5.1 When to Use Direct Connect

Direct Connect provides dedicated network connection to AWS.

| Factor | Direct Connect | VPN |

|---------|----------------|-----|

| **Bandwidth** | 50 Mbps - 100 Gbps | Up to 1.5 Gbps (VPN) |

| **Latency** | Consistent | Variable (internet) |

| **Security** | Private network | Encrypted over internet |

| **Cost** | High (port + data transfer) | Low (hourly + data transfer) |

| **Use Case** | Production, high-volume | Dev/test, low-volume |

Use Direct Connect if:

```yaml

☐ 1+ Gbps sustained bandwidth to AWS

☐ Consistent latency required (trading, real-time)

☐ Regulatory requirement (private network, not internet)

☐ Large data transfers (daily backups, migrations)

```

5.2 Direct Connect Architecture

Direct Connect links your data center to AWS Direct Connect location.

Connection Types:

```yaml

Dedicated Connection:

- 1 Gbps, 10 Gbps, or 100 Gbps

- Physical fiber connection

- Cost: ~$0.30/Mbps/month (varies by region)

Hosted Connection:

- 50 Mbps - 10 Gbps

- Provisioned via AWS Partner

- Cost: Variable (partner pricing)

```

5.3 Public vs. Private Virtual Interfaces

Direct Connect supports two types of virtual interfaces.

| VIF Type | Use Case | Routes |

|----------|----------|--------|

| **Private** | VPC access (Direct Connect Gateway) | VPC prefixes |

| **Public** | Public AWS services (S3, DynamoDB) | Public IP prefixes |

Recommended Configuration:

```yaml

☐ Private VIF for VPC access (required)

☐ Public VIF for S3, DynamoDB (optional but recommended)

☐ Redundant connections (two Direct Connect links for HA)

```

---

6. Network Security

6.1 Security Groups: Stateful Firewalls

Security groups control instance-level inbound/outbound traffic.

Best Practices:

```yaml

☐ Whitelist specific ports/protocols (no 0.0.0.0/0 for inbound)

☐ Use security group references (not IPs when possible)

☐ Document rules in description (who, why, when)

☐ Regular audits (remove unused rules via Trusted Advisor)

☐ Separate SGs per tier (web, app, database)

```

6.2 NACLs: Stateless Network Control

NACLs operate at subnet level (stateless, both directions).

When to Use NACLs:

```yaml

☐ Subnet-level guards (complement security groups)

☐ Temporary blocks during incident response

☐ Compliance requirements for network ACLs

```

Example NACL (Private Subnet):

```yaml

Inbound Rules:

Rule 100: Allow TCP 1024-65535 from 10.0.0.0/8 (return traffic)

Rule 200: Allow TCP 443 from 10.0.0.0/8 (HTTPS)

Rule *: Deny all (default)

Outbound Rules:

Rule 100: Allow TCP 443 to 0.0.0.0/0 (HTTPS)

Rule 200: Allow TCP 1024-65535 to 0.0.0.0/0 (ephemeral)

Rule *: Deny all (default)

```

6.3 AWS Shield: DDoS Protection

Shield Standard is automatic. Shield Advanced requires subscription.

| Feature | Shield Standard | Shield Advanced |

|---------|-----------------|-----------------|

| **Cost** | Free (included) | $3,000/month + usage |

| **Protection** | Infrastructure layer (L3/L4) | Application layer (L7) |

| **Support** | AWS support only | 24/7 DRT (DDoS Response Team) |

| **Cost Protection** | No | Yes (credits for spikes) |

Enable Shield Advanced if:

```yaml

☐ Public-facing applications

☐ Previous DDoS attacks

☐ Regulatory requirement (protection guaranteed)

☐ Revenue impact from downtime

```

---

7. Monitoring and Troubleshooting

Required Metrics

```yaml

VPC:

- NAT Gateway bandwidth (bytes in/out)

- NAT Gateway connection count

- VPC Flow Logs (traffic analysis)

CloudFront:

- Requests (total, cached vs. uncached)

- Origin latency (time to fetch from origin)

- Error rate (4xx, 5xx)

- Cache hit ratio (target: 90%+)

Route 53:

- Health check status

- DNS query volume

- Alarm notifications

```

Troubleshooting Tools

```yaml

☐ VPC Reachability Analyzer (path tracing)

☐ Network Access Analyzer (security analysis)

☐ CloudWatch Logs Insights (VPC Flow Log queries)

☐ AWS Global Accelerator (fixed IP, improved routing)

```

---

8. Cost Optimization Checklist

Immediate Actions (Week 1)

Short-Term (Month 1)

Long-Term (Quarter 1)

---

Summary: Networking Excellence Pillars

1. **Multi-AZ VPC architecture** (fault tolerance, low latency)

2. **Private subnets for production** (public subnets for ALBs only)

3. **CloudFront CDN** (global performance, DDoS protection)

4. **Route 53 health checks** (automatic failover, DNS routing)

5. **VPC endpoints** (private AWS service access, no NAT Gateway)

6. **Direct Connect for hybrid** (consistent latency, security)

7. **Monitor and optimize** (flow logs, metrics, cost analysis)

8. **Network security** (security groups, NACLs, Shield)

---

Need Help with Network Architecture?

Our network architects can design secure, high-performance VPC architectures, implement hybrid connectivity, and optimize your networking costs.

<a href="/contact" className="text-aws-orange font-semibold hover:text-aws-light">

Schedule a Free Network Consultation →

</a>

Internal Linking Strategy:

---

*Last updated: January 5, 2025*