TECH **AWS VPC Peering, Transit Gateway, and VPC Endpoints: Zero-Fluff Study Guide**

AWS VPC Peering, Transit Gateway, and VPC Endpoints: Zero-Fluff Study Guide

For AWS Solutions Architect – Associate (SAA-C03) and Real-World Deployments

1. What This Is & Why It Matters

You’re a cloud engineer at a fintech startup. Your company has: - A legacy VPC (10.0.0.0/16) running a monolithic app in us-east-1.
- A new microservices VPC (172.16.0.0/16) in the same region, hosting APIs and databases.
- A third VPC (192.168.0.0/16) in us-west-2 for disaster recovery.

The problem:
- Your microservices need to query the legacy app’s PostgreSQL database (private subnet).
- The DR site must sync data nightly with the primary region.
- Your developers complain about slow S3 uploads because traffic routes through a NAT gateway.

What breaks if you ignore this:
- VPC Peering: If you don’t set it up, your VPCs can’t talk to each other. You’ll resort to public IPs or VPNs, which are slower, less secure, and cost more.
- Transit Gateway: Without it, you’ll drown in a spaghetti of VPC peerings (N(N-1)/2 connections for N VPCs). Adding a 4th VPC? That’s 6 peerings to manage.
- VPC Endpoints:* If you skip them, your private subnets will route S3/DynamoDB traffic through NAT gateways, adding latency and cost ($0.045/GB for NAT vs. $0.01/GB for Gateway Endpoints).

The superpower you gain:
- VPC Peering: Simple, direct VPC-to-VPC communication (like a private LAN cable between two offices).
- Transit Gateway: A single "hub" to connect all VPCs, VPNs, and on-prem networks (like a corporate switchboard).
- VPC Endpoints: Private, high-speed access to AWS services (S3, DynamoDB, etc.) without leaving the AWS network (like a secret tunnel to the data center).

2. Core Concepts & Components

VPC Peering

• Definition: A direct, private network connection between two VPCs (same or different regions/accounts).
• Production insight: ⚠️ No transitive routing – if VPC A peers with VPC B, and VPC B peers with VPC C, A cannot talk to C via B. You must peer A→C directly.
• Key limits:
• Max 125 peerings per VPC (soft limit; request increase via AWS Support).
• No overlapping CIDR blocks (e.g., both VPCs can’t use 10.0.0.0/16).
• Same-region peering only (for cross-region, use Transit Gateway).

Transit Gateway (TGW)

• Definition: A hub-and-spoke network router that connects VPCs, VPNs, and on-prem networks.
• Production insight: Replaces the "N² peering problem" with a single attachment per VPC. Costs $0.05/hour + $0.02/GB data processing (cheaper than managing 100+ peerings).
• Key features:
• Route propagation: Automatically shares routes between attachments (no manual route table updates).
• Multicast support: Rarely used, but critical for financial trading or media streaming.
• Inter-region peering: Connect TGWs in different regions (e.g., us-east-1 ↔ eu-west-1).

VPC Endpoints

Gateway Endpoints

• Definition: A private connection to S3 or DynamoDB that bypasses the public internet.
• Production insight: Free (no hourly cost) and reduces NAT gateway costs (S3 traffic no longer eats NAT bandwidth).
• Key limits:
• Only for S3 and DynamoDB (no other AWS services).
• Must be in the same region as the VPC.
• No IPv6 support (yet).

Interface Endpoints (PrivateLink)

• Definition: A private ENI (Elastic Network Interface) in your subnet that connects to AWS services (e.g., SQS, KMS, ECR) or your own services (via PrivateLink).
• Production insight: Costs $0.01/hour + $0.01/GB (cheaper than NAT for high-volume traffic). Critical for hybrid cloud (on-prem → AWS without VPN).
• Key features:
• Supports 100+ AWS services (unlike Gateway Endpoints).
• Works across regions (e.g., us-east-1 VPC can access us-west-2 SQS).
• Security: Uses Security Groups (unlike Gateway Endpoints, which use VPC route tables).

