RDS DB Maintenance

AWS RDS DB Maintenance & Upgrades

~ Last updated on : ~ jayendrapatil

RDS DB Maintenance and Upgrades

  • Changes to a DB instance can occur when a DB instance is manually modified for e.g. DB engine version is upgraded, or when RDS performs maintenance on an instance

RDS Maintenance

  • RDS performs periodic maintenance on RDS resources, such as DB instances, and most often involves updates to the DB instance’s operating system (OS).
  • Maintenance items can either
    • be applied manually on a DB instance at one’s convenience
    • or wait for the automatic maintenance process initiated by RDS during the defined weekly maintenance window.
  • Maintenance window only determines when pending operations start but does not limit the total execution time of these operations.
  • Maintenance operations are not guaranteed to finish before the maintenance window ends and can continue beyond the specified end time.
  • Maintenance update availability can be checked both on the RDS console and by using the RDS API. And if an update is available, one can
    • Defer the maintenance items.
    • Apply the maintenance items immediately.
    • Schedule them to start during the next defined maintenance window
  • Maintenance items marked as
    • Required cannot be deferred indefinitely, if deferred AWS will send a notify the time when the update will be performed next
    • Available and can be deferred indefinitely and the update will not be applied to the DB instance.
  • Required patching is automatically scheduled only for patches that are related to security and instance reliability. Such patching occurs infrequently (typically once every few months) and seldom requires more than a fraction of your maintenance window.
  • Maintenance items require that RDS take the DB instance offline for a short time. Maintenance that requires DB instances to be offline includes scale compute operations, which generally take only a few minutes from start to finish, and required operating system or database patching.
  • Multi-AZ deployment for the DB instance reduces the impact of a maintenance event by following these steps:
    • Perform maintenance on standby.
    • Promote the standby to primary.
    • Perform maintenance on the old primary, which becomes the new standby.
  • When the database engine for the DB instance is modified in a Multi-AZ deployment, RDS upgrades both the primary and secondary DB instances at the same time. In this case, the database engine for the entire Multi-AZ deployment is shut down during the upgrade.

Multi-AZ DB Cluster Maintenance (Two Readable Standbys)

  • RDS Multi-AZ DB clusters (with two readable standbys) provide significantly reduced downtime during maintenance compared to traditional Multi-AZ DB instances.
  • Minor version upgrades and system maintenance updates can be completed with typically 35 seconds or less of downtime using Multi-AZ DB clusters.
  • Downtime can be further reduced to typically 1 second or less when combined with:
    • Amazon RDS Proxy
    • AWS Advanced JDBC Wrapper Driver
    • PgBouncer (for PostgreSQL)
    • ProxySQL (for MySQL)
  • During maintenance on a Multi-AZ DB cluster:
    • Maintenance is applied to the reader instances first
    • One of the reader instances is promoted to writer
    • Maintenance is then applied to the former writer
    • The process results in an automatic failover with minimal downtime

Operating System Updates

  • Upgrades to the operating system are most often for security issues and should be done as soon as possible.
  • OS updates on a DB instance can be applied at one’s convenience or can wait for the maintenance process initiated by RDS to apply the update during the defined maintenance window
  • DB instance is not automatically backed up when an OS update is applied and should be backup up before the update is applied

