DEV Community

Cover image for AWS RDS Connectivity Troubleshooting: A Practical Engineer's Guide
Nitish Pandey
Nitish Pandey

Posted on

AWS RDS Connectivity Troubleshooting: A Practical Engineer's Guide

#aws #database #infrastructure #networking

Your RDS instance is available. So why can't your application connect?

Your application is running.

Amazon RDS shows Available.

Your Security Group looks correct.

And yet:

Application → RDS
             ❌ Connection failed
Enter fullscreen mode Exit fullscreen mode

This is one of those AWS problems that looks simple but can consume a lot of troubleshooting time.

The common mistake is treating it as only a database problem.

In reality, RDS connectivity can fail at several layers:

Application
    ↓
DNS
    ↓
Network
    ↓
Security Groups
    ↓
Route Tables
    ↓
Network ACLs
    ↓
Database Port
    ↓
RDS
    ↓
Authentication
Enter fullscreen mode Exit fullscreen mode

The goal of this guide is simple:

Find the exact layer where the connection fails instead of making random configuration changes.

🏗️ A Typical AWS Architecture

A common private AWS architecture looks like this:

                    AWS VPC
┌─────────────────────────────────────────────┐
│                                             │
│  Application Subnet       Database Subnet   │
│                                             │
│  ┌──────────────┐        ┌──────────────┐  │
│  │ EC2 / EKS    │        │     RDS      │  │
│  │ Application  │───────>│ PostgreSQL   │  │
│  └──────────────┘ TCP    └──────────────┘  │
│                   5432                      │
│                                             │
│       Security Groups                       │
│              │                              │
│       Route Tables                          │
│              │                              │
│       Network ACLs                          │
│                                             │
└─────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

The application has to successfully pass through multiple networking layers before it can communicate with RDS.

🚨 Common Symptoms

You may see errors such as:

connection timed out
Enter fullscreen mode Exit fullscreen mode 
connection refused
Enter fullscreen mode Exit fullscreen mode 
could not connect to server
Enter fullscreen mode Exit fullscreen mode 
no route to host
Enter fullscreen mode Exit fullscreen mode 
temporary failure in name resolution
Enter fullscreen mode Exit fullscreen mode 
password authentication failed
Enter fullscreen mode Exit fullscreen mode 
Access denied
Enter fullscreen mode Exit fullscreen mode

These errors are not equivalent.

For example:

DNS failure
Enter fullscreen mode Exit fullscreen mode

is very different from:

TCP connection timeout
Enter fullscreen mode Exit fullscreen mode

which is different again from:

Authentication failure
Enter fullscreen mode Exit fullscreen mode

Understanding the error category immediately narrows the investigation.

🔎 My RDS Troubleshooting Flow

I recommend troubleshooting in this order:

1. DNS
   ↓
2. Network reachability
   ↓
3. Security Groups
   ↓
4. Route Tables
   ↓
5. Network ACLs
   ↓
6. Database port
   ↓
7. RDS configuration
   ↓
8. Authentication
Enter fullscreen mode Exit fullscreen mode

This prevents unnecessary configuration changes.

1️⃣ Start With DNS

Before changing a Security Group, verify that the RDS endpoint resolves correctly.

nslookup <rds-endpoint>
Enter fullscreen mode Exit fullscreen mode

On Linux:

dig <rds-endpoint>
Enter fullscreen mode Exit fullscreen mode

You can also use:

dig +short <rds-endpoint>
Enter fullscreen mode Exit fullscreen mode

For example:

dig +short mydb.xxxxxx.ap-south-1.rds.amazonaws.com
Enter fullscreen mode Exit fullscreen mode

You want to establish:

Application host
      |
      v
RDS DNS endpoint
      |
      v
IP address
Enter fullscreen mode Exit fullscreen mode

If DNS fails

Investigate:

  • VPC DNS support
  • VPC DNS hostnames
  • DNS resolver configuration
  • /etc/resolv.conf
  • Custom DNS configuration
  • Network-level DNS restrictions

If the hostname does not resolve, changing the RDS Security Group will not solve the problem.

