RDS Database Authentication

Accessing databases on Amazon RDS (PostgreSQL, MySQL, SQL Server, etc.) involves two distinct layers: the network layer (the database needs to be reachable via security groups, VPC, and subnet) and the authentication layer (the database needs to recognize who is connecting). This article focuses on the second layer — where two fundamentally different models exist.

Model 1: Native Database User

The traditional model. You create a user directly inside the database with CREATE USER and define permissions with GRANT.

-- Create user in PostgreSQL
CREATE USER engineer_joao WITH PASSWORD 'StrongPassword123!';

-- Grant permissions on specific tables
GRANT SELECT, INSERT ON schema_app.customers_table TO engineer_joao;
GRANT SELECT ON schema_app.orders_table TO engineer_joao;

Characteristics:

• The user and password exist inside the database — they are independent of AWS IAM.
• The password is static and needs to be rotated manually (or via Secrets Manager).
• Each database has its own users — there is no centralization.
• Revoking access requires connecting to the database and executing DROP USER or REVOKE.

Problems:

• Shared passwords: In practice, teams end up sharing credentials from a "generic user" instead of creating individual users.
• Eternal passwords: Once created, the password is rarely rotated.
• Weak auditing: Knowing who ran which query is difficult when multiple engineers use the same user.
• Credential sprawl: Each database has its own users, multiplying the problem in environments with dozens of databases.

Model 2: IAM Authentication on RDS

AWS allows RDS databases (PostgreSQL and MySQL) to use IAM tokens instead of passwords to authenticate connections. In this model, the user exists in the database, but authentication is done via IAM — the database validates a temporary token generated by AWS instead of a static password.

Configuration

To enable IAM authentication on RDS, the following steps are required:

1. Enable IAM Authentication on RDS:

aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --enable-iam-database-authentication \
  --apply-immediately

2. Create the database user with IAM authentication grant:

-- PostgreSQL
CREATE USER engineer_joao;
GRANT rds_iam TO engineer_joao;

The GRANT rds_iam tells PostgreSQL that this user authenticates via IAM token instead of a password.

3. Grant IAM permission to the AWS user:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds-db:<region>:<account>:dbuser:<dbi-resource-id>/engineer_joao"
    }
  ]
}

4. Connect using the token:

# Generate authentication token
TOKEN=$(aws rds generate-db-auth-token \
  --hostname my-database.abc123.us-east-1.rds.amazonaws.com \
  --port 5432 \
  --username engineer_joao)

# Connect to the database with the token
psql "host=my-database.abc123.us-east-1.rds.amazonaws.com \
      port=5432 \
      dbname=my_database \
      user=engineer_joao \
      password=$TOKEN \
      sslmode=require"

IAM Auth Advantages

Aspect	Native Password	IAM Auth
Credential type	Static password	Temporary token (15 min)
Where authentication lives	Inside the database	AWS IAM
Rotation	Manual or via Secrets Manager	Automatic (token expires)
Auditing	Database logs only	CloudTrail + database logs
Centralization	Each database is independent	Centralized in IAM
Revocation	Connect to database and remove	Remove IAM policy

IAM Auth Limitations

• Available only for PostgreSQL and MySQL on RDS (and Aurora).
• Limit of 20 connections per second using IAM Auth per RDS instance — not suitable for high-frequency applications.
• The token is valid for 15 minutes — suitable for interactive sessions, but requires automatic renewal for long-running connections.
• SQL Server, Oracle, and MariaDB on RDS do not support IAM Auth — in those cases, the native user model (with possible Secrets Manager integration) is the only option.

In Practice: Which Model to Use?

In most organizations, both models coexist:

• Applications typically use native users with passwords managed by AWS Secrets Manager (with automatic rotation). The volume of connections per second in production frequently exceeds the IAM Auth limit.
• Engineers and human access are the ideal scenario for IAM Auth — sporadic connections, short duration, and the need for granular auditing.

This separation is exactly the point where Just-in-Time access management tools like Apono operate most efficiently — controlling who receives the rds-db:connect policy and for how long (for IAM Auth) or creating and removing temporary users directly in the database (for native authentication).