Introduction

An EC2 instance should usually be able to reach an RDS instance without exposing the database to the public internet, but several AWS network layers must line up first. Most failed connections come down to security groups, VPC placement, route tables, or using the wrong endpoint and port.

Start With the Simplest Network Model

The easiest and safest setup is:

• EC2 and RDS in the same VPC
• the database not publicly accessible
• the RDS security group allowing inbound traffic from the EC2 security group

That last point matters more than many people expect. Instead of allowing a CIDR block manually, it is usually cleaner to allow the EC2 instance's security group as the source on the RDS security group.

For example, if you are using PostgreSQL, the inbound rule on the RDS security group should allow TCP port 5432 from the EC2 security group.

Check the RDS Endpoint and Port

Do not guess the hostname. Use the actual RDS endpoint shown in the console or returned by the CLI. The endpoint is not the instance ID, not the DB name, and not a private IP you copied earlier.

Typical ports are:

• MySQL or MariaDB: 3306
• PostgreSQL: 5432
• SQL Server: often 1433

From the EC2 instance, test basic network reachability first:

nc -vz mydb.abcdefg123.us-east-1.rds.amazonaws.com 5432

If the port is reachable, the problem is probably credentials, SSL settings, or the database engine itself. If the port is not reachable, stay focused on networking.

Security Groups Are the First Place to Look

For a private EC2 to private RDS connection, the most common rule set is:

• EC2 security group allows normal outbound traffic
• RDS security group allows inbound traffic from the EC2 security group on the database port

AWS CLI can show the RDS security groups:

aws rds describe-db-instances \
  --db-instance-identifier mydb \
  --query 'DBInstances[0].VpcSecurityGroups[*].VpcSecurityGroupId'

A conceptual security group setup looks like this:

1EC2 security group: sg-app
2RDS security group: sg-db
3
4sg-db inbound rule:
5- protocol: TCP
6- port: 5432
7- source: sg-app

Using the EC2 security group as the source is better than pinning a private IP that may later change.

Then Check VPC, Subnets, Routes, and NACLs

If the security groups look right but the connection still fails, verify that both resources can actually route traffic to each other.

Questions to answer:

• Are EC2 and RDS in the same VPC?
• If not, is there VPC peering, Transit Gateway, or another approved path?
• Do route tables allow return traffic?
• Are network ACLs blocking the database port or ephemeral response ports?

With default VPC settings, security groups are usually the real issue. In more locked-down environments, NACLs and routing become more likely causes.

Public Accessibility Is Usually Not the Right Fix

Many people see a connection failure and immediately toggle RDS to publicly accessible. That is usually unnecessary if the EC2 instance is already inside the same VPC.

Making RDS public only helps when your network design actually requires internet-routable access. For application servers inside the same VPC, private connectivity is the normal design and usually the better security posture.

Separate Network Errors From Authentication Errors

A timeout means something different from a login failure.

Common patterns:

• connection timeout: networking problem
• connection refused: wrong port, listener problem, or path blocked differently
• authentication failed: network path exists, credentials or DB permissions are wrong

That distinction helps you avoid debugging passwords when the packet never reaches the database.

Common Pitfalls

The most common mistake is opening the RDS security group to the EC2 instance's public IP instead of the EC2 security group. Inside AWS, the private path is what usually matters.

Another mistake is using the wrong endpoint. Developers often try the instance hostname, an old failover address, or a copied IP instead of the managed RDS endpoint.

People also forget outbound rules on the EC2 side. Many security groups allow all egress by default, but hardened environments may not.

Finally, do not treat publicly accessible as a universal repair switch. If EC2 and RDS are meant to communicate privately, a public database often adds risk without fixing the underlying network misconfiguration.

Summary

• Prefer private EC2 to private RDS connectivity inside the same VPC.
• Allow inbound database traffic on the RDS security group from the EC2 security group.
• Test the real RDS endpoint and correct engine port from the EC2 instance.
• If security groups look right, inspect VPC routing and network ACLs next.
• Distinguish timeouts from authentication failures so you debug the right layer.