Aws Vpc

---
name: aws-vpc
description: "Expert coverage of AWS VPC networking: VPC design, subnets, Security Groups, NACLs, Transit Gateway, VPC peering, PrivateLink, Direct Connect, NAT Gateway, VPN, Flow Logs, and Network Firewall. Use for \"AWS VPC\", \"Security Group\", \"NACL\", \"Transit Gateway\", \"TGW\", \"Direct Connect\", \"PrivateLink\", \"NAT Gateway\", \"VPC peering\", \"AWS networking\". Do NOT use for cross-vendor comparison, platform selection, or category-wide architecture -- use the `cloud-networking` skill. Do NOT use for general AWS account/resource management beyond VPC networking -- that's the `aws` skill (in the `cloud-platforms` plugin)."
license: MIT
---

# AWS VPC

This skill covers AWS VPC networking. Areas of expertise include:

- VPC design, CIDR planning, and subnet architecture
- Security Groups (stateful) and NACLs (stateless)
- Transit Gateway (TGW) for hub-and-spoke and full-mesh connectivity
- VPC peering (intra-region and inter-region)
- PrivateLink (Interface Endpoints) and Gateway Endpoints
- Direct Connect (dedicated, hosted, DX Gateway)
- NAT Gateway and Internet Gateway
- Site-to-site VPN and VPN Gateway
- VPC Flow Logs for traffic analysis
- AWS Network Firewall for centralized inspection
- Route tables, prefix lists, and managed prefix lists
- AWS RAM (Resource Access Manager) for cross-account sharing

## How to Approach Tasks

1. **Classify** the request:
   - **Design** -- Load `references/architecture.md` for VPC patterns, subnet layout, TGW design
   - **Security** -- Apply Security Group and NACL guidance below
   - **Connectivity** -- Determine if intra-VPC, inter-VPC, hybrid, or internet and apply relevant guidance
   - **Troubleshooting** -- Use Flow Logs, route table analysis, SG/NACL inspection
   - **Automation** -- Apply CloudFormation, Terraform, or AWS CLI guidance

2. **Gather context** -- Number of VPCs, regions, accounts, traffic patterns, compliance requirements, existing Direct Connect or VPN

3. **Analyze** -- Apply AWS-specific reasoning. Consider cost (data transfer charges), availability (multi-AZ), and AWS service limits.

4. **Recommend** -- Provide actionable guidance with AWS CLI examples, console paths, or IaC snippets

5. **Verify** -- Suggest validation steps (VPC Reachability Analyzer, Flow Logs, route table checks)

## VPC Design

### CIDR Planning

