EC2 Cannot Connect to RDS: VPC Networking Debug Walkthrough

EC2 to RDS connectivity in the same VPC has a small set of root causes. The temptation is to start changing things until it works — usually by opening Security Groups too widely — which creates security debt. The disciplined approach is bottom-up layer testing.

The layers, in order

• TCP reachability — ping won't work to RDS (ICMP blocked) but nc -zv 5432 tests TCP connectivity
• Security Group on RDS — must allow inbound from EC2's SG or VPC CIDR
• Security Group on EC2 — default allows all outbound; custom SGs may restrict
• NACL on the subnet — stateless, must allow both directions explicitly
• VPC routing — same VPC handled by default; cross-VPC needs peering or Transit Gateway
• DNS resolution — RDS endpoints are DNS names; EC2 must resolve them; VPC DNS settings
• Application layer — SSL requirements, IAM auth, credentials

Step-by-step debug

Step 1 — test TCP with `nc`

• nc -zv 5432 — succeeded means network is fine, issue is app/auth; timed out means blocked at network layer

Step 2 — inspect RDS Security Group

• Look for inbound rule on the database port; source should be the EC2's Security Group (SG-to-SG, the recommended pattern) or VPC CIDR
• SG-to-SG is best because as EC2 instances scale they remain authorized automatically; hardcoded IPs break when ASGs replace instances

Step 3 — check NACL on the RDS subnet

• NACLs are stateless — you need both inbound (port 5432) AND outbound (ephemeral ports 1024-65535)
• Default NACLs allow all; custom NACLs need explicit rules; the most common bug is forgetting the ephemeral outbound for the response

Step 4 — verify VPC routing

• Same VPC: local route handles it automatically
• Cross-VPC: requires VPC Peering or Transit Gateway with explicit routes

Step 5 — RDS publicly accessible and DNS

• If RDS is private, DNS endpoint should resolve to private IP from inside the VPC; VPC must have enableDnsSupport and enableDnsHostnames
• Always connect via DNS endpoint, never IP — IP changes on failover, DNS stays stable

Step 6 — use Reachability Analyzer to skip the layers

• AWS service that simulates the path and tells you exactly which SG, NACL, or route blocks
• Free for 100 analyses per month; should be the first tool you reach for, before manual debugging

Step 7 — application layer

• If TCP works but auth fails: check SSL requirement (rds.force_ssl), IAM database auth, credentials, database name
• Spring Boot example: ?ssl=true&sslmode=require in JDBC URL

The mistakes to avoid

• Don't use 0.0.0.0/0 in RDS Security Group — even "temporarily"; combined with PubliclyAccessible: true, this is a data breach pattern
• RDS in public subnet is wrong; RDS should be in private subnets across multiple AZs; DB subnet group references these
• Don't connect via IP; the underlying IP changes on failover, the DNS endpoint stays stable
• Connection pooling matters; HikariCP with sensible pool size (10-20 per app instance); for Lambda+RDS use RDS Proxy to multiplex connections

The strategic answer

• Use Reachability Analyzer before manual debugging — diagnoses 90 percent of issues in 30 seconds
• Standardize on SG-to-SG for service-to-service authorization (no hardcoded IPs)
• Document the network topology — VPC peering, TGW attachments, route tables, SG dependencies; teams with diagrams debug faster
• Treat RDS like any sensitive resource — in private subnets, SG locked to specific source SGs, never publicly accessible without explicit business justification