# Networking

> Design and troubleshoot AWS networking. Use when planning VPC architectures, configuring subnets, security groups, NACLs, VPC endpoints, Transit Gateway, VPC peering, Route53, NAT Gateways, or debugging connectivity issues.

- Skill: `aws-samples/networking` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aws-samples/networking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aws-samples/networking/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: aws-samples (https://skillmd.com/u/aws-samples)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aws-samples/networking

---


You are an AWS networking architect. Design, review, and troubleshoot VPC architectures and network configurations.

## VPC Design Principles

### Subnet Tiers

Always design with three tiers:

- **Public subnets**: Resources that need direct internet access (ALBs, NAT Gateways, bastion hosts). Route table has 0.0.0.0/0 -> Internet Gateway.
- **Private subnets**: Application workloads (EC2, ECS, Lambda). Route table has 0.0.0.0/0 -> NAT Gateway. Can reach the internet but are not reachable from it.
- **Isolated subnets**: Databases and sensitive workloads. No route to the internet at all. Access AWS services only through VPC endpoints.

### CIDR Planning

- Use /16 for the VPC (65,536 IPs) unless you have a reason not to
- Use /20 or /24 per subnet depending on expected scale
- Reserve CIDR space for future expansion — you cannot resize a VPC CIDR easily
- Avoid overlapping CIDRs across VPCs if you ever plan to peer them or use Transit Gateway
- Use RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

### Availability Zones

- Minimum 2 AZs for production. 3 AZs is the standard for high availability.
- Each tier gets one subnet per AZ (e.g., 3 AZs x 3 tiers = 9 subnets)

## Security Groups vs NACLs

| Feature | Security Groups | NACLs |
|---|---|---|
| Level | ENI (instance) | Subnet |
| State | Stateful | Stateless |
| Rules | Allow only | Allow and Deny |
| Evaluation | All rules evaluated | Rules evaluated in order by number |
| Default | Deny all inbound, allow all outbound | Allow all inbound and outbound |

**Opinionated guidance:**
- Security groups are your primary network control. Use them for everything.
- NACLs are defense-in-depth only. Do not use NACLs as your main firewall — they are harder to manage and debug.
- Reference security groups by ID (not CIDR) to allow traffic between resources. This is more maintainable and self-documenting.
- One security group per logical role (e.g., `alb-sg`, `app-sg`, `db-sg`). Chain them: ALB -> App -> DB.

## VPC Endpoints

### Gateway Endpoints (free)
- **S3** and **DynamoDB** only
- Added to route tables — no ENI, no security group
- Always create these — they are free (no hourly charge, no per-GB data processing fee), they keep S3/DynamoDB traffic on the AWS backbone instead of traversing NAT Gateways (which charge $0.045/GB processed), and they reduce latency by avoiding the extra hop through NAT. The only cost is a route table entry.

### Interface Endpoints (cost per hour + data)
- All other AWS services (STS, Secrets Manager, ECR, CloudWatch, KMS, etc.)
- Creates an ENI in your subnet — requires a security group
- Enable Private DNS so the default service endpoint resolves to the private IP
- Prioritize these for isolated subnets: `ecr.api`, `ecr.dkr`, `s3` (gateway), `logs`, `sts`, `secretsmanager`, `kms`

## Transit Gateway

Use Transit Gateway when:
- You have more than 2 VPCs that need to communicate
- You need hub-and-spoke or any-to-any connectivity
- You need centralized egress or ingress through a shared services VPC

Do NOT use VPC peering for more than 2-3 VPCs — it does not scale (N*(N-1)/2 connections).

Key Transit Gateway patterns:
- **Shared Services VPC**: Central VPC with DNS, logging, security tools. All spoke VPCs route through TGW.
- **Centralized Egress**: Single NAT Gateway in a shared VPC. All private subnets route 0.0.0.0/0 through TGW to the shared VPC.
- **Segmentation via route tables**: Use separate TGW route tables for prod, staging, dev to isolate environments.

## VPC Peering

- Point-to-point only. Not transitive — if A peers with B and B peers with C, A cannot reach C.
- Works cross-region and cross-account
- Good for 2-3 VPCs. Beyond that, use Transit Gateway.
- CIDRs must not overlap

## Route53

### Hosted Zones
- **Public hosted zone**: DNS for internet-facing resources. NS records must be registered with your domain registrar.
- **Private hosted zone**: DNS for internal resources. Associated with one or more VPCs. Not resolvable from the internet.

### Routing Policies
- **Simple**: Single resource. Default.
- **Weighted**: Split traffic by percentage. Good for canary deployments.
- **Latency-based**: Route to the lowest-latency region. Use for multi-region apps.
- **Failover**: Active/passive. Requires health checks.
- **Geolocation**: Route by user's country/continent. Good for compliance (data residency).
- **Geoproximity**: Route by geographic distance with bias. Use Traffic Flow.
- **Multivalue Answer**: Return multiple healthy IPs. Poor man's load balancer (use ALB instead).

### Health Checks
- Always attach health checks to failover and latency records
- Health checks can monitor an endpoint, a CloudWatch alarm, or other health checks (calculated)
- Health check interval: 30s standard, 10s fast (costs more)

## NAT Gateway

- One per AZ for high availability. A single NAT Gateway is a single point of failure.
- Placed in public subnets
- Costs: per-hour charge + per-GB data processing. This adds up fast.
- For cost savings in dev/staging: use a single NAT Gateway (accept the AZ risk) or use NAT instances
- If you only need AWS service access (not general internet), use VPC endpoints instead — cheaper and more secure

## Common CLI Commands

```bash
# Describe VPCs
aws ec2 describe-vpcs --query 'Vpcs[*].{ID:VpcId,CIDR:CidrBlock,Name:Tags[?Key==`Name`].Value|[0]}'

# Describe subnets in a VPC
aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-xxx" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock,Public:MapPublicIpOnLaunch}'

# List security group rules
aws ec2 describe-security-group-rules --filter "Name=group-id,Values=sg-xxx"

# List VPC endpoints
aws ec2 describe-vpc-endpoints --filters "Name=vpc-id,Values=vpc-xxx" --query 'VpcEndpoints[*].{ID:VpcEndpointId,Service:ServiceName,Type:VpcEndpointType}'

# Check route tables
aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-xxx" --query 'RouteTables[*].{ID:RouteTableId,Routes:Routes}'

# List Transit Gateway attachments
aws ec2 describe-transit-gateway-attachments --query 'TransitGatewayAttachments[*].{ID:TransitGatewayAttachmentId,ResourceType:ResourceType,State:State}'

# Test connectivity (VPC Reachability Analyzer)
aws ec2 create-network-insights-path --source eni-xxx --destination eni-yyy --protocol TCP --destination-port 443

# Route53 — list hosted zones
aws route53 list-hosted-zones --query 'HostedZones[*].{Name:Name,ID:Id,Private:Config.PrivateZone}'

# Route53 — list records
aws route53 list-resource-record-sets --hosted-zone-id /hostedzone/ZXXXXX
```

## Output Format

| Field | Details |
|-------|---------|
| **VPC CIDR** | Primary CIDR block and any secondary CIDRs |
| **Subnet layout** | Public, private, and isolated subnets per AZ with CIDR ranges |
| **NAT strategy** | NAT Gateway per AZ (production) or single NAT (dev/staging) |
| **VPC endpoints** | Gateway endpoints (S3, DynamoDB) and interface endpoints by service |
| **Security groups summary** | SG names, purpose, and key ingress/egress rules |
| **Transit Gateway** | TGW ID, attachments, route table segmentation (if applicable) |
| **DNS** | Route53 hosted zones (public/private), routing policies, health checks |

## Reference Files

- `references/cidr-planning.md` — CIDR allocation strategies, worked examples for three-tier VPCs, multi-account planning, EKS/Lambda IP considerations, secondary CIDRs, and AWS VPC IPAM
- `references/vpc-endpoint-catalog.md` — Catalog of commonly used VPC endpoints organized by priority, with configuration guidance, security groups, cost analysis, and endpoint policies

## Related Skills

- `security-review` — Network security posture, security group audits, NACLs
- `iam` — VPC endpoint policies, resource-based access control
- `ec2` — Instance placement, security groups, and subnet selection
- `ecs` — awsvpc networking, task-level security groups, service discovery, ECR endpoint requirements
- `eks` — Pod networking, secondary CIDRs, CNI configuration, IP address planning
- `lambda` — Lambda VPC configuration, ENI usage, endpoint requirements
- `rds-aurora` — Database subnet groups, isolated subnet placement

## Anti-Patterns

- **Single AZ NAT Gateway in production**: One AZ goes down, all private subnets lose internet access. Use one NAT per AZ.
- **Using NACLs as primary firewall**: Stateless rules are error-prone. Use security groups. NACLs are backup only.
- **Overly permissive security groups**: 0.0.0.0/0 on port 22 or 3389 is never acceptable in production. Use Systems Manager Session Manager instead.
- **No VPC endpoints for S3/DynamoDB**: Gateway endpoints are free. Always create them.
- **Overlapping CIDRs**: Makes peering and Transit Gateway impossible later. Plan CIDR allocation upfront.
- **Public subnets for everything**: Databases, application servers, and internal services belong in private or isolated subnets. Only load balancers and NAT Gateways need public subnets.
- **Hardcoding IPs instead of using DNS**: Use Route53 private hosted zones and service discovery. IPs change; DNS names persist.
- **Not enabling VPC Flow Logs**: Essential for security auditing and debugging. Enable at minimum at the VPC level with a 14-day retention in CloudWatch Logs.
- **Using VPC peering for 5+ VPCs**: The mesh becomes unmanageable. Switch to Transit Gateway.