---
title: A Staff Platform Engineer's Architectural Guide: Deploying EKS and RDS in Same vs. Different AWS VPCs
created: 2026-03-30
updated: 2026-03-30
type: summary
tags: ["architecture", "aws", "notes", "telegram", "vpc"]
external: http://go/ui/posts/2305/
status: inbox
---

It isn’t necessarily "bad" to put them in the same VPC—in fact, for many startups and medium-sized projects, it is the **preferred** setup because it is simpler and higher performing.

However, as a **Staff Platform Engineer**, you likely care about blast weight, security boundaries, and scalability. In that context, there are strong arguments for the "Multi-VPC" approach.

Here is a breakdown of how to decide:

---

## When "Same VPC" is Actually Better
* **Latency:** Minimal network hops. Traffic stays within the AWS fabric of a single logical network.
* **Cost:** You avoid VPC Peering data transfer charges (if in the same AZ) and Transit Gateway processing fees ($0.02 per GB).
* **Simplicity:** No need to manage complex Route Tables, CIDR overlaps, or Peering handshakes. 
* **Security Group Referencing:** You can allow traffic to RDS by referencing the EKS Security Group ID directly. This is much cleaner than managing IP ranges.

---

## When "Different VPCs" is the Right Choice (The Platform View)
In a mature "Platform" or "Landing Zone" architecture, we often separate them for these reasons:

### 1. Blast Radius & Lifecycle Management
If you accidentally delete or misconfigure a VPC-level resource (like an Internet Gateway or a Route Table), you only impact one layer. You can destroy and recreate your entire EKS VPC (e.g., for a major version migration) without touching your persistent data layer (RDS).

### 2. IP Address Exhaustion (The EKS "IP Hunger")
The AWS VPC CNI assigns a **private VPC IP to every single Pod**. 
* A large EKS cluster can easily swallow a `/20` or `/19` subnet.
* If your RDS is in the same VPC, you are competing for the same finite pool of IP addresses.
* By putting RDS in its own VPC, you can give it a tiny, dedicated CIDR (like a `/24`) and save the massive ranges for EKS.

### 3. Compliance and Audit
Many regulatory frameworks (like PCI-DSS or SOC2) prefer "Data Residency" isolation. It is easier to prove to an auditor that your database is isolated if it sits in a physically distinct VPC with a **Transit Gateway** or **Firewall** inspecting traffic in between.

### 4. Organizational Structure
If you have a "Data Team" and a "Platform/DevOps Team," giving each their own VPC allows for **IAM-level separation**. The Data team can have full admin rights over the RDS VPC without being able to touch the EKS networking.

---

## Comparison Summary

| Feature | Same VPC (Monolithic) | Different VPCs (Modular) |
| :--- | :--- | :--- |
| **Setup Speed** | Fast / Instant | Slower (Peering/TGW config) |
| **Performance** | Maximum | Negligible overhead |
| **Security** | Security Groups only | SGs + Network Isolation |
| **IP Management** | Difficult (Competing for IPs) | Easy (Dedicated ranges) |
| **Operational Risk** | High (Shared fate) | Low (Isolated environments) |

---

## My Recommendation for Your Role
Since you are working at a "Staff" level:

1.  **For Production:** Use **Different VPCs**. It aligns with the "Landing Zone" philosophy. Connect them via **VPC Peering** if it’s just one-to-one, or **Transit Gateway** if you have multiple clusters (Dev, Staging, Prod) that all need to talk to a centralized Data VPC.
2.  **For Sandbox/POC:** Use the **Same VPC**. Don't over-engineer for a temporary environment where cost and speed are the priority.



**Are you leaning towards using a Hub-and-Spoke model with a Transit Gateway, or would you prefer a simpler Peering setup for now?**
