Home / AWS / AWS cloud troubleshooting: AWS RDS Connection Refused Because max_connections

AWS

AWS cloud troubleshooting: AWS RDS Connection Refused Because max_connections

Fix AWS RDS connection failures caused by exhausting `max_connections`, using query inspection, idle session cleanup, pooling, and parameter group tuning.

Published: Jan 22, 20269 min readBy FixWikiHub Editorial Team

Abstract illustration for a troubleshooting knowledge base category.

Introduction

Amazon RDS databases have a maximum connection limit determined by the max_connections parameter, which controls how many simultaneous client connections the database can accept. When this limit is reached, new connection attempts are rejected with errors like "too many connections" or "connection refused." This limit exists because each connection consumes memory and resources on the database instance.

The max_connections setting defaults based on instance class—larger instances get higher limits. However, applications can still exhaust these limits through connection leaks, improper pooling configuration, or traffic spikes. When connections pile up without being released, the database becomes unreachable even though CPU and storage may appear healthy.

Resolving connection exhaustion requires both immediate intervention to restore access and root cause analysis to prevent recurrence. Simply increasing the limit often delays rather than solves the problem if the underlying connection management issues aren't addressed.

Symptoms

When RDS max_connections is exhausted, you will observe these symptoms:

Applications report "too many connections" or "connection refused" errors
CloudWatch metric DatabaseConnections shows near-limit values
Connection pool timeouts occur even with available pool capacity
New application instances cannot connect to the database
Login attempts via CLI or admin tools fail
Existing connections continue working but new ones fail

Common error messages:

``` PostgreSQL: FATAL: remaining connection slots are reserved for non-replication superuser connections FATAL: sorry, too many clients already

MySQL: ERROR 1040 (HY000): Too many connections

SQL Server: Login failed for user 'app_user'. Reason: Failed to open the explicitly specified database. ```

Application logs:

```python psycopg2.OperationalError: FATAL: sorry, too many clients already

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) FATAL: remaining connection slots are reserved

mysql.connector.errors.DatabaseError: 1040 (HY000): Too many connections ```

CloudWatch metrics:

bash

DatabaseConnections: 450 (max_connections is 450)
CPUUtilization: 15% (healthy)
FreeableMemory: 2GB (healthy)

Common Causes

Several factors cause RDS connection exhaustion:

1.Connection leaks: Application code opens connections but doesn't close them properly. Over time, idle connections accumulate.
2.Improper connection pooling: Missing connection pool, pool configured too large, or pool not reusing connections efficiently.
3.Traffic spikes: Sudden increase in application instances or requests creates more connections than the database can handle.
4.Long-running transactions: Connections held open for extended periods reduce available slots.
5.Worker processes: Background job systems spawning many workers each opening their own connections.
6.Connection storms: Application restarts or deployments cause all instances to reconnect simultaneously.
7.Idle connection accumulation: Applications or monitoring tools opening connections without proper cleanup.
8.Incorrect max_connections for instance size: Parameter group setting too high relative to available memory.

Step-by-Step Fix

Follow these steps to diagnose and resolve RDS connection exhaustion:

Step 1: Check current connection count

Measure current connections against the limit:

```sql -- PostgreSQL SELECT count(*) as current_connections, (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') as max_connections FROM pg_stat_activity;

-- View connections by state SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

-- MySQL SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';

SELECT count(*) FROM information_schema.processlist; ```

Step 2: Identify idle or problematic connections

Find connections that aren't actively being used:

```sql -- PostgreSQL: Find idle connections SELECT pid, usename, application_name, client_addr, state, query_start, state_change FROM pg_stat_activity WHERE state = 'idle' ORDER BY state_change ASC LIMIT 20;

-- Find long-running queries SELECT pid, usename, query_start, now() - query_start as duration, query FROM pg_stat_activity WHERE state = 'active' AND query_start < now() - interval '5 minutes' ORDER BY duration DESC;

-- MySQL: Show process list SHOW FULL PROCESSLIST;

-- Find idle connections SELECT * FROM information_schema.processlist WHERE COMMAND = 'Sleep' ORDER BY TIME DESC; ```

