RDS maintenance windows are a critical, yet often misunderstood, part of managing your database instances.
Let’s dive into how they actually work and how to use them without causing unexpected downtime.
{
"DBInstanceIdentifier": "my-prod-db-instance",
"AutoMinorVersionUpgrade": true,
"PreferredMaintenanceWindow": "sun:03:00-sun:04:00"
}
This JSON snippet represents a typical RDS instance configuration. DBInstanceIdentifier is obvious. AutoMinorVersionUpgrade tells RDS to automatically apply minor version upgrades during the maintenance window. The PreferredMaintenanceWindow is the crucial part here: "sun:03:00-sun:04:00" means it’s scheduled for Sunday between 3 AM and 4 AM UTC.
The most surprising thing about RDS maintenance is that the window isn’t a guarantee of when an update will happen, but rather the only time it can happen. RDS will attempt to apply updates within this window, but if it’s too busy, or if the update itself takes longer than the window, it might be deferred to the next available window. This deferral is a safety mechanism to prevent updates from breaking your application during peak hours, but it can lead to confusion if you’re not aware of it.
Consider a scenario where you have a read replica. If a minor version upgrade is scheduled for your primary instance, RDS will first attempt to upgrade the read replica before upgrading the primary. This is done to minimize downtime. The replica is promoted to be the new primary, the old primary is upgraded, and then it’s re-attached as a replica. However, this process can take time, and if the upgrade within the primary instance exceeds the maintenance window, the entire operation might be pushed to the next window.
The actual process involves RDS taking a snapshot of your DB instance before initiating the upgrade. This snapshot is a safety net. If something goes wrong during the upgrade, RDS can roll back to the snapshot. The instance is then restarted with the new version. For Multi-AZ deployments, RDS upgrades one Availability Zone at a time. It fails over to the upgraded standby, upgrades the old primary, and then re-establishes replication. This is why Multi-AZ is highly recommended for production workloads.
Here’s how you might manually trigger a maintenance action if you don’t want to wait for the scheduled window, though this is generally not recommended for production:
aws rds apply-pending-maintenance-action \
--resource-name arn:aws:rds:us-east-1:123456789012:db:my-prod-db-instance \
--apply-action system-update \
--opt-in-type immediate
This command, using the AWS CLI, tells RDS to apply any pending maintenance actions (like a minor version upgrade) immediately. The resource-name is the ARN of your DB instance. apply-action system-update specifies the type of action, and opt-in-type immediate forces the action to occur outside the preferred maintenance window. Again, use this with extreme caution and only in non-production environments or during a planned outage.
The PreferredMaintenanceWindow format is ddd:hh:mm-ddd:hh:mm where ddd is a three-letter abbreviation for the day of the week (Mon, Tue, Wed, Thu, Fri, Sat, Sun) and hh:mm is the time in 24-hour format. The times are in Coordinated Universal Time (UTC). For example, tue:08:00-tue:09:00 means Tuesday, between 8 AM and 9 AM UTC. It’s crucial to pick a window that aligns with your application’s lowest traffic periods. Many teams opt for weekend early mornings or late nights.
A key aspect often overlooked is how parameter group and option group modifications interact with maintenance. Changes to parameter groups that require a reboot (indicated by RequiresReboot: true in the DescribeDBInstanceAutomatedBackups output or DescribeDBInstances output) will also be applied during the maintenance window if not applied manually. This can lead to unexpected reboots if you’ve recently modified a parameter group and haven’t applied the changes.
The most common mistake is assuming the maintenance window is a hard deadline for all updates. RDS will attempt to apply updates within that window. If the update is complex, or if the instance is under heavy load, the update might be deferred. You can check the Maintenance and Backups section of your DB instance details in the AWS console to see if there are any pending maintenance actions and when they are scheduled. If you see a "pending" status and no action within your window, it’s likely been deferred.
The next thing you’ll likely encounter is understanding how major version upgrades are handled, which are never automatic and always require explicit user action.