DEV Community: Nitish Pandey

AWS RDS Connectivity Troubleshooting: A Practical Engineer's Guide

Nitish Pandey — Wed, 12 Aug 2026 06:37:37 +0000

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

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

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                          │
│                                             │
└─────────────────────────────────────────────┘

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

connection refused

could not connect to server

no route to host

temporary failure in name resolution

password authentication failed

Access denied

These errors are not equivalent.

For example:

DNS failure

is very different from:

TCP connection timeout

which is different again from:

Authentication failure

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

This prevents unnecessary configuration changes.

1️⃣ Start With DNS

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

nslookup <rds-endpoint>

On Linux:

dig <rds-endpoint>

You can also use:

dig +short <rds-endpoint>

For example:

dig +short mydb.xxxxxx.ap-south-1.rds.amazonaws.com

You want to establish:

Application host
      |
      v
RDS DNS endpoint
      |
      v
IP address

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

MySQL

nc -zv <rds-endpoint> 3306

Example:

nc -zv mydb.xxxxxx.ap-south-1.rds.amazonaws.com 5432

Connection succeeds

TCP connectivity ✓

The network path and port are reachable.

Move to database-level troubleshooting.

Connection times out

TCP connectivity ✗

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

A PostgreSQL RDS Security Group could contain:

Type: PostgreSQL
Protocol: TCP
Port: 5432
Source: Application Security Group

For MySQL:

Type: MySQL/Aurora
Protocol: TCP
Port: 3306
Source: Application Security Group

Prefer Security Group references

Prefer:

Source = sg-application

instead of:

Source = 0.0.0.0/0

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

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

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

Database port

PostgreSQL:

MySQL:

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

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>

MySQL

mysql -h <rds-endpoint> -u <username> -p

At this point, you might receive:

password authentication failed

or:

Access denied

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

Then test the actual database connection:

psql \
  -h <rds-endpoint> \
  -p 5432 \
  -U <username> \
  -d <database>

The troubleshooting path becomes:

DNS
 ↓
TCP 5432
 ↓
Security Group
 ↓
Route
 ↓
Network ACL
 ↓
PostgreSQL
 ↓
Username
 ↓
Password
 ↓
Database

🐬 MySQL Example

MySQL commonly uses TCP port 3306.

Test:

nc -zv <rds-endpoint> 3306

Then:

mysql \
  -h <rds-endpoint> \
  -P 3306 \
  -u <username> \
  -p

The troubleshooting sequence remains:

DNS
 ↓
TCP 3306
 ↓
Security Group
 ↓
Route
 ↓
Network ACL
 ↓
MySQL
 ↓
Authentication

⚠️ Common Failure Scenarios

Scenario 1 — DNS Does Not Resolve

DNS
 ↓
❌
RDS endpoint

Investigate:

VPC DNS settings
Resolver configuration
DNS endpoint spelling
Custom DNS servers

Scenario 2 — DNS Works but TCP Times Out

DNS       ✓
TCP       ✗

Focus on:

Security Group
Route Table
Network ACL
Subnet
Network path

Scenario 3 — TCP Works but Login Fails

DNS       ✓
TCP       ✓
Login     ✗

Now investigate:

Username
Password
Database
SSL/TLS
Authentication

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

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

If you're attempting:

Laptop
   |
   v
Internet
   |
   v
Private RDS

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

✅ Prefer

Application SG
       ↓
    RDS SG

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>

dig <rds-endpoint>

dig +short <rds-endpoint>

TCP Connectivity

nc -zv <rds-endpoint> 5432

nc -zv <rds-endpoint> 3306

Routing

ip route

Network Interfaces

ip addr

DNS Configuration

cat /etc/resolv.conf

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?

✅ 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

🧠 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

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

Biryani CSS Art — India's Soul in Every Grain 🍛

Nitish Pandey — Sat, 08 Aug 2026 05:37:58 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

I chose to build a classic Dum Biryani — the ultimate comfort food! 🍛
There is nothing quite like opening a steaming handi of biryani and seeing the rich, saffron-colored rice dotted with fried onions, mint, and spices. It's a dish that brings people together and feels like a warm hug, making it the perfect inspiration for the Comfort Food challenge.

