Reset or Change an RDS Master Password (Console and CLI), Find the Username, and Why Secrets Manager Keeps Changing It

To reset an Amazon RDS master password, open the database in the RDS console, choose Modify, type a New master password, and continue; or run aws rds modify-db-instance --db-instance-identifier mydb --master-user-password 'NewPassw0rd' (use modify-db-cluster for Aurora). It takes effect within a minute or two with no reboot and no downtime, while the status shows resetting-master-credentials. You do not need the old password, only IAM permission to modify the instance. Forgot the username? It is in the console's Configuration tab, or aws rds describe-db-instances --query "DBInstances[].MasterUsername". If your password "changes by itself", the instance uses RDS-managed credentials in AWS Secrets Manager: RDS generates the password, stores it in a secret named like rds!db-..., and rotates it every 7 days by default, so applications must read it from Secrets Manager instead of a config file. Below: every way to reset or rotate it, how to get the current password, how to switch between managed and manual passwords, password rules per engine, and the errors that follow a reset.

The shop's reporting tool stopped connecting to the database every Monday morning. Jake reset the master password by hand each time, it worked for a week, and then it failed again. The pattern was the clue: the database had been created with "Manage master credentials in AWS Secrets Manager" selected, and RDS was rotating the password on schedule, exactly as designed. The tool had the old password pasted into its settings.

New to RDS or to database passwords on AWS? The cards below cover RDS itself, the two login errors that send people here, and Secrets Manager.

First: which kind of password does your database have?

An RDS database uses one of two ways to hold its master password, and the reset is different for each. Check before you change anything:

aws rds describe-db-instances --db-instance-identifier shop-db \
  --query "DBInstances[].[MasterUsername,MasterUserSecret.SecretArn,MasterUserSecret.SecretStatus]" --output table

In the console, the same answer is on the database's Configuration tab: a managed database shows a "Master credentials ARN" linking to its secret, while a manual one shows only the username. For Aurora, look at the cluster's Configuration tab, since the credentials belong to the cluster. It takes ten seconds and decides everything that follows: resetting a managed password by hand, without turning management off, is not possible, and resetting a manual one while applications expect a secret leaves them with nothing to read.

Jake: "There's a secret ARN with rds!db in it. So it's been rotating all along?"

Ethan: "Every seven days. The tool needs to read the secret, not remember a password."

Reset a manual master password (console and CLI)

In the console:

1. Open RDS, choose Databases, and select your database (for Aurora, select the cluster, not an instance).
2. Choose Modify.
3. Under Settings, enter the New master password and confirm it.
4. Choose Continue, then Modify DB instance. The password change is applied as soon as possible whatever you pick for scheduling.
5. Wait until the status goes from resetting-master-credentials back to available (usually a minute or two), then connect with the new password.

With the AWS CLI (Windows users: single quotes stop special characters being read by the shell in PowerShell; in Command Prompt use double quotes):

aws rds modify-db-instance --db-instance-identifier shop-db \
  --master-user-password 'Correct-Horse-Battery-2026' --apply-immediately

aws rds wait db-instance-available --db-instance-identifier shop-db

Things worth knowing about the reset:

• No old password needed: RDS checks your IAM permission (rds:ModifyDBInstance), not the database password. That is also why you should limit who has that permission.
• No reboot, no downtime: existing connections stay open; new connections need the new password.
• Read replicas take the password from the primary; change it there.
• Snapshots keep the old password: a database restored from a snapshot starts with the password it had when the snapshot was taken, so reset it after a restore if you have rotated since.

Why your RDS password keeps changing: Secrets Manager rotation

Since late 2022, RDS can manage the master password for you. When "Manage master credentials in AWS Secrets Manager" is selected (at creation or later):

• RDS generates the password (28 characters, mixed case, digits and punctuation) and stores it in a secret named rds!db-<id>.
• RDS rotates it every seven days by default; you can change the schedule on the secret.
• Nobody needs to see or type it: applications fetch it from Secrets Manager at connect time.
• Deleting the database deletes the secret too.

So "my RDS password resets every week" is the feature working. The fix is in the application: read the secret at start-up (and again when a login fails), instead of storing the password. If the application cannot do that (an old reporting tool, a third-party product), either switch the database back to a manual password (see below) or give that tool its own database user with a password you control, and keep the master user for administration.

Our Secrets Manager explainer covers secrets in general, and our cost comparison shows what a secret costs each month.

