WordPress Database Connection Error When Using Amazon RDS

A WordPress site that displays “Error establishing a database connection” cannot currently reach or authenticate to its database. When the database is Amazon RDS, the cause may be a typo in WordPress settings, a blocked network path, an RDS event, or a server-side problem such as exhausted connections.

Start with checks that are quick and reversible. Don’t change several settings at once, open database access to the internet, or install troubleshooting plugins during an outage. Record the exact error and time, make a backup before editing configuration, then test one likely cause at a time.

1. Triage the outage before changing anything

Note the time the problem started, the site’s exact message, and whether the error affects the whole site or only the admin area. Check whether the site recently moved hosts, changed its RDS instance, rotated credentials, renewed a certificate, or deployed code. These details help distinguish a connection failure from a WordPress or application problem.

Keep a small incident scratchpad. Include timestamps with the time zone, what you tested, and the result. For example:

• 14:05 UTC: Homepage returns “Error establishing a database connection.”
• 14:11 UTC: RDS console shows instance available; no maintenance in progress.
• 14:16 UTC: Connection test from the web server times out.

Check the site from another network or device, and ask whether other applications that use the same RDS instance are affected. If only WordPress is down, investigate its settings and the web host first. If several applications are failing, prioritize RDS health and network access.

What changed: establish a baseline

At this stage, nothing has been changed. You have documented the symptom and its timing.

How to roll back

No rollback is needed. Keep the notes even if the site recovers; they can help explain a transient failover or maintenance event.

2. Check RDS health and recent events

In the AWS console, open RDS, select the correct Region and database, and review its status, recent events, maintenance, and monitoring metrics. Confirm that you are looking at the instance or cluster the WordPress site is supposed to use—not a staging database or a similarly named production instance.

Look for a reboot, failover, storage issue, maintenance operation, or change to the endpoint. A Multi-AZ failover may briefly interrupt active connections. WordPress may recover on its own after the database is available again, but persistent errors usually mean there is another issue to resolve.

Review CloudWatch metrics such as database connections, CPU, free storage, and available memory. A database at its connection limit can reject new connections even if the instance appears online. Don’t reboot an apparently healthy production database as a first step: a reboot can create another interruption and won’t fix incorrect credentials or blocked traffic.

What changed: inspect, don’t modify

Checking RDS status and metrics is read-only. Record any event time and compare it with the first failure reported in your scratchpad.

How to roll back

No rollback is needed because you have not changed the database. If you find a recent change, identify its owner and purpose before reversing it.

3. Verify the database credentials and endpoint

WordPress reads its database settings from wp-config.php. A valid database name and password are not enough if the host value points to the wrong database. Carefully compare the site’s configuration with the intended RDS database details.

WordPress setting What to verify DB_NAME The database exists on the intended RDS instance. DB_USER The username is correct and is allowed to access that database. DB_PASSWORD The current password matches the database user’s password. DB_HOST The value uses the correct RDS endpoint hostname and port.

For MySQL or MariaDB on RDS, the host typically looks like database-name.abc123xyz.us-east-1.rds.amazonaws.com. Use the endpoint hostname shown in the RDS console, not an IP address. RDS can change the underlying IP during failover or maintenance; the DNS hostname is the stable connection target. Include the correct port if it is not the default port, 3306—for example, your-endpoint.rds.amazonaws.com:3306.

Check for common mistakes: a copied endpoint from another environment, a missing character in the hostname, an accidental space, an outdated password after rotation, or a database user that exists on one instance but not another. If credentials are stored in a secrets manager or deployment system, check which value the live web server actually receives. Avoid posting passwords in tickets, chat, screenshots, or logs.

Test access from the web server

If you have shell access, test from the same server or container that runs WordPress. A laptop connection test is not conclusive because it uses a different network path and security group.

For a MySQL client, a test may look like this:

mysql -h your-endpoint.rds.amazonaws.com -P 3306 -u your_user -p your_database

The -p option prompts for the password rather than placing it directly in the command. A timeout usually points toward network access or routing. An “access denied” response more often indicates a username, password, or database permission problem. A successful login from the web server narrows the search to WordPress configuration or its PHP database driver.

What changed: validate values without exposing secrets

You have compared the live settings with the intended RDS details and, if possible, tested a database login. No setting has changed yet.

How to roll back

https://fantasticlawyers.com/2026/10/11/best-criminal-lawyers-brisbane/

No rollback is needed. If you do correct a value, save a copy of the original file first and change only the incorrect setting.

4. Check the RDS security group and network path

The RDS security group controls which network sources can connect to the database. A frequent cause of timeouts is an inbound rule that allows the wrong source or port. The usual secure setup is to allow the database port from the web server’s security group, rather than from a broad public range.

Check the following in AWS:

• The RDS security group has an inbound rule for the database engine’s port, commonly TCP 3306 for MySQL or MariaDB.
• The rule’s source matches the web server’s security group, or the correct private network range when security-group references are not available.
• The web server and RDS instance have a valid network path, including compatible VPCs, subnets, routing, and network ACL rules.
• The application is connecting from the expected server, container, or hosting provider—not from a changed IP address or new deployment environment.

Do not solve a timeout by opening the database to 0.0.0.0/0. That exposes the database to connection attempts from anywhere on the internet. If you must add a temporary rule for diagnosis, restrict it to a known, trusted source, set an expiry or removal reminder, and document why it was needed.