2️⃣ Test TCP Connectivity

Once DNS works, test whether the application host can reach the database port.

PostgreSQL 

nc -zv <rds-endpoint> 5432
Enter fullscreen mode Exit fullscreen mode

MySQL 

nc -zv <rds-endpoint> 3306
Enter fullscreen mode Exit fullscreen mode

Example:

nc -zv mydb.xxxxxx.ap-south-1.rds.amazonaws.com 5432
Enter fullscreen mode Exit fullscreen mode

Connection succeeds 

TCP connectivity ✓
Enter fullscreen mode Exit fullscreen mode

The network path and port are reachable.

Move to database-level troubleshooting.

Connection times out 

TCP connectivity ✗
Enter fullscreen mode Exit fullscreen mode

Investigate:

  • Security Groups
  • Route Tables
  • Network ACLs
  • Subnets
  • Network path

Connection refused

Investigate:

  • Database availability
  • Incorrect port
  • Incorrect endpoint
  • Database configuration

3️⃣ Check Security Groups

Don't simply ask:

"Is the Security Group open?"

Ask:

"Does the RDS Security Group allow traffic from the application?"

For example:

Application EC2
     |
     | TCP 5432
     v
RDS Security Group
Enter fullscreen mode Exit fullscreen mode

A PostgreSQL RDS Security Group could contain:

Type: PostgreSQL
Protocol: TCP
Port: 5432
Source: Application Security Group
Enter fullscreen mode Exit fullscreen mode

For MySQL:

Type: MySQL/Aurora
Protocol: TCP
Port: 3306
Source: Application Security Group
Enter fullscreen mode Exit fullscreen mode

Prefer Security Group references

Prefer:

Source = sg-application
Enter fullscreen mode Exit fullscreen mode

instead of:

Source = 0.0.0.0/0
Enter fullscreen mode Exit fullscreen mode

when the architecture allows it.

Opening a database to the entire internet just because you're troubleshooting is a bad practice.

4️⃣ Check Route Tables

A correct Security Group does not guarantee network connectivity.

You also need a valid network route.

Conceptually:

Application Subnet
        |
        v
   Route Table
        |
        v
    RDS Subnet
Enter fullscreen mode Exit fullscreen mode

For a normal RDS deployment inside the same VPC, the VPC's local route should provide connectivity between the relevant subnets.

For more complex architectures, investigate:

  • VPC Peering
  • Transit Gateway
  • Cross-account networking
  • Shared VPC architectures
  • Custom route tables

Check the actual subnet associations rather than assuming the correct route table is attached.

5️⃣ Check Network ACLs

Network ACLs are another layer that can be overlooked.

Unlike Security Groups, Network ACLs are stateless.

That means return traffic must also be permitted.

Application Subnet
       |
       v
Application NACL
       |
       v
RDS Subnet
       |
       v
RDS NACL
       |
       v
Return traffic
Enter fullscreen mode Exit fullscreen mode

Check:

  • Inbound rules
  • Outbound rules
  • Ephemeral ports
  • Rule numbers
  • Allow/deny ordering

Don't modify NACLs randomly.

First establish whether the NACL is actually affecting the connection path.

6️⃣ Verify RDS Configuration

Once the network path looks correct, check the database itself.

Verify:

Database engine 

PostgreSQL
MySQL
MariaDB
Aurora
Enter fullscreen mode Exit fullscreen mode

Database port

PostgreSQL:

5432
Enter fullscreen mode Exit fullscreen mode

MySQL:

3306
Enter fullscreen mode Exit fullscreen mode

Endpoint

Make sure the application is using the correct endpoint.

RDS status

Confirm the instance or cluster is in an appropriate state such as:

Available
Enter fullscreen mode Exit fullscreen mode

Also review:

  • DB subnet group
  • Parameter group
  • Cluster/instance configuration
  • Public/private accessibility
  • SSL/TLS requirements
  • Recent configuration changes

7️⃣ Test Database Authentication

If TCP connectivity works, move to the database layer.

PostgreSQL 

psql -h <rds-endpoint> -U <username> -d <database>
Enter fullscreen mode Exit fullscreen mode