3. Step-by-Step Hands-On

Task: Connect Two VPCs with Peering + Access S3 Privately

Prerequisites:
- AWS account with admin IAM permissions.
- Two VPCs in the same region: - VPC-A: 10.0.0.0/16 (with a private subnet 10.0.1.0/24).
- VPC-B: 172.16.0.0/16 (with a private subnet 172.16.1.0/24).
- An EC2 instance in each VPC (Amazon Linux 2, t3.micro).

Step 1: Create a VPC Peering Connection

1. Request the peering connection:
   bash
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-1234567890abcdef0 \ # VPC-A
--peer-vpc-id vpc-0987654321fedcba0 \ # VPC-B
--peer-region us-east-1

2. Output: Note the VpcPeeringConnectionId (e.g., pcx-12345678).

3. Accept the peering request (if cross-account):
   bash
aws ec2 accept-vpc-peering-connection \
--vpc-peering-connection-id pcx-12345678

4. Add routes to both VPCs’ route tables:

5. For VPC-A’s route table (attached to 10.0.1.0/24):
   bash
aws ec2 create-route \
--route-table-id rtb-1234567890abcdef0 \
--destination-cidr-block 172.16.0.0/16 \
--vpc-peering-connection-id pcx-12345678

6. For VPC-B’s route table (attached to 172.16.1.0/24):
   bash
aws ec2 create-route \
--route-table-id rtb-0987654321fedcba0 \
--destination-cidr-block 10.0.0.0/16 \
--vpc-peering-connection-id pcx-12345678

7. Verify connectivity:

8. SSH into the EC2 instance in VPC-A and ping the private IP of the instance in VPC-B:
   bash
ping 172.16.1.100

Step 2: Create a Gateway Endpoint for S3

1. Create the endpoint:
   bash
aws ec2 create-vpc-endpoint \
--vpc-id vpc-1234567890abcdef0 \ # VPC-A
--service-name com.amazonaws.us-east-1.s3 \
--vpc-endpoint-type Gateway \
--route-table-ids rtb-1234567890abcdef0

2. Output: Note the VpcEndpointId (e.g., vpce-12345678).

3. Verify S3 access from the private subnet:

4. SSH into the EC2 instance in VPC-A and run:
   bash
aws s3 ls
5. If it works, no NAT gateway was used (check CloudWatch metrics for NatGatewayBytesOut to confirm).

Step 3: (Bonus) Create an Interface Endpoint for SQS

1. Create the endpoint:
   bash
aws ec2 create-vpc-endpoint \
--vpc-id vpc-1234567890abcdef0 \ # VPC-A
--service-name com.amazonaws.us-east-1.sqs \
--vpc-endpoint-type Interface \
--subnet-ids subnet-1234567890abcdef0 \ # Private subnet in VPC-A
--security-group-ids sg-1234567890abcdef0 # Allow HTTPS (443)

2. Test SQS access:

3. From the EC2 instance in VPC-A, run:
   bash
aws sqs list-queues

4. ? Production-Ready Best Practices

Security

