RDS or Aurora parameter change not taking effect - pending-reboot, static parameters and the wrong parameter group

#Symptoms

• You changed a value in a parameter group, but SHOW max_connections; or SELECT @@max_connections; still returns the old value.
• The console shows the instance's parameter group as pending-reboot.
• modify-db-parameter-group fails with InvalidParameterCombination or InvalidParameterValue.
• The change worked on the writer but not on a reader, or the other way round.

Work through the checks in order. Most cases are settled by check 1 or 2.

#Check 1: are you editing the group that is actually attached?

People often edit a group with a similar name, or edit a DB parameter group when the setting lives in the Aurora cluster parameter group.

DB=prod-orders-db

aws rds describe-db-instances --db-instance-identifier $DB \
  --query 'DBInstances[0].{Engine:Engine,Cluster:DBClusterIdentifier,ParamGroups:DBParameterGroups}' \
  --output json

For Aurora, also check the cluster-level group:

aws rds describe-db-clusters --db-cluster-identifier prod-orders \
  --query 'DBClusters[0].{ClusterGroup:DBClusterParameterGroup,Members:DBClusterMembers[].[DBInstanceIdentifier,IsClusterWriter,DBClusterParameterGroupStatus]}' \
  --output json

In Aurora, instances can each use a different DB parameter group. If a reader didn't change, check that it has the same group as the writer.

Note

You can't change the default.* parameter groups. If an instance uses a default group, create a custom group, attach it, and reboot. The attach itself only takes effect after a reboot.

#Check 2: read the apply status

ParameterApplyStatus in the output above tells you where the change is:

For a fleet view:

aws rds describe-db-instances \
  --query "DBInstances[?DBParameterGroups[?ParameterApplyStatus=='pending-reboot']].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]" \
  --output table

#Check 3: is the parameter static or dynamic?

aws rds describe-db-parameters --db-parameter-group-name prod-pg16 \
  --query "Parameters[?ParameterName=='max_connections'].[ParameterName,ParameterValue,ApplyType,ApplyMethod,IsModifiable,AllowedValues]" \
  --output table

• ApplyType = static means it only changes after a reboot. max_connections and shared_buffers are static on PostgreSQL.
• ApplyType = dynamic can be applied with ApplyMethod=immediate.
• IsModifiable = False means RDS manages the value and you can't change it.

To list only the values you have changed in the group, use --source user:

aws rds describe-db-parameters --db-parameter-group-name prod-pg16 --source user \
  --query 'Parameters[].[ParameterName,ParameterValue,ApplyType]' --output table

Set the apply method to match the type. If you ask for immediate on a static parameter, the call fails:

# Dynamic parameter - applies without a reboot
aws rds modify-db-parameter-group --db-parameter-group-name prod-pg16 \
  --parameters "ParameterName=work_mem,ParameterValue=65536,ApplyMethod=immediate"

# Static parameter - must use pending-reboot
aws rds modify-db-parameter-group --db-parameter-group-name prod-pg16 \
  --parameters "ParameterName=max_connections,ParameterValue=800,ApplyMethod=pending-reboot"

For Aurora cluster groups, use modify-db-cluster-parameter-group and describe-db-cluster-parameters with the same options.

#Check 4: confirm inside the engine

The engine has the final say. Check units too, because RDS stores many memory parameters in kB or 8 kB pages.

PostgreSQL:

SELECT name, setting, unit, source, pending_restart
FROM pg_settings
WHERE name IN ('max_connections', 'work_mem', 'shared_buffers');

source shows where the value comes from. A value of user, database or session means something overrides the parameter group:

-- Per-role or per-database overrides
SELECT coalesce(r.rolname, '*') AS role, coalesce(d.datname, '*') AS db, s.setconfig
FROM pg_db_role_setting s
LEFT JOIN pg_roles r ON r.oid = s.setrole
LEFT JOIN pg_database d ON d.oid = s.setdatabase;

MySQL / Aurora MySQL:

SELECT @@GLOBAL.max_connections, @@SESSION.wait_timeout, @@GLOBAL.wait_timeout;

A session variable is set when the connection opens. Existing pooled connections keep the old session value until they reconnect, even after a dynamic global change.

#Formula values

Defaults like {DBInstanceClassMemory/12582880} are calculated from the instance class. If you resize the instance and the group still uses the formula, the effective value changes. If you replaced the formula with a fixed number, a larger instance won't get more connections. Check which one is in the group before you blame the reboot.

#The fix: reboot safely

Warning

A reboot drops every connection. On a Single-AZ instance expect a short outage. Schedule it, and tell the application owners.

# Multi-AZ instance deployment: reboot with failover to keep downtime short
aws rds reboot-db-instance --db-instance-identifier $DB --force-failover

aws rds wait db-instance-available --db-instance-identifier $DB

aws rds describe-db-instances --db-instance-identifier $DB \
  --query 'DBInstances[0].DBParameterGroups' --output table

For Aurora, reboot each instance with reboot-db-instance: readers first, the writer last. Rebooting the writer doesn't fail it over, so writes stop until it is back. To avoid that, fail over to an updated reader with aws rds failover-db-cluster --db-cluster-identifier prod-orders --target-db-instance-identifier <reader> and then reboot the old writer. Whether a writer reboot also restarts the readers depends on the engine version, so check your version's documentation.

To attach a different group and reboot in one planned change:

aws rds modify-db-instance --db-instance-identifier $DB \
  --db-parameter-group-name prod-pg16-v2 --apply-immediately
# Status becomes pending-reboot; then reboot as above

Caution

A static parameter with an invalid value, such as shared_buffers larger than the instance's memory, can stop the database from starting after the reboot. It ends up in incompatible-parameters. Test the change on a non-production copy of the same instance class first. Keep the previous group so you can attach it again.

#Quick symptom map

To reset a bad value:

aws rds reset-db-parameter-group --db-parameter-group-name prod-pg16 \
  --parameters "ParameterName=shared_buffers,ApplyMethod=pending-reboot"

#Prevent it next time

• Manage parameter groups in Terraform or CloudFormation. Version the group name (-v2) for static changes, so you can roll back by attaching the old group again.
• Alert on pending-reboot. Run the fleet query above on a schedule, or listen for RDS configuration-change events in EventBridge.
• Record in the change ticket whether each parameter is static or dynamic. Book a reboot window for every static change.
• After every change, check the value in the engine, not just in the console.