MySQL 

mysql -h <rds-endpoint> -u <username> -p
Enter fullscreen mode Exit fullscreen mode

At this point, you might receive:

password authentication failed
Enter fullscreen mode Exit fullscreen mode

or:

Access denied
Enter fullscreen mode Exit fullscreen mode

That's useful information.

It means the network connection may already be working.

Now investigate:

  • Username
  • Password
  • Database name
  • SSL/TLS
  • Authentication method
  • Application secrets
  • IAM database authentication, if configured

🐘 PostgreSQL Example

PostgreSQL commonly uses TCP port 5432.

First test the port:

nc -zv <rds-endpoint> 5432
Enter fullscreen mode Exit fullscreen mode

Then test the actual database connection:

psql \
  -h <rds-endpoint> \
  -p 5432 \
  -U <username> \
  -d <database>
Enter fullscreen mode Exit fullscreen mode

The troubleshooting path becomes:

DNS
 ↓
TCP 5432
 ↓
Security Group
 ↓
Route
 ↓
Network ACL
 ↓
PostgreSQL
 ↓
Username
 ↓
Password
 ↓
Database
Enter fullscreen mode Exit fullscreen mode

🐬 MySQL Example

MySQL commonly uses TCP port 3306.

Test:

nc -zv <rds-endpoint> 3306
Enter fullscreen mode Exit fullscreen mode

Then:

mysql \
  -h <rds-endpoint> \
  -P 3306 \
  -u <username> \
  -p
Enter fullscreen mode Exit fullscreen mode

The troubleshooting sequence remains:

DNS
 ↓
TCP 3306
 ↓
Security Group
 ↓
Route
 ↓
Network ACL
 ↓
MySQL
 ↓
Authentication
Enter fullscreen mode Exit fullscreen mode

⚠️ Common Failure Scenarios

Scenario 1 — DNS Does Not Resolve 

DNS
 ↓
❌
RDS endpoint
Enter fullscreen mode Exit fullscreen mode

Investigate:

  • VPC DNS settings
  • Resolver configuration
  • DNS endpoint spelling
  • Custom DNS servers

Scenario 2 — DNS Works but TCP Times Out 

DNS       ✓
TCP       ✗
Enter fullscreen mode Exit fullscreen mode

Focus on:

Security Group
Route Table
Network ACL
Subnet
Network path
Enter fullscreen mode Exit fullscreen mode

Scenario 3 — TCP Works but Login Fails 

DNS       ✓
TCP       ✓
Login     ✗
Enter fullscreen mode Exit fullscreen mode

Now investigate:

Username
Password
Database
SSL/TLS
Authentication
Enter fullscreen mode Exit fullscreen mode

Don't keep changing networking rules when the network is already working.

Scenario 4 — Wrong Database Port

For example:

Application → 5432
RDS Engine  → MySQL / 3306
Enter fullscreen mode Exit fullscreen mode

The application is connecting to the wrong port.

Always verify the actual database engine and port.

Scenario 5 — RDS Is Private

A common architecture is:

Internet
   |
   v
ALB
   |
   v
Application
   |
   v
Private RDS
Enter fullscreen mode Exit fullscreen mode

If you're attempting:

Laptop
   |
   v
Internet
   |
   v
Private RDS
Enter fullscreen mode Exit fullscreen mode

the problem may be the network architecture rather than the database.

🔐 Security Considerations

Troubleshooting should never become an excuse for creating security problems.

❌ Avoid 

RDS
 ↓
0.0.0.0/0
Enter fullscreen mode Exit fullscreen mode

✅ Prefer 

Application SG
       ↓
    RDS SG
Enter fullscreen mode Exit fullscreen mode

Also consider:

  • Keep databases private where appropriate.
  • Use encryption at rest.
  • Use TLS for database connections.
  • Store credentials in AWS Secrets Manager or another appropriate secrets-management solution.
  • Never commit database passwords to Git.
  • Never include credentials in screenshots or public troubleshooting posts.

🧪 Useful Linux Commands

DNS 