Step 3: Terminate problematic connections

Kill idle or stuck connections:

```sql -- PostgreSQL: Terminate specific connection SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle' AND state_change < now() - interval '10 minutes' AND pid <> pg_backend_pid();

-- Terminate connections from specific application SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE application_name = 'leaky-app' AND pid <> pg_backend_pid();

-- MySQL: Kill specific process KILL CONNECTION 12345;

-- Kill all idle connections SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE COMMAND = 'Sleep' AND TIME > 300; ```

Step 4: Check RDS CloudWatch metrics

Monitor connection trends:

```bash # Get connection metrics aws cloudwatch get-metric-statistics \ --namespace AWS/RDS \ --metric-name DatabaseConnections \ --dimensions Name=DBInstanceIdentifier,Value=my-db \ --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --period 3600 \ --statistics Average,Maximum

# Check if connections correlate with events aws rds describe-events \ --db-instance-identifier my-db \ --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) ```

Step 5: Implement or fix connection pooling

Add connection pooling to reduce direct connections:

```bash # Option 1: Enable RDS Proxy aws rds create-db-proxy \ --db-proxy-name my-proxy \ --engine-family POSTGRESQL \ --auth "AuthScheme=SECRETS,SecretArn=arn:aws:secretsmanager:region:account:secret:my-secret" \ --role-arn arn:aws:iam::account:role/RDSProxyRole \ --vpc-subnet-ids subnet-1 subnet-2 \ --vpc-security-group-ids sg-12345

# Register the DB instance with the proxy aws rds register-db-proxy-targets \ --db-proxy-name my-proxy \ --db-instance-identifiers my-db

# Option 2: Use PgBouncer (for PostgreSQL) # Deploy PgBouncer as a sidecar or separate service

# Option 3: Fix application connection pool # Example for Python/SQLAlchemy from sqlalchemy import create_engine from sqlalchemy.pool import QueuePool

engine = create_engine( "postgresql://user:pass@host/db", poolclass=QueuePool, pool_size=10, max_overflow=20, pool_timeout=30, pool_recycle=1800 ) ```

Step 6: Adjust max_connections if necessary

Increase the limit after ensuring connections are managed properly:

```bash # Create or modify parameter group aws rds modify-db-parameter-group \ --db-parameter-group-name my-param-group \ --parameters "ParameterName=max_connections,ParameterValue=500,ApplyMethod=pending-reboot"

# For PostgreSQL, also consider shared_buffers impact aws rds modify-db-parameter-group \ --db-parameter-group-name my-param-group \ --parameters "ParameterName=shared_buffers,ParameterValue={DBInstanceClassMemory/4},ApplyMethod=pending-reboot"

# Reboot the instance to apply aws rds reboot-db-instance --db-instance-identifier my-db ```

Step 7: Set up connection monitoring

Monitor connections going forward:

bash

# Create CloudWatch alarm for connections
aws cloudwatch put-metric-alarm \
  --alarm-name rds-connections-high \
  --metric-name DatabaseConnections \
  --namespace AWS/RDS \
  --dimensions Name=DBInstanceIdentifier,Value=my-db \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 400 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:region:account:alerts

Step 8: Review application connection code

Audit application for connection issues:

```python # WRONG: Connection not closed def get_data(): conn = psycopg2.connect(DATABASE_URL) cur = conn.cursor() cur.execute("SELECT * FROM data") return cur.fetchall() # Connection never closed!

# CORRECT: Using context manager def get_data(): with psycopg2.connect(DATABASE_URL) as conn: with conn.cursor() as cur: cur.execute("SELECT * FROM data") return cur.fetchall() # Connection automatically closed

# CORRECT: Connection pooling from sqlalchemy import create_engine

engine = create_engine(DATABASE_URL, pool_size=10)

def get_data(): with engine.connect() as conn: result = conn.execute("SELECT * FROM data") return result.fetchall() ```

Verification

After fixing connection issues, verify normal operation:

