AWS RDS Endpoint Connection Timeout: Fix It Fast

1. Security Group Rules Blocking Traffic (Most Common)

Had a client last month whose entire Node.js backend couldn't connect to their RDS MySQL instance. The error was a plain 'connection timed out' after 10 seconds. I checked the security group attached to the RDS — inbound rules were set to allow traffic from '0.0.0.0/0' but only on port 3306. That looked fine at first. But the catch: the RDS security group wasn't allowing traffic from the application server's security group, just from the public IP of the server. When the server was in a private subnet with a NAT gateway, the source IP changed every reboot. So the real fix: use the source security group ID, not an IP.

Here's what to do:

1. Open the RDS console, find your database instance.
2. Look at the VPC security group under 'Connectivity & security'.
3. Go to EC2 > Security Groups, edit the inbound rules for that group.
4. Add a rule: Type = MYSQL/Aurora (or your DB type), Protocol = TCP, Port range = 3306 (or your DB port), Source = the security group ID of your app server (e.g., sg-0123456789abcdef).
5. Save and test the connection.

Don't open to 0.0.0.0/0 unless you're behind a VPN. That's lazy and insecure. I've seen too many companies get hacked because of this.

2. VPC Subnet or Route Table Misconfiguration

Another common one: your EC2 instance and RDS are in the same VPC, but the subnet of the RDS is in a different availability zone and the route table doesn't have a route to the NAT gateway or internet gateway. Or worse, the RDS is in a public subnet but the app is in a private subnet with no NAT.

Here's the deal: RDS instances in a VPC are accessible from within the VPC by default if the security groups allow it. But if your app is in a private subnet that uses a NAT gateway to reach the internet, the RDS endpoint might be resolved to a public IP (if it's publicly accessible). That public IP is not reachable from a private subnet without a NAT. The fix: make sure the RDS is in the same VPC and the app's subnet has a route to the RDS's subnet directly. No NAT needed if they're in the same VPC.

Steps to check:

1. Go to VPC console, click 'Your VPCs'.
2. Make sure both EC2 and RDS are in the same VPC ID.
3. Check the route tables attached to the app's subnet. There should be a local route (10.0.0.0/16 -> local) that covers the RDS subnet's CIDR.
4. If the RDS is publicly accessible (checkbox 'Publicly accessible' set to Yes), the endpoint resolves to a public IP. To reach that from a private subnet, you need a NAT gateway in a public subnet. Or better: disable public access and keep everything internal.

Pro tip: I always put RDS in a private subnet, no public access, and use EC2 in a private subnet too. Everything stays inside the VPC. No NAT costs, no latency, and it's more secure.

3. DNS Resolution Timeout or Wrong Endpoint

Sometimes the problem isn't network rules — it's DNS. The application uses the RDS endpoint hostname (like mydb.xxxxx.us-east-1.rds.amazonaws.com) but the DNS can't resolve it. This happens when the EC2 instance doesn't have outbound internet access (for public endpoints) or when the VPC doesn't have the DNS resolution attributes enabled.

Check this with a simple command from your app server:

nslookup mydb.xxxxx.us-east-1.rds.amazonaws.com

If it returns '** server can't find ...' or times out, you've got a DNS problem. For RDS in the same VPC, the endpoint should resolve to a private IP (like 10.0.1.5). If you see a public IP (like 54.xxx.xxx.xxx) and you're in a private subnet, that's a problem — you need the 'Publicly accessible' option set to No on the RDS.

Fix: Enable DNS resolution in the VPC (VPC settings > 'Enable DNS resolution' and 'Enable DNS hostnames' must be Yes). Also check that the security group allows outbound DNS traffic (UDP port 53) to the VPC's DNS resolver (this is usually automatic but some restrictive SGs block it).

If you're using a custom DNS (like Route 53 Resolver), make sure the RDS endpoint is in the private hosted zone. Had a client once whose RDS was in a different region and they used a hardcoded IP instead of the endpoint. That broke after a failover. Don't do that — always use the endpoint DNS name.

Quick-Reference Summary Table