• VPC Peering:
• Restrict peering to specific accounts (use aws:PrincipalArn in the peering request).
• Disable "Allow DNS resolution" if you don’t need it (prevents DNS spoofing).
• Transit Gateway:
• Use route tables to segment traffic (e.g., isolate prod from dev).
• Enable AWS Network Firewall for east-west traffic inspection.
• VPC Endpoints:
• Gateway Endpoints: Restrict S3 bucket access with VPC endpoint policies:
  json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my-bucket/*"],
"Condition": {"StringEquals": {"aws:SourceVpc": "vpc-12345678"}}
}
]
}
• Interface Endpoints: Attach a Security Group that only allows HTTPS (443) from your private subnets.

Cost Optimization

• VPC Peering: Free, but data transfer costs apply ($0.01/GB for same-region, $0.02/GB for cross-region).
• Transit Gateway:
• Use attachment sharing (one TGW per region, share with multiple accounts).
• Monitor data processing costs (CloudWatch metric: BytesIn/BytesOut).
• VPC Endpoints:
• Gateway Endpoints are free (use them for S3/DynamoDB).
• Interface Endpoints cost $0.01/hour – delete unused ones.

Reliability & Maintainability

• Naming conventions:
• VPC Peering: pcx-prod-to-dev-us-east-1
• Transit Gateway: tgw-prod-hub-us-east-1
• VPC Endpoints: vpce-s3-gw-prod-us-east-1
• Tagging:
• Tag all resources with Environment=prod, Owner=team-finance, etc.
• Idempotency:
• Use Terraform/CloudFormation to manage peerings and endpoints (avoid manual CLI commands).

Observability

• CloudWatch Metrics to Monitor:
• VpcPeeringConnectionBytesIn/Out (peering traffic).
• TransitGatewayBytesIn/Out (TGW data processing).
• VpcEndpointBytesIn/Out (endpoint traffic).
• Alarms:
• Set up a billing alarm for TGW data processing costs.
• Alert on failed peering connections (VpcPeeringConnectionState = failed).

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "You have 5 VPCs in us-east-1. What’s the most scalable way to connect them?"
2. ✅ Transit Gateway (avoids N² peerings).

3. ❌ VPC Peering (5 VPCs = 10 peerings).

4. "A private subnet needs to access S3 without NAT. What’s the cheapest solution?"

5. ✅ Gateway Endpoint (free, no NAT costs).

6. ❌ Interface Endpoint ($0.01/hour).

7. "A VPC in us-east-1 needs to access SQS in us-west-2. How?"

8. ✅ Interface Endpoint in us-west-2 (cross-region support).
9. ❌ Gateway Endpoint (S3/DynamoDB only).

Key Trap Distinctions

7. ? Hands-On Challenge

Challenge:
You have: - A VPC (10.0.0.0/16) with a private subnet (10.0.1.0/24).
- An EC2 instance in the private subnet.
- A DynamoDB table (my-table) in the same region.

Task:
Configure the private subnet to access DynamoDB without a NAT gateway or public internet.

Solution:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-1234567890abcdef0 \
  --service-name com.amazonaws.us-east-1.dynamodb \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-1234567890abcdef0

Why it works:
- Gateway Endpoints bypass the public internet and route DynamoDB traffic privately.
- No NAT gateway costs (saves $0.045/GB).

8. ? Rapid-Reference Crib Sheet

VPC Peering

• CLI to create:
  bash aws ec2 create-vpc-peering-connection --vpc-id vpc-123 --peer-vpc-id vpc-456
• Max peerings per VPC: 125 (request increase via AWS Support).
• ⚠️ No transitive routing (A→B→C ≠ A→C).
• Data transfer cost: $0.01/GB (same region), $0.02/GB (cross-region).

Transit Gateway

• CLI to create:
  bash aws ec2 create-transit-gateway --description "prod-hub"
• Cost: $0.05/hr + $0.02/GB data processing.
• ⚠️ Default route table: All attachments share one route table (create separate ones for isolation).
• Max attachments per TGW: 5,000 (soft limit).

VPC Endpoints

• ⚠️ Gateway Endpoints: Must be in the same region as the VPC.
• ⚠️ Interface Endpoints: Deploy in private subnets (not public).

9. ? Where to Go Next

1. AWS VPC Peering Documentation
2. AWS Transit Gateway Deep Dive
3. VPC Endpoints Best Practices
4. AWS Well-Architected Framework (Networking)

Final Tip:
Bookmark this guide and try every step in a sandbox account. The best way to learn AWS networking is to break it, fix it, and break it again. ?