```sql -- Check connection count is healthy SELECT count(*) as current_connections, (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') as max_connections FROM pg_stat_activity;

-- Expected: current_connections significantly below max_connections -- Healthy ratio: current < 80% of max

-- Verify idle connections are minimal SELECT state, count(*) FROM pg_stat_activity GROUP BY state; -- Expected: Most connections should be 'active' or 'idle' with recent state_change ```

Test application connectivity:

```bash # Test new connections work psql -h my-db.xxxx.region.rds.amazonaws.com -U app_user -d mydb -c "SELECT 1"

# Monitor connections during load test watch -n 5 "psql -h \$HOST -U \$USER -d \$DB -c 'SELECT count(*) FROM pg_stat_activity'"

# Check CloudWatch shows stable connection count aws cloudwatch get-metric-statistics \ --namespace AWS/RDS \ --metric-name DatabaseConnections \ --dimensions Name=DBInstanceIdentifier,Value=my-db \ --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --period 300 \ --statistics Average ```

Prevention

To prevent RDS connection exhaustion:

1.Always use connection pooling: Implement RDS Proxy or application-level pooling.

python

# SQLAlchemy with proper pooling
engine = create_engine(
    DATABASE_URL,
    pool_size=10,
    max_overflow=20,
    pool_timeout=30,
    pool_recycle=1800,  # Recycle connections after 30 minutes
    pool_pre_ping=True  # Verify connections before use
)

1.Monitor connection metrics: Set up alerts before limits are reached.

bash

# Alert at 80% of max_connections
aws cloudwatch put-metric-alarm \
  --alarm-name rds-connections-warning \
  --threshold 360 \  # 80% of 450
  --comparison-operator GreaterThanThreshold

1.Implement connection timeouts: Configure idle connection timeout.

```sql -- PostgreSQL: Set idle transaction timeout ALTER SYSTEM SET idle_in_transaction_session_timeout = '300000'; -- 5 minutes

-- MySQL: Set wait_timeout SET GLOBAL wait_timeout = 300; SET GLOBAL interactive_timeout = 300; ```

1.Size connection pools correctly: Don't over-allocate connections.

python

# Formula: pool_size = (connections per instance) * (number of instances)
# Keep total below 80% of max_connections
# Example: 10 instances, 10 connections each = 100 total pool size

1.Regular connection audits: Periodically review connection patterns.

sql

-- Monthly check for long-idle connections
SELECT count(*) FROM pg_stat_activity 
WHERE state = 'idle' 
AND state_change < now() - interval '1 hour';

1.Document connection limits: Keep documentation of limits and pool configurations.

markdown

## Database Connection Configuration
- Instance: db.r5.large
- max_connections: 450
- RDS Proxy: Enabled (pool_size: 100)
- App pool size: 10 per instance
- Total instances: 8 (80 connections max)
- Headroom: 370 connections available

[AWS troubleshooting: Fix IAM Permission Denied - Complete Tro](fix-iam-permission-denied)
[AWS cloud troubleshooting: AWS ACM Certificate Pending Validation Because the](aws-acm-certificate-pending-validation-wrong-route53-zone)
[AWS cloud troubleshooting: AWS ALB Returns 502 Because the Target Closed the ](aws-alb-502-target-closed-connection-keepalive-timeout-mismatch)
[AWS cloud troubleshooting: Fix AWS ALB CreateListener TargetGroupNotFound Err](aws-alb-createlistener-targetgroupnotfound)
[AWS cloud troubleshooting: Fix Aws Alb Lambda 502 Bad Gateway Issue in AWS](aws-alb-lambda-502-bad-gateway)

Was this guide helpful?

Related search paths

People also search for

If the symptom is close but not identical, these search paths usually surface the right neighboring fixes faster than scrolling the full archive.

AWS cloud troubleshooting: AWS RDS Connection Refused AWS cloud troubleshooting: AWS RDS Connection Refused AWS AWS cloud troubleshooting: AWS RDS Connection Refused troubleshooting AWS cloud troubleshooting: AWS RDS Connection Refused fix Fix AWS RDS connection failures caused by exhausting `max_connections`, using query inspection, idle session cleanup, pooling, and parameter group tuning AWS Fix AWS RDS connection failures caused by exhausting `max_connections`, using query inspection, idle session cleanup, pooling, and parameter group tuning

