networking

name	networking
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.
allowed-tools	Read, Grep, Glob, Bash(aws *), mcp__plugin_aws-dev-toolkit_awsknowledge__*

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 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.