Database Engine Version Upgrade

  • DB instance engine version can be upgraded when a new DB engine version is supported by RDS.
  • Database version upgrades consist of major and minor version upgrades.
    • Major database version upgrades
      • can contain changes that are not backward-compatible
      • RDS doesn’t apply major version upgrades automatically
      • DB instance should be manually modified and thoroughly tested before applying it to the production instances.
      • RDS Blue/Green Deployments can be used to perform major version upgrades with minimal downtime (typically under 5 seconds with direct endpoint connections, or under 2 seconds with AWS Advanced JDBC Driver).
    • Minor version upgrades
      • Each DB engine handles minor version upgrade slightly differently
        for e.g. RDS automatically apply minor version upgrades to a DB instance running PostgreSQL, but must be manually applied to a DB instance running Oracle.
      • Auto Minor Version Upgrade (AmVU) setting controls whether RDS automatically applies minor version upgrades during the maintenance window.
      • In cases of critical security issues or when a version reaches its end-of-support date, RDS might apply a minor version upgrade even if Auto Minor Version Upgrade is disabled.
  • Amazon posts an announcement to the forums announcement page and sends a customer e-mail notification before upgrading an DB instance
  • Amazon schedule the upgrades at specific times through the year, to help plan around them, because downtime is required to upgrade a DB engine version, even for Multi-AZ instances.
  • RDS takes two DB snapshots during the upgrade process.
    • First DB snapshot is of the DB instance before any upgrade changes have been made. If the upgrade fails, it can be restored from the snapshot to create a DB instance running the old version.
    • Second DB snapshot is taken when the upgrade completes. After the upgrade is complete, database engine can’t be reverted to the previous version. For returning to the previous version, restore the first DB snapshot taken to create a new DB instance.
  • If the DB instance is using read replication, all of the Read Replicas must be upgraded before upgrading the source instance.
  • If the DB instance is in a Multi-AZ deployment, both the primary and standby replicas are upgraded at the same time and would result in an outage. The time for the outage varies based on your database engine, version, and the size of your DB instance.

AWS Organizations Upgrade Rollout Policy

  • AWS Organizations now supports upgrade rollout policies to centrally manage and stagger automatic minor version upgrades across multiple database resources and AWS accounts.
  • Allows defining upgrade sequences using simple orders (first, second, last) applied through account-level policies or resource tags.
  • When new minor versions become eligible for automatic upgrade, the policy ensures upgrades start with development environments first, allowing validation before proceeding to production.
  • Key features:
    • AWS Health notifications between phases for monitoring progress
    • Built-in validation periods to ensure stability
    • Ability to disable automatic progression at any time if issues are detected
  • Eliminates operational overhead of coordinating upgrades manually or through custom tools across hundreds of resources and accounts.
  • Available in all AWS commercial Regions and AWS GovCloud (US) Regions.
  • Manageable via AWS Management Console, CLI, SDKs, CloudFormation, or CDK.

RDS Maintenance Window

  • Every DB instance has a weekly maintenance window defined during which any system changes are applied.
  • Maintenance window is an opportunity to control when DB instance modifications and software patching occur, in the event either are requested or required.
  • If a maintenance event is scheduled for a given week, it will be initiated during the 30-minute maintenance window as defined
  • Maintenance events mostly complete during the 30-minute maintenance window, although larger maintenance events may take more time
  • 30-minute maintenance window is selected at random from an 8-hour block of time per region. If you don’t specify a preferred maintenance window when you create the DB instance, Amazon RDS assigns a 30-minute maintenance window on a randomly selected day of the week.
  • RDS will consume some of the resources on the DB instance while maintenance is being applied, minimally affecting performance.
  • For some maintenance events, a Multi-AZ failover may be required for a maintenance update to be complete.

RDS Blue/Green Deployments for Upgrades and Maintenance

  • RDS Blue/Green Deployments provide a safer and faster method for performing database upgrades and maintenance with minimal downtime.
  • A Blue/Green Deployment creates a staging environment (Green) that mirrors the production environment (Blue) and keeps them synchronized.
  • Supported use cases include:
    • Major version database engine upgrades
    • Minor version upgrades
    • Maintenance updates and OS patching
    • Instance scaling (compute changes)
    • Storage volume shrink (since November 2024) – the only native way to reduce RDS allocated storage
    • Parameter group changes
  • Switchover downtime is typically under 5 seconds for single-Region configurations (as of January 2026).
  • Applications using the AWS Advanced JDBC Driver typically see under 2 seconds of downtime due to eliminated DNS propagation delays.
  • No application endpoint changes are required after switchover.
  • Supported for Amazon Aurora and Amazon RDS engines including PostgreSQL, MySQL, and MariaDB in all AWS regions.
  • For PostgreSQL:
    • Uses physical replication by default for minor version upgrades (faster, lower lag)
    • Uses logical replication when performing major version upgrades
  • Blue/Green Deployments also support Aurora Global Databases (as of November 2025), including primary and all secondary regions.