Also check whether the RDS instance is private. A private RDS database is commonly reached from an application server inside the VPC, through a VPN, or through another approved private connection. Making the database publicly accessible is not a safe shortcut and may still fail if security groups or routing are wrong.

What changed: make the smallest network correction

If you find a missing or incorrect rule, update only that rule to allow the application server’s security group on the database port. Record the old and new values and the time of the change.

How to roll back

Restore the previous inbound rule if the correction causes a new problem. Remove any temporary diagnostic rule as soon as testing is complete. Never leave a broad public database rule in place.

5. Review wp-config.php safely

Before editing wp-config.php, make a secure backup of the file and confirm you can restore it. Use your hosting control panel, SFTP, or a deployment process you already trust. Don’t paste the file into a public support forum: it contains database credentials and may contain authentication keys.

The basic settings are usually similar to these:

define( 'DB_NAME', 'wordpress_db' );

define( 'DB_USER', 'wordpress_user' ); define( 'DB_PASSWORD', 'replace-with-the-current-password' ); define( 'DB_HOST', 'your-endpoint.rds.amazonaws.com:3306' );

Preserve the existing formatting and quoting. Confirm that the definitions occur once and that the file has no accidental characters, missing quotes, or trailing spaces. If your host injects configuration through environment variables or a secrets manager, changing the file may not be the correct fix; verify the deployment method first.

Avoid changing table prefixes or unrelated constants while troubleshooting a connection. These don’t repair network access and can create additional problems. Likewise, don’t enable public debug output on a live site. If you need more detail, use private server logs and turn off temporary diagnostics after the investigation.

What changed: correct only a confirmed wrong value

When you have a verified mismatch, update that one setting and test the site. Keep the original file backup and note the change.

How to roll back

Restore the saved copy of wp-config.php if the site becomes less available or the change is incorrect. Check file ownership and permissions after restoring it.

6. Check SSL connection requirements

An SSL connection can matter when the database requires or enforces encrypted connections. If WordPress or its PHP MySQL driver is not configured with the required CA certificate or TLS options, the connection may fail even when the endpoint, password, and security group are correct.

First verify the RDS engine’s encryption or SSL settings and whether a recent policy change made TLS mandatory. Then confirm that the web server’s PHP MySQL driver supports the required TLS version and that the correct Amazon RDS CA certificate is available and current. Certificate paths and connection options depend on the hosting environment and driver; don’t copy a setting intended for a different platform without checking its documentation.

If the error appeared after a certificate update or a change that required encrypted connections, compare the application’s SSL configuration with the current RDS requirements. Do not disable enforced encryption as a quick fix. Instead, correct the client’s certificate trust and TLS configuration, and test from the application server.

What changed: update the client’s TLS configuration only if required

If you add or update a CA certificate or connection option, document its file path, source, and renewal process. Test the connection before treating the incident as resolved.

How to roll back

Restore the previous client configuration or certificate only if it remains valid and compatible with the database’s current requirements. Never roll back by disabling a security requirement without an approved risk decision.

7. Check the web host, PHP, and connection limits

If RDS is healthy and the network path is open, inspect the application server. Check disk space, memory, CPU, PHP-FPM or web-server health, and the PHP error log around the recorded failure time. A full disk, stopped PHP service, resource exhaustion, or deployment error can prevent WordPress from connecting even when the database is fine.

Confirm that the PHP version has a working MySQL driver, usually mysqli or a compatible driver supported by the site’s PHP version. If the database test succeeds from the server but WordPress still fails, inspect PHP logs for errors such as a missing extension, TLS negotiation failure, or an invalid configuration value.

Check for connection spikes or a database connection limit. A plugin or background job may open too many connections, but don’t start disabling plugins at random. If you have a recent backup and a safe way to test, reproduce the issue on staging or disable one suspected component at a time, recording each change.

What changed: isolate one application-side cause at a time

Use logs and controlled tests before altering services or plugins. If a restart is necessary, restart only the affected service and record its status before and after.

How to roll back

Re-enable any component you disabled for testing, restore prior service configuration, and return to the saved deployment if the change worsens the outage.

8. Confirm recovery and prevent a repeat

After the site returns, test the homepage, a representative post, the WordPress login page, and one database-backed action such as a form or search. Check application and RDS logs for continuing errors. A page loading once is not enough if the connection is still unstable.

Close out the scratchpad with the confirmed cause, the fix, the time service recovered, and any temporary rule or diagnostic setting you removed. Keep database credentials in a secure secrets system, document the correct endpoint per environment, and alert the team before password rotation or network changes. Monitor RDS connections and storage so capacity problems can be addressed before they become an outage.

Quick troubleshooting summary

1. Record the exact error, start time, and recent changes.
2. Check the correct RDS instance’s status, events, and connection metrics.
3. Verify the database name, user, password, and db endpoint hostname in the live WordPress configuration.
4. Test from the web server and interpret a timeout differently from an access-denied error.
5. Confirm the RDS security group allows the application server on the correct port.
6. Check SSL connection requirements, PHP logs, host health, and connection limits.
7. Make one documented change at a time, with a backup and a clear rollback plan.

The fastest safe fix is usually the smallest confirmed correction: a stale endpoint, rotated password, or missing security-group rule. If the evidence points to a hosting or AWS networking issue, provide your provider or cloud administrator with the timestamp, source server or security group, destination endpoint and port, exact error text, and the tests already performed. That gives them a specific path to investigate without sharing database secrets.