How to get the current RDS password (aws rds get password)

For a managed password, read the secret:

SECRET=$(aws rds describe-db-instances --db-instance-identifier shop-db \
  --query "DBInstances[].MasterUserSecret.SecretArn" --output text)
aws secretsmanager get-secret-value --secret-id "$SECRET" --query SecretString --output text

The result is a small JSON document with username and password. In Python, applications do the same at connect time:

import json, boto3

secret_arn = "arn:aws:secretsmanager:eu-west-2:111122223333:secret:rds!db-0a1b2c3d-AbCdEf"
creds = json.loads(boto3.client("secretsmanager").get_secret_value(SecretId=secret_arn)["SecretString"])
# connect with creds["username"] and creds["password"]

In the console, open Secrets Manager, choose the secret named rds!db-... (the database's Configuration tab links to it), and choose Retrieve secret value. Reading it needs secretsmanager:GetSecretValue on the secret and kms:Decrypt on its KMS key, so a person who can modify the database cannot necessarily read the password, and the other way round; that separation is useful, and worth keeping. Each read is also recorded in CloudTrail as a GetSecretValue call, so you can see who looked at the password and when.

For a manual password, there is no way to "see" it: RDS does not store it in readable form. If nobody knows it, reset it as above. To skip passwords entirely for MySQL and PostgreSQL applications, consider IAM database authentication, where apps log in with short-lived tokens.

For Lambda functions connecting through RDS Proxy, the proxy reads the secret for you, so rotations do not break connections; our RDS Proxy guide covers that setup.

Make your applications survive rotation

Managed passwords only work if every application reads the secret instead of remembering a password. The patterns that hold up, by where the application runs:

• Any long-running service: read the secret at start-up, keep it in memory, and on an authentication error, fetch it again once and retry the connection. Rotation then costs one failed login at most, never an outage.
• With a cache: the AWS Secrets Manager caching libraries (for Python, Java and other languages) keep the secret in memory and refresh it on a schedule, which saves API calls and money in busy applications.
• AWS Lambda: the AWS Parameters and Secrets Lambda Extension caches secrets inside the execution environment, so functions read them over a local HTTP call instead of calling Secrets Manager every time. Or connect through RDS Proxy, which reads the secret itself.
• Amazon ECS: secrets injected as environment variables are read only when a task starts, so after a rotation, running tasks keep the old password. Either have the application read the secret itself, or force a new deployment after rotation.
• Third-party tools that only accept a typed password: give them their own database user with a password you manage, as described below; do not point them at the rotating master user.

A minimal retry pattern in Python, for a service that keeps a connection pool:

import json, boto3, psycopg

sm = boto3.client("secretsmanager")
SECRET = "arn:aws:secretsmanager:eu-west-2:111122223333:secret:rds!db-0a1b2c3d-AbCdEf"

def creds():
    return json.loads(sm.get_secret_value(SecretId=SECRET)["SecretString"])

def connect(c):
    return psycopg.connect(host="shop-db.abc123.eu-west-2.rds.amazonaws.com", dbname="shop",
                           user=c["username"], password=c["password"], sslmode="require")

current = creds()
try:
    conn = connect(current)
except psycopg.OperationalError:
    current = creds()          # the password may have just rotated: fetch once more
    conn = connect(current)

The same idea works in any language: treat an authentication failure as "my copy of the password may be stale", refresh once, and only then report an error.

Jake: "So the report tool fails Mondays because it only learned the password once?"

Ethan: "Right. Anything that reads the secret again on a failed login never notices the rotation."

Rotate a managed password right now

If a managed password may have leaked, or you want a fresh one before a handover, rotate immediately instead of waiting for the schedule:

aws rds modify-db-instance --db-instance-identifier shop-db \
  --rotate-master-user-password --apply-immediately

In the console: Modify, Settings, Rotate secret immediately, and choose Apply immediately on the confirmation page (rotation requires it). Applications that read the secret pick up the new password on their next fetch; anything with the old one cached fails until it re-reads.

To change how often it rotates, open the secret in Secrets Manager and edit its rotation configuration: a longer interval, or a schedule expression that rotates at a quiet time, such as early Sunday morning. Rotating at a predictable, low-traffic moment makes any application that still caches the password fail where you can see it, instead of in the middle of a working day. Turning rotation off entirely is possible but gives up most of the reason for managed credentials; if an application cannot cope with rotation, a separate user for it is the better fix.

Jake: "So rotating is a reset where the app doesn't even notice?"

Ethan: "If the app reads the secret, yes. That's the whole point of letting RDS hold it."

RDS Proxy and password changes

RDS Proxy sits between your applications and the database and logs in on their behalf using credentials from Secrets Manager: one secret for each database user the proxy may use. That changes how a reset feels:

• With a managed or rotated secret, the proxy picks up the new password from the secret, and applications connected to the proxy do not need to know it at all.
• With a manual reset, update the secret the proxy uses straight away; until you do, the proxy's new connections to the database fail even though the password is correct everywhere else.
• Applications can sign in to the proxy with IAM authentication, so no application holds a database password in the first place; the proxy holds the only copy, in Secrets Manager.

For Lambda functions in particular, this is the cleanest setup: no password in the function, connection pooling for spiky traffic, and rotation that nobody notices.

Switch between managed and manual passwords

Turning management on or off takes effect immediately and causes no downtime:

# let RDS manage it (generates a new password and a secret)
aws rds modify-db-instance --db-instance-identifier shop-db --manage-master-user-password

# take it back: stop managing and set your own
aws rds modify-db-instance --db-instance-identifier shop-db \
  --no-manage-master-user-password --master-user-password 'Your-Own-Strong-Password'

Know the limits before you choose managed: creating new read replicas from a source with managed credentials is not supported for most engines (SQL Server and Db2 are the exceptions), and neither are Blue/Green Deployments or RDS Custom. If you rely on those, a manual password stored in a secret you manage is the workaround. If the secret ever shows status impaired (usually because a KMS key or permission changed), fix the cause, or turn management off and on again.

Plan the switch like a password change, because it is one. Turning management on generates a brand-new password at once, so every application using the old one fails until it reads the secret. Turning it off sets the password you supply, so applications reading the secret need to move to wherever you will keep the new one. Do it in a quiet window, with the application changes ready, and check the database's status returns to available before you test logins. You can also choose your own KMS key for the managed secret when you turn management on (--master-user-secret-kms-key-id), which matters if your security rules require customer managed keys.

Find your RDS master username

Forgot the username, not the password? It never changes after creation and is easy to look up:

aws rds describe-db-instances --query "DBInstances[].[DBInstanceIdentifier,Engine,MasterUsername]" --output table
aws rds describe-db-clusters --query "DBClusters[].[DBClusterIdentifier,Engine,MasterUsername]" --output table

In the console it is on the database's Configuration tab, as "Master username". Common defaults people chose are admin (MySQL, MariaDB), postgres (PostgreSQL) and admin or sa-style names for SQL Server, but only the console or CLI tells you what yours is. For managed credentials, the secret's JSON also contains the username next to the password.

Better than sharing the master login: give each application its own database user, so a password change for one never breaks the others.

1. Connect as the master user with a client (MySQL Workbench, psql, DBeaver).
2. Create a user for the application: CREATE USER report_tool IDENTIFIED BY '...'; in MySQL, or CREATE ROLE report_tool LOGIN PASSWORD '...'; in PostgreSQL.
3. Grant only what it needs, such as read access to the reporting schema.
4. Store that password in its own secret, with rotation if the application can re-read it.
5. Point the application at the new user, and keep the master user for administration only.

Jake: "So the report tool gets its own login, and the master password can rotate all it likes?"

Ethan: "Exactly. One password per job. Nothing else breaks on Monday."

What you cannot change: the master username, and the "root" password

Two common requests have no direct answer in RDS, and knowing that saves a long search.

Renaming the master user. The master username is fixed when the database is created; there is no modify option for it, and restoring a snapshot keeps it too. If the name itself is the problem (it appears in an audit as a shared generic "admin", say), create a new administrative user with the privileges you need, move people and tools to it, and keep the master user for break-glass use only, with its password managed and rotated by RDS. A new database created from scratch, with a migration, is the only way to get a different master name.

The root or default password. RDS databases have no default password and no hidden root login you can use. On MySQL, the root account belongs to RDS, and the master user you created takes its place for you; on PostgreSQL, the real postgres superuser is RDS's, and your master user has rds_superuser. Guides that tell you to start MySQL with --skip-grant-tables to reset a root password do not apply: you have no access to the server process. The master password reset through RDS is the only route, and it is quicker anyway.

Jake: "A blog post said to restart MySQL in safe mode to reset the root password."

Ethan: "That's for a server you own. On RDS there's no server to restart. Modify, new master password, done."

Password policies and stronger login rules

RDS itself does not expire manual master passwords or force a change after a number of days; if your security rules require rotation, managed credentials are the way to get it without anyone remembering. Inside the database, you can tighten the rules further:

• PostgreSQL: store passwords with SCRAM rather than MD5 by setting password_encryption to scram-sha-256 in the parameter group, and limit which methods RDS accepts with rds.accepted_password_auth_method. After changing the encryption setting, reset each user's password so it is stored the new way.
• MySQL 8: the password validation component can enforce length and character rules for users you create inside the database.
• All engines: require TLS for connections (for example rds.force_ssl on PostgreSQL and SQL Server, or require_secure_transport on MySQL) so the new password never crosses the network in clear text.
• Passwordless where possible: IAM database authentication for MySQL and PostgreSQL removes stored passwords for applications entirely.

Database logins do not support MFA directly. The usual approach is to put the strong controls in front of the database instead: people reach it through Session Manager or a bastion that requires MFA at sign-in, and applications use IAM authentication or rotated secrets.

Aurora clusters

For Aurora, the password belongs to the cluster, so you modify the cluster rather than one of its instances:

aws rds modify-db-cluster --db-cluster-identifier shop-aurora \
  --master-user-password 'Correct-Horse-Battery-2026' --apply-immediately

# or rotate a managed one
aws rds modify-db-cluster --db-cluster-identifier shop-aurora --rotate-master-user-password --apply-immediately

All instances in the cluster, writer and readers, use the new password straight away. The same applies to Multi-AZ DB clusters. Two Aurora-specific notes: an Aurora global database has one master user across Regions, so change it on the primary cluster; and Aurora Serverless clusters that have scaled to zero accept the change but only wake for the next connection, which is when you will first see whether the new password works.

Jake: "I modified the writer instance and the password option wasn't there."

Ethan: "On Aurora it lives on the cluster. Select the cluster row, then Modify."

SQL Server, Oracle and Db2: the same reset, different master users

The reset itself works the same way on every RDS engine: Modify in the console, or modify-db-instance --master-user-password. What differs is what the master user can do afterwards:

• SQL Server: the master user is not a full sysadmin; RDS keeps that role for itself so it can manage the instance. The master user can create logins, databases and users, and resetting its password through RDS restores the permissions RDS gives it. If an application connects as the master login, the reset breaks it in the same way as on other engines.
• Oracle: the master user has a set of administrative privileges, but not SYS or SYSDBA, which RDS reserves. Password resets go through RDS, not ALTER USER on the master account, if you want the restore-privileges behavior.
• Db2: the master user is the instance administrator inside the limits RDS sets; resets follow the same modify command.

On all of them, the rejected characters and the "no old password needed" rule are the same, and the change applies without a reboot. For SQL Server applications that use Windows authentication through AWS Managed Microsoft AD, the master password does not affect them at all; their logins come from the directory.

Password rules by engine

Characters such as @ and / are rejected because they break connection strings (user:password@host/db). If an existing password contains :, # or %, URL-encode it in database URLs, or pass it as a separate parameter in your driver.

A long passphrase of plain words and digits ("Correct-Horse-Battery-2026") avoids every special-character problem and is strong. Better still, let RDS generate and rotate it.

Restore a master user's lost privileges

If someone revoked privileges from the master user (a REVOKE run in the wrong window, a broken migration), setting a new master password through RDS also restores the master user's standard privileges. It is the official way back in when the master user can still log in but can no longer manage the database. After the reset, confirm with SHOW GRANTS FOR CURRENT_USER; in MySQL or \du in psql, and then fix whatever script removed them, so the next run does not repeat it. For MySQL privilege errors that are not about the master user, see our ERROR 1045 guide.

It helps to know what "standard privileges" means on each engine. On PostgreSQL, the master user is a member of the rds_superuser role, which can do most administrative work but is not a true superuser. On MySQL and MariaDB, the master user holds a broad set of global privileges (creating users and databases, granting rights) without the few that would let it change the server itself. Asking for privileges RDS keeps for itself, such as a true PostgreSQL superuser or MySQL's SUPER on recent versions, fails whatever the password; those tasks go through RDS features such as parameter groups instead.

Reset the password of a normal database user

The master password is changed through RDS; every other database user is changed inside the database, by the master user or another account with the right privilege:

-- MySQL / MariaDB
ALTER USER 'report_tool'@'%' IDENTIFIED BY 'New-Report-Pass-2026';

-- PostgreSQL
ALTER ROLE report_tool WITH PASSWORD 'New-Report-Pass-2026';

-- SQL Server
ALTER LOGIN report_tool WITH PASSWORD = 'New-Report-Pass-2026';

Then update wherever that application reads its password, ideally its own secret. For users that should rotate too, Secrets Manager can rotate an application user's password with a Lambda function from its templates. The "alternating users" strategy keeps two users with the same rights and switches between them, so a connection made just before rotation never finds its password gone, which is the safest choice for busy applications.

If you have lost the master password as well, reset the master first through RDS, then use it to fix the other users.

CloudFormation, CDK and Terraform: keep the password out of your code

Infrastructure code is where master passwords most often leak: written into a template, committed to Git, or stored in Terraform state. Each tool has a cleaner option:

• CloudFormation: set ManageMasterUserPassword: true on AWS::RDS::DBInstance (or the cluster) instead of MasterUserPassword. RDS creates the secret, and !GetAtt Database.MasterUserSecret.SecretArn gives you its ARN to pass to applications.
• AWS CDK: the database constructs can generate credentials into Secrets Manager for you; pass the secret to your services rather than a plain string.
• Terraform: manage_master_user_password = true on aws_db_instance or aws_rds_cluster lets RDS own the password, and the master_user_secret attribute exposes the secret ARN. If you set password directly, Terraform keeps it in plain text in the state file, so protect the state (encrypted remote backend, tight access) or use the write-only password argument that newer provider versions offer.

One trap with templates: if a template sets MasterUserPassword and someone later resets the password in the console, the next stack update can set it back to the template's value, breaking every application that learned the new one. Pick one owner for the password, the template, a person, or RDS, and stick to it.

Who changed the password? Auditing resets

When a database login suddenly fails, the first question is whether someone reset the master password. Two records answer it:

1. CloudTrail: every reset is a ModifyDBInstance (or ModifyDBCluster) call, with who made it and when. The password value itself is not recorded in the event, so the log is safe to share with your team. Search Event history for the event name, filtered to the database's identifier.
2. RDS events: the database's event list shows a "reset master credentials" style message at the time of the change. In the console it is the database's Logs and events tab, and aws rds describe-events --source-identifier shop-db --source-type db-instance lists it from the CLI.

To be told the next time, subscribe to the database's configuration change events with an RDS event subscription to an SNS topic, or an EventBridge rule on RDS events. And keep rds:ModifyDBInstance to a small group: anyone with that permission can set a new master password without knowing the old one, which is the convenient part of RDS and also the part worth guarding.

Locked out completely: no password, no idea who has access

The worst case is a database nobody can log in to and nobody seems able to modify. It is recoverable, in this order:

1. Find an identity with rds:ModifyDBInstance on the database: an administrator role, an IAM Identity Center permission set with admin rights, or, in a standalone account, the root user. No database credential is needed for the reset.
2. Reset the master password as above, then sign in and check the database's users and grants.
3. If the account itself is locked (no administrator can sign in), recover access to the AWS account first through the root user's email and MFA recovery; RDS cannot be reached any other way.
4. Afterwards, switch the database to managed credentials or store the password in a secret, give applications their own users, and make sure at least two people can reach an administrator role.

Restoring a snapshot to a new instance does not get around a lost password, since the restored copy has the same one; the reset is the tool, and it only needs AWS permissions.

Many databases at once

After a staff change or a suspected leak, you may need fresh passwords on every database in an account. Start by listing which ones are managed and which are not:

aws rds describe-db-instances \
  --query "DBInstances[].[DBInstanceIdentifier,Engine,MasterUserSecret.SecretStatus]" --output table

Managed databases rotate with one command each (modify-db-instance --rotate-master-user-password --apply-immediately), and their applications should carry on, since they read the secret. Databases with manual passwords need a new password each, which is the moment to move them to managed credentials instead of inventing new passwords by hand. Work in small batches, check each application after its database changes, and leave Aurora clusters to modify-db-cluster. The listing above, run across Regions, also doubles as an audit: any row without a secret status is a password that lives in someone's head or in a file.

For a regular check, an AWS Config custom rule or a small scheduled Lambda function can report databases without managed credentials, so new ones created by hand do not slip back to manual passwords unnoticed.

Snapshots, replicas and restored copies

Passwords travel with the data in a few ways people do not expect:

• A restored snapshot starts with the master password from snapshot time. After restoring an old snapshot for an investigation, reset its password before anyone connects, and do not reuse production secrets for the copy.
• Read replicas share the primary's users and passwords, because they replicate the database itself. A promoted replica keeps them too, so after promotion the new standalone database still accepts the old application logins.
• Cross-Region replicas and copied snapshots behave the same way across Regions: same users, same passwords.
• Development copies made from production snapshots carry production passwords into a less protected place. Reset them as part of the refresh script, every time.

Jake: "The test database restored from last month still takes the production password."

Ethan: "Of course: it's last month's production, users and all. Reset it in the refresh script, every time."

Testing the new password from a Windows PC

After a reset, test the login before telling anyone it is fixed. From Windows, the usual tools are MySQL Workbench for MySQL and MariaDB, pgAdmin or DBeaver for PostgreSQL, and SQL Server Management Studio for SQL Server. Use the database's endpoint from its Connectivity tab as the host, the master username, and the new password.

Most databases are not reachable from a home or office PC directly, and they should not be. Two safe ways to connect:

• Session Manager port forwarding: from a PC with the AWS CLI and the Session Manager plugin, forward a local port through any managed EC2 instance in the same VPC to the database, then point your client at localhost:

  aws ssm start-session --target i-0123456789abcdef0 --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters host="shop-db.abc123.eu-west-2.rds.amazonaws.com",portNumber="5432",localPortNumber="15432"

  No open ports, no bastion password, and every session is logged.
• A client on an EC2 instance or in CloudShell's VPC environment inside the same network as the database.

If the client times out instead of rejecting the password, the reset worked and the problem is the network path; our connection timeout guide covers it. A clear "access denied" or "authentication failed" means the network is fine and the credentials are wrong: check the username, the database name, and whether the status had reached available when you tried.

After a reset: a five-minute checklist

1. Wait for available, then log in once yourself with the new password.
2. Update every place that holds it: your secret (if you manage one), application settings, and scheduled jobs.
3. Restart or redeploy applications that read the password only at start-up, such as ECS tasks with injected secrets.
4. Check the logs for authentication failures over the next hour; each one names a place you missed.
5. Record who reset it and why, even in a one-line ticket, so the next person investigating a login failure does not start from zero.

Most "the reset did not work" reports are step 2 or 3: the database accepted the new password at once, but something kept the old one. A quick search of your configuration repository and parameter store for the database's endpoint name usually finds every place that still holds a copy. Each one you find is a candidate for reading the secret instead, so the next reset touches nothing but the database.

Errors after a reset, and fixes

• "Access denied for user" (MySQL) or "password authentication failed" (PostgreSQL) right after a reset: the change was still applying, the app has the old password cached, or it connects as a different user. Wait for available, restart the app, and check the username. Our Postgres guide covers the PostgreSQL side.
• "PAM authentication failed for user" (PostgreSQL): that user is set up for IAM database authentication (it has the rds_iam role), so PostgreSQL expects an IAM token, not a password. Either connect with a token generated by aws rds generate-db-auth-token, or, if the user should log in with a password, remove it from rds_iam (REVOKE rds_iam FROM report_tool;) and set a password. Our IAM authentication guide covers the token side.
• InvalidParameterCombination when setting a password: the instance has managed credentials; use --no-manage-master-user-password together with --master-user-password.
• InvalidParameterValue: the password breaks the length or character rules above.
• AccessDenied on ModifyDBInstance: your IAM identity lacks rds:ModifyDBInstance; turning on managed credentials also needs secretsmanager:CreateSecret and kms:DescribeKey.
• Status stuck in resetting-master-credentials for a long time: usually another pending modification is running; our stuck-in-modifying guide explains what to check.
• Timeout instead of a password error: that is networking (security group, public access), not the password; see our connection timeout guide.

Frequently asked questions

The reporting tool now connects as its own database user with a password the team controls, stored in a secret it can read. The master password stays managed by RDS and rotates weekly, and nobody has typed it since. Monday mornings are quiet again.

The clean-up went further than the one tool. Ethan listed every database in the account, moved the two with manual master passwords to managed credentials, gave each application its own user, and added a step to the development refresh script that resets the copied database's passwords. An RDS event subscription now posts to the team chat whenever a master password changes, so the next "it stopped working" starts with a known cause instead of a guess.

Revision note. Written October 20, 2026. A password that changes every Monday is usually a feature with a missing integration.