- VPC CIDR: RFC 1918 recommended (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- Minimum /28, maximum /16 per VPC
- Up to 5 secondary CIDRs per VPC (request increase via support)
- Plan for growth: do not use the entire /16 on day one
- Non-overlapping CIDRs required for VPC peering and TGW attachments

### Subnet Architecture

```
VPC: 10.0.0.0/16

Public subnets (IGW route):
  10.0.1.0/24  (AZ-a) -- ALBs, NAT GW, bastion
  10.0.2.0/24  (AZ-b)
  10.0.3.0/24  (AZ-c)

Private subnets (NAT GW route):
  10.0.10.0/24 (AZ-a) -- Application servers, ECS tasks, Lambda VPC
  10.0.11.0/24 (AZ-b)
  10.0.12.0/24 (AZ-c)

Data subnets (no internet route):
  10.0.20.0/24 (AZ-a) -- RDS, ElastiCache, EFS
  10.0.21.0/24 (AZ-b)
  10.0.22.0/24 (AZ-c)

TGW subnets (TGW attachment):
  10.0.30.0/28 (AZ-a) -- Dedicated small subnets for TGW ENIs
  10.0.30.16/28 (AZ-b)
  10.0.30.32/28 (AZ-c)
```

**Key rules:**
- AWS reserves 5 IPs per subnet (.0, .1, .2, .3, .255)
- Each subnet is in exactly one AZ
- Create matching subnets in 2+ AZs for high availability
- Use /28 subnets for TGW attachments (minimal IP consumption)

### Route Tables

Each subnet associates with one route table:

```
# Public subnet route table
10.0.0.0/16    local
0.0.0.0/0      igw-xxxxx

# Private subnet route table
10.0.0.0/16    local
0.0.0.0/0      nat-xxxxx    (NAT Gateway in same AZ)
10.1.0.0/16    tgw-xxxxx    (Route to other VPCs via TGW)

# Data subnet route table
10.0.0.0/16    local
10.1.0.0/16    tgw-xxxxx    (Route to other VPCs, no internet)
```

## Security Groups

Stateful packet filtering at the ENI level:
- Rules are "allow" only -- implicit deny for anything not matched
- Inbound and outbound rules evaluated independently (return traffic auto-allowed)
- Can reference other Security Groups as source/destination (same region, same VPC or peered VPC)
- Up to 5 SGs per ENI; up to 60 inbound + 60 outbound rules per SG (adjustable)

### Design Patterns

```
# Web tier SG
Inbound:  TCP 443 from 0.0.0.0/0 (HTTPS from internet)
Inbound:  TCP 80  from 0.0.0.0/0  (HTTP redirect)
Outbound: TCP 8080 to sg-app-tier  (To application tier)

# App tier SG
Inbound:  TCP 8080 from sg-web-tier
Outbound: TCP 5432 to sg-db-tier   (To database tier)
Outbound: TCP 443  to pl-s3        (To S3 via prefix list)

# DB tier SG
Inbound:  TCP 5432 from sg-app-tier
Outbound: (none needed -- stateful return traffic auto-allowed)
```

**Best practice**: Use SG references instead of CIDR blocks whenever possible. SG references automatically update when instances are added/removed.

## NACLs (Network ACLs)

Stateless packet filtering at the subnet level:
- Numbered rules evaluated in order (lowest first, first match wins)
- Both allow and deny rules
- Must explicitly allow return traffic (ephemeral ports 1024-65535)
- Default NACL: allows all traffic

```
# Example: Block specific source CIDR
Rule 100: DENY TCP from 198.51.100.0/24 to any:any
Rule 200: ALLOW TCP from 0.0.0.0/0 to any:443
Rule 300: ALLOW TCP from 0.0.0.0/0 to any:1024-65535  (return traffic)
Rule *:   DENY all
```

**Best practice**: Use NACLs for coarse subnet-level blocking only. Security Groups should be the primary access control.

## Transit Gateway (TGW)

### Architecture

Regional hub interconnecting VPCs, VPNs, and Direct Connect:
- Up to 5,000 attachments per TGW
- Up to 50 Gbps burst per VPC attachment (AWS scales automatically)
- TGW route tables for segmentation (separate Dev/Prod routing domains)
- Route propagation: attachments can auto-propagate routes to TGW route tables

### Route Table Segmentation

```
TGW Route Table: Production
  Associations: VPC-Prod-A, VPC-Prod-B, VPC-Shared-Services
  Propagations: VPC-Prod-A, VPC-Prod-B, VPC-Shared-Services, DX-Gateway
  Routes: 10.0.0.0/8 -> DX-Gateway (on-prem)

TGW Route Table: Development
  Associations: VPC-Dev-A, VPC-Dev-B, VPC-Shared-Services
  Propagations: VPC-Dev-A, VPC-Dev-B, VPC-Shared-Services
  Routes: (no on-prem route -- Dev isolated from on-prem)
```

### Inter-Region TGW Peering

- TGWs in different regions can peer
- Non-transitive: Region-A TGW <-> Region-B TGW peering does not extend to Region-C
- Static routes only (no route propagation across peering)
- Data transfer charges apply for inter-region traffic

### TGW with Centralized Inspection

```
VPC-A -> TGW -> Inspection VPC (AWS Network Firewall) -> TGW -> VPC-B
```

- Route all inter-VPC traffic through an Inspection VPC
- AWS Network Firewall deployed in the Inspection VPC
- TGW appliance mode enabled for correct return path routing
- Symmetric routing required for stateful inspection

## Direct Connect

### Components

- **Connection**: Physical 1/10/100 Gbps link at a DX location
- **Virtual Interface (VIF)**: Logical connection over the physical link
  - **Private VIF**: Access VPCs (via VGW or DX Gateway)
  - **Public VIF**: Access AWS public services (S3, DynamoDB endpoints)
  - **Transit VIF**: Access TGW (supports transitive routing to all TGW-attached VPCs)
- **DX Gateway**: Connect to VPCs in multiple regions from one DX connection

### Redundancy Design

```
On-prem Router-A --> DX Location-1 --> DX Connection-1 --> DX Gateway --> TGW
On-prem Router-B --> DX Location-2 --> DX Connection-2 --> DX Gateway --> TGW
```

- Two connections in separate DX locations for 99.99% SLA
- BGP with AS-path prepending to prefer primary path
- Site-to-site VPN as backup (lower cost than second DX)

### MACsec

Layer-2 encryption on dedicated DX connections:
- Available on 10G and 100G dedicated connections
- Encrypts traffic between customer router and AWS DX endpoint
- No throughput penalty
- Requires MACsec-capable customer equipment

## PrivateLink

### Interface Endpoints (PrivateLink)

- ENI with private IP placed in your subnet
- Connects to AWS services (EC2 API, Secrets Manager, SSM, etc.) or third-party SaaS
- Traffic stays within AWS network -- never traverses the internet
- DNS resolution: VPC DNS resolves service endpoint to the ENI's private IP
- Security Group controls access to the endpoint

### Gateway Endpoints

- For S3 and DynamoDB only
- Free (no hourly or data charges)
- Added as a route in the route table (prefix list target)
- Does not use an ENI -- route-based

### VPC Endpoint Services (Your Own Services)

- Expose NLB-backed services to other VPCs without peering
- Consumer creates an Interface Endpoint in their VPC
- Connection approval workflow (manual or automatic)
- Cross-account and cross-region supported

## VPC Flow Logs

### Configuration

```bash
# Create Flow Log for VPC
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-xxxxx \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-flow-logs-bucket

# Custom fields
--log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}'
```

### Interpreting Flow Logs

```
2 123456789012 eni-xxxxx 10.0.1.50 10.0.2.100 443 49152 6 25 5000 1620000000 1620000060 ACCEPT OK
```

- `action: ACCEPT` = Security Group and NACL allowed the traffic
- `action: REJECT` = Either SG or NACL denied the traffic
- Flow Logs do not distinguish SG deny from NACL deny
- Flow Logs capture metadata only -- not packet contents

### VPC Reachability Analyzer

Automated path analysis between two endpoints:
- Analyzes route tables, SGs, NACLs, VPC peering, TGW routes
- Identifies the specific component blocking connectivity
- No actual traffic sent -- configuration analysis only
- Use for: "Why can't instance A reach instance B?"

## Common Pitfalls

1. **Single-AZ NAT Gateway** -- NAT Gateway is AZ-scoped. If you deploy one NAT GW in AZ-a and AZ-a has an outage, all private subnets lose internet access. Deploy one NAT GW per AZ.

2. **Missing return routes on TGW** -- When adding a new VPC to TGW, you must add routes in both directions: TGW route table must have a route to the new VPC, and the new VPC's route table must have routes to other VPCs via TGW.

3. **Security Group rule limits** -- Default is 60 inbound + 60 outbound rules per SG, 5 SGs per ENI. Hitting this limit silently prevents adding rules. Request a limit increase or consolidate rules.

4. **Inter-AZ data transfer costs** -- Every cross-AZ packet incurs $0.01/GB each direction ($0.02/GB round trip). This adds up for high-volume east-west traffic. Design accordingly.

5. **TGW appliance mode not enabled** -- When routing through a centralized firewall/NVA in an inspection VPC, TGW appliance mode must be enabled on the inspection VPC attachment. Without it, return traffic may take an asymmetric path and be dropped by the stateful firewall.

6. **Overlapping CIDR with default VPC** -- Every region has a default VPC with 172.31.0.0/16. If your corporate allocation uses this range, delete or modify the default VPC before deploying.

7. **Flow Log latency** -- Flow Logs have a 10-minute default aggregation window. They are not real-time. Do not rely on them for real-time incident response.

## Reference Files

Load these when you need deep knowledge:

- `references/architecture.md` -- VPC internals, subnet design, TGW architecture, Direct Connect topology, PrivateLink implementation, VPN configuration, Flow Log analysis. Read for design and troubleshooting questions.