Yes, on Amazon RDS. With IAM database authentication your app asks for an authentication token and uses it as the database password. Each token has a lifetime of 15 minutes, so there is no long-lived password to leak. It has limits, including extra memory use on the database and gaps in logging.
How it works
The RDS documentation says you do not use a password to connect to a database instance with this method. Instead you use an authentication token, a unique string that Amazon RDS generates on request. Tokens are generated using AWS Signature Version 4, and each has a lifetime of 15 minutes.
The docs also say the token is only used for authentication and does not affect the session after it is established. A connection opened with a valid token keeps working after that token expires. Only new connections need a fresh one.
Network traffic to and from the database is encrypted with SSL or TLS when you use this method, according to the same page.
Compared with a stored password
| Question | Stored password | IAM token |
|---|---|---|
| What is the secret? | A string kept in a vault or env var | A token generated on request |
| How long does it live? | Until rotated | 15 minutes |
| Where is the credential issued? | Database | AWS identity system |
| What if it leaks in a log? | Valid until you rotate | Expires within the window |
| Pool friendly? | Yes | Needs care, see below |
The security gain is real. A leaked config file or log line no longer holds a working credential after a quarter hour. Rotation becomes the default instead of a project.
The caveats from the documentation
- Memory. The docs say IAM database authentication requires compute resources on the database instance, and you need between 300 and 1000 MiB of extra memory for reliable connectivity.
- Logging. The page states that CloudWatch and CloudTrail do not log IAM authentication, and that these services do not track the generate token API calls that authorize the role to connect. Plan your audit trail around that.
- Token size. The token is generally about 1 KB or larger. Because it is used as the password in the connection string, the docs say you should make sure your driver does not truncate it.
That third point is a common cause of confusing failures. If a driver or proxy caps password length, connections fail with an authentication error that looks like a permissions problem.
What to change in your app
- Create the database user for IAM authentication and grant it only the privileges the app needs. See least privilege roles for PostgreSQL.
- Give the compute role permission to connect as that database user.
- Generate a token in code at connection time, not at deploy time.
- In a pool, make the pool request a fresh token whenever it opens a connection, since tokens expire in 15 minutes.
- Require TLS and verify the server certificate. See sslmode verify-full.
- Keep a separate migration role. See separating migration and runtime roles.
Is it the right call for you?
If your team already manages workload identity in AWS, it removes a secret from the picture. If you run many short connections, check the memory note and the logging gap first. Other clouds and databases have their own versions of this idea, so read the provider's documentation for the real numbers rather than assuming they match.
Safeguard scans dependencies, including database drivers and cloud SDKs. A free scan is at gold.safeguard.sh/scan.
Quick check
Does the connection drop when the token expires?
The docs say the token is only used for authentication and does not affect the session after it is established.
Are IAM logins recorded in CloudTrail?
The RDS docs say CloudWatch and CloudTrail do not log IAM authentication, so plan other audit sources.
Is the token small?
No. The docs say it is generally about 1 KB or larger, so check your driver's password length handling.
Sources
Last reviewed: 19 October 2026.
