---
title: Detailed Approaches for Securely Connecting Amazon EKS Pods to RDS Instances Across Separate AWS VPCs Using Private Network Endpoints
created: 2026-03-30
updated: 2026-03-30
type: summary
tags: ["eks", "networking", "notes", "rds", "telegram"]
external: http://go/ui/posts/2304/
---

**user**: I have provisioned EKS in my VPC, and also a RDS in my another VPC as well, how can I access RDS from a eks pod via private network endpoint?

**claude**: There are a few approaches to connect your EKS pods to RDS across VPCs privately. Here are the main options:

## Option 1: VPC Peering (Simplest)

Connect both VPCs directly so they can route traffic to each other.

1. **Create a VPC Peering Connection** between the EKS VPC and the RDS VPC
2. **Update Route Tables** in both VPCs to route traffic to the peer VPC's CIDR
3. **Update Security Groups** on the RDS instance to allow inbound traffic from the EKS VPC CIDR (or the pod CIDR specifically)
4. **Use the RDS private endpoint** (e.g. `mydb.xxxx.us-east-1.rds.amazonaws.com`) directly from your pods — it resolves to a private IP once peering is in place

**Key gotcha**: VPC CIDRs must not overlap.

---

## Option 2: AWS Transit Gateway (Recommended for scale)

Better if you have multiple VPCs or plan to grow.

1. Create a **Transit Gateway**
2. **Attach both VPCs** to the Transit Gateway
3. Update **route tables** in each VPC to send cross-VPC traffic through the TGW
4. Update **RDS security groups** to allow ingress from the EKS VPC CIDR

This is more scalable than peering since it's hub-and-spoke rather than mesh.

---

## Option 3: RDS Proxy + PrivateLink (More complex, more control)

If you want to avoid VPC peering entirely:

1. Create an **RDS Proxy** in the RDS VPC
2. Expose it via **AWS PrivateLink** (VPC Endpoint Service)
3. Create a **VPC Interface Endpoint** in the EKS VPC pointing to that service
4. Pods connect through the endpoint DNS name

This is useful when you can't peer VPCs (e.g. overlapping CIDRs).

---

## Security Group Rules to Configure

Regardless of the approach, make sure:

```
RDS Security Group - Inbound:
  Type: PostgreSQL (or MySQL)
  Port: 5432 (or 3306)
  Source: EKS node security group ID (or pod CIDR if using custom networking)
```

If your pods use **IAM Roles for Service Accounts (IRSA)**, you can also layer on **RDS IAM authentication** on top of any of these network solutions.

---

## Recommendation

| Scenario | Recommended Approach |
|---|---|
| Simple setup, non-overlapping CIDRs | VPC Peering |
| Multiple VPCs or future growth | Transit Gateway |
| Overlapping CIDRs / strict isolation | PrivateLink |

**VPC Peering** is the fastest to set up for a typical two-VPC scenario. Just make sure your CIDRs don't overlap, and the route table + security group updates are the most common things people miss.

**user**: I have provisioned EKS in my VPC, and also a RDS in my another VPC as well, how can I access RDS from a eks pod via private network endpoint?

**chatgpt**: You’re essentially trying to enable **private, cross-VPC connectivity** between your ["cloud_service","Amazon EKS","Kubernetes service"] pods and your ["cloud_service","Amazon RDS","managed database service"] instance. There are a few valid architectures, but only **one is usually correct depending on ownership, scale, and isolation requirements**.

Let’s break it down systematically.

---

# ✅ Option 1 (Most Common): **VPC Peering**
### When to use
- Same AWS account (or trusted accounts)
- Simple network topology
- No overlapping CIDRs

### How it works
You create a **VPC Peering connection** between:
- VPC-A → (EKS cluster)
- VPC-B → (RDS instance)

### Steps
1. Create VPC peering connection
2. Update route tables:
   - EKS VPC → route to RDS CIDR via peering
   - RDS VPC → route to EKS CIDR via peering
3. Update Security Groups:
   - RDS SG: allow inbound from EKS pod CIDR (or node CIDR)
4. Ensure DNS resolution is enabled:
   - Enable `enableDnsHostnames` + `enableDnsSupport`
   - Enable “DNS resolution from peer VPC” in peering settings

### Important nuance (often missed)
EKS pods **don’t always use node IPs** depending on CNI:
- Default AWS VPC CNI → pods get VPC IPs → works directly
- If using overlay (Calico, etc.) → routing becomes trickier

---

# ✅ Option 2 (Better for scale): **AWS Transit Gateway**
### When to use
- Multiple VPCs
- Hub-and-spoke architecture
- Future scalability

Instead of peering meshes, you connect both VPCs to a **["cloud_service","AWS Transit Gateway","network hub"]**

### Pros
- Cleaner routing
- Avoids peering explosion
- Centralized control

### Cons
- Extra cost
- Slightly more complex

---

# ⚠️ Option 3 (Often misunderstood): **PrivateLink**
Using **["cloud_service","AWS PrivateLink","private endpoint service"]** is **NOT ideal for RDS access in most cases**

### Why?
- RDS is **not natively exposed via PrivateLink** (except Aurora + special setups)
- You’d need:
  - NLB in front of RDS
  - Endpoint service
  - Extra complexity

👉 This is usually overengineering unless you need strict service isolation.

---

# ✅ Option 4 (Advanced): **Shared VPC / Same VPC**
If you can:
- Put EKS and RDS in same VPC (different subnets)

This eliminates all complexity.

---

# 🔥 Key Networking Checklist (Critical)
Regardless of approach:

### 1. Security Groups
- RDS SG must allow:
  ```
  Source: EKS Pod CIDR or Node SG
  Port: 5432 (Postgres) / 3306 (MySQL)
  ```

### 2. Network ACLs
- Ensure no deny rules blocking traffic

### 3. DNS
- Use RDS endpoint (e.g. `xxx.rds.amazonaws.com`)
- Ensure cross-VPC DNS resolution works

### 4. EKS CNI behavior
Check:
```bash
kubectl get configmap aws-node -n kube-system -o yaml
```
Make sure pods have routable IPs

---

# 🧠 Subtle Gotcha (Most people hit this)
Even if routing is correct:
- **RDS only allows connections from IPs it recognizes**
- If you whitelist node SG but pods use different IP range → connection fails

👉 safest approach:
- Allow **node security group**
OR
- Allow full **EKS VPC CIDR**

---

# 🏗️ Example Architecture (Recommended)
```
[EKS Pod]
   ↓
[VPC A - 10.0.0.0/16]
   ↓ (VPC Peering / TGW)
[VPC B - 10.1.0.0/16]
   ↓
[RDS Instance]
```

---

# 🧩 My Recommendation
Given your setup:
- Start with **VPC Peering**
- Move to **Transit Gateway** only if:
  - You expect more VPCs
  - You want centralized routing

---

# If you want, I can go deeper:
- Terraform setup for peering/TGW
- Debugging connection timeouts from pod
- How to test from inside a pod (`psql`, `mysql`)
- Security hardening (IAM auth, TLS)

Just tell me 👍
