RDS and Aurora pending maintenance: a checklist for OS updates, minor upgrades and certificate rotation

#Goal

RDS shows "Maintenance: required" or "available" on a database, an AWS Health notice says a forced update is coming, or a database restarted overnight and nobody knew why. This checklist gets you from "what is pending?" to "applied, in a window we chose, with the app ready for it".

Work through it per Region. Pending maintenance is Regional, and so are all the commands below.

#1. List everything that is pending

aws rds describe-pending-maintenance-actions \
  --query "PendingMaintenanceActions[].{resource:ResourceIdentifier,action:PendingMaintenanceActionDetails[0].Action,autoAfter:PendingMaintenanceActionDetails[0].AutoAppliedAfterDate,forced:PendingMaintenanceActionDetails[0].ForcedApplyDate,optIn:PendingMaintenanceActionDetails[0].OptInStatus,desc:PendingMaintenanceActionDetails[0].Description}" \
  --output table

A resource can have more than one action. If a row looks incomplete, drop the [0] and look at the full PendingMaintenanceActionDetails list.

The fields that matter:

• Every row has an owner and a planned date before ForcedApplyDate.
• Repeat for each account and Region you run databases in.

To see the same notices across an organisation, AWS Health lists scheduled changes (the Health API requires a Business, Enterprise On-Ramp or Enterprise support plan):

aws health describe-events --region us-east-1 \
  --filter "services=RDS,eventTypeCategories=scheduledChange,eventStatusCodes=upcoming" \
  --query "events[].{type:eventTypeCode,region:region,start:startTime}" --output table

#2. Know your maintenance windows

aws rds describe-db-instances \
  --query "DBInstances[].{db:DBInstanceIdentifier,engine:Engine,ver:EngineVersion,window:PreferredMaintenanceWindow,autoMinor:AutoMinorVersionUpgrade,multiAZ:MultiAZ,ca:CACertificateIdentifier}" \
  --output table

aws rds describe-db-clusters \
  --query "DBClusters[].{cluster:DBClusterIdentifier,engine:Engine,ver:EngineVersion,window:PreferredMaintenanceWindow}" \
  --output table

Windows are in UTC, in the format ddd:hh:mm-ddd:hh:mm, and must be at least 30 minutes long. If you never set one, RDS picked a random window for you, which may land in your business hours.

aws rds modify-db-instance --db-instance-identifier prod-db \
  --preferred-maintenance-window "sun:03:00-sun:04:00"

For Aurora, set the window on the cluster with modify-db-cluster and on each instance with modify-db-instance.

• Every production database has a deliberate window, outside peak hours, that the application team knows about.
• Non-production windows are earlier in the week than production, so problems show up there first.

#3. Understand the impact of each action

Warning

Multi-AZ protects you from OS maintenance, not from engine upgrades. On a Multi-AZ DB instance deployment both copies are upgraded together, so a minor version upgrade is a real outage. Plan it like one.

Exact behaviour varies by engine and deployment type (Multi-AZ DB instance vs Multi-AZ DB cluster vs Aurora); check the engine's upgrade documentation before a production change.

• Each pending action is mapped to its expected impact in your change record.

#4. Check the minor version upgrade path

aws rds describe-db-engine-versions --engine postgres --engine-version 16.3 \
  --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade==\`false\`].EngineVersion" \
  --output text

Replace the engine and version with yours (mysql, aurora-postgresql, aurora-mysql, sqlserver-se and so on). Version names vary by engine; use what describe-db-instances reports.

• Decide whether AutoMinorVersionUpgrade stays on. On is fine for most workloads if your window is right; turn it off only if you have a process that actually performs the upgrades.
• Engine versions approaching end of standard support are tracked separately. Running past that date on RDS can enrol you in paid Extended Support for some engines; check the current RDS engine version calendar.

#5. Get the application ready

• The application reconnects after dropped connections, with retry and back-off. Most "maintenance broke prod" incidents are apps that never reconnect.
• It connects using the DNS endpoint, never an IP address, and DNS caching TTLs are short (JVM networkaddress.cache.ttl, for example).
• For Aurora, writes go to the cluster endpoint and reads to the reader endpoint.
• RDS Proxy in front of the database is worth considering if failover time is a problem; it holds client connections during a failover.
• For certificate rotation, clients that verify the server certificate trust the new CA bundle before you rotate. Download the current global bundle from the RDS documentation and deploy it first.

#6. Apply on your terms

Take a manual snapshot before anything engine-related:

aws rds create-db-snapshot --db-instance-identifier prod-db \
  --db-snapshot-identifier prod-db-pre-maint-2026-10-29

Then either apply now, during an agreed change slot:

aws rds apply-pending-maintenance-action \
  --resource-identifier arn:aws:rds:eu-west-1:111122223333:db:prod-db \
  --apply-action system-update \
  --opt-in-type immediate

or schedule it for the next maintenance window with --opt-in-type next-maintenance. --opt-in-type undo-opt-in cancels a next-maintenance opt-in that hasn't started. Use the cluster ARN (:cluster:) for actions listed against an Aurora cluster.

Minor engine upgrades can also be driven directly:

aws rds modify-db-instance --db-instance-identifier prod-db \
  --engine-version 16.4 --apply-immediately

Caution

--apply-immediately on modify-db-instance also applies every other queued modification in PendingModifiedValues (instance class change, storage change and so on). Check that field first so you don't trigger more than you planned.

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query "DBInstances[0].{pending:PendingModifiedValues,params:DBParameterGroups[].ParameterApplyStatus}"

For a CA rotation:

aws rds modify-db-instance --db-instance-identifier prod-db \
  --ca-certificate-identifier rds-ca-rsa2048-g1 --apply-immediately

List the CAs available in your Region with aws rds describe-certificates before choosing one.

#7. Verify afterwards

aws rds describe-events --source-type db-instance \
  --source-identifier prod-db --duration 240 \
  --query "Events[].{time:Date,msg:Message}" --output table

• The events show the maintenance or upgrade completed, and the instance is available.
• describe-pending-maintenance-actions no longer lists the action.
• Application error rates and connection counts are back to normal.

#Prevent it next time

Subscribe to RDS maintenance and availability events so nobody is surprised again:

aws rds create-event-subscription --subscription-name rds-maintenance \
  --sns-topic-arn arn:aws:sns:eu-west-1:111122223333:dba-alerts \
  --source-type db-instance \
  --event-categories maintenance availability failover notification

• Run step 1 weekly (or route AWS Health scheduled changes to EventBridge) and track open items like any other ticket.
• Patch non-production first, then production a week later, on a fixed cadence.
• Test application reconnect during a planned failover (aws rds reboot-db-instance --force-failover on a Multi-AZ instance) at least once a quarter.