Explore Related Topics

Browse Guides from Other Categories

Discover troubleshooting guides from related categories to expand your knowledge.

FAQ

AWS Troubleshooting FAQs

Common questions about troubleshooting and preventing similar issues

How do I know if this aws-errors troubleshooting guide applies to my situation?

This guide is designed for aws-errors issues. If you're experiencing similar symptoms described in the article, follow the step-by-step instructions. Start with the most common causes and work through the diagnostic process.

Is it safe to follow these aws-errors troubleshooting steps?

Yes, all steps are designed to be safe and non-destructive. We recommend creating backups before making significant changes and testing each step before proceeding to the next.

How long does it typically take to resolve this type of aws-errors issue?

Most aws-errors issues can be resolved within 30 minutes to 2 hours, depending on the complexity and root cause. Follow the troubleshooting flow to identify and fix the problem efficiently.

How can I prevent this aws-errors issue from happening again?

Regular maintenance, monitoring, and following best practices for aws-errors configuration can help prevent recurrence. Consider implementing automated checks and alerts for early detection.

Written by

FixWikiHub Editorial Team

Our editorial team consists of experienced DevOps engineers, systems administrators, and cloud architects with hands-on experience in production environments across AWS, Azure, GCP, and on-premises infrastructure.

Every guide undergoes technical review for accuracy and is updated when software versions, commands, or best practices change.

Last updated: Jan 22, 2026

About our team

Important Notice

Disclaimer & Safety Guidelines

The troubleshooting steps in this guide are provided for educational and informational purposes. Before applying any changes to production systems:

Test in a staging environment first — Always verify commands and configurations in a non-production environment before deploying to live systems.
Create backups — Ensure you have current backups of databases, configurations, and critical files before making changes.
Understand the impact — Review how each step may affect your specific environment, dependencies, and users.
Consult official documentation — This guide supplements, but does not replace, official vendor documentation and best practices.

FixWikiHub is not responsible for any damages arising from the use of this content. See our Terms of Use for more information.

Resources

Official Documentation & Further Reading

For authoritative information, consult the official documentation for the technologies discussed in this guide. Our troubleshooting content supplements, but does not replace, vendor documentation.

AWS Documentation — Official Amazon Web Services guides and API references
Kubernetes Documentation — Official Kubernetes documentation
Nginx Documentation — Official Nginx web server documentation
Apache Documentation — Official Apache HTTP Server documentation
Docker Documentation — Official Docker container documentation

AWS cloud troubleshooting: AWS RDS Connection Refused Because max_connections

Introduction

Symptoms

Common Causes

Step-by-Step Fix

Step 1: Check current connection count

Step 2: Identify idle or problematic connections

Step 3: Terminate problematic connections

Step 4: Check RDS CloudWatch metrics

Step 5: Implement or fix connection pooling

Step 6: Adjust max_connections if necessary

Step 7: Set up connection monitoring

Step 8: Review application connection code

Verification

Prevention

Related Articles

People also search for

Browse Guides from Other Categories

WordPress

SSL

DNS

AWS Troubleshooting FAQs

FixWikiHub Editorial Team

Disclaimer & Safety Guidelines

Official Documentation & Further Reading

AWS cloud troubleshooting: AWS RDS Connection Refused Because max_connections

Introduction

Symptoms

Common Causes

Step-by-Step Fix

Step 1: Check current connection count

Step 2: Identify idle or problematic connections

Step 3: Terminate problematic connections

Step 4: Check RDS CloudWatch metrics

Step 5: Implement or fix connection pooling

Step 6: Adjust max_connections if necessary

Step 7: Set up connection monitoring

Step 8: Review application connection code

Verification

Prevention

Related Articles

People also search for

Share this guide

More AWS Troubleshooting Guides

Browse Guides from Other Categories

AWS Troubleshooting FAQs

FixWikiHub Editorial Team

Disclaimer & Safety Guidelines

Official Documentation & Further Reading