RDS Extended Support

  • Amazon RDS Extended Support provides up to three additional years of critical security and bug fixes beyond a major version’s end of standard support date.
  • Available for Amazon Aurora MySQL, Aurora PostgreSQL, RDS for MySQL, and RDS for PostgreSQL.
  • Gives flexibility to upgrade, migrate, and transform databases at your own pace while still receiving security fixes from AWS.
  • Key characteristics:
    • Charged as a per vCPU-hour fee in addition to regular RDS instance charges.
    • Pricing increases over time: Year 1 and Year 2 are at the same rate, Year 3 pricing is doubled (approximately).
    • Charges apply to all instances including replicas and standbys in Multi-AZ configurations.
    • Reserved Instance discounts do NOT apply to Extended Support charges.
    • No charge for DB snapshots, but restoring a snapshot to an EOL version will trigger Extended Support enrollment and charges.
  • Automatic enrollment: After a major engine version reaches end of standard support, instances running that version are automatically enrolled in Extended Support and charges begin.
  • Opting out: You can prevent enrollment by specifying open-source-rds-extended-support-disabled for the --engine-lifecycle-support CLI option when creating or restoring instances.
  • Ending enrollment: Upgrade to a newer engine version still under standard support to stop Extended Support charges.
  • Extended Support charges appear as a separate line item on your bill (Usage Type: ‘ExtendedSupport’).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has launched an RDS MySQL DB with the Multi AZ feature. The user has scheduled the scaling of instance storage during maintenance window. What is the correct order of events during maintenance window? 1. Perform maintenance on standby 2. Promote standby to primary 3. Perform maintenance on original primary 4. Promote original master back as primary
    1. 1, 2, 3, 4
    2. 1, 2, 3
    3. 2, 3, 4, 1
  2. Can I control if and when MySQL based RDS Instance is upgraded to new supported versions?
    1. No
    2. Only in VPC
    3. Yes
  3. A user has scheduled the maintenance window of an RDS DB on Monday at 3 AM. Which of the below mentioned events may force to take the DB instance offline during the maintenance window?
    1. Enabling Read Replica
    2. Making the DB Multi AZ
    3. DB password change
    4. Security patching
  4. A user has launched an RDS postgreSQL DB with AWS. The user did not specify the maintenance window during creation. The user has configured RDS to update the DB instance type from micro to large. If the user wants to have it during the maintenance window, what will AWS do?
    1. AWS will not allow to update the DB until the maintenance window is configured
    2. AWS will select the default maintenance window if the user has not provided it
    3. AWS will ask the user to specify the maintenance window during the update
    4. It is not possible to change the DB size from micro to large with RDS
  5. Can I test my DB Instance against a new version before upgrading?
    1. No
    2. Yes
    3. Only in VPC
  6. A company wants to perform a major version upgrade on their production RDS PostgreSQL database with minimal downtime. Which approach provides the least downtime?
    1. Perform an in-place major version upgrade during the maintenance window
    2. Use RDS Blue/Green Deployments to create a staging environment with the new version and switchover
    3. Create a read replica, promote it, and point the application to it
    4. Take a snapshot, restore it with the new engine version, and switch DNS
  7. An organization is managing hundreds of RDS instances across multiple AWS accounts. They want automatic minor version upgrades to roll out to development environments first before production. Which feature should they use?
    1. AWS Systems Manager Maintenance Windows
    2. RDS Blue/Green Deployments
    3. AWS Organizations Upgrade Rollout Policy
    4. AWS Config remediation rules
  8. A company is running RDS for PostgreSQL 11 which has reached end of standard support. They are not ready to upgrade to a newer version. What happens if they take no action?
    1. The database will be terminated after 90 days
    2. The database will be automatically upgraded to the latest version
    3. The database will be enrolled in RDS Extended Support with additional per-vCPU-hour charges
    4. The database will continue running with no changes or charges
  9. A company uses RDS Multi-AZ DB clusters with two readable standbys and wants to minimize downtime during minor version upgrades. What is the expected downtime?
    1. 5-10 minutes
    2. 1-2 minutes
    3. Typically 35 seconds or less, reducible to under 1 second with RDS Proxy
    4. Zero downtime
  10. Which of the following can be achieved using RDS Blue/Green Deployments? (Select THREE)
    1. Major version engine upgrades
    2. Storage volume shrink
    3. Cross-region replication setup
    4. Instance class scaling
    5. Enabling Multi-AZ on an existing single-AZ instance

References