Demo

Here is my CSS Art representation of a traditional Biryani Handi!
I built this primarily using vanilla CSS to create the realistic clay texture of the pot, the individual grains of rice, the steam animations, and the garnishes. I added a tiny bit of JavaScript just for a subtle mouse-parallax tilt effect and a saffron sparkle when you click the pot.

https://github.com/pandeynitish23/dev_css_chalange/
https://dev-css-chalange.nitishkumar-nk-np.workers.dev/

Journey

Building this was a really fun exercise in CSS gradients and positioning!
What I'm most proud of:

The Clay Handi: I used layered radial and linear gradients along with inset box shadows to give the pot a realistic, 3D clay texture with lighting highlights.
The Rice & Garnishes: Creating individual rice grains, mint leaves, and onion crisps using CSS border-radius and positioning was tedious but incredibly rewarding when it all came together.
The Atmosphere: Adding animated steam and floating background spice particles helped bring the scene to life and make it feel hot and fresh. It was a great challenge keeping the JavaScript minimal and relying on pure CSS for the heavy lifting of the art itself!

How I Update Applications in an AWS Auto Scaling Group Using Golden AMIs

Nitish Pandey — Sat, 08 Aug 2026 05:08:05 +0000

Introduction

If you've ever managed applications running in an Amazon EC2 Auto Scaling Group, you've probably wondered what's the safest way to deploy updates without manually logging into every instance.

Over the last few months, I've been using a --Golden AMI-- approach for application deployments. It has made deployments much more consistent, easier to roll back, and reduced the chances of configuration drift.

In this article, I'll share the process I follow.

Why I Prefer Golden AMIs

There are many ways to deploy applications on EC2.

You can SSH into instances and update them manually, but over time that creates inconsistencies because every server ends up slightly different.

Instead, I update one EC2 instance, verify everything, create a new AMI, and let the Auto Scaling Group launch new instances from that image.

That way every instance is identical.

Step 1 – Prepare a Working EC2 Instance

I usually follow one of these approaches:

Detach an EC2 instance from the Auto Scaling Group without reducing the desired capacity.
Or launch a temporary EC2 instance from the current production AMI.

This gives me a safe environment to make changes without affecting live traffic.

Step 2 – Deploy the Changes

Once connected to the instance, I:

Pull the latest application code
Update configuration if needed
Restart the application
Verify the application starts correctly

For example:

git pull origin main

sudo systemctl restart myapp

Step 3 – Verify Everything

Before creating an AMI, I always make sure:

The application is running
APIs respond correctly
Services are healthy
Logs don't show unexpected errors

It's much better to spend a few extra minutes testing than discover a problem after every instance has been updated.

Step 4 – Create a Golden AMI

After everything looks good, I create a new AMI from the updated instance.

I also use a meaningful naming convention such as:

myapp-prod-v2

This makes future deployments and rollbacks easier to manage.

Step 5 – Update the Launch Template

Next, I create a new Launch Template version using the new AMI and set it as the default version.

Now the Auto Scaling Group knows which image should be used for new instances.

Step 6 – Start an Instance Refresh

This is probably my favorite part because AWS handles most of the work.

The Auto Scaling Group:

Launches a new instance
Waits for health checks
Terminates one old instance
Repeats until every instance has been replaced

The deployment happens gradually, so users aren't affected.

Step 7 – Final Checks

Once the refresh finishes, I verify:

Target Group health
CloudWatch metrics
Application functionality
Auto Scaling Group status

If everything looks good, I terminate the temporary EC2 instance.

What If Something Goes Wrong?

One of the biggest benefits of this approach is how easy rollback becomes.

I simply change the Launch Template back to the previous version and start another Instance Refresh.

AWS gradually replaces the instances with the previous working AMI.

Final Thoughts

This is the deployment process I've found most reliable for applications running on EC2 Auto Scaling Groups. It keeps deployments consistent, reduces manual work, and makes rolling back much less stressful when something doesn't go as planned.

I'm always interested in learning different approaches, so if you manage applications on EC2, how do you handle deployments? Do you use Golden AMIs, CodeDeploy, containers, or something else?