✅ Day 13 of My Cloud Journey ☁️ — Route Tables + VPC Peering Deep Dive 🔀🌐

Today was all about understanding two fundamental building blocks of AWS networking — Route Tables and VPC Peering. These concepts are crucial for controlling how traffic flows within your AWS environment and how different VPCs can communicate securely and privately.

---

🔁 What is a Route Table?

A Route Table in AWS defines the rules (routes) that determine how network traffic is directed. Each subnet in a VPC must be associated with a route table — either the default one or a custom one you create.

🧩 Key Points:

• Every VPC has a main route table by default.

• You can associate custom route tables with subnets for specific routing behavior.

• Route tables contain routes that direct traffic:

  • Local VPC traffic

  • Internet Gateway (IGW) for public access

  • NAT Gateway for private subnet internet access

  • VPC Peering, VPNs, or Transit Gateways

---

✅ Hands-On Steps: Create and Use a Route Table

1. Navigate to the VPC Dashboard

2. Click on "Route Tables" from the sidebar

3. Create a new Route Table:

   • Give it a name (e.g., Public-Route-Table)

   • Select the correct VPC

4. Add a Route:

   • Destination: 0.0.0.0/0

   • Target: Internet Gateway (select your IGW)

5. Associate the Route Table with a subnet:

   • Click on the route table

   • Choose “Subnet Associations”

   • Select your public subnet

6. Now, the associated subnet can route internet traffic via IGW — it becomes a Public Subnet.

💡 Tip: Always double-check subnet associations and ensure NAT/IGW are correctly configured.

---

🔗 What is VPC Peering?

VPC Peering allows two VPCs to communicate with each other using private IPs — even across different AWS accounts or regions (with inter-region peering). There’s no need to go over the public internet, making it secure and efficient.

🧠 Key Concepts:

• VPC Peering is one-to-one (no transitive peering).

• Must update route tables on both VPCs for connectivity.

• Security Groups must allow traffic to/from the peered VPC.

• You cannot use overlapping CIDR blocks.

---

🛠 Steps: Set Up VPC Peering (Same Account)

1. Go to VPC Dashboard → Peering Connections

2. Click “Create Peering Connection”

   • Select your Requester VPC

   • Choose Accepter VPC (can be in same or another region/account)

3. Click “Create Peering Connection”

4. Select the new connection → Click “Actions → Accept Request”

5. Update Route Tables:

   • For VPC A, add a route to VPC B’s CIDR block via Peering Connection ID

   • Repeat for VPC B, routing to VPC A

6. Update Security Groups to allow traffic between both VPCs:

   • E.g., allow inbound TCP on port 22 from the other VPC’s CIDR

💡 Note: Both VPCs must have non-overlapping CIDR blocks and correctly updated route tables.

---

🔐 Use Case Scenario

Let’s say:

• VPC A hosts a web app frontend

• VPC B hosts an RDS database

You want the frontend in VPC A to connect to the DB in VPC B securely. You would:

1. Create a VPC Peering Connection

2. Update route tables in both VPCs

3. Adjust security groups to allow traffic

4. Test connectivity using private IPs (no internet needed)

---

🧠 What I Learned:

• How route tables control traffic within and outside the VPC

• A public subnet is just a subnet with a route to the IGW

• VPC Peering is a powerful tool for cross-VPC/private communication

• Importance of keeping CIDR blocks non-overlapping

• Need to configure both routing and security for peering to work

---

📌 Summary

---

🚀 What’s Next?

Tomorrow (Day 14), I’ll be setting up a private subnet with a NAT Gateway, and test how private instances can access the internet without being exposed directly. Stay tuned — we’re building real-world VPC architectures!