How to debug implicit rdsauthproxy

Question

Hi!

I have a pool of RDS readers, to which I connect with IAM tokens. Once in a while, when trying to connect, my clients get "PAM authentication failed". It happened again this morning (2025-07-21 09h23UTC), and all the errors originated from the same RDS instance.

I consulted the error log of that RDS instance during that time frame, and it contains a bunch of the following:

```
 * Host rdsauthproxy:1108 was resolved.
 * IPv6: (none)
 * IPv4: 172.17.15.2
 *   Trying 172.17.15.2:1108...
 * connect to 172.17.15.2 port 1108 from 172.17.15.3 port 13474 failed: Connection refused
 * Failed to connect to rdsauthproxy port 1108 after 9 ms: Could not connect to server
 * closing connection #0
 ```

After less than a minute, the error went away, and normal operations resumed.

Now, how do I debug this? This RDS auth proxy seems to be automatically generated/handled within RDS, as I do not see it in the RDS > Proxies menu of the console. Was it down? Did it get too many connections? Were there some networking issues between the RDS instance and that proxy? I can't tell!

Also, FWIW, I know about the IAM token 15 minute expiration. I don't *think* it's the cause because operations work ok for many days/weeks over a pool of 3 to 6 RDS instances, and all of the sudden, they break over a _single_ RDS instance for about a minute, across many clients which happenned to reconnect during that timeframe.)

Any tip is appreciated.
Thank you!

re:Post Agent · Answer

When you're experiencing "PAM authentication failed" errors with IAM authentication to your RDS readers, the logs you shared provide important clues. The error messages show that the RDS instance was unable to connect to an internal authentication component called "rdsauthproxy" (on port 1108), which is different from the user-configurable RDS Proxy service that appears in the RDS > Proxies menu.

This internal rdsauthproxy is part of the IAM authentication mechanism for RDS. When you connect using IAM authentication, the database needs to validate your IAM token by communicating with this internal proxy component.

To troubleshoot this issue:

1. Check the `TargetHealth` status of your database instances using the AWS CLI command `describe-db-proxy-targets`. Look for instances with a `State` value of `UNAVAILABLE` and examine the `Reason` and `Description` fields for more details.

2. If the `Reason` shows `PENDING_PROXY_CAPACITY`, it could indicate that the proxy was scaling during that time, which might explain the temporary nature of your issue.

3. If the `Reason` shows `UNREACHABLE`, `CONNECTION_FAILED`, or `AUTH_FAILURE`, the description field should provide more specific information about what went wrong.

4. Since the issue was temporary and affected only one instance, it could have been caused by:
- A temporary network connectivity issue between the RDS instance and the internal authentication proxy
- The internal proxy component temporarily being overloaded with connection requests
- A brief scaling or maintenance operation on the authentication infrastructure

5. Monitor CloudWatch metrics for your RDS instances to look for spikes in connection attempts or other anomalies during the affected time period.

6. Consider implementing connection retry logic in your application to handle these temporary authentication failures gracefully.

Since the issue resolved itself quickly, it was likely a transient problem with the internal authentication infrastructure rather than an issue with your IAM tokens or configuration.  
**Sources**  
[Troubleshooting for RDS Proxy - Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.troubleshooting.html)  
[Troubleshooting for RDS Proxy - Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.troubleshooting.html)

How to debug implicit rdsauthproxy

Add your answer

Relevant content