
Description
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.md
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
# 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 IPAMreferences/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, NACLsiam— VPC endpoint policies, resource-based access controlec2— Instance placement, security groups, and subnet selectionecs— awsvpc networking, task-level security groups, service discovery, ECR endpoint requirementseks— Pod networking, secondary CIDRs, CNI configuration, IP address planninglambda— Lambda VPC configuration, ENI usage, endpoint requirementsrds-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.
More skills from the startups repository
View all 42 skillsagentcore
design Amazon Bedrock AgentCore architectures
Jul 12AgentsArchitectureAWSaidlc-lite
develop AI applications on AWS
Jul 12AgentsAI InfrastructureAWSEngineeringarchitect-for-startups
advise on AWS architecture for startups
Jul 12ArchitectureAWSStrategyaws-architect
design and review AWS architectures
Jul 12ArchitectureAWSInfrastructureaws-compare
compare AWS architecture options
Jul 12ArchitectureAWSCost OptimizationSecurityaws-debug
debug AWS infrastructure and deployment failures
Jul 12AWSDebuggingDeploymentObservability
More from AWS Labs
View publisheragentcore-investigation
investigate Bedrock AgentCore runtime sessions
mcp
Jul 12AWSDebuggingLogsObservabilityamazon aurora dsql
build applications with Aurora DSQL
mcp
Jul 12AuroraAWSDatabaseServerless +1aurora dsql
build applications with Aurora DSQL
mcp
Jul 12AWSDatabaseServerlessSQLaws dsql
build applications with Aurora DSQL
mcp
Jul 12AWSDatabaseMigrationServerless +1distributed postgres
build applications with Aurora DSQL
mcp
Jul 12AWSDatabasePostgreSQLServerless +1distributed sql
build applications with Aurora DSQL
mcp
Jul 12AWSDatabaseServerlessSQL