nslookup <rds-endpoint>
Enter fullscreen mode Exit fullscreen mode 
dig <rds-endpoint>
Enter fullscreen mode Exit fullscreen mode 
dig +short <rds-endpoint>
Enter fullscreen mode Exit fullscreen mode

TCP Connectivity 

nc -zv <rds-endpoint> 5432
Enter fullscreen mode Exit fullscreen mode 
nc -zv <rds-endpoint> 3306
Enter fullscreen mode Exit fullscreen mode

Routing 

ip route
Enter fullscreen mode Exit fullscreen mode

Network Interfaces 

ip addr
Enter fullscreen mode Exit fullscreen mode

DNS Configuration 

cat /etc/resolv.conf
Enter fullscreen mode Exit fullscreen mode

These commands help answer:

Who am I?
Where am I?
How is traffic routed?
Which DNS resolver am I using?
Can I reach the database port?
Enter fullscreen mode Exit fullscreen mode

✅ RDS Troubleshooting Checklist 

[ ] Confirm the exact error
[ ] Confirm the application host
[ ] Confirm the RDS endpoint
[ ] Confirm database engine
[ ] Confirm database port
[ ] Test DNS resolution
[ ] Test TCP connectivity
[ ] Check application Security Group
[ ] Check RDS Security Group
[ ] Verify RDS inbound rules
[ ] Verify route tables
[ ] Check Network ACLs
[ ] Verify subnet configuration
[ ] Confirm RDS status
[ ] Test database login
[ ] Verify username
[ ] Verify password
[ ] Verify database name
[ ] Check SSL/TLS requirements
[ ] Check application configuration
[ ] Check recent network changes
[ ] Validate the fix
[ ] Document the root cause
Enter fullscreen mode Exit fullscreen mode

🧠 The Biggest Lesson

The most important lesson isn't a particular AWS command.

It's the troubleshooting mindset.

When someone says:

"The application can't connect to RDS."

Don't immediately ask:

"What's wrong with the Security Group?"

Instead ask:

"At which exact layer does the connection fail?"

Use this model:

             RDS Connectivity

                    │
                    ▼
                  DNS
                    │
                    ▼
               Network
                    │
                    ▼
            Security Groups
                    │
                    ▼
              Route Tables
                    │
                    ▼
              Network ACLs
                    │
                    ▼
              Database Port
                    │
                    ▼
                   RDS
                    │
                    ▼
             Authentication
Enter fullscreen mode Exit fullscreen mode

Once you identify the failing layer, the number of possible causes becomes much smaller.

🎯 Final Thoughts

Good cloud troubleshooting isn't about memorizing hundreds of commands.

It's about building a repeatable investigation process.

My preferred approach is:

Observe → Isolate → Test → Fix → Validate → Prevent

And most importantly:

Don't make five changes at once.

If you change the Security Group, route table, NACL, application configuration, and database settings simultaneously, you may fix the problem—but you won't know why.

Make controlled changes, validate each step, and document what you learn.

📚 More AWS Production Troubleshooting

I'm building a public collection of practical AWS troubleshooting scenarios:

  • AWS ALB 504 Gateway Timeout
  • RDS connectivity
  • EC2 application failures
  • Auto Scaling configuration drift
  • CloudWatch investigations
  • VPC and Security Group troubleshooting
  • EKS troubleshooting
  • ECR → EKS deployments
  • Terraform production troubleshooting

The goal is simple:

Turn real production troubleshooting experience into practical knowledge that other cloud engineers can use.

👨‍💻 About Me

I'm an AWS Cloud Engineer working with cloud infrastructure, automation, Kubernetes, Terraform, and production troubleshooting.

I'm also exploring the intersection of AWS, AI infrastructure, and AIOps and documenting what I learn along the way.

If you're working with AWS and have encountered an interesting production issue, I'd love to hear about it.

What is the strangest AWS connectivity problem you've had to troubleshoot?

AWS #AmazonRDS #AWSCloud #CloudEngineering #DevOps #AWSNetworking #CloudComputing #SRE #Terraform #Kubernetes

Top comments (0)