Configure Amazon RDS Multi-AZ for High Availability

Overview

Configure your Amazon RDS DB instances and clusters for Multi‑AZ or other supported high‑availability options to improve resilience and reduce downtime. This plan inventories your current RDS footprint, guides you through selecting which databases to update, captures your availability and scheduling preferences, applies the necessary configuration changes to instances and clusters, and then validates that everything is operating as expected in multiple Availability Zones.

Execution Details

Phase 1: Assessment

In the assessment phase, the plan builds a complete picture of your current RDS environment and prepares inputs for later decisions.

Inventory RDS DB instances

The plan:

• Collects a full list of RDS DB instances in scope.
• Records key attributes such as identifier, engine and engine version, instance class, Region and Availability Zone, subnet group and subnets, current status, and whether Multi‑AZ is enabled.
• Distinguishes the deployment type where possible (e.g., Single‑AZ vs Multi‑AZ DB instance).
• Summarizes how many instances are Single‑AZ versus Multi‑AZ.
• Stores this inventory in a structured format for later use.

Inventory RDS DB clusters and HA configuration

The plan:

• Collects a full list of RDS DB clusters, including Aurora and Multi‑AZ DB clusters.
• Records key details such as cluster identifier, engine and version, status, endpoints (writer/reader), subnet group and subnets, and number of AZs in use.
• Identifies whether each cluster is configured as a Multi‑AZ DB cluster or uses other engine‑specific high‑availability options.
• Lists all member DB instances with their roles (writer/reader) and Availability Zones.
• Summarizes which clusters are already highly available and which are not.
• Stores this inventory for later reference.

User selection of RDS resources for Multi‑AZ

Using the collected inventories, the plan:

• Presents you with the DB instance inventory, including current Multi‑AZ status and key attributes.
• Presents you with the DB cluster inventory, including high‑availability status, AZ distribution, and member instances.
• Highlights which resources are already highly available versus Single‑AZ.
• Guides you in selecting which standalone DB instances should be converted to Multi‑AZ.
• Guides you in selecting which DB clusters should be configured or adjusted for Multi‑AZ/high availability, based on engine support.
• Captures the final, user‑approved lists of DB instance and DB cluster identifiers to modify.
• Captures any resources that must not be changed and records your confirmation of the in‑scope resources.

User Multi‑AZ deployment preferences

For the resources you selected, the plan:

• Presents the list of targeted DB instances and clusters.
• Guides you through specifying AZ preferences for secondary or additional AZs where supported.
• Captures whether to use existing DB subnet groups or specific Multi‑AZ‑capable subnet groups.
• Records your preferences for the number of AZs when multiple options exist (for example, at least two AZs).
• Captures whether changes should be applied immediately or only during preferred maintenance windows.
• Records acceptable downtime or performance impact constraints during conversion.
• Captures any special handling instructions (for example, avoiding certain AZs).
• Stores these preferences in a structured format for use in the configuration phase.

Phase 2: Configuration

In the configuration phase, the plan applies Multi‑AZ or high‑availability settings to the resources you approved, honoring your preferences where possible.

Configure Multi‑AZ for selected DB instances

For each selected standalone DB instance, the plan:

• Uses the final approved instance list from the assessment phase.
• Confirms that the engine and instance class support Multi‑AZ.
• Ensures that an appropriate DB subnet group spans at least two Availability Zones.
• Applies your preferences for AZ selection and subnet group usage.
• Updates the instance configuration to enable Multi‑AZ.
• Applies changes immediately or schedules them during the maintenance window based on your choices.
• Monitors instance status during the modification.
• Verifies that the instance is reported as Multi‑AZ enabled after completion.
• Records any instances that could not be converted and the reasons, and produces a summary of all instances successfully configured for Multi‑AZ.

Configure Multi‑AZ or high availability for selected DB clusters

For each selected DB cluster, the plan:

• Uses the final approved cluster list from the assessment phase.
• Confirms that the engine and cluster type support Multi‑AZ or another high‑availability mode.
• Verifies that the DB subnet group spans at least two Availability Zones as required.
• Applies your preferences for AZ distribution, subnet group usage, and number of AZs where supported.
• For clusters not yet highly available, updates settings to enable the appropriate Multi‑AZ or HA configuration (for example, Multi‑AZ DB cluster options or adding replicas in other AZs when applicable).
• For clusters already using high availability, makes adjustments only where you explicitly requested them (such as changing AZs or the number of instances).
• Applies configuration changes immediately or during maintenance windows according to your preferences.
• Monitors cluster and member instance status during the modifications.
• Verifies that the cluster reports Multi‑AZ/high‑availability enabled and that instances are distributed across AZs as intended.
• Documents any clusters that could not be configured as desired and provides a summary of all clusters successfully configured.

Phase 3: Validation

In the validation phase, the plan confirms that Multi‑AZ and high‑availability configurations are correctly applied and healthy.

Validate Multi‑AZ configuration for DB instances

For each DB instance targeted in the configuration phase, the plan:

• Retrieves the latest configuration details.
• Confirms that the Multi‑AZ flag is enabled.
• Ensures the instance status is healthy and available or otherwise in an expected non‑error state.
• Verifies association with a subnet group that spans at least two Availability Zones.
• Checks for the absence of recent errors or failed modifications related to Multi‑AZ changes.
• Documents any instances where Multi‑AZ is not configured as intended, with reasons and recommended follow‑up.
• Finalizes a validation summary listing all instances with successful Multi‑AZ configuration.

Validate Multi‑AZ or high‑availability configuration for DB clusters

For each DB cluster targeted in the configuration phase, the plan:

• Retrieves the latest cluster configuration details.
• Confirms that the appropriate Multi‑AZ or high‑availability mode is enabled for the engine.
• Verifies that the subnet group spans at least two Availability Zones.
• Confirms that member instances are distributed across multiple AZs as intended.
• Ensures cluster and instance statuses are healthy and available or otherwise in expected non‑error states.
• Checks that there are no recent errors or failed modifications related to HA configuration.
• Documents any clusters where the desired Multi‑AZ or high‑availability configuration is not in place, with reasons and follow‑up actions.
• Produces a final validation summary listing all clusters successfully configured for Multi‑AZ or high availability.