🔒 Secure EC2 ↔ RDS Access Across AWS Accounts Using VPC Peering

Ever faced the challenge of needing to access a private RDS database in one AWS account from an EC2 instance in another — all without exposing either to the public internet?

Welcome to the world of VPC Peering — one of AWS's cleanest and most cost-effective ways to enable secure, low-latency, private communication between services across accounts.

In this guide, I’ll walk you through the exact setup, share the architecture diagram, and highlight critical gotchas that might just save you hours of troubleshooting.

---

🧠 The Use Case

You have:

• An EC2 instance (or Lambda/ECS) in AWS Account A

• A private RDS instance in AWS Account B

• No intention to expose either via public IPs

✅ The goal: Enable the EC2 to privately connect to the RDS using VPC peering.

---

🖼️ Architecture Diagram

---

✅ Solution Overview: VPC Peering to the Rescue

VPC Peering creates a direct network route between two VPCs — even across AWS accounts — with no internet in between. It allows private IP communication while retaining full control via route tables and security groups.

---

🧭 Step-by-Step Setup

1. 🔌 Create and Accept the VPC Peering Connection

In Account A (EC2-side):

• Navigate to VPC → Peering Connections

• Create a new connection:

  • Requester VPC: Account A’s VPC ID

  • Accepter Account: Account B's AWS Account ID

  • Accepter Account Region: Account B’s Region

  • Accepter VPC: Account B’s VPC ID

In Account B (RDS-side):

• Go to VPC → Peering Connections

• Accept the pending connection

✅ The peering status will go from “Pending” to “Active”

---

2. 📡 Update Route Tables (Bidirectional Routing)

You need both VPCs to know how to reach each other.

In Account A (EC2-side):

• Go to the route table attached to your EC2 subnet - usually private subnet

• Add a route:

  • Destination: Account B’s VPC CIDR (e.g., 10.1.0.0/16)

  • Target: VPC Peering Connection

In Account B (RDS-side):

• Find the route table linked to your RDS subnet

• Add a reverse route:

  • Destination: Account A’s VPC CIDR (e.g., 10.0.0.0/16)

  • Target: Same Peering Connection

---

3. 🔐 Update Security Groups

Even with a network path open, security groups can still block traffic.

On RDS (Account B):

• Inbound Rules:

  • Type: MySQL/Aurora (or your DB engine)

  • Port: 3306 (or appropriate port)

  • Source: Either EC2’s private IP (e.g., 10.0.1.10/32) or entire subnet (e.g., 10.0.0.0/16)

On EC2 (Account A):

• Optional: Outbound rules allowing access to RDS IP/CIDR on port 3306

---

4. 🌐 Enable DNS Resolution Over Peering

To use RDS’s hostname instead of private IP:

• Go to Peering Connections in both accounts

• Select the connection

• Enable:

  • DNS resolution from peer VPC

If DNS doesn’t work, test with RDS’s private IP.

---

5. ✅ Test the Connection

From the EC2 instance:

nc -zv <rds-endpoint> 3306

🎉 If that works — you're done!

---

🚨 Common Gotcha: Overlapping CIDRs ❌

If both VPCs use the same CIDR block (e.g., 10.0.0.0/16), VPC peering will fail — either during creation or route propagation. AWS won’t allow peering between VPCs with overlapping CIDRs, even across different accounts.

🔥 Tip: Always plan VPC CIDRs in advance to avoid overlap!

📦 Multi-VPC Peering Warning

Let’s say using VPC Peering you want to connect:

• Account A → Account B

• Account C → Account B

In this case, the CIDRs of Account A and Account C must also be different. Why?

👉 Because Account B cannot have overlapping peer routes to both VPCs — otherwise, routing will break, and AWS will prevent the second peering connection.

✅ Each VPC involved in a mesh of peering relationships must have unique, non-overlapping CIDRs.

🧠 Rule of thumb: Treat CIDR planning like IP real estate — allocate with future growth and peering in mind!

---

🔍 VPC Peering: Pros, Cons & Caveats

VPC Peering is a simple and effective way to enable private communication between AWS VPCs—even across accounts. But like any architecture decision, it comes with trade-offs.

✅ Why Choose VPC Peering?

• 🔒 Private & Secure: No internet exposure. Traffic stays within the AWS global network.

• ⚡ Low Latency: Traffic flows directly between VPCs without NAT or public IP hops.

• 💰 Cost-Effective: No data processing fees like Transit Gateway. You only pay for the standard inter-AZ or inter-region data transfer.

• 🛠 Easy Setup: Create → Accept → Route → Secure — it takes minutes, not hours.

⚠️ Limitations to Know

• 🔁 One-to-One Only: VPC Peering is non-transitive — VPC A peered with B cannot reach VPC C unless explicitly peered.

• 🚫 CIDR Block Overlap: Peering fails if VPCs use overlapping CIDRs (e.g., both 10.0.0.0/16).

• 💥 Multi-VPC Conflicts: If two or more source VPCs (e.g., Accounts A & C) want to peer with the same target VPC (Account B), each VPC must have a unique CIDR. If A and C share a CIDR block, only one peering can succeed.

• 🧭 Manual Route Table Management: You must manually update routes on both sides — no automatic propagation.

💸 Cost Overview

Please check AWS VPC Peering Pricing for the latest pricing.

---

✅ Final Thoughts

• 🔐 VPC Peering is a secure, scalable, and budget-friendly way to enable private cross-account access

• 🧠 Don’t forget to configure route tables, security groups, and DNS resolution

• 🚫 CIDR block overlap is a dealbreaker — plan wisely!

• 🧰 Choose the right migration tool based on your data and downtime needs

---

🙌 Was this helpful?

I write about real-world DevOps experiences and AWS solutions on DevOps Stories.

If you found this guide useful, share it, comment, or follow for more real-world AWS & infrastructure content!