Skip to content

AWS Updated 2026-07-04

RDS maintenance windows: what actually restarts and how to schedule around it

Not everything in an RDS maintenance window restarts the database. Here is which maintenance actions cause downtime, how Multi-AZ changes the math, and how to schedule and defer maintenance deliberately.

The RDS maintenance window is a weekly 30-minute-plus slot when AWS is allowed to apply pending maintenance — most weeks nothing happens in it at all. When something does, the impact ranges from none (many networking and host-side changes) to a full restart (engine minor version upgrades, some OS patches). On Multi-AZ, restart-class maintenance is applied to the standby first, followed by a failover, which shrinks minutes of downtime to roughly a failover’s worth. The operational skill is knowing what is pending, what it will do, and choosing when it lands instead of being surprised.

What’s happening

Three separate mechanisms get conflated under “maintenance”, and untangling them is most of the clarity:

The maintenance window (PreferredMaintenanceWindow) is a weekly schedule slot, minimum 30 minutes. If you never set one, AWS assigned a random slot per region — which is how databases end up patching Tuesday 9:00 a.m. local time. The window is when pending actions may run; an empty pending queue means an uneventful window.

Pending maintenance actions are the queue: OS patches, underlying hardware/host updates, certificate rotations, and mandatory engine patches. Each action carries a type and urgency — some are available (apply whenever you like), some have an AutoAppliedAfterDate (applies in a window after that date), and rare security-critical ones are forced with a deadline. You can apply any of them early, on your schedule, instead of waiting to be scheduled.

Auto minor version upgrade (AutoMinorVersionUpgrade) is a per-instance flag: when true, RDS upgrades the engine to the current preferred minor version during a window once it deems the version eligible. Minor version upgrades restart the engine. This flag, left at its default of enabled, is the number-one source of “the database restarted and nobody knew why”.

What restarts and what does not: engine minor upgrades — restart, always. OS/host maintenance — sometimes a restart or host replacement, stated per action. CA certificate rotation — requires a reboot to pick up the new cert on the instance. Parameter group static-parameter changes wait for your reboot, not the window. And scaling storage does not restart the instance at all.

Multi-AZ changes the arithmetic: for restart-class maintenance, RDS patches the standby, fails over, then patches the old primary — so the customer-visible interruption is a failover (commonly under a minute or two) rather than a full single-instance patch cycle. Single-AZ instances take the whole restart as downtime.

What to check first

  • The pending queue — is anything actually scheduled, and is it available, auto-applied-after, or forced?
  • Your window — RDS > Databases > your-instance > Maintenance & backups shows the current slot; verify it is genuinely off-peak in your timezone, not UTC-random.
  • AutoMinorVersionUpgrade — decide deliberately whether AWS may restart your engine on its schedule.
  • Multi-AZ status — it determines whether restart-class maintenance costs you a failover or full downtime.

How to verify

# What maintenance is pending, and how urgent
aws rds describe-pending-maintenance-actions \
  --query 'PendingMaintenanceActions[].[ResourceIdentifier,
           PendingMaintenanceActionDetails[].[Action,AutoAppliedAfterDate,CurrentApplyDate,Description]]'

# Current window and the auto-upgrade flag
aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[PreferredMaintenanceWindow,AutoMinorVersionUpgrade,MultiAZ,EngineVersion]'

After any window in which something ran, the record is in the event log:

aws rds describe-events --source-identifier prod-db --source-type db-instance \
  --duration 10080 --query 'Events[].[Date,Message]' --output table

The runbook

  1. Set the window on purpose. aws rds modify-db-instance --db-instance-identifier prod-db --preferred-maintenance-window sun:07:00-sun:08:00 (times are UTC — convert; Sunday 07:00 UTC is Sunday 03:00 in Montréal in summer). Keep it clear of the backup window; the two cannot overlap.
  2. Decide the auto-minor-upgrade policy per tier. Reasonable production stance: enabled for staging so upgrades soak there first, disabled in production, with minors applied manually a week later. If you disable it, you own tracking versions — unpatched minors are how databases run engine versions with known CVEs.
  3. Apply maintenance early when a queue item appears, on a night you choose: aws rds apply-pending-maintenance-action --resource-identifier arn:aws:rds:ca-central-1:123456789012:db:prod-db --apply-action system-update --opt-in-type immediate. immediate runs now; next-maintenance pins it to the coming window; undo-opt-in cancels a next-window opt-in.
  4. Read each action’s description before it lands. The details say whether a restart or failover is expected. For restart-class actions on Multi-AZ, expect a failover: brief write interruption, DNS repoint, in-flight transactions rolled back — the client-side hygiene from unexpected failover applies verbatim.
  5. Subscribe to maintenance events. An RDS event subscription on the maintenance category, plus AWS Health notifications at health.aws.amazon.com, means scheduled maintenance is an email two weeks ahead, not a surprise mid-incident.
  6. After the window, verify. Check the event log, engine version, and application error rates for the window period. A maintenance action that half-applied or a version bump that broke a driver assumption should be caught Monday morning by you, not Thursday by a customer.

When this is the wrong move

Deferring maintenance indefinitely is not a strategy — forced actions will apply at the deadline whether or not it suits you, and deferred OS patches accumulate risk quietly. If your workload genuinely cannot tolerate any regular interruption window, the answer is not fighting the window; it is architecture that absorbs failovers (Multi-AZ, read traffic on replicas, retry logic) — a single-AZ instance with a “never restart” requirement is a contradiction, and no setting resolves it. Full engine-by-engine maintenance behaviour is in the Amazon RDS documentation.

Common mistakes

  • Never setting the window and discovering it is mid-business-hours only when a restart lands there.
  • Treating the window as “AWS restarts my DB weekly” — most windows are no-ops; the pending queue is what matters.
  • Leaving AutoMinorVersionUpgrade on in production unaudited, then attributing the resulting restart to an outage.
  • Rebooting for a static parameter change during business hours because “maintenance already restarts things anyway” — static parameters wait for your reboot; schedule it like maintenance.

Keeping it under control

  • Review describe-pending-maintenance-actions across the fleet weekly — one CLI call, thirty seconds.
  • Standardize windows fleet-wide in a documented off-peak slot, staging windows a week ahead of production.
  • Event subscriptions on maintenance and failover categories to the ops channel.
  • Track engine minor versions in your inventory if auto-upgrade is off; stale minors are a silent liability.
  • Rehearse restart-class maintenance in staging first — same action, same engine version, measured app impact.

Maintenance windows are one of the few parts of RDS where you get to choose when the disruption happens — teams that exercise that choice stop having maintenance incidents at all. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.