# Multi-AZ DB cluster deployments for Amazon RDS A *Multi-AZ DB cluster deployment* is a semisynchronous, high availability deployment mode of Amazon RDS with two readable replica DB instances. A Multi-AZ DB cluster has a writer DB instance and two reader DB instances in three separate Availability Zones in the same AWS Region. Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower write latency when compared to Multi-AZ DB instance deployments. You can import data from an on-premises database to a Multi-AZ DB cluster by following the instructions in [Importing data to an Amazon RDS for MySQL database with reduced downtime](mysql-importing-data-reduced-downtime.md). You can purchase reserved DB instances for a Multi-AZ DB cluster. For more information, see [Reserved DB instances for a Multi-AZ DB cluster](USER_WorkingWithReservedDBInstances.md#USER_WorkingWithReservedDBInstances.MultiAZDBClusters). Feature availability and support varies across specific versions of each database engine, and across AWS Regions. For more information on version and Region availability of Amazon RDS with Multi-AZ DB clusters, see [Supported Regions and DB engines for Multi-AZ DB clusters in Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.MultiAZDBClusters.md). **Topics** + [ ## Instance class availability for Multi-AZ DB clusters ](#multi-az-db-clusters-concepts.InstanceAvailability) + [ ## Multi-AZ DB cluster architecture ](#multi-az-db-clusters-concepts-overview) + [ ## Parameter groups for Multi-AZ DB clusters ](#multi-az-db-clusters-concepts-parameter-groups) + [ ## RDS Proxy with Multi-AZ DB clusters ](#multi-az-db-clusters-proxy) + [ ## Replica lag and Multi-AZ DB clusters ](#multi-az-db-clusters-concepts-replica-lag) + [ ## Multi-AZ DB cluster snapshots ](#multi-az-db-clusters-concepts-snapshot) + [ # Creating a Multi-AZ DB cluster for Amazon RDS ](create-multi-az-db-cluster.md) + [ # Connecting to a Multi-AZ DB cluster for Amazon RDS ](multi-az-db-clusters-concepts-connection-management.md) + [ # Automatically connecting an AWS compute resource and a Multi-AZ DB cluster for Amazon RDS ](multi-az-compute-rds-connect.md) + [ # Modifying a Multi-AZ DB cluster for Amazon RDS ](modify-multi-az-db-cluster.md) + [ # Upgrading the engine version of a Multi-AZ DB cluster for Amazon RDS ](multi-az-db-clusters-upgrading.md) + [ # Renaming a Multi-AZ DB cluster for Amazon RDS ](multi-az-db-cluster-rename.md) + [ # Rebooting a Multi-AZ DB cluster and reader DB instances for Amazon RDS ](multi-az-db-clusters-concepts-rebooting.md) + [ # Failing over a Multi-AZ DB cluster for Amazon RDS ](multi-az-db-clusters-concepts-failover.md) + [ # Setting up PostgreSQL logical replication with Multi-AZ DB clusters for Amazon RDS ](USER_MultiAZDBCluster_LogicalRepl.md) + [ # Working with Multi-AZ DB cluster read replicas for Amazon RDS ](USER_MultiAZDBCluster_ReadRepl.md) + [ # Setting up external replication from Multi-AZ DB clusters for Amazon RDS ](multi-az-db-clusters-external-replication.md) + [ # Deleting a Multi-AZ DB cluster for Amazon RDS ](USER_DeleteMultiAZDBCluster.Deleting.md) + [ # Limitations of Multi-AZ DB clusters for Amazon RDS ](multi-az-db-clusters-concepts.Limitations.md) **Important** Multi-AZ DB clusters aren't the same as Aurora DB clusters. For information about Aurora DB clusters, see the [Amazon Aurora User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html). ## Instance class availability for Multi-AZ DB clusters Multi-AZ DB cluster deployments are supported for the following DB instance classes: `db.m5d`, `db.m6gd`, `db.m6id`, `db.m6idn`, `db.r5d`, `db.r6gd`, `db.x2iedn`, `db.r6id`, and `db.r6idn`, and `db.c6gd`. **Note** The c6gd instance classes are the only ones that support the `medium` instance size. For more information about DB instance classes, see [DB instance classes](Concepts.DBInstanceClass.md). ## Multi-AZ DB cluster architecture With a Multi-AZ DB cluster, Amazon RDS replicates data from the writer DB instance to both of the reader DB instances using the DB engine's native replication capabilities. When a change is made on the writer DB instance, it's sent to each reader DB instance. Multi-AZ DB cluster deployments use semisynchronous replication, which requires acknowledgment from at least one reader DB instance in order for a change to be committed. It doesn't require acknowledgment that events have been fully executed and committed on *all* replicas. Reader DB instances act as automatic failover targets and also serve read traffic to increase application read throughput. If an outage occurs on your writer DB instance, RDS manages failover to one of the reader DB instances. RDS does this based on which reader DB instance has the most recent change record. The following diagram shows a Multi-AZ DB cluster. ![\[Multi-AZ DB cluster\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/multi-az-db-cluster.png) Multi-AZ DB clusters typically have lower write latency when compared to Multi-AZ DB instance deployments. They also allow read-only workloads to run on reader DB instances. The RDS console shows the Availability Zone of the writer DB instance and the Availability Zones of the reader DB instances. You can also use the [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) CLI command or the [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) API operation to find this information. **Important** To prevent replication errors in RDS for MySQL Multi-AZ DB clusters, we strongly recommend that all tables have a primary key. ## Parameter groups for Multi-AZ DB clusters In a Multi-AZ DB cluster, a *DB cluster parameter group* acts as a container for engine configuration values that are applied to every DB instance in the Multi-AZ DB cluster. In a Multi-AZ DB cluster, a *DB parameter group* is set to the default DB parameter group for the DB engine and DB engine version. The settings in the DB cluster parameter group are used for all of the DB instances in the cluster. For information about parameter groups, see [Working with DB cluster parameter groups for Multi-AZ DB clusters](USER_WorkingWithDBClusterParamGroups.md). ## RDS Proxy with Multi-AZ DB clusters You can use Amazon RDS Proxy to create a proxy for your Multi-AZ DB clusters. By using RDS Proxy, your applications can pool and share database connections to improve their ability to scale. Each proxy performs connection *multiplexing*, also known as connection reuse. With multiplexing, RDS Proxy performs all the operations for a transaction using one underlying database connection. RDS Proxy can also reduce the downtime for a minor version upgrade of a Multi-AZ DB cluster to one second or less. For more information about the benefits of RDS Proxy, see [Amazon RDS Proxy](rds-proxy.md). To set up a proxy for a Multi-AZ DB cluster, choose **Create an RDS Proxy** when creating the cluster. For instructions to create and manage RDS Proxy endpoints, see [Working with Amazon RDS Proxy endpoints](rds-proxy-endpoints.md). ## Replica lag and Multi-AZ DB clusters *Replica lag* is the difference in time between the latest transaction on the writer DB instance and the latest applied transaction on a reader DB instance. The Amazon CloudWatch metric `ReplicaLag` represents this time difference. For more information about CloudWatch metrics, see [Monitoring Amazon RDS metrics with Amazon CloudWatch](monitoring-cloudwatch.md). Although Multi-AZ DB clusters allow for high write performance, replica lag can still occur due to the nature of engine-based replication. Because any failover must first resolve the replica lag before it promotes a new writer DB instance, monitoring and managing this replica lag is a consideration. For RDS for MySQL Multi-AZ DB clusters, failover time depends on replica lag of both remaining reader DB instances. Both the reader DB instances must apply unapplied transactions before one of them is promoted to the new writer DB instance. For RDS for PostgreSQL Multi-AZ DB clusters, failover time depends on the lowest replica lag of the two remaining reader DB instances. The reader DB instance with the lowest replica lag must apply unapplied transactions before it is promoted to the new writer DB instance. For a tutorial that shows you how to create a CloudWatch alarm when replica lag exceeds a set amount of time, see [Tutorial: Creating an Amazon CloudWatch alarm for Multi-AZ DB cluster replica lag for Amazon RDS](multi-az-db-cluster-cloudwatch-alarm.md). ### Common causes of replica lag In general, replica lag occurs when the write workload is too high for the reader DB instances to apply the transactions efficiently. Various workloads can incur temporary or continuous replica lag. Some examples of common causes are the following: + High write concurrency or heavy batch updating on the writer DB instance, causing the apply process on the reader DB instances to fall behind. + Heavy read workload that is using resources on one or more reader DB instances. Running slow or large queries can affect the apply process and can cause replica lag. + Transactions that modify large amounts of data or DDL statements can sometimes cause a temporary increase in replica lag because the database must preserve commit order. ### Mitigating replica lag For Multi-AZ DB clusters for RDS for MySQL and RDS for PostgreSQL, you can mitigate replica lag by reducing the load on your writer DB instance. You can also use flow control to reduce replica lag. *Flow control* works by throttling writes on the writer DB instance, which ensures that replica lag doesn't continue to grow unbounded. Write throttling is accomplished by adding a delay into the end of a transaction, which decreases the write throughput on the writer DB instance. Although flow control doesn't guarantee lag elimination, it can help reduce overall lag in many workloads. The following sections provide information about using flow control with RDS for MySQL and RDS for PostgreSQL. #### Mitigating replica lag with flow control for RDS for MySQL When you are using RDS for MySQL Multi-AZ DB clusters, flow control is turned on by default using the dynamic parameter `rpl_semi_sync_master_target_apply_lag`. This parameter specifies the upper limit that you want for replica lag. As replica lag approaches this configured limit, flow control throttles the write transactions on the writer DB instance to try to contain the replica lag below the specified value. In some cases, replica lag can exceed the specified limit. By default, this parameter is set to 120 seconds. To turn off flow control, set this parameter to its maximum value of 86,400 seconds (one day). To view the current delay injected by flow control, show the parameter `Rpl_semi_sync_master_flow_control_current_delay` by running the following query. ``` SHOW GLOBAL STATUS like '%flow_control%'; ``` Your output should look similar to the following. ``` +-------------------------------------------------+-------+ | Variable_name | Value | +-------------------------------------------------+-------+ | Rpl_semi_sync_master_flow_control_current_delay | 2010 | +-------------------------------------------------+-------+ 1 row in set (0.00 sec) ``` **Note** The delay is shown in microseconds. When you have Performance Insights turned on for an RDS for MySQL Multi-AZ DB cluster, you can monitor the wait event corresponding to a SQL statement indicating that the queries were delayed by a flow control. When a delay was introduced by a flow control, you can view the wait event `/wait/synch/cond/semisync/semi_sync_flow_control_delay_cond` corresponding to the SQL statement on the Performance Insights dashboard. To view these metrics, make sure that the Performance Schema is turned on. For information about Performance Insights, see [Monitoring DB load with Performance Insights on Amazon RDS](USER_PerfInsights.md). #### Mitigating replica lag with flow control for RDS for PostgreSQL When you are using RDS for PostgreSQL Multi-AZ DB clusters, flow control is deployed as an extension. It turns on a background worker for all DB instances in the DB cluster. By default, the background workers on the reader DB instances communicate the current replica lag with the background worker on the writer DB instance. If the lag exceeds two minutes on any reader DB instance, the background worker on the writer DB instance adds a delay at the end of a transaction. To control the lag threshold, use the parameter `flow_control.target_standby_apply_lag`. When a flow control throttles a PostgreSQL process, the `Extension` wait event in `pg_stat_activity` and Performance Insights indicates that. The function `get_flow_control_stats` displays details about how much delay is currently being added. Flow control can benefit most online transaction processing (OLTP) workloads that have short but highly concurrent transactions. If the lag is caused by long-running transactions, such as batch operations, flow control doesn't provide as strong a benefit. You can turn off flow control by removing the extension from the `shared_preload_libraries` and rebooting your DB instance. ## Multi-AZ DB cluster snapshots Amazon RDS creates and saves automated backups of your Multi-AZ DB cluster during the configured backup window. RDS creates a storage volume snapshot of your DB cluster, backing up the entire cluster and not just individual instances. You can also take manual backups of your Multi-AZ DB cluster. For very long-term backups, consider exporting the snapshot data to Amazon S3. For more information, see [Creating a Multi-AZ DB cluster snapshot for Amazon RDS](USER_CreateMultiAZDBClusterSnapshot.md). You can restore a Multi-AZ DB cluster to a specific point in time, creating a new Multi-AZ DB cluster. For instructions, see [Restoring a Multi-AZ DB cluster to a specified time](USER_PIT.MultiAZDBCluster.md). Alternately, you can restore a Multi-AZ DB cluster snapshot to a Single-AZ deployment or Multi-AZ DB instance deployment. For instructions, see [Restoring from a Multi-AZ DB cluster snapshot to a DB instance](USER_RestoreFromMultiAZDBClusterSnapshot.md). # Creating a Multi-AZ DB cluster for Amazon RDS A Multi-AZ DB cluster has a writer DB instance and two reader DB instances in three separate Availability Zones. Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower latency when compared to Multi-AZ deployments. For more information about Multi-AZ DB clusters, see [Multi-AZ DB cluster deployments for Amazon RDS](multi-az-db-clusters-concepts.md). **Note** Multi-AZ DB clusters are supported only for the MySQL and PostgreSQL DB engines. ## DB cluster prerequisites **Important** Before you can create a Multi-AZ DB cluster, you must complete the tasks in [Setting up your Amazon RDS environment](CHAP_SettingUp.md). The following are prerequisites to complete before creating a Multi-AZ DB cluster. **Topics** + [ ### Configure the network for the DB cluster ](#create-multi-az-db-cluster-prerequisites-VPC) + [ ### Additional prerequisites ](#create-multi-az-db-cluster-prerequisites-additional) ### Configure the network for the DB cluster You can create a Multi-AZ DB cluster only in a virtual private cloud (VPC) based on the Amazon VPC service. It must be in an AWS Region that has at least three Availability Zones. The DB subnet group that you choose for the DB cluster must cover at least three Availability Zones. This configuration ensures that each DB instance in the DB cluster is in a different Availability Zone. To set up connectivity between your new DB cluster and an Amazon EC2 instance in the same VPC, do so when you create the DB cluster. To connect to your DB cluster from resources other than EC2 instances in the same VPC, configure the network connections manually. **Topics** + [ #### Configure automatic network connectivity with an EC2 instance ](#create-multi-az-db-cluster-prerequisites-VPC-automatic) + [ #### Configure the network manually ](#create-multi-az-db-cluster-prerequisites-VPC-manual) #### Configure automatic network connectivity with an EC2 instance When you create a Multi-AZ DB cluster, you can use the AWS Management Console to set up connectivity between an EC2 instance and the new DB cluster. When you do so, RDS configures your VPC and network settings automatically. The DB cluster is created in the same VPC as the EC2 instance so that the EC2 instance can access the DB cluster. The following are requirements for connecting an EC2 instance with the DB cluster: + The EC2 instance must exist in the AWS Region before you create the DB cluster. If no EC2 instances exist in the AWS Region, the console provides a link to create one. + The user who is creating the DB cluster must have permissions to perform the following operations: + `ec2:AssociateRouteTable` + `ec2:AuthorizeSecurityGroupEgress` + `ec2:AuthorizeSecurityGroupIngress` + `ec2:CreateRouteTable` + `ec2:CreateSubnet` + `ec2:CreateSecurityGroup` + `ec2:DescribeInstances` + `ec2:DescribeNetworkInterfaces` + `ec2:DescribeRouteTables` + `ec2:DescribeSecurityGroups` + `ec2:DescribeSubnets` + `ec2:ModifyNetworkInterfaceAttribute` + `ec2:RevokeSecurityGroupEgress` Using this option creates a private DB cluster. The DB cluster uses a DB subnet group with only private subnets to restrict access to resources within the VPC. To connect an EC2 instance to the DB cluster, choose **Connect to an EC2 compute resource** in the **Connectivity** section on the **Create database** page. ![\[Connect an EC2 instance\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/ec2-set-up-connection-create.png) When you choose **Connect to an EC2 compute resource**, RDS sets the following options automatically. You can't change these settings unless you choose not to set up connectivity with an EC2 instance by choosing **Don't connect to an EC2 compute resource**. **** | Console option | Automatic setting | | --- | --- | | **Virtual Private Cloud (VPC)** | RDS sets the VPC to the one associated with the EC2 instance. | | **DB subnet group** | RDS requires a DB subnet group with a private subnet in the same Availability Zone as the EC2 instance. If a DB subnet group that meets this requirement exists, then RDS uses the existing DB subnet group. By default, this option is set to Automatic setup. When you choose **Automatic setup** and there is no DB subnet group that meets this requirement, the following action happens. RDS uses three available private subnets in three Availability Zones where one of the Availability Zones is the same as the EC2 instance. If a private subnet isn’t available in an Availability Zone, RDS creates a private subnet in the Availability Zone. Then RDS creates the DB subnet group.When a private subnet is available, RDS uses the route table associated with the subnet and adds any subnets it creates to this route table. When no private subnet is available, RDS creates a route table without internet gateway access and adds the subnets it creates to the route table.RDS also allows you to use existing DB subnet groups. Select **Choose existing** if you want to use an existing DB subnet group of your choice. | | **Public access** | RDS chooses **No** so that the DB cluster isn't publicly accessible. For security, it is a best practice to keep the database private and make sure it isn't accessible from the internet. | | **VPC security group (firewall)** | RDS creates a new security group that is associated with the DB cluster. The security group is named `rds-ec2-n`, where `n` is a number. This security group includes an inbound rule with the EC2 VPC security group (firewall) as the source. This security group that is associated with the DB cluster allows the EC2 instance to access the DB cluster. RDS also creates a new security group that is associated with the EC2 instance. The security group is named `ec2-rds-n`, where `n` is a number. This security group includes an outbound rule with the VPC security group of the DB cluster as the source. This security group allows the EC2 instance to send traffic to the DB cluster. You can add another new security group by choosing **Create new** and typing the name of the new security group. You can add existing security groups by choosing **Choose existing** and selecting security groups to add. | | **Availability Zone** | RDS chooses the Availability Zone of the EC2 instance for one DB instance in the Multi-AZ DB cluster deployment. RDS randomly chooses a different Availability Zone for both of the other DB instances. The writer DB instance is created in the same Availability Zone as the EC2 instance. There is the possibility of cross Availability Zone costs if a failover occurs and the writer DB instance is in a different Availability Zone. | For more information about these settings, see [Settings for creating Multi-AZ DB clusters](#create-multi-az-db-cluster-settings). If you change these settings after the DB cluster is created, the changes might affect the connection between the EC2 instance and the DB cluster. #### Configure the network manually To connect to your DB cluster from resources other than EC2 instances in the same VPC, configure the network connections manually. If you use the AWS Management Console to create your Multi-AZ DB cluster, you can have Amazon RDS automatically create a VPC for you. Or you can use an existing VPC or create a new VPC for your Multi-AZ DB cluster. Your VPC must have at least one subnet in each of at least three Availability Zones for you to use it with a Multi-AZ DB cluster. For information on VPCs, see [Amazon VPC and Amazon RDS](USER_VPC.md). If you don't have a default VPC or you haven't created a VPC, and you don't plan to use the console, do the following: + Create a VPC with at least one subnet in each of at least three of the Availability Zones in the AWS Region where you want to deploy your DB cluster. For more information, see [Working with a DB instance in a VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md#Overview.RDSVPC.Create). + Specify a VPC security group that authorizes connections to your DB cluster. For more information, see [Provide access to your DB instance in your VPC by creating a security group](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup) and [Controlling access with security groups](Overview.RDSSecurityGroups.md). + Specify an RDS DB subnet group that defines at least three subnets in the VPC that can be used by the Multi-AZ DB cluster. For more information, see [Working with DB subnet groups](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Subnets). For information about limitations that apply to Multi-AZ DB clusters, see [Limitations of Multi-AZ DB clusters for Amazon RDS](multi-az-db-clusters-concepts.Limitations.md). If you want to connect to a resource that isn't in the same VPC as the Multi-AZ DB cluster, see the appropriate scenarios in [Scenarios for accessing a DB instance in a VPC](USER_VPC.Scenarios.md). ### Additional prerequisites Before you create your Multi-AZ DB cluster, consider the following additional prerequisites: + To tailor the configuration parameters for your DB cluster, specify a DB cluster parameter group with the required parameter settings. For information about creating or modifying a DB cluster parameter group, see [Parameter groups for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups). + Determine the TCP/IP port number to specify for your DB cluster. The firewalls at some companies block connections to the default ports. If your company firewall blocks the default port, choose another port for your DB cluster. All DB instances in a DB cluster use the same port. + If the major engine version for your database reached the RDS end of standard support date, you must use the Extended Support CLI option or the RDS API parameter. For more information, see RDS Extended Support in [Settings for creating Multi-AZ DB clusters](#create-multi-az-db-cluster-settings). ## Creating a DB cluster You can create a Multi-AZ DB cluster using the AWS Management Console, the AWS CLI, or the RDS API. ### Console You can create a Multi-AZ DB cluster by choosing **Multi-AZ DB cluster** in the **Availability and durability** section. **To create a Multi-AZ DB cluster using the console** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the upper-right corner of the AWS Management Console, choose the AWS Region in which you want to create the DB cluster. For information about the AWS Regions that support Multi-AZ DB clusters, see [Limitations of Multi-AZ DB clusters for Amazon RDS](multi-az-db-clusters-concepts.Limitations.md). 1. In the navigation pane, choose **Databases**. 1. Choose **Create database**. To create a Multi-AZ DB cluster, make sure that **Standard Create** is selected and **Easy Create** isn't. 1. In **Engine type**, choose **MySQL** or **PostgreSQL**. 1. For **Version**, choose the DB engine version. For information about the DB engine versions that support Multi-AZ DB clusters, see [Limitations of Multi-AZ DB clusters for Amazon RDS](multi-az-db-clusters-concepts.Limitations.md). 1. In **Templates**, choose the appropriate template for your deployment. 1. In **Availability and durability**, choose **Multi-AZ DB cluster**. ![\[Multi-AZ DB cluster choice\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/multi-az-db-cluster-create.png) 1. In **DB cluster identifier**, enter the identifier for your DB cluster. 1. In **Master username**, enter your master user name, or keep the default setting. 1. Enter your master password: 1. In the **Settings** section, open **Credential Settings**. 1. If you want to specify a password, clear the **Auto generate a password** box if it is selected. 1. (Optional) Change the **Master username** value. 1. Enter the same password in **Master password** and **Confirm password**. 1. For **DB instance class**, choose a DB instance class. For a list of supported DB instance classes, see [Instance class availability for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts.InstanceAvailability). 1. (Optional) Set up a connection to a compute resource for this DB cluster. You can configure connectivity between an Amazon EC2 instance and the new DB cluster during DB cluster creation. For more information, see [Configure automatic network connectivity with an EC2 instance](#create-multi-az-db-cluster-prerequisites-VPC-automatic). 1. In the **Connectivity** section under **VPC security group (firewall)**, if you select **Create new**, a VPC security group is created with an inbound rule that allows your local computer's IP address to access the database. 1. For the remaining sections, specify your DB cluster settings. For information about each setting, see [Settings for creating Multi-AZ DB clusters](#create-multi-az-db-cluster-settings). 1. Choose **Create database**. If you chose to use an automatically generated password, the **View credential details** button appears on the **Databases** page. To view the master user name and password for the DB cluster, choose **View credential details**. To connect to the DB cluster as the master user, use the user name and password that appear. **Important** You can't view the master user password again. 1. For **Databases**, choose the name of the new DB cluster. On the RDS console, the details for the new DB cluster appear. The DB cluster has a status of **Creating** until the DB cluster is created and ready for use. When the state changes to **Available**, you can connect to the DB cluster. Depending on the DB cluster class and storage allocated, it can take several minutes for the new DB cluster to be available. ### AWS CLI Before you create a Multi-AZ DB cluster using the AWS CLI, make sure to fulfill the required prerequisites. These include creating a VPC and an RDS DB subnet group. For more information, see [DB cluster prerequisites](#create-multi-az-db-cluster-prerequisites). To create a Multi-AZ DB cluster by using the AWS CLI, call the [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) command. Specify the `--db-cluster-identifier`. For the `--engine` option, specify either `mysql` or `postgres`. For information about each option, see [Settings for creating Multi-AZ DB clusters](#create-multi-az-db-cluster-settings). For information about the AWS Regions, DB engines, and DB engine versions that support Multi-AZ DB clusters, see [Limitations of Multi-AZ DB clusters for Amazon RDS](multi-az-db-clusters-concepts.Limitations.md). The `create-db-cluster` command creates the writer DB instance for your DB cluster, and two reader DB instances. Each DB instance is in a different Availability Zone. For example, the following command creates a MySQL 8.0 Multi-AZ DB cluster named `mysql-multi-az-db-cluster`. **Example** For Linux, macOS, or Unix: ``` 1. aws rds create-db-cluster \ 2. --db-cluster-identifier mysql-multi-az-db-cluster \ 3. --engine mysql \ 4. --engine-version 8.0.32 \ 5. --master-username admin \ 6. --manage-master-user-password \ 7. --port 3306 \ 8. --backup-retention-period 1 \ 9. --db-subnet-group-name default \ 10. --allocated-storage 4000 \ 11. --storage-type io1 \ 12. --iops 10000 \ 13. --db-cluster-instance-class db.m5d.xlarge ``` For Windows: ``` 1. aws rds create-db-cluster ^ 2. --db-cluster-identifier mysql-multi-az-db-cluster ^ 3. --engine mysql ^ 4. --engine-version 8.0.32 ^ 5. --manage-master-user-password ^ 6. --master-username admin ^ 7. --port 3306 ^ 8. --backup-retention-period 1 ^ 9. --db-subnet-group-name default ^ 10. --allocated-storage 4000 ^ 11. --storage-type io1 ^ 12. --iops 10000 ^ 13. --db-cluster-instance-class db.m5d.xlarge ``` The following command creates a PostgreSQL 13.4 Multi-AZ DB cluster named `postgresql-multi-az-db-cluster`. **Example** For Linux, macOS, or Unix: ``` 1. aws rds create-db-cluster \ 2. --db-cluster-identifier postgresql-multi-az-db-cluster \ 3. --engine postgres \ 4. --engine-version 13.4 \ 5. --manage-master-user-password \ 6. --master-username postgres \ 7. --port 5432 \ 8. --backup-retention-period 1 \ 9. --db-subnet-group-name default \ 10. --allocated-storage 4000 \ 11. --storage-type io1 \ 12. --iops 10000 \ 13. --db-cluster-instance-class db.m5d.xlarge ``` For Windows: ``` 1. aws rds create-db-cluster ^ 2. --db-cluster-identifier postgresql-multi-az-db-cluster ^ 3. --engine postgres ^ 4. --engine-version 13.4 ^ 5. --manage-master-user-password ^ 6. --master-username postgres ^ 7. --port 5432 ^ 8. --backup-retention-period 1 ^ 9. --db-subnet-group-name default ^ 10. --allocated-storage 4000 ^ 11. --storage-type io1 ^ 12. --iops 10000 ^ 13. --db-cluster-instance-class db.m5d.xlarge ``` ### RDS API Before you can create a Multi-AZ DB cluster using the RDS API, make sure to fulfill the required prerequisites, such as creating a VPC and an RDS DB subnet group. For more information, see [DB cluster prerequisites](#create-multi-az-db-cluster-prerequisites). To create a Multi-AZ DB cluster by using the RDS API, call the [ CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) operation. Specify the `DBClusterIdentifier`. For the `Engine` parameter, specify either `mysql` or `postgresql`. For information about each option, see [Settings for creating Multi-AZ DB clusters](#create-multi-az-db-cluster-settings). The `CreateDBCluster` operation creates the writer DB instance for your DB cluster, and two reader DB instances. Each DB instance is in a different Availability Zone. ## Settings for creating Multi-AZ DB clusters For details about settings that you choose when you create a Multi-AZ DB cluster, see the following table. For more information about the AWS CLI options, see [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html). For more information about the RDS API parameters, see [ CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). | Console setting | Setting description | CLI option and RDS API parameter | | --- | --- | --- | | **Allocated storage** | The amount of storage to allocate for each DB instance in your DB cluster (in gibibyte). For more information, see [Amazon RDS DB instance storage](CHAP_Storage.md). | **CLI option:** `--allocated-storage` **API parameter:** `AllocatedStorage` | | Auto minor version upgrade | **Enable auto minor version upgrade** to have your DB cluster receive preferred minor DB engine version upgrades automatically when they become available. Amazon RDS performs automatic minor version upgrades in the maintenance window. | **CLI option:** `--auto-minor-version-upgrade` `--no-auto-minor-version-upgrade` **API parameter:** `AutoMinorVersionUpgrade` | | Backup retention period | The number of days that you want automatic backups of your DB cluster to be retained. For a Multi-AZ DB cluster, this value must be set to **1** or greater. For more information, see [Introduction to backups](USER_WorkingWithAutomatedBackups.md). | **CLI option:** `--backup-retention-period` **API parameter:** `BackupRetentionPeriod` | | Backup window | The time period during which Amazon RDS automatically takes a backup of your DB cluster. Unless you have a specific time that you want to have your database backed up, use the default of **No preference**. For more information, see [Introduction to backups](USER_WorkingWithAutomatedBackups.md). | **CLI option:** `--preferred-backup-window` **API parameter:** `PreferredBackupWindow` | | **Certificate authority** | The certificate authority (CA) for the server certificate used by the DB cluster. For more information, see [Using SSL/TLS to encrypt a connection to a DB instance or cluster ](UsingWithRDS.SSL.md). | **CLI option:** `--ca-certificate-identifier` **RDS API parameter:** `CACertificateIdentifier` | | Copy tags to snapshots | This option copies any DB cluster tags to a DB snapshot when you create a snapshot. For more information, see [Tagging Amazon RDS resources](USER_Tagging.md). | **CLI option:** `-copy-tags-to-snapshot` `-no-copy-tags-to-snapshot` **RDS API parameter:** `CopyTagsToSnapshot` | | Database authentication | The database authentication option that you want to use. Choose **Password authentication** to authenticate database users with database passwords only. Choose **Password and IAM DB authentication** to authenticate database users with database passwords and user credentials through users and roles. For more information, see [IAM database authentication for MariaDB, MySQL, and PostgreSQL](UsingWithRDS.IAMDBAuth.md). | **CLI option:** `--enable-iam-database-authentication` `--no-enable-iam-database-authentication` **RDS API parameter:** `EnableIAMDatabaseAuthentication` | | Database port | The port that you want to access the DB cluster through. The default port is shown. The port can't be changed after the DB cluster is created. The firewalls at some companies block connections to the default ports. If your company firewall blocks the default port, enter another port for your DB cluster. | **CLI option:** `--port` **RDS API parameter:** `Port` | | DB cluster identifier | The name for your DB cluster. Name your DB clusters in the same way that you name your on-premises servers. Your DB cluster identifier can contain up to 63 alphanumeric characters, and must be unique for your account in the AWS Region you chose. | **CLI option:** `--db-cluster-identifier` **RDS API parameter:** `DBClusterIdentifier` | | DB instance class | The compute and memory capacity of each DB instance in the Multi-AZ DB cluster, for example `db.m5d.xlarge`. If possible, choose a DB instance class large enough that a typical query working set can be held in memory. When working sets are held in memory the system can avoid writing to disk, which improves performance. For a list of supported DB instance classes, see [Instance class availability for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts.InstanceAvailability). | **CLI option:** `--db-cluster-instance-class` **RDS API parameter:** `DBClusterInstanceClass` | | **DB cluster parameter group** | The DB cluster parameter group that you want associated with the DB cluster. For more information, see [Parameter groups for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups). | **CLI option:** `--db-cluster-parameter-group-name` **RDS API parameter:** `DBClusterParameterGroupName` | | DB engine version | The version of database engine that you want to use. | **CLI option:** `--engine-version` **RDS API parameter:** `EngineVersion` | | DB cluster parameter group | The DB instance parameter group to associate with the DB cluster. For more information, see [Parameter groups for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups). | **CLI option:** `--db-cluster-parameter-group-name` **RDS API parameter:** `DBClusterParameterGroupName` | | DB subnet group | The DB subnet group you want to use for the DB cluster. Select Choose existing to use an existing DB subnet group. Then choose the required subnet group from the Existing DB subnet groups dropdown list.Choose **Automatic setup** to let RDS select a compatible DB subnet group. If none exist, RDS creates a new subnet group for your cluster.For more information, see [Working with DB subnet groups](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Subnets). | **CLI option:** `--db-subnet-group-name` **RDS API parameter:** `DBSubnetGroupName` | | Deletion protection | **Enable deletion protection** to prevent your DB cluster from being deleted. If you create a production DB cluster with the console, deletion protection is turned on by default. For more information, see [Deleting a DB instance](USER_DeleteInstance.md). | **CLI option:** `--deletion-protection` `--no-deletion-protection` **RDS API parameter:** `DeletionProtection` | | Encryption | **Enable Encryption** to turn on encryption at rest for this DB cluster. Encryption is turned on by default for Multi-AZ DB clusters. For more information, see [Encrypting Amazon RDS resources](Overview.Encryption.md). | **CLI options:** `--kms-key-id` `--storage-encrypted` `--no-storage-encrypted` **RDS API parameters:** `KmsKeyId` `StorageEncrypted` | | Enhanced Monitoring | **Enable enhanced monitoring** to turn on metrics gathering in real time for the operating system that your DB cluster runs on. For more information, see [Monitoring OS metrics with Enhanced Monitoring](USER_Monitoring.OS.md). | **CLI options:** `--monitoring-interval` `--monitoring-role-arn` **RDS API parameters:** `MonitoringInterval` `MonitoringRoleArn` | | Initial database name | The name for the database on your DB cluster. If you don't provide a name, Amazon RDS doesn't create a database on the DB cluster for MySQL. However, it does create a database on the DB cluster for PostgreSQL. The name can't be a word reserved by the database engine. It has other constraints depending on the DB engine. MySQL: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/create-multi-az-db-cluster.html) PostgreSQL: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/create-multi-az-db-cluster.html) | **CLI option:** `--database-name` **RDS API parameter:** `DatabaseName` | | **Log exports** | The types of database log files to publish to Amazon CloudWatch Logs. For more information, see [Publishing database logs to Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md). | **CLI option:** `-enable-cloudwatch-logs-exports` **RDS API parameter:** `EnableCloudwatchLogsExports` | | Maintenance window | The 30-minute window in which pending modifications to your DB cluster are applied. If the time period doesn't matter, choose **No preference**. For more information, see [Amazon RDS maintenance window](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance). | **CLI option:** `--preferred-maintenance-window` **RDS API parameter:** `PreferredMaintenanceWindow` | | Manage master credentials in AWS Secrets Manager | Select **Manage master credentials in AWS Secrets Manager** to manage the master user password in a secret in Secrets Manager. Optionally, choose a KMS key to use to protect the secret. Choose from the KMS keys in your account, or enter the key from a different account. For more information, see [Password management with Amazon RDS and AWS Secrets Manager](rds-secrets-manager.md). | **CLI option:** `--manage-master-user-password \| --no-manage-master-user-password` `--master-user-secret-kms-key-id` **RDS API parameter:** `ManageMasterUserPassword` `MasterUserSecretKmsKeyId` | | Master password | The password for your master user account. | **CLI option:** `--master-user-password` **RDS API parameter:** `MasterUserPassword` | | Master username | The name that you use as the master user name to log on to your DB cluster with all database privileges. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/create-multi-az-db-cluster.html) You can't change the master user name after the Multi-AZ DB cluster is created. For more information on privileges granted to the master user, see [Master user account privileges](UsingWithRDS.MasterAccounts.md). | **CLI option:** `--master-username` **RDS API parameter:** `MasterUsername` | | Performance Insights | **Enable Performance Insights** to monitor your DB cluster load so that you can analyze and troubleshoot your database performance. Choose a retention period to determine how much Performance Insights data history to keep. The retention setting is **Default (7 days)**. To retain your performance data for longer, specify 1–24 months. For more information about retention periods, see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md). Choose a KMS key to use to protect the key used to encrypt this database volume. Choose from the KMS keys in your account, or enter the key from a different account. For more information, see [Monitoring DB load with Performance Insights on Amazon RDS](USER_PerfInsights.md). | **CLI options:** `--enable-performance-insights` `--no-enable-performance-insights` `--performance-insights-retention-period` `--performance-insights-kms-key-id` **RDS API parameters:** `EnablePerformanceInsights` `PerformanceInsightsRetentionPeriod` `PerformanceInsightsKMSKeyId` | | Provisioned IOPS | The amount of Provisioned IOPS (input/output operations per second) to be initially allocated for the DB cluster. | **CLI option:** `--iops` **RDS API parameter:** `Iops` | | Public access | **Publicly accessible** to give the DB cluster a public IP address, meaning that it's accessible outside the VPC. To be publicly accessible, the DB cluster also has to be in a public subnet in the VPC. **Not publicly accessible** to make the DB cluster accessible only from inside the VPC. For more information, see [Hiding a DB instance in a VPC from the internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding). To connect to a DB cluster from outside of its VPC, the DB cluster must be publicly accessible. Also, access must be granted using the inbound rules of the DB cluster's security group, and other requirements must be met. For more information, see [Can't connect to Amazon RDS DB instance](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). If your DB cluster isn't publicly accessible, you can use an AWS Site-to-Site VPN connection or an Direct Connect connection to access it from a private network. For more information, see [Internetwork traffic privacy](inter-network-traffic-privacy.md). | **CLI option:** `--publicly-accessible` `--no-publicly-accessible` **RDS API parameter:** `PubliclyAccessible` | | RDS Extended Support | Select **Enable RDS Extended Support** to allow supported major engine versions to continue running past the RDS end of standard support date. When you create a DB cluster, Amazon RDS defaults to RDS Extended Support. To prevent the creation of a new DB cluster after the RDS end of standard support date and to avoid charges for RDS Extended Support, disable this setting. Your existing DB clusters won't incur charges until the RDS Extended Support pricing start date. For more information, see [Amazon RDS Extended Support with Amazon RDS](extended-support.md). | **CLI option:** `--engine-lifecycle-support` **RDS API parameter:** `EngineLifecycleSupport` | | **Storage throughput** | The storage throughput value for the DB cluster. This setting is visible only if you choose General Purpose SSD (gp3) for the storage type. This setting is not configurable and is automatically set based on the IOPS that you specify. For more information, see [gp3 storage (recommended)](CHAP_Storage.md#gp3-storage). | This value is automatically calculated and doesn't have a CLI option. | | **RDS Proxy** | Choose **Create an RDS Proxy** to create a proxy for your DB cluster. Amazon RDS automatically creates an IAM role and a Secrets Manager secret for the proxy. | Not available when creating a DB cluster. | | Storage type | The storage type for your DB cluster. Only General Purpose SSD (gp3), Provisioned IOPS (io1), and Provisioned IOPS SSD (io2) storage are supported. For more information, see [Amazon RDS storage types](CHAP_Storage.md#Concepts.Storage). | **CLI option:** `--storage-type` **RDS API parameter:** `StorageType` | | Virtual Private Cloud (VPC) | A VPC based on the Amazon VPC service to associate with this DB cluster. For more information, see [Amazon VPC and Amazon RDS](USER_VPC.md). | For the CLI and API, you specify the VPC security group IDs. | | VPC security group (firewall) | The security groups to associate with the DB cluster. For more information, see [Overview of VPC security groups](Overview.RDSSecurityGroups.md#Overview.RDSSecurityGroups.VPCSec). | **CLI option:** `--vpc-security-group-ids` **RDS API parameter:** `VpcSecurityGroupIds` | ## Settings that don't apply when creating Multi-AZ DB clusters The following settings in the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) and the RDS API operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) don't apply to Multi-AZ DB clusters. You also can't specify these settings for Multi-AZ DB clusters in the console. | AWS CLI setting | RDS API setting | | --- | --- | | `--availability-zones` | `AvailabilityZones` | | `--backtrack-window` | `BacktrackWindow` | | `--character-set-name` | `CharacterSetName` | | `--domain` | `Domain` | | `--domain-iam-role-name` | `DomainIAMRoleName` | | `--enable-global-write-forwarding \| --no-enable-global-write-forwarding` | `EnableGlobalWriteForwarding` | | `--enable-http-endpoint \| --no-enable-http-endpoint` | `EnableHttpEndpoint` | | `--global-cluster-identifier` | `GlobalClusterIdentifier` | | `--option-group-name` | `OptionGroupName` | | `--pre-signed-url` | `PreSignedUrl` | | `--replication-source-identifier` | `ReplicationSourceIdentifier` | | `--scaling-configuration` | `ScalingConfiguration` | # Connecting to a Multi-AZ DB cluster for Amazon RDS A Multi-AZ DB cluster has three DB instances instead of a single DB instance. Each connection is handled by a specific DB instance. When you connect to a Multi-AZ DB cluster, the hostname and port that you specify point to a fully qualified domain name called an *endpoint*. The Multi-AZ DB cluster uses the endpoint mechanism to abstract these connections so that you don't need to specify exactly which DB instance in the DB cluster to connect to. Thus, you don't have to hardcode all the hostnames or write your own logic for rerouting connections when some DB instances aren't available. The writer endpoint connects to the writer DB instance of the DB cluster, which supports both read and write operations. The reader endpoint connects to either of the two reader DB instances, which support only read operations. Using endpoints, you can map each connection to the appropriate DB instance or group of DB instances based on your use case. For example, to perform DDL and DML statements, you can connect to whichever DB instance is the writer DB instance. To perform queries, you can connect to the reader endpoint, with the Multi-AZ DB cluster automatically managing connections among the reader DB instances. For diagnosis or tuning, you can connect to a specific DB instance endpoint to examine details about a specific DB instance. For information about connecting to a DB instance, see [Connecting to an Amazon RDS DB instance](CHAP_CommonTasks.Connect.md). For more information about connecting to Multi-AZ DB clusters, see the following topics. **Topics** + [Cluster endpoints](#multi-az-db-clusters-concepts-connection-management-endpoints-cluster) + [Reader endpoints](#multi-az-db-clusters-concepts-connection-management-endpoints-reader) + [Instance endpoints](#multi-az-db-clusters-concepts-connection-management-endpoints-instance) + [High availability connections](#multi-az-db-clusters-concepts-connection-management-endpoints-ha) + [Connecting to Multi-AZ DB clusters with the AWS drivers for Amazon RDSConnecting to Multi-AZ DB clusters with the Amazon Web Services (AWS) JDBC Driver](maz-cluster-connect-drivers.md) ## Types of Multi-AZ DB cluster endpoints An endpoint is represented by a unique identifier that contains a host address. The following types of endpoints are available from a Multi-AZ DB cluster: **Cluster endpoint** A *cluster endpoint* (or *writer endpoint*) for a Multi-AZ DB cluster connects to the current writer DB instance for that DB cluster. This endpoint is the only one that can perform write operations such as DDL and DML statements. This endpoint can also perform read operations. Each Multi-AZ DB cluster has one cluster endpoint and one writer DB instance. You use the cluster endpoint for all write operations on the DB cluster, including inserts, updates, deletes, and DDL changes. You can also use the cluster endpoint for read operations, such as queries. If the current writer DB instance of a DB cluster fails, the Multi-AZ DB cluster automatically fails over to a new writer DB instance. During a failover, the DB cluster continues to serve connection requests to the cluster endpoint from the new writer DB instance, with minimal interruption of service. The following example illustrates a cluster endpoint for a Multi-AZ DB cluster. `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com` For more information about connecting to cluster endpoints, see [Cluster endpoints](#multi-az-db-clusters-concepts-connection-management-endpoints-cluster). **Reader endpoint** A *reader endpoint* for a Multi-AZ DB cluster provides support for read-only connections to the DB cluster. Use the reader endpoint for read operations, such as `SELECT` queries. By processing those statements on the reader DB instances, this endpoint reduces the overhead on the writer DB instance. It also helps the cluster to scale the capacity to handle simultaneous `SELECT` queries. Each Multi-AZ DB cluster has one reader endpoint. The reader endpoint sends each connection request to one of the reader DB instances. When you use the reader endpoint for a session, you can only perform read-only statements such as `SELECT` in that session. The following example illustrates a reader endpoint for a Multi-AZ DB cluster. The read-only intent of a reader endpoint is denoted by the `-ro` within the cluster endpoint name. `mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com` For more information about connecting to reader endpoints, see [Reader endpoints](#multi-az-db-clusters-concepts-connection-management-endpoints-reader). **Instance endpoint** An *instance endpoint* connects to a specific DB instance within a Multi-AZ DB cluster. Each DB instance in a DB cluster has its own unique instance endpoint. So there is one instance endpoint for the current writer DB instance of the DB cluster, and there is one instance endpoint for each of the reader DB instances in the DB cluster. The instance endpoint provides direct control over connections to the DB cluster. This control can help you address scenarios where using the cluster endpoint or reader endpoint might not be appropriate. For example, your client application might require more fine-grained load balancing based on workload type. In this case, you can configure multiple clients to connect to different reader DB instances in a DB cluster to distribute read workloads. The following example illustrates an instance endpoint for a DB instance in a Multi-AZ DB cluster. `mydbinstance.123456789012.us-east-1.rds.amazonaws.com` For more information about connecting to instance endpoints, see [Instance endpoints](#multi-az-db-clusters-concepts-connection-management-endpoints-instance). ## Viewing endpoints Use the console, AWS CLI, or Amazon RDS API to view the cluster, reader, and instance endpoints. ------ #### [ Console ] In the AWS Management Console, you see the cluster endpoint and the reader endpoint on the details page for each Multi-AZ DB cluster. You see the instance endpoint in the details page for each DB instance. ------ #### [ AWS CLI ] With the AWS CLI, you see the writer and reader endpoints in the output of the [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) command. For example, the following command shows the endpoint attributes for all clusters in your current AWS Region. ``` aws rds describe-db-cluster-endpoints ``` ------ #### [ Amazon RDS API ] With the Amazon RDS API, you retrieve the endpoints by calling the [DescribeDBClusterEndpoints](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterEndpoints.html) action. The output also shows Amazon Aurora DB cluster endpoints, if any exist. ------ ## Cluster endpoints Each Multi-AZ DB cluster has a single built-in cluster endpoint, whose name and other attributes are managed by Amazon RDS. You can't create, delete, or modify this kind of endpoint. You use the cluster endpoint when you administer your DB cluster, perform extract, transform, load (ETL) operations, or develop and test applications. The cluster endpoint connects to the writer DB instance of the cluster. The writer DB instance is the only DB instance where you can create tables and indexes, run `INSERT` statements, and perform other DDL and DML operations. The physical IP address pointed to by the cluster endpoint changes when the failover mechanism promotes a new DB instance to be the writer DB instance for the cluster. If you use any form of connection pooling or other multiplexing, be prepared to flush or reduce the time-to-live for any cached DNS information. Doing so ensures that you don't try to establish a read/write connection to a DB instance that became unavailable or is now read-only after a failover. ## Reader endpoints You use the reader endpoint for read-only connections to your Multi-AZ DB cluster. This endpoint helps your DB cluster handle a query-intensive workload. The reader endpoint is the endpoint that you supply to applications that do reporting or other read-only operations on the cluster. The reader endpoint sends connections to available reader DB instances in a Multi-AZ DB cluster. Each Multi-AZ cluster has a single built-in reader endpoint, whose name and other attributes are managed by Amazon RDS. You can't create, delete, or modify this kind of endpoint. ## Instance endpoints Each DB instance in a Multi-AZ DB cluster has its own built-in instance endpoint, whose name and other attributes are managed by Amazon RDS. You can't create, delete, or modify this kind of endpoint. With a Multi-AZ DB cluster, you typically use the writer and reader endpoints more often than the instance endpoints. In day-to-day operations, the main way that you use instance endpoints is to diagnose capacity or performance issues that affect one specific DB instance in a Multi-AZ DB cluster. While connected to a specific DB instance, you can examine its status variables, metrics, and so on. Doing this can help you determine what's happening for that DB instance that's different from what's happening for other DB instances in the cluster. ## High availability connections For Multi-AZ DB clusters where high availability is important, use the writer endpoint for read/write or general-purpose connections and the reader endpoint for read-only connections. The writer and reader endpoints manage DB instance failover better than instance endpoints do. Unlike the instance endpoints, the writer and reader endpoints automatically change which DB instance they connect to if a DB instance in your cluster becomes unavailable. If the writer DB instance of a DB cluster fails, Amazon RDS automatically fails over to a new writer DB instance. It does so by promoting a reader DB instance to a new writer DB instance. If a failover occurs, you can use the writer endpoint to reconnect to the newly promoted writer DB instance. Or you can use the reader endpoint to reconnect to one of the reader DB instances in the DB cluster. During a failover, the reader endpoint might direct connections to the new writer DB instance of a DB cluster for a short time after a reader DB instance is promoted to the new writer DB instance. If you design your own application logic to manage instance endpoint connections, you can manually or programmatically discover the resulting set of available DB instances in the DB cluster. # Connecting to Multi-AZ DB clusters with the AWS drivers for Amazon RDS The AWS suite of drivers has been designed to provide support for faster switchover and failover times, and authentication with AWS Secrets Manager, AWS Identity and Access Management (IAM), and Federated Identity. The AWS drivers rely on monitoring DB cluster status and being aware of the cluster topology to determine the new writer. This approach reduces switchover and failover times to single-digit seconds, compared to tens of seconds for open-source drivers. As new service features are introduced, the goal of the AWS suite of drivers is to have built-in support for these service features. ## Connecting to Multi-AZ DB clusters with the Amazon Web Services (AWS) JDBC Driver The Amazon Web Services (AWS) JDBC Driver is designed as an advanced JDBC wrapper to help applications take advantage of the features of clustered databases. This wrapper is complementary to and extends the functionality of an existing JDBC driver. The driver is drop-in compatible with the following community drivers: + MySQL Connector/J + MariaDB Connector/J + pgJDBC To install the AWS JDBC Driver, append the AWS JDBC Driver .jar file (located in the application `CLASSPATH`), and keep references to the respective community driver. Update the respective connection URL prefix as follows: + `jdbc:mysql://` to `jdbc:aws-wrapper:mysql://` + `jdbc:mariadb://` to `jdbc:aws-wrapper:mariadb://` + `jdbc:postgresql://` to `jdbc:aws-wrapper:postgresql://` For more information about the AWS JDBC Driver and complete instructions for using it, see the [Amazon Web Services (AWS) JDBC Driver GitHub repository](https://github.com/awslabs/aws-advanced-jdbc-wrapper). ## Connecting to Multi-AZ DB clusters with the Amazon Web Services (AWS) Python Driver The Amazon Web Services (AWS) Python Driver is designed as an advanced Python wrapper. This wrapper is complementary to and extends the functionality of the open-source Psycopg driver. The AWS Python Driver supports Python versions 3.8 and higher. You can install the `aws-advanced-python-wrapper` package using the `pip` command, along with the `psycopg` open-source packages. For more information about the AWS Python Driver and complete instructions for using it, see the [Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/awslabs/aws-advanced-python-wrapper). # Automatically connecting an AWS compute resource and a Multi-AZ DB cluster for Amazon RDS You can automatically connect a Multi-AZ DB cluster and AWS compute resources such as Amazon Elastic Compute Cloud (Amazon EC2) instances and AWS Lambda functions. The following topics provide detailed instructions for configuring network settings, security groups, and connection parameters to establish reliable connections to Amazon RDS DB instances within a Multi-AZ DB cluster deployment. They focus on optimizing network connectivity and performance for applications interacting with Multi-AZ DB cluster, ensuring secure and efficient data operations. **Topics** + [ # Automatically connecting an EC2 instance and a Multi-AZ DB cluster ](multiaz-ec2-rds-connect.md) + [ # Automatically connecting a Lambda function and a Multi-AZ DB cluster ](multiaz-lambda-rds-connect.md) # Automatically connecting an EC2 instance and a Multi-AZ DB cluster You can use the Amazon RDS console to simplify setting up a connection between an Amazon Elastic Compute Cloud (Amazon EC2) instance and a Multi-AZ DB cluster. Often, your Multi-AZ DB cluster is in a private subnet and your EC2 instance is in a public subnet within a VPC. You can use a SQL client on your EC2 instance to connect to your Multi-AZ DB cluster. The EC2 instance can also run web servers or applications that access your private Multi-AZ DB cluster. ![\[Automatically connect a Multi-AZ DB cluster with an EC2 instance.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/multi-az-ec2-connect-overview.png) If you want to connect to an EC2 instance that isn't in the same VPC as the Multi-AZ DB cluster, see the scenarios in [Scenarios for accessing a DB instance in a VPC](USER_VPC.Scenarios.md). **Topics** + [ ## Overview of automatic connectivity with an EC2 instance ](#multiaz-ec2-rds-connect-overview) + [ ## Connecting an EC2 instance and a Multi-AZ DB cluster automatically ](#multiaz-ec2-rds-connect-connecting) + [ ## Viewing connected compute resources ](#multiaz-ec2-rds-connect-viewing) ## Overview of automatic connectivity with an EC2 instance When you set up a connection between an EC2 instance and a Multi-AZ DB cluster automatically, Amazon RDS configures the VPC security group for your EC2 instance and for your DB cluster. The following are requirements for connecting an EC2 instance with a Multi-AZ DB cluster: + The EC2 instance must exist in the same VPC as the Multi-AZ DB cluster. If no EC2 instances exist in the same VPC, the console provides a link to create one. + The user who is setting up connectivity must have permissions to perform the following EC2 operations: + `ec2:AuthorizeSecurityGroupEgress` + `ec2:AuthorizeSecurityGroupIngress` + `ec2:CreateSecurityGroup` + `ec2:DescribeInstances` + `ec2:DescribeNetworkInterfaces` + `ec2:DescribeSecurityGroups` + `ec2:ModifyNetworkInterfaceAttribute` + `ec2:RevokeSecurityGroupEgress` When you set up a connection to an EC2 instance, Amazon RDS acts according to the current configuration of the security groups associated with the Multi-AZ DB cluster and EC2 instance, as described in the following table. | Current RDS security group configuration | Current EC2 security group configuration | RDS action | | --- | --- | --- | | There are one or more security groups associated with the Multi-AZ DB cluster with a name that matches the pattern `rds-ec2-n` (where `n` is a number). A security group that matches the pattern hasn't been modified. This security group has only one inbound rule with the VPC security group of the EC2 instance as the source. | There are one or more security groups associated with the EC2 instance with a name that matches the pattern `rds-ec2-n` (where `n` is a number). A security group that matches the pattern hasn't been modified. This security group has only one outbound rule with the VPC security group of the Multi-AZ DB cluster as the source. | Amazon RDS takes no action. A connection was already configured automatically between the EC2 instance and Multi-AZ DB cluster. Because a connection already exists between the EC2 instance and the RDS database, the security groups aren't modified. | | Either of the following conditions apply: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-ec2-rds-connect.html) | Either of the following conditions apply: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-ec2-rds-connect.html) | [RDS action: create new security groups](ec2-rds-connect.md#rds-action-create-new-security-groups) | | There are one or more security groups associated with the Multi-AZ DB cluster with a name that matches the pattern `rds-ec2-n`. A security group that matches the pattern hasn't been modified. This security group has only one inbound rule with the VPC security group of the EC2 instance as the source. | There are one or more security groups associated with the EC2 instance with a name that matches the pattern `ec2-rds-n`. However, none of these security groups can be used for the connection with the Multi-AZ DB cluster. A security group can't be used if it doesn't have one outbound rule with the VPC security group of the Multi-AZ DB cluster as the source. A security group also can't be used if it has been modified. | [RDS action: create new security groups](ec2-rds-connect.md#rds-action-create-new-security-groups) | | There are one or more security groups associated with the Multi-AZ DB cluster with a name that matches the pattern `rds-ec2-n`. A security group that matches the pattern hasn't been modified. This security group has only one inbound rule with the VPC security group of the EC2 instance as the source. | A valid EC2 security group for the connection exists, but it is not associated with the EC2 instance. This security group has a name that matches the pattern `rds-ec2-n`. It hasn't been modified. It has only one outbound rule with the VPC security group of the Multi-AZ DB cluster as the source. | [RDS action: associate EC2 security group](ec2-rds-connect.md#rds-action-associate-ec2-security-group) | | Either of the following conditions apply: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-ec2-rds-connect.html) | There are one or more security groups associated with the EC2 instance with a name that matches the pattern `rds-ec2-n`. A security group that matches the pattern hasn't been modified. This security group has only one outbound rule with the VPC security group of the Multi-AZ DB cluster as the source. | [RDS action: create new security groups](ec2-rds-connect.md#rds-action-create-new-security-groups) | **RDS action: create new security groups** Amazon RDS takes the following actions: + Creates a new security group that matches the pattern `rds-ec2-n`. This security group has an inbound rule with the VPC security group of the EC2 instance as the source. This security group is associated with the Multi-AZ DB cluster and allows the EC2 instance to access the Multi-AZ DB cluster. + Creates a new security group that matches the pattern `ec2-rds-n`. This security group has an outbound rule with the VPC security group of the Multi-AZ DB cluster as the source. This security group is associated with the EC2 instance and allows the EC2 instance to send traffic to the Multi-AZ DB cluster. **RDS action: associate EC2 security group** Amazon RDS associates the valid, existing EC2 security group with the EC2 instance. This security group allows the EC2 instance to send traffic to the Multi-AZ DB cluster. ## Connecting an EC2 instance and a Multi-AZ DB cluster automatically Before setting up a connection between an EC2 instance and an RDS database, make sure you meet the requirements described in [Overview of automatic connectivity with an EC2 instance](ec2-rds-connect.md#ec2-rds-connect-overview). If you make changes to security groups after you configure connectivity, the changes might affect the connection between the EC2 instance and the RDS database. **Note** You can only set up a connection between an EC2 instance and an RDS database automatically by using the AWS Management Console. You can't set up a connection automatically with the AWS CLI or RDS API. **To connect an EC2 instance and an RDS database automatically** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**, and then choose the RDS database. 1. From **Actions**, choose **Set up EC2 connection**. The **Set up EC2 connection** page appears. 1. On the **Set up EC2 connection** page, choose the EC2 instance. ![\[Set up EC2 connection page.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/auto-connect-rds-ec2-set-up.png) If no EC2 instances exist in the same VPC, choose **Create EC2 instance** to create one. In this case, make sure the new EC2 instance is in the same VPC as the RDS database. 1. Choose **Continue**. The **Review and confirm** page appears. ![\[EC2 connection review and confirmation page.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/auto-connect-rds-ec2-confirm.png) 1. On the **Review and confirm** page, review the changes that RDS will make to set up connectivity with the EC2 instance. If the changes are correct, choose **Confirm and set up**. If the changes aren't correct, choose **Previous** or **Cancel**. ## Viewing connected compute resources You can use the AWS Management Console to view the compute resources that are connected to an RDS database. The resources shown include compute resource connections that were set up automatically. You can set up connectivity with compute resources automatically in the following ways: + You can select the compute resource when you create the database. For more information, see [Creating an Amazon RDS DB instance](USER_CreateDBInstance.md) and [Creating a Multi-AZ DB cluster for Amazon RDS](create-multi-az-db-cluster.md). + You can set up connectivity between an existing database and a compute resource. For more information, see [Automatically connecting an EC2 instance and an RDS database](ec2-rds-connect.md#ec2-rds-connect-connecting). The listed compute resources don't include ones that were connected to the database manually. For example, you can allow a compute resource to access a database manually by adding a rule to the VPC security group associated with the database. For a compute resource to be listed, the following conditions must apply: + The name of the security group associated with the compute resource matches the pattern `ec2-rds-n` (where `n` is a number). + The security group associated with the compute resource has an outbound rule with the port range set to the port that the RDS database uses. + The security group associated with the compute resource has an outbound rule with the source set to a security group associated with the RDS database. + The name of the security group associated with the RDS database matches the pattern `rds-ec2-n` (where `n` is a number). + The security group associated with the RDS database has an inbound rule with the port range set to the port that the RDS database uses. + The security group associated with the RDS database has an inbound rule with the source set to a security group associated with the compute resource. **To view compute resources connected to an RDS database** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**, and then choose the name of the RDS database. 1. On the **Connectivity & security** tab, view the compute resources in the **Connected compute resources**. ![\[Connected compute resources.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/ec2-connected-compute-resources.png) # Automatically connecting a Lambda function and a Multi-AZ DB cluster You can use the RDS console to simplify setting up a connection between a Lambda function and a Multi-AZ DB cluster. You can use the RDS console to simplify setting up a connection between a Lambda function and a Multi-AZ DB cluster. Often, your Multi-AZ DB cluster is in a private subnet within a VPC. The Lambda function can be used by applications to access your private Multi-AZ DB cluster. The following image shows a direct connection between your Multi-AZ DB cluster and your Lambda function. ![\[Automatically connect a Multi-AZ DB cluster with a Lambda function.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/auto-connect-maz-lambda.png) You can set up the connection between your Lambda function and your database through RDS Proxy to improve your database performance and resiliency. Often, Lambda functions make frequent, short database connections that benefit from connection pooling that RDS Proxy offers. You can take advantage of any IAM authentication that you already have for Lambda functions, instead of managing database credentials in your Lambda application code. For more information, see [Amazon RDS Proxy](rds-proxy.md). You can use the console to automatically create a proxy for your connection. You can also select existing proxies. The console updates the proxy security group to allow connections from your database and Lambda function. You can input your database credentials or select the Secrets Manager secret you require to access the database. ![\[Automatically connect a Multi-AZ DB cluster with a Lambda function through RDS Proxy.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/auto-connect-maz-lambda-Proxy.png) **Topics** + [ ## Overview of automatic connectivity with a Lambda function ](#multiaz-lambda-rds-connect-overview) + [ ## Automatically connecting a Lambda function and a Multi-AZ DB cluster ](#multiaz-lambda-rds-connect-connecting) + [ ## Viewing connected compute resources ](#multiaz-lambda-rds-connect-viewing) ## Overview of automatic connectivity with a Lambda function When you set up a connection between a Lambda function and a Multi-AZ DB cluster automatically, Amazon RDS configures the VPC security group for your Lambda function and for your DB cluster. The following are requirements for connecting a Lambda function with a Multi-AZ DB cluster: + The Lambda function must exist in the same VPC as the Multi-AZ DB cluster. If no Lambda function exists in the same VPC, the console provides a link to create one. + The user who sets up connectivity must have permissions to perform the following Amazon RDS, Amazon EC2, Lambda, Secrets Manager, and IAM operations: + Amazon RDS + `rds:CreateDBProxies` + `rds:DescribeDBInstances` + `rds:DescribeDBProxies` + `rds:ModifyDBInstance` + `rds:ModifyDBProxy` + `rds:RegisterProxyTargets` + Amazon EC2 + `ec2:AuthorizeSecurityGroupEgress` + `ec2:AuthorizeSecurityGroupIngress` + `ec2:CreateSecurityGroup` + `ec2:DeleteSecurityGroup` + `ec2:DescribeSecurityGroups` + `ec2:RevokeSecurityGroupEgress` + `ec2:RevokeSecurityGroupIngress` + Lambda + `lambda:CreateFunctions` + `lambda:ListFunctions` + `lambda:UpdateFunctionConfiguration` + Secrets Manager + `sercetsmanager:CreateSecret` + `secretsmanager:DescribeSecret` + IAM + `iam:AttachPolicy` + `iam:CreateRole` + `iam:CreatePolicy` + AWS KMS + `kms:describeKey` When you set up a connection between a Lambda function and a Multi-AZ DB cluster, Amazon RDS configures the VPC security group for your function and for your Multi-AZ DB cluster. If you use RDS Proxy, then Amazon RDS also configures the VPC security group for the proxy. Amazon RDS acts according to the current configuration of the security groups associated with the Multi-AZ DB cluster and Lambda function, and proxy, as described in the following table. | Current RDS security group configuration | Current Lambda security group configuration | Current proxy security group configuration | RDS action | | --- | --- | --- | --- | | Amazon RDS takes no action because security groups of all resources follow the correct naming pattern and have the right inbound and outbound rules. | There are one or more security groups associated with the Multi-AZ DB cluster with a name that matches the pattern `rds-lambda-n` (where `n` is a number) or if the `TargetHealth` of an associated proxy is `AVAILABLE`. A security group that matches the pattern hasn't been modified. This security group has only one inbound rule with the VPC security group of the Lambda function or proxy as the source. | There are one or more security groups associated with the Lambda function with a name that matches the pattern `lambda-rds-n` or `lambda-rdsproxy-n` (where `n` is a number). A security group that matches the pattern hasn't been modified. This security group has only one outbound rule with either the VPC security group of the Multi-AZ DB cluster or the proxy as the destination. | There are one or more security groups associated with the proxy with a name that matches the pattern `rdsproxy-lambda-n` (where `n` is a number). A security group that matches the pattern hasn't been modified. This security group has inbound and outbound rules with the VPC security groups of the Lambda function and the Multi-AZ DB cluster. | | Either of the following conditions apply: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) Amazon RDS can't use a security group that doesn't have one inbound rule with the VPC security group of the Lambda function or proxy as the source. Amazon RDS also can't use a security group that has been modified. Examples of modifications include adding a rule or changing the port of an existing rule. | Either of the following conditions apply: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) Amazon RDS can't use a security group if it doesn't have one outbound rule with the VPC security group of the Multi-AZ DB cluster or proxy as the source. Amazon RDS also can't use a security group that has been modified. | Either of the following conditions apply:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html)Amazon RDS can't use a security group that doesn't have inbound and outbound rules with the VPC security group of the Multi-AZ DB cluster and the Lambda function. Amazon RDS also can't use a security group that has been modified. | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) | | There are one or more security groups associated with the Multi-AZ DB cluster with a name that matches the pattern `rds-lambda-n` or if the `TargetHealth` of an associated proxy is `AVAILABLE`. A security group that matches the pattern hasn't been modified. This security group has only one inbound rule with the VPC security group of the Lambda function or proxy as the source. | There are one or more security groups associated with the Lambda function with a name that matches the pattern `lambda-rds-n` or `lambda-rdsproxy-n`. However, Amazon RDS can't use any of these security groups for the connection with the Multi-AZ DB cluster. Amazon RDS can't use a security group that doesn't have one outbound rule with the VPC security group of the Multi-AZ DB cluster or proxy as the destination. Amazon RDS also can't use a security group that has been modified. | There are one or more security groups associated with the proxy with a name that matches the pattern `rdsproxy-lambda-n`. However, Amazon RDS can't use any of these security groups for the connection with the Multi-AZ DB cluster or Lambda function. Amazon RDS can't use a security group that doesn't have inbound and outbound rules with the VPC security group of the Multi-AZ DB cluster and the Lambda function. Amazon RDS also can't use a security group that has been modified. | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) | | There are one or more security groups associated with the Multi-AZ DB cluster with a name that matches the pattern `rds-lambda-n` or if the `TargetHealth` of an associated proxy is `AVAILABLE`. A security group that matches the pattern hasn't been modified. This security group has only one inbound rule with the VPC security group of the Lambda function or proxy as the source. | A valid Lambda security group for the connection exists, but it is not associated with the Lambda function. This security group has a name that matches the pattern `lambda-rds-n` or `lambda-rdsproxy-n`. It hasn't been modified. It has only one outbound rule with the VPC security group of the Multi-AZ DB cluster or proxy as the destination. | A valid proxy security group for the connection exists, but it is not associated with the proxy. This security group has a name that matches the pattern `rdsproxy-lambda-n`. It hasn't been modified. It has inbound and outbound rules with the VPC security group of the Multi-AZ DB cluster and the Lambda function. | [RDS action: associate Lambda security group](#maz-lam-action-associate-lam-security-group) | | Either of the following conditions apply: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) | There are one or more security groups associated with the Lambda function with a name that matches the pattern `lambda-rds-n` or `lambda-rdsproxy-n`. A security group that matches the pattern hasn't been modified. This security group has only one outbound rule with the VPC security group of the Multi-AZ DB cluster or proxy as the destination. | There are one or more security groups associated with the proxy with a name that matches the pattern `rdsproxy-lambda-n`. A security group that matches the pattern hasn't been modified. This security group has inbound and outbound rules with the VPC security group of the Multi-AZ DB cluster and the Lambda function. | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) | | There are one or more security groups associated with the Multi-AZ DB cluster with a name that matches the pattern `rds-rdsproxy-n` (where `n` is a number). | Either of the following conditions apply: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) Amazon RDS can't use a security group that doesn't have one outbound rule with the VPC security group of the Multi-AZ DB cluster or proxy as the destination. Amazon RDS also can't use a security group that has been modified. | Either of the following conditions apply:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html)Amazon RDS can't use a security group that doesn't have inbound and outbound rules with the VPC security group of the Multi-AZ DB cluster and the Lambda function. Amazon RDS also can't use a security group that has been modified. | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) | **RDS action: create new security groups** Amazon RDS takes the following actions: + Creates a new security group that matches the pattern `rds-lambda-n`.This security group has an inbound rule with the VPC security group of the Lambda function or proxy as the source. This security group is associated with the Multi-AZ DB cluster and allows the function or proxy to access the Multi-AZ DB cluster. + Creates a new security group that matches the pattern `lambda-rds-n`. This security group has an outbound rule with the VPC security group of the Multi-AZ DB cluster or proxy as the destination. This security group is associated with the Lambda function and allows the Lambda function to send traffic to the Multi-AZ DB cluster or send traffic through a proxy. + Creates a new security group that matches the pattern `rdsproxy-lambda-n`. This security group has inbound and outbound rules with the VPC security group of the Multi-AZ DB cluster and the Lambda function. **RDS action: associate Lambda security group** Amazon RDS associates the valid, existing Lambda security group with the Lambda function. This security group allows the function to send traffic to the Multi-AZ DB cluster or send traffic through a proxy. ## Automatically connecting a Lambda function and a Multi-AZ DB cluster You can use the Amazon RDS console to automatically connect a Lambda function to your Multi-AZ DB cluster. This simplifies the process of setting up a connection between these resources. You can also use RDS Proxy to include a proxy in your connection. Lambda functions make frequent short database connections that benefit from the connection pooling that RDS Proxy offers. You can also use any IAM authentication that you've already set up for your Lambda function, instead of managing database credentials in your Lambda application code. You can connect an existing Multi-AZ DB cluster to new and existing Lambda functions using the **Set up Lambda connection** page. The setup process automatically sets up the required security groups for you. Before setting up a connection between a Lambda function and a Multi-AZ DB cluster, make sure that: + Your Lambda function and Multi-AZ DB cluster are in the same VPC. + You have the right permissions for your user account. For more information about the requirements, see [Overview of automatic connectivity with a Lambda function](lambda-rds-connect.md#lambda-rds-connect-overview). If you change security groups after you configure connectivity, the changes might affect the connection between the Lambda function and the Multi-AZ DB cluster. **Note** You can automatically set up a connection between a Multi-AZ DB cluster and a Lambda function only in the AWS Management Console. To connect a Lambda function, all instances in the Multi-AZ DB cluster must be in the **Available** state. **To automatically connect a Lambda function and a Multi-AZ DB cluster** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**, and then choose the Multi-AZ DB cluster that you want to connect to a Lambda function. 1. For **Actions**, choose **Set up Lambda connection**. 1. On the **Set up Lambda connection** page, under **Select Lambda function**, do either of the following: + If you have an existing Lambda function in the same VPC as your Multi-AZ DB cluster, choose **Choose existing function**, and then choose the function. + If you don't have a Lambda function in the same VPC, choose **Create new function**, and then enter a **Function name**. The default runtime is set to Nodejs.18. You can modify the settings for your new Lambda function in the Lambda console after you complete the connection setup. 1. (Optional) Under **RDS Proxy**, select **Connect using RDS Proxy**, and then do any of the following: + If you have an existing proxy that you want to use, choose **Choose existing proxy**, and then choose the proxy. + If you don't have a proxy, and you want Amazon RDS to automatically create one for you, choose **Create new proxy**. Then, for **Database credentials**, do either of the following: 1. Choose **Database username and password**, and then enter the **Username** and **Password** for your Multi-AZ DB cluster. 1. Choose **Secrets Manager secret**. Then, for **Select secret**, choose an AWS Secrets Manager secret. If you don't have a Secrets Manager secret, choose **Create new Secrets Manager secret** to [create a new secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html). After you create the secret, for **Select secret**, choose the new secret. After you create the new proxy, choose **Choose existing proxy**, and then choose the proxy. Note that it might take some time for your proxy to be available for connection. 1. (Optional) Expand **Connection summary** and verify the highlighted updates for your resources. 1. Choose **Set up**. After you confirm the setup, Amazon RDS begins the process of connecting your Lambda function, RDS Proxy (if you used a proxy), and Multi-AZ DB cluster. The console shows the **Connection details** dialog box, which lists the security group changes that allow connections between your resources. ## Viewing connected compute resources You can use the AWS Management Console to view the compute resources that are connected to your Multi-AZ DB cluster. The resources shown include compute resource connections that Amazon RDS set up automatically. The listed compute resources don't include those that are manually connected to the Multi-AZ DB cluster. For example, you can allow a compute resource to access your Multi-AZ DB cluster manually by adding a rule to your VPC security group associated with the cluster. For the console to list a Lambda function, the following conditions must apply: + The name of the security group associated with the compute resource matches the pattern `lambda-rds-n` or `lambda-rdsproxy-n` (where `n` is a number). + The security group associated with the compute resource has an outbound rule with the port range set to the port of the Multi-AZ DB cluster or an associated proxy. The destination for the outbound rule must be set to a security group associated with the Multi-AZ DB cluster or an associated proxy. + The name of the security group attached to the proxy associated with your database matches the pattern `rds-rdsproxy-n` (where `n` is a number). + The security group associated with the function has an outbound rule with the port set to the port that the Multi-AZ DB cluster or associated proxy uses. The destination must be set to a security group associated with the Multi-AZ DB cluster or associated proxy. **To view compute resources automatically connected to a Multi-AZ DB cluster** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**, and then choose the Multi-AZ DB cluster. 1. On the **Connectivity & security** tab, view the compute resources under **Connected compute resources**. # Modifying a Multi-AZ DB cluster for Amazon RDS A Multi-AZ DB cluster has a writer DB instance and two reader DB instances in three separate Availability Zones. Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower latency when compared to Multi-AZ deployments. For more information about Multi-AZ DB clusters, see [Multi-AZ DB cluster deployments for Amazon RDS](multi-az-db-clusters-concepts.md). You can modify a Multi-AZ DB cluster to change its settings. You can also perform operations on a Multi-AZ DB cluster, such as taking a snapshot of it. **Important** You can't modify the DB instances within a Multi-AZ DB cluster. All modifications must be done at the DB cluster level. The only operation you can perform on a DB instance within a Multi-AZ DB cluster is rebooting it. You can modify a Multi-AZ DB cluster using the AWS Management Console, the AWS CLI, or the RDS API. ## Console **To modify a Multi-AZ DB cluster** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**, and then choose the Multi-AZ DB cluster that you want to modify. 1. Choose **Modify**. The **Modify DB cluster** page appears. 1. Change any of the settings that you want. For information about each setting, see [Settings for modifying Multi-AZ DB clusters](#modify-multi-az-db-cluster-settings). 1. When all the changes are as you want them, choose **Continue** and check the summary of modifications. 1. (Optional) Choose **Apply immediately** to apply the changes immediately. Choosing this option can cause downtime in some cases. For more information, see [Applying changes immediately](#modify-multi-az-db-cluster-apply-immediately). 1. On the confirmation page, review your changes. If they're correct, choose **Modify DB cluster** to save your changes. Or choose **Back** to edit your changes or **Cancel** to cancel your changes. ## AWS CLI To modify a Multi-AZ DB cluster by using the AWS CLI, call the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) command. Specify the DB cluster identifier and the values for the options that you want to modify. For information about each option, see [Settings for modifying Multi-AZ DB clusters](#modify-multi-az-db-cluster-settings). **Example** The following code modifies `my-multi-az-dbcluster` by setting the backup retention period to 1 week (7 days). The code turns on deletion protection by using `--deletion-protection`. To turn off deletion protection, use `--no-deletion-protection`. The changes are applied during the next maintenance window by using `--no-apply-immediately`. Use `--apply-immediately` to apply the changes immediately. For more information, see [Applying changes immediately](#modify-multi-az-db-cluster-apply-immediately). For Linux, macOS, or Unix: ``` aws rds modify-db-cluster \ --db-cluster-identifier my-multi-az-dbcluster \ --backup-retention-period 7 \ --deletion-protection \ --no-apply-immediately ``` For Windows: ``` aws rds modify-db-cluster ^ --db-cluster-identifier my-multi-az-dbcluster ^ --backup-retention-period 7 ^ --deletion-protection ^ --no-apply-immediately ``` ## RDS API To modify a Multi-AZ DB cluster by using the Amazon RDS API, call the [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) operation. Specify the DB cluster identifier, and the parameters for the settings that you want to modify. For information about each parameter, see [Settings for modifying Multi-AZ DB clusters](#modify-multi-az-db-cluster-settings). ## Applying changes immediately When you modify a Multi-AZ DB cluster, you can apply the changes immediately. To apply changes immediately, you choose the **Apply Immediately** option in the AWS Management Console. Or you use the `--apply-immediately` option when calling the AWS CLI or set the `ApplyImmediately` parameter to `true` when using the Amazon RDS API. If you don't choose to apply changes immediately, the changes are put into the pending modifications queue. During the next maintenance window, any pending changes in the queue are applied. If you choose to apply changes immediately, your new changes and any changes in the pending modifications queue are applied. **Important** If any of the pending modifications require the DB cluster to be temporarily unavailable (*downtime*), choosing the apply immediately option can cause unexpected downtime. When you choose to apply a change immediately, any pending modifications are also applied immediately, instead of during the next maintenance window. If you don't want a pending change to be applied in the next maintenance window, you can modify the DB instance to revert the change. You can do this by using the AWS CLI and specifying the `--apply-immediately` option. Changes to some database settings are applied immediately, even if you choose to defer your changes. To see how the different database settings interact with the apply immediately setting, see [Settings for modifying Multi-AZ DB clusters](#modify-multi-az-db-cluster-settings). ## Settings for modifying Multi-AZ DB clusters For details about settings that you can use to modify a Multi-AZ DB cluster, see the following table. For more information about the AWS CLI options, see [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). For more information about the RDS API parameters, see [ ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). | Console setting | Setting description | CLI option and RDS API parameter | When the change occurs | Downtime notes | | --- | --- | --- | --- | --- | | **Allocated storage** | The amount of storage to allocate for each DB instance in your DB cluster (in gibibyte). For more information, see [Amazon RDS DB instance storage](CHAP_Storage.md). | **CLI option:** `--allocated-storage` **RDS API parameter:** `AllocatedStorage` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime doesn't occur during this change. | | Auto minor version upgrade | **Enable auto minor version upgrade** to have your DB cluster receive preferred minor DB engine version upgrades automatically when they become available. Amazon RDS performs automatic minor version upgrades in the maintenance window. | **CLI option:** `--auto-minor-version-upgrade` `--no-auto-minor-version-upgrade` **RDS API parameter:** `AutoMinorVersionUpgrade` | The change occurs immediately. This setting ignores the apply immediately setting. | Downtime occurs during this change. | | Backup retention period | The number of days that automatic backups of your DB cluster are retained. This value must be greater than zero. For more information, see [Introduction to backups](USER_WorkingWithAutomatedBackups.md). | **CLI option:** `--backup-retention-period` **RDS API parameter:** `BackupRetentionPeriod` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime doesn't occur during this change. | | Backup window | The time period during which Amazon RDS automatically takes a backup of your DB cluster. Unless you have a specific time that you want to have your database backed up, use the default of **No preference**. For more information, see [Introduction to backups](USER_WorkingWithAutomatedBackups.md). | **CLI option:** `--preferred-backup-window` **RDS API parameter:** `PreferredBackupWindow` | The change is applied asynchronously, as soon as possible. | Downtime doesn't occur during this change. | | **Certificate authority** | The certificate authority (CA) for the server certificate used by the DB cluster. For more information, see [Using SSL/TLS to encrypt a connection to a DB instance or cluster ](UsingWithRDS.SSL.md). | **CLI option:** `--ca-certificate-identifier` **RDS API parameter:** `CACertificateIdentifier` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime only occurs if the DB engine doesn't support rotation without restart. You can use the [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI command to determine whether the DB engine supports rotation without restart. | | Copy tags to snapshots | This option copies any DB cluster tags to a DB snapshot when you create a snapshot. For more information, see [Tagging Amazon RDS resources](USER_Tagging.md). | **CLI option:** `-copy-tags-to-snapshot` `-no-copy-tags-to-snapshot` **RDS API parameter:** `CopyTagsToSnapshot` | The change occurs immediately. This setting ignores the apply immediately setting. | Downtime doesn't occur during this change. | | Database authentication | For Multi-AZ DB clusters, only **Password authentication** is supported. | None because password authentication is the default. | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime doesn't occur during this change. | | **DB cluster identifier** | The DB cluster identifier. This value is stored as a lowercase string. When you change the DB cluster identifier, the DB cluster endpoint changes. The identifiers and endpoints of the DB instances in the DB cluster also change. The new DB cluster name must be unique. The maximum length is 63 characters. The names of the DB instances in the DB cluster are changed to correspond with the new name of the DB cluster. A new DB instance name can't be the same as the name of an existing DB instance. For example, if you change the DB cluster name to `maz`, a DB instance name might be changed to `maz-instance-1`. In this case, there can't be an existing DB instance named `maz-instance-1`. For more information, see [Renaming a Multi-AZ DB cluster for Amazon RDS](multi-az-db-cluster-rename.md). | **CLI option:** `--new-db-cluster-identifier` **RDS API parameter:** `NewDBClusterIdentifier` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime doesn't occur during this change. | | DB cluster instance class | The compute and memory capacity of each DB instance in the Multi-AZ DB cluster, for example `db.r6gd.xlarge`. If possible, choose a DB instance class large enough that a typical query working set can be held in memory. When working sets are held in memory, the system can avoid writing to disk, which improves performance. For more information, see [Instance class availability for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts.InstanceAvailability). | **CLI option:** `--db-cluster-instance-class` **RDS API parameter:** `DBClusterInstanceClass` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime occurs during this change. | | **DB cluster parameter group** | The DB cluster parameter group that you want associated with the DB cluster. For more information, see [Parameter groups for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups). | **CLI option:** `--db-cluster-parameter-group-name` **RDS API parameter:** `DBClusterParameterGroupName` | The parameter group change occurs immediately. | Downtime doesn't occur during this change. When you change the parameter group, changes to some parameters are applied to the DB instances in the Multi-AZ DB cluster immediately without a reboot. Changes to other parameters are applied only after the DB instances are rebooted. | | DB engine version | The version of database engine that you want to use. | **CLI option:** `--engine-version` **RDS API parameter:** `EngineVersion` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime occurs during this change. | | Deletion protection | **Enable deletion protection** to prevent your DB cluster from being deleted. For more information, see [Deleting a DB instance](USER_DeleteInstance.md). | **CLI option:** `--deletion-protection` `--no-deletion-protection` **RDS API parameter:** `DeletionProtection` | The change occurs immediately. This setting ignores the apply immediately setting. | Downtime doesn't occur during this change. | | Maintenance window | The 30-minute window in which pending modifications to your DB cluster are applied. If the time period doesn't matter, choose **No preference**. For more information, see [Amazon RDS maintenance window](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance). | **CLI option:** `--preferred-maintenance-window` **RDS API parameter:** `PreferredMaintenanceWindow` | The change occurs immediately. This setting ignores the apply immediately setting. | If there are one or more pending actions that cause downtime, and the maintenance window is changed to include the current time, those pending actions are applied immediately and downtime occurs. | | Manage master credentials in AWS Secrets Manager | Select **Manage master credentials in AWS Secrets Manager** to manage the master user password in a secret in Secrets Manager. Optionally, choose a KMS key to use to protect the secret. Choose from the KMS keys in your account, or enter the key from a different account. If RDS is already managing the master user password for the DB cluster, you can rotate the master user password by choosing **Rotate secret immediately**. For more information, see [Password management with Amazon RDS and AWS Secrets Manager](rds-secrets-manager.md). | **CLI option:** `--manage-master-user-password \| --no-manage-master-user-password` `--master-user-secret-kms-key-id` `--rotate-master-user-password \| --no-rotate-master-user-password` **RDS API parameter:** `ManageMasterUserPassword` `MasterUserSecretKmsKeyId` `RotateMasterUserPassword` | If you are turning on or turning off automatic master user password management, the change occurs immediately. This change ignores the apply immediately setting. If you are rotating the master user password, you must specify that the change is applied immediately. | Downtime doesn't occur during this change. | | New master password | The password for your master user account. | **CLI option:** `--master-user-password` **RDS API parameter:** `MasterUserPassword` | The change is applied asynchronously, as soon as possible. This setting ignores the apply immediately setting. | Downtime doesn't occur during this change. | | Provisioned IOPS | The amount of Provisioned IOPS (input/output operations per second) to be initially allocated for the DB cluster. | **CLI option:** `--iops` **RDS API parameter:** `Iops` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime doesn't occur during this change. | | Public access | **Publicly accessible** to give the DB cluster a public IP address, meaning that it's accessible outside its virtual private cloud (VPC). To be publicly accessible, the DB cluster also has to be in a public subnet in the VPC. **Not publicly accessible** to make the DB cluster accessible only from inside the VPC. For more information, see [Hiding a DB instance in a VPC from the internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding). To connect to a DB cluster from outside of its VPC, the DB cluster must be publicly accessible. Also, access must be granted using the inbound rules of the DB cluster's security group, and other requirements must be met. For more information, see [Can't connect to Amazon RDS DB instance](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). If your DB cluster isn't publicly accessible, you can use an AWS Site-to-Site VPN connection or an Direct Connect connection to access it from a private network. For more information, see [Internetwork traffic privacy](inter-network-traffic-privacy.md). | Not available when modifying a DB cluster. | The change occurs immediately. This setting ignores the apply immediately setting. | Downtime doesn't occur during this change. | | Storage type | The storage type for your DB cluster. Only General Purpose SSD (gp3), Provisioned IOPS (io1), and Provisioned IOPS SSD (io2) storage are supported. For more information, see [Amazon RDS storage types](CHAP_Storage.md#Concepts.Storage). | **CLI option:** `--storage-type` **RDS API parameter:** `StorageType` | If you choose to apply the change immediately, it occurs immediately. If you don't choose to apply the change immediately, it occurs during the next maintenance window. | Downtime doesn't occur during this change. | | VPC security group | The security groups to associate with the DB cluster. For more information, see [Overview of VPC security groups](Overview.RDSSecurityGroups.md#Overview.RDSSecurityGroups.VPCSec). | **CLI option:** `--vpc-security-group-ids` **RDS API parameter:** `VpcSecurityGroupIds` | The change is applied asynchronously, as soon as possible. This setting ignores the apply immediately setting. | Downtime doesn't occur during this change. | ## Settings that don't apply when modifying Multi-AZ DB clusters The following settings in the AWS CLI command [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) and the RDS API operation [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) don't apply to Multi-AZ DB clusters. You also can't modify these settings for Multi-AZ DB clusters in the console. | AWS CLI setting | RDS API setting | | --- | --- | | `--backtrack-window` | `BacktrackWindow` | | `--cloudwatch-logs-export-configuration` | `CloudwatchLogsExportConfiguration` | | `--copy-tags-to-snapshot \| --no-copy-tags-to-snapshot` | `CopyTagsToSnapshot` | | `--db-instance-parameter-group-name` | `DBInstanceParameterGroupName` | | `--domain` | `Domain` | | `--domain-iam-role-name` | `DomainIAMRoleName` | | `--enable-global-write-forwarding \| --no-enable-global-write-forwarding` | `EnableGlobalWriteForwarding` | | `--enable-http-endpoint \| --no-enable-http-endpoint` | `EnableHttpEndpoint` | | `--option-group-name` | `OptionGroupName` | | `--port` | `Port` | | `--scaling-configuration` | `ScalingConfiguration` | | `--storage-type` | `StorageType` | # Upgrading the engine version of a Multi-AZ DB cluster for Amazon RDS Amazon RDS provides newer versions of each supported database engine so that you can keep your Multi-AZ DB cluster up to date. This topic explains the process of upgrading a Multi-AZ DB cluster to newer versions. Upgrading a Multi-AZ DB cluster involves selecting a new compatible engine version and planning for potential downtime. The process ensures minimal disruption by utilizing the failover capabilities of the Multi-AZ architecture. Best practices include performing upgrades during low-traffic periods, testing in non-production environments, and verifying application compatibility with the new version. **Topics** + [ ## Minor version upgrades ](#multi-az-db-clusters-upgrade-minor) + [ ## Major version upgrades ](#multi-az-db-clusters-upgrade-major) + [ ## Upgrading a Multi-AZ DB cluster ](#multi-az-db-clusters-upgrade-process) + [ ## Upgrading Multi-AZ DB cluster read replicas ](#multi-az-db-clusters-upgrade-replicas) + [ ## Monitoring Multi-AZ DB cluster upgrades with events ](#multi-az-db-clusters-upgrade-monitoring) ## Minor version upgrades A minor version upgrade includes only changes that are backward-compatible with existing applications. When you initiate a minor version upgrade, Amazon RDS first upgrades the reader DB instances one at a time. Then, one of the reader DB instances switches to be the new writer DB instance. Amazon RDS then upgrades the old writer instance (which is now a reader instance). Downtime during the upgrade is limited to the time it takes for one of the reader DB instances to become the new writer DB instance. This downtime acts like an automatic failover. For more information, see [Failing over a Multi-AZ DB cluster for Amazon RDS](multi-az-db-clusters-concepts-failover.md). Note that the replica lag of your Multi-AZ DB cluster might affect the downtime. For more information, see [Replica lag and Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-replica-lag). For RDS for PostgreSQL Multi-AZ DB cluster read replicas, Amazon RDS upgrades the cluster member instances one at a time. The reader and writer cluster roles don't switch during the upgrade. Therefore, your DB cluster might experience downtime while Amazon RDS upgrades the cluster writer instance. **Note** The downtime for a Multi-AZ DB cluster minor version upgrade is typically 35 seconds. When used with RDS Proxy, you can further reduce downtime to one second or less. For more information, see [Amazon RDS Proxy](rds-proxy.md). Alternately, you can use an open source database proxy such as [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/), [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/), or the [AWS Advanced JDBC Wrapper Driver](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/). ## Major version upgrades A major version upgrade can introduce changes that aren't compatible with existing applications. When you initiate a major version upgrade of an RDS for PostgreSQL Multi-AZ DB cluster, Amazon RDS simultaneously upgrades the reader and writer instances. Therefore, your DB cluster might not be available until the upgrade completes. When you initiate a major version upgrade of an RDS for MySQL Multi-AZ DB cluster, Amazon RDS upgrades the cluster member instances one at a time, so replication occurs from a lower engine version to a higher one. It's important to ensure that your workload is compatible with both the source and target engine versions during a major version upgrade, as engine versions might differ in syntax and features. **Note** Like minor version upgrades, the downtime for an RDS for MySQL major version upgrade is typically 35 seconds. When used with RDS Proxy, you can further reduce downtime to one second or less. For more information, see [Amazon RDS Proxy](rds-proxy.md). ## Upgrading a Multi-AZ DB cluster The process for upgrading the engine version of a Multi-AZ DB cluster is the same as the process for upgrading a DB instance engine version. For instructions, see [Upgrading a DB instance engine version](USER_UpgradeDBInstance.Upgrading.md). The only difference is that when using the AWS Command Line Interface (AWS CLI), you use the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) command and specify the `--db-cluster-identifier` parameter (along with the `--allow-major-version-upgrade` parameter). For more information about major and minor version upgrades, see the following documentation for your DB engine: + [Upgrades of the RDS for PostgreSQL DB engine](USER_UpgradeDBInstance.PostgreSQL.md) + [Upgrades of the RDS for MySQL DB engine](USER_UpgradeDBInstance.MySQL.md) ## Upgrading Multi-AZ DB cluster read replicas Amazon RDS doesn't automatically upgrade Multi-AZ DB cluster read replicas. For *minor* version upgrades, you must first manually upgrade all read replicas and then upgrade the cluster. Otherwise, the upgrade is blocked. When you perform a *major* version upgrade of a cluster, the replication state of all read replicas changes to **terminated**. You must delete and recreate the read replicas after the upgrade completes. For more information, see [Monitoring read replication](USER_ReadRepl.Monitoring.md). ## Monitoring Multi-AZ DB cluster upgrades with events When you upgrade the engine version of a Multi-AZ DB cluster, Amazon RDS emits a specific event during each phase of the process. To track the progress of an upgrade, you can view or subscribe to these events. For more information about RDS events, see [Monitoring Amazon RDS events](working-with-events.md). For detailed information about a specific Amazon RDS event that occurs during your engine upgrade, see [Amazon RDS event categories and event messages](USER_Events.Messages.md). # Renaming a Multi-AZ DB cluster for Amazon RDS You can rename a Multi-AZ DB cluster by using the AWS Management Console, the AWS CLI `modify-db-cluster` command, or the Amazon RDS API `ModifyDBCluster` operation. Renaming a Multi-AZ DB cluster can have significant effects. The following is a list of considerations before you rename a Multi-AZ DB cluster. + When you rename a Multi-AZ DB cluster, the cluster endpoints for the Multi-AZ DB cluster change. These endpoints change because they include the name you assigned to the Multi-AZ DB cluster. You can redirect traffic from an old endpoint to a new one. For more information about Multi-AZ DB cluster endpoints, see [Connecting to a Multi-AZ DB cluster for Amazon RDS](multi-az-db-clusters-concepts-connection-management.md). + When you rename a Multi-AZ DB cluster, the old DNS name that was used by the Multi-AZ DB cluster is deleted, although it could remain cached for a few minutes. The new DNS name for the renamed Multi-AZ DB cluster becomes effective in about two minutes. The renamed Multi-AZ DB cluster isn't available until the new name becomes effective. + You can't use an existing Multi-AZ DB cluster name when renaming a cluster. + Metrics and events associated with the name of a Multi-AZ DB cluster are maintained if you reuse a DB cluster name. + Multi-AZ DB cluster tags remain with the Multi-AZ DB cluster, regardless of renaming. + DB cluster snapshots are retained for a renamed Multi-AZ DB cluster. **Note** A Multi-AZ DB cluster is an isolated database environment running in the cloud. A Multi-AZ DB cluster can host multiple databases. For information about changing a database name, see the documentation for your DB engine. ## Renaming to replace an existing Multi-AZ DB cluster The most common scenarios for renaming a Multi-AZ DB cluster include restoring data from a DB cluster snapshot or performing point-in-time recovery (PITR). By renaming the Multi-AZ DB cluster, you can replace the Multi-AZ DB cluster without changing any application code that references the Multi-AZ DB cluster. In these cases, complete the following steps: 1. Stop all traffic going to the Multi-AZ DB cluster. You can redirect traffic from accessing the databases on the Multi-AZ DB cluster, or choose another way to prevent traffic from accessing your databases on the Multi-AZ DB cluster. 1. Rename the existing Multi-AZ DB cluster. 1. Create a new Multi-AZ DB cluster by restoring from a DB cluster snapshot or recovering to a point in time. Then, give the new Multi-AZ DB cluster the name of the previous Multi-AZ DB cluster. If you delete the old Multi-AZ DB cluster, you are responsible for deleting any unwanted DB cluster snapshots of the old Multi-AZ DB cluster. ## Console **To rename a Multi-AZ DB cluster** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**. 1. Choose the Multi-AZ DB cluster that you want to rename. 1. Choose **Modify**. 1. In **Settings**, enter a new name for **DB cluster identifier**. 1. Choose **Continue**. 1. To apply the changes immediately, choose **Apply immediately**. Choosing this option can cause an outage in some cases. For more information, see [Applying changes immediately](modify-multi-az-db-cluster.md#modify-multi-az-db-cluster-apply-immediately). 1. On the confirmation page, review your changes. If they are correct, choose **Modify cluster** to save your changes. Alternatively, choose **Back** to edit your changes, or choose **Cancel** to discard your changes. ## AWS CLI To rename a Multi-AZ DB cluster, use the AWS CLI command [ modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Provide the current `--db-cluster-identifier` value and `--new-db-cluster-identifier` parameter with the new name of the Multi-AZ DB cluster. **Example** For Linux, macOS, or Unix: ``` 1. aws rds modify-db-cluster \ 2. --db-cluster-identifier DBClusterIdentifier \ 3. --new-db-cluster-identifier NewDBClusterIdentifier ``` For Windows: ``` 1. aws rds modify-db-cluster ^ 2. --db-cluster-identifier DBClusterIdentifier ^ 3. --new-db-cluster-identifier NewDBClusterIdentifier ``` ## RDS API To rename a Multi-AZ DB cluster, call the Amazon RDS API operation [ ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) with the following parameters: + `DBClusterIdentifier` – The existing name of the DB cluster. + `NewDBClusterIdentifier` – The new name of the DB cluster. # Rebooting a Multi-AZ DB cluster and reader DB instances for Amazon RDS You might need to reboot your Multi-AZ DB cluster, usually for maintenance reasons. For example, if you make certain modifications or change the DB cluster parameter group associated with a DB cluster, you reboot the DB cluster. Doing so causes the changes to take effect. If a DB cluster isn't using the latest changes to its associated DB cluster parameter group, the AWS Management Console shows the DB cluster parameter group with a status of **pending-reboot**. The **pending-reboot** parameter groups status doesn't result in an automatic reboot during the next maintenance window. To apply the latest parameter changes to that DB cluster, manually reboot the DB cluster. For more information about parameter groups, see [Parameter groups for Multi-AZ DB clusters](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups). Rebooting a DB cluster restarts the database engine service. Rebooting a DB cluster results in a momentary outage, during which the DB cluster status is set to **rebooting**. You can't reboot your DB cluster if it isn't in the **Available** state. Your database can be unavailable for several reasons, such as an in-progress backup, a previously requested modification, or a maintenance-window action. The time required to reboot your DB cluster depends on the crash recovery process, the database activity at the time of reboot, and the behavior of your specific DB cluster. To improve the reboot time, we recommend that you reduce database activity as much as possible during the reboot process. Reducing database activity reduces rollback activity for in-transit transactions. **Important** Multi-AZ DB clusters don't support reboot with a failover. When you reboot the writer instance of a Multi-AZ DB cluster, it doesn't affect the reader DB instances in that DB cluster and no failover occurs. When you reboot a reader DB instance, no failover occurs. To fail over a Multi-AZ DB cluster, choose **Failover** in the console, call the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html), or call the API operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html). ## Console **To reboot a DB cluster** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**, and then choose the Multi-AZ DB cluster that you want to reboot. 1. For **Actions**, choose **Reboot**. The **Reboot DB cluster** page appears. 1. Choose **Reboot** to reboot your DB cluster. Or choose **Cancel**. ## AWS CLI To reboot a Multi-AZ DB cluster by using the AWS CLI, call the [reboot-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-cluster.html) command. ``` aws rds reboot-db-cluster --db-cluster-identifier mymultiazdbcluster ``` ## RDS API To reboot a Multi-AZ DB cluster by using the Amazon RDS API, call the [RebootDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBCluster.html) operation. # Failing over a Multi-AZ DB cluster for Amazon RDS If there is a planned or unplanned outage of your writer DB instance in a Multi-AZ DB cluster, Amazon RDS automatically fails over to a reader DB instance in different Availability Zone. This ensures high availability with minimal disruption. Failovers can occur during hardware failures, network issues, or manual requests. The topic outlines the automatic detection of failures, the sequence of events during failover, and its impact on read and write operations. It also provides best practices for monitoring and minimizing failover times. The time it takes for the failover to complete depends on the database activity and other conditions when the writer DB instance became unavailable. Failover times are typically under 35 seconds. Failover completes when both reader DB instances have applied outstanding transactions from the failed writer. When the failover is complete, it can take additional time for the RDS console to reflect the new Availability Zone. **Topics** + [ ## Automatic failovers ](#multi-az-db-clusters-concepts-failover-automatic) + [ ## Manually failing over a Multi-AZ DB cluster ](#multi-az-db-clusters-concepts-failover-manual) + [ ## Determining whether a Multi-AZ DB cluster has failed over ](#multi-az-db-clusters-concepts-failover-determining) + [ ## Setting the JVM TTL for DNS name lookups ](#multi-az-db-clusters-concepts-failover-java-dns) ## Automatic failovers Amazon RDS handles failovers automatically so you can resume database operations as quickly as possible without administrative intervention. To fail over, the writer DB instance switches automatically to a reader DB instance. ## Manually failing over a Multi-AZ DB cluster If you manually fail over a Multi-AZ DB cluster, RDS first terminates the primary DB instance. Then, the internal monitoring system detects that the primary DB instance is unhealthy and promotes a readable replica DB instance. Failover times are typically under 35 seconds. You can fail over a Multi-AZ DB cluster manually using the AWS Management Console, the AWS CLI, or the RDS API. ### Console **To fail over a Multi-AZ DB cluster manually** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**. 1. Choose the Multi-AZ DB cluster that you want to fail over. 1. For **Actions**, choose **Failover**. The **Failover DB cluster** page appears. 1. Choose **Failover** to confirm the manual failover. ### AWS CLI To fail over a Multi-AZ DB cluster manually, use the AWS CLI command [ failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html). **Example** ``` 1. aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster ``` ### RDS API To fail over a Multi-AZ DB cluster manually, call the Amazon RDS API [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) and specify the `DBClusterIdentifier`. ## Determining whether a Multi-AZ DB cluster has failed over To determine if your Multi-AZ DB cluster has failed over, you can do the following: + Set up DB event subscriptions to notify you by email or SMS that a failover has been initiated. For more information about events, see [Working with Amazon RDS event notification](USER_Events.md). + View your DB events by using the Amazon RDS console or API operations. + View the current state of your Multi-AZ DB cluster by using the Amazon RDS console, the AWS CLI, and the RDS API. For information on how you can respond to failovers, reduce recovery time, and other best practices for Amazon RDS, see [Best practices for Amazon RDS](CHAP_BestPractices.md). ## Setting the JVM TTL for DNS name lookups The failover mechanism automatically changes the Domain Name System (DNS) record of the DB instance to point to the reader DB instance. As a result, you need to re-establish any existing connections to your DB instance. In a Java virtual machine (JVM) environment, due to how the Java DNS caching mechanism works, you might need to reconfigure JVM settings. The JVM caches DNS name lookups. When the JVM resolves a host name to an IP address, it caches the IP address for a specified period of time, known as the *time-to-live* (TTL). Because AWS resources use DNS name entries that occasionally change, we recommend that you configure your JVM with a TTL value of no more than 60 seconds. Doing this makes sure that when a resource's IP address changes, your application can receive and use the resource's new IP address by requerying the DNS. On some Java configurations, the JVM default TTL is set so that it never refreshes DNS entries until the JVM is restarted. Thus, if the IP address for an AWS resource changes while your application is still running, it can't use that resource until you manually restart the JVM and the cached IP information is refreshed. In this case, it's crucial to set the JVM's TTL so that it periodically refreshes its cached IP information. **Note** The default TTL can vary according to the version of your JVM and whether a security manager is installed. Many JVMs provide a default TTL less than 60 seconds. If you're using such a JVM and not using a security manager, you can ignore the rest of this topic. For more information on security managers in Oracle, see [The security manager](https://docs.oracle.com/javase/tutorial/essential/environment/security.html) in the Oracle documentation. To modify the JVM's TTL, set the [https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html](https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html) property value. Use one of the following methods, depending on your needs: + To set the property value globally for all applications that use the JVM, set `networkaddress.cache.ttl` in the `$JAVA_HOME/jre/lib/security/java.security` file. ``` networkaddress.cache.ttl=60 ``` + To set the property locally for your application only, set `networkaddress.cache.ttl` in your application's initialization code before any network connections are established. ``` java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); ``` # Setting up PostgreSQL logical replication with Multi-AZ DB clusters for Amazon RDS By using PostgreSQL logical replication with your Multi-AZ DB cluster, you can replicate and synchronize individual tables rather than the entire database instance. Logical replication uses a publish and subscribe model to replicate changes from a source to one or more recipients. It works by using change records from the PostgreSQL write-ahead log (WAL). For more information, see [Performing logical replication for Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md). When you create a new logical replication slot on the writer DB instance of a Multi-AZ DB cluster, the slot is asynchronously copied to each reader DB instance in the cluster. The slots on the reader DB instances are continuously synchronized with those on the writer DB instance. Logical replication is supported for Multi-AZ DB clusters running RDS for PostgreSQL version 14.8-R2 and higher, and 15.3-R2 and higher. **Note** In addition to the native PostgreSQL logical replication feature, Multi-AZ DB clusters running RDS for PostgreSQL also support the `pglogical` extension. For more information about PostgreSQL logical replication, see [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) in the PostgreSQL documentation. **Topics** + [ ## Prerequisites ](#multi-az-db-clusters-logical-replication-prereqs) + [ ## Setting up logical replication ](#multi-az-db-clusters-logical-replication) + [ ## Limitations and recommendations ](#multi-az-db-clusters-logical-replication-limitations) ## Prerequisites To configure PostgreSQL logical replication for Multi-AZ DB clusters, you must meet the following prerequisites. + Your user account must be a member of the `rds_superuser` group and have `rds_superuser` privileges. For more information, see [Understanding PostgreSQL roles and permissions](Appendix.PostgreSQL.CommonDBATasks.Roles.md). + Your Multi-AZ DB cluster must be associated with a custom DB cluster parameter group so that you can configure the parameter values described in the following procedure. For more information, see [Working with DB cluster parameter groups for Multi-AZ DB clusters](USER_WorkingWithDBClusterParamGroups.md). ## Setting up logical replication To set up logical replication for a Multi-AZ DB cluster, you enable specific parameters within the associated DB cluster parameter group, then create logical replication slots. **Note** Starting with PostgreSQL version 16, you can use reader DB instances of the Multi-AZ DB cluster for logical replication. **To set up logical replication for an RDS for PostgreSQL Multi-AZ DB cluster** 1. Open the custom DB cluster parameter group associated with your RDS for PostgreSQL Multi-AZ DB cluster. 1. In the **Parameters** search field, locate the `rds.logical_replication` static parameter and set its value to `1`. This parameter change can increase WAL generation, so enable it only when you’re using logical slots. 1. As part of this change, configure the following DB cluster parameters. + `max_wal_senders` + `max_replication_slots` + `max_connections` Depending on your expected usage, you might also need to change the values of the following parameters. However, in many cases, the default values are sufficient. + `max_logical_replication_workers` + `max_sync_workers_per_subscription` 1. Reboot the Multi-AZ DB cluster for the parameter values to take effect. For instructions, see [Rebooting a Multi-AZ DB cluster and reader DB instances for Amazon RDS](multi-az-db-clusters-concepts-rebooting.md). 1. Create a logical replication slot on the writer DB instance of the Multi-AZ DB cluster as explained in [Working with logical replication slots](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots). This process requires that you specify a decoding plugin. Currently, RDS for PostgreSQL supports the `test_decoding`, `wal2json`, and `pgoutput` plugins that ship with PostgreSQL. The slot is asynchronously copied to each reader DB instance in the cluster. 1. Verify the state of the slot on all reader DB instances of the Multi-AZ DB cluster. To do so, inspect the `pg_replication_slots` view on all reader DB instances and make sure that the `confirmed_flush_lsn` state is making progress while the application is actively consuming logical changes. The following commands demonstrate how to inspect the replication state on the reader DB instances. ``` % psql -h test-postgres-instance-2.abcdefabcdef.us-west-2.rds.amazonaws.com postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D0001700 (1 row) postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D8003628 (1 row) % psql -h test-postgres-instance-3.abcdefabcdef.us-west-2.rds.amazonaws.com postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D0001700 (1 row) postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D8003628 (1 row) ``` After you complete your replication tasks, stop the replication process, drop replication slots, and turn off logical replication. To turn off logical replication, modify your DB cluster parameter group and set the value of `rds.logical_replication` back to `0`. Reboot the cluster for the parameter change to take effect. ## Limitations and recommendations The following limitations and recommendations apply to using logical replication with Multi-AZ DB clusters running PostgreSQL version 16: + You can use only writer DB instances to create or drop logical replication slots. For example, the `CREATE SUBSCRIPTION` command must use the cluster writer endpoint in the host connection string. + You must use the cluster writer endpoint during any table synchronization or resynchronization. For example, you can use the following commands to resynchronize a newly added table: ``` Postgres=>ALTER SUBSCRIPTION subscription-name CONNECTION host=writer-endpoint Postgres=>ALTER SUBSCRIPTION subscription-name REFRESH PUBLICATION ``` + You must wait for table synchronization to complete before using the reader DB instances for logical replication. You can use the `[pg\$1subscription\$1rel](https://www.postgresql.org/docs/current/catalog-pg-subscription-rel.html)` catalog table to monitor table synchronization. Table synchronization is complete when the `srsubstate` column is set to ready (`r`). + We recommend using instance endpoints for the logical replication connection once initial table synchronization is complete. The following command reduces load on the writer DB instance by offloading replication to one of the reader DB instances: ``` Postgres=>ALTER SUBSCRIPTION subscription-name CONNECTION host=reader-instance-endpoint ``` You can't use the same slot on more than one DB instance at a time. When two or more applications are replicating logical changes from different DB instances in the cluster, some changes might be lost due to a cluster failover or network issue. In these situations, you can use instance endpoints for logical replication in the host connection string. The other application using the same configuration will show the following error message: ``` replication slot slot_name is already active for PID x providing immediate feedback. ``` + While using the `pglogical` extension, you can only use the cluster writer endpoint. The extension has known limitations that can create unused logical replication slots during table synchronization. Stale replication slots reserve write-ahead log (WAL) files and can lead to disk space problems. # Working with Multi-AZ DB cluster read replicas for Amazon RDS A DB cluster read replica is a special type of cluster that you create from a source DB instance. After you create a read replica, any updates made to the primary DB instance are asynchronously copied to the Multi-AZ DB cluster read replica. You can reduce the load on your primary DB instance by routing read queries from your applications to the read replica. Using read replicas, you can elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. You can also create one or more DB instance read replicas from a Multi-AZ DB cluster. DB instance read replicas let you scale beyond the compute or I/O capacity of the source Multi-AZ DB cluster by directing excess read traffic to the read replicas. Currently, you can't create a Multi-AZ DB cluster read replica from an existing Multi-AZ DB cluster. When choosing between migrating to a Multi-AZ DB cluster using a read replica or creating a DB instance read replica from a Multi-AZ DB cluster, consider your specific use case and performance requirements. **Migrating to a Multi-AZ DB cluster using a read replica** This approach is ideal when you need to enhance the availability and durability of your database while minimizing downtime. By using a read replica to transition to a Multi-AZ DB cluster, you can ensure continuous operation and data consistency. This method is particularly useful for production environments where maintaining availability and reducing impact on live workloads are critical. **Creating a DB instance read replica from a Multi-AZ DB cluster** This method is suitable when you want to scale read operations or offload read traffic from your primary database instance. By creating a read replica from an existing Multi-AZ DB cluster, you can distribute read-heavy workloads and improve performance without affecting the primary instance's stability. Choosing the right approach depends on whether your priority is to ensure high availability and durability or to scale read performance. Evaluate your workload characteristics and operational requirements to make an informed decision. **Topics** + [ # Migrating to a Multi-AZ DB cluster using a read replica ](multi-az-db-clusters-migrating-to-with-read-replica.md) + [ # Creating a DB instance read replica from a Multi-AZ DB cluster ](multi-az-db-clusters-create-instance-read-replica.md) # Migrating to a Multi-AZ DB cluster using a read replica To migrate a Single-AZ deployment or Multi-AZ DB instance deployment to a Multi-AZ DB cluster deployment with reduced downtime, you can create a Multi-AZ DB cluster read replica. For the source, you specify the DB instance in the Single-AZ deployment or the primary DB instance in the Multi-AZ DB instance deployment. The DB instance can process write transactions during the migration to a Multi-AZ DB cluster. Consider the following before you create a Multi-AZ DB cluster read replica: + The source DB instance must be on a version that supports Multi-AZ DB clusters. For more information, see [Supported Regions and DB engines for Multi-AZ DB clusters in Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.MultiAZDBClusters.md). + The Multi-AZ DB cluster read replica must be on the same major version as its source, and the same or higher minor version. + You must turn on automatic backups on the source DB instance by setting the backup retention period to a value other than 0. + The allocated storage of the source DB instance must be 100 GiB or higher. + For RDS for MySQL, both the `gtid-mode` and `enforce_gtid_consistency` parameters must be set to `ON` for the source DB instance. You must use a custom parameter group, not the default parameter group. For more information, see [DB parameter groups for Amazon RDS DB instances](USER_WorkingWithDBInstanceParamGroups.md). + An active, long-running transaction can slow the process of creating the read replica. We recommend that you wait for long-running transactions to complete before creating a read replica. + If you delete the source DB instance for a Multi-AZ DB cluster read replica, the read replica is promoted to a standalone Multi-AZ DB cluster. ## Creating and promoting the Multi-AZ DB cluster read replica You can create and promote a Multi-AZ DB cluster read replica using the AWS Management Console, AWS CLI, or RDS API. **Note** We strongly recommend that you create all read replicas in the same virtual private cloud (VPC) based on Amazon VPC of the source DB instance. If you create a read replica in a different VPC from the source DB instance, Classless Inter-Domain Routing (CIDR) ranges can overlap between the replica and the Amazon RDS system. CIDR overlap makes the replica unstable, which can negatively impact applications connecting to it. If you receive an error when creating the read replica, choose a different destination DB subnet group. For more information, see [Working with a DB instance in a VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md). ### Console To migrate a Single-AZ deployment or Multi-AZ DB instance deployment to a Multi-AZ DB cluster using a read replica, complete the following steps using the AWS Management Console. 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Create the Multi-AZ DB cluster read replica. 1. In the navigation pane, choose **Databases**. 1. Choose the DB instance that you want to use as the source for a read replica. 1. For **Actions**, choose **Create read replica**. 1. For **Availability and durability**, choose **Multi-AZ DB cluster**. 1. For **DB instance identifier**, enter a name for the read replica. 1. For the remaining sections, specify your DB cluster settings. For information about a setting, see [Settings for creating Multi-AZ DB clusters](create-multi-az-db-cluster.md#create-multi-az-db-cluster-settings). 1. Choose **Create read replica**. 1. When you are ready, promote the read replica to be a standalone Multi-AZ DB cluster: 1. Stop any transactions from being written to the source DB instance, and then wait for all updates to be made to the read replica. Database updates occur on the read replica after they have occurred on the primary DB instance. This replication lag can vary significantly. Use the `ReplicaLag` metric to determine when all updates have been made to the read replica. For more information about replica lag, see [Monitoring read replication](USER_ReadRepl.Monitoring.md). 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the Amazon RDS console, choose **Databases**. The **Databases** pane appears. Each read replica shows **Replica** in the **Role** column. 1. Choose the Multi-AZ DB cluster read replica that you want to promote. 1. For **Actions**, choose **Promote**. 1. On the **Promote read replica** page, enter the backup retention period and the backup window for the newly promoted Multi-AZ DB cluster. 1. When the settings are as you want them, choose **Promote read replica**. 1. Wait for the status of the promoted Multi-AZ DB cluster to be `Available`. 1. Direct your applications to use the promoted Multi-AZ DB cluster. Optionally, delete the Single-AZ deployment or Multi-AZ DB instance deployment if it is no longer needed. For instructions, see [Deleting a DB instance](USER_DeleteInstance.md). ### AWS CLI To migrate a Single-AZ deployment or Multi-AZ DB instance deployment to a Multi-AZ DB cluster using a read replica, complete the following steps using the AWS CLI. 1. Create the Multi-AZ DB cluster read replica. To create a read replica from the source DB instance, use the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html). For `--replication-source-identifier`, specify the Amazon Resource Name (ARN) of the source DB instance. For Linux, macOS, or Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier mymultiazdbcluster \ --replication-source-identifier arn:aws:rds:us-east-2:123456789012:db:mydbinstance --engine postgres \ --db-cluster-instance-class db.m5d.large \ --storage-type io1 \ --iops 1000 \ --db-subnet-group-name defaultvpc \ --backup-retention-period 1 ``` For Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier mymultiazdbcluster ^ --replication-source-identifier arn:aws:rds:us-east-2:123456789012:db:mydbinstance --engine postgres ^ --db-cluster-instance-class db.m5d.large ^ --storage-type io1 ^ --iops 1000 ^ --db-subnet-group-name defaultvpc ^ --backup-retention-period 1 ``` 1. Stop any transactions from being written to the source DB instance, and then wait for all updates to be made to the read replica. Database updates occur on the read replica after they have occurred on the primary DB instance. This replication lag can vary significantly. Use the `Replica Lag` metric to determine when all updates have been made to the read replica. For more information about replica lag, see [Monitoring read replication](USER_ReadRepl.Monitoring.md). 1. When you are ready, promote the read replica to be a standalone Multi-AZ DB cluster. To promote a Multi-AZ DB cluster read replica, use the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html). For `--db-cluster-identifier`, specify the identifier of the Multi-AZ DB cluster read replica. ``` aws rds promote-read-replica-db-cluster --db-cluster-identifier mymultiazdbcluster ``` 1. Wait for the status of the promoted Multi-AZ DB cluster to be `Available`. 1. Direct your applications to use the promoted Multi-AZ DB cluster. Optionally, delete the Single-AZ deployment or Multi-AZ DB instance deployment if it is no longer needed. For instructions, see [Deleting a DB instance](USER_DeleteInstance.md). ### RDS API To migrate a Single-AZ deployment or Multi-AZ DB instance deployment to a Multi-AZ DB cluster using a read replica, complete the following steps using the RDS API. 1. Create the Multi-AZ DB cluster read replica. To create a Multi-AZ DB cluster read replica, use the [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) operation with the required parameter `DBClusterIdentifier`. For `ReplicationSourceIdentifier`, specify the Amazon Resource Name (ARN) of the source DB instance. 1. Stop any transactions from being written to the source DB instance, and then wait for all updates to be made to the read replica. Database updates occur on the read replica after they have occurred on the primary DB instance. This replication lag can vary significantly. Use the `Replica Lag` metric to determine when all updates have been made to the read replica. For more information about replica lag, see [Monitoring read replication](USER_ReadRepl.Monitoring.md). 1. When you are ready, promote read replica to be a standalone Multi-AZ DB cluster. To promote a Multi-AZ DB cluster read replica, use the [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) operation with the required parameter `DBClusterIdentifier`. Specify the identifier of the Multi-AZ DB cluster read replica. 1. Wait for the status of the promoted Multi-AZ DB cluster to be `Available`. 1. Direct your applications to use the promoted Multi-AZ DB cluster. Optionally, delete the Single-AZ deployment or Multi-AZ DB instance deployment if it is no longer needed. For instructions, see [Deleting a DB instance](USER_DeleteInstance.md). ## Limitations for creating a Multi-AZ DB cluster read replica The following limitations apply to creating a Multi-AZ DB cluster read replica from a Single-AZ deployment or Multi-AZ DB instance deployment. + You can't create a Multi-AZ DB cluster read replica in an AWS account that is different from the AWS account that owns the source DB instance. + You can't create a Multi-AZ DB cluster read replica in a different AWS Region from the source DB instance. + You can't recover a Multi-AZ DB cluster read replica to a point in time. + Storage encryption must have the same settings on the source DB instance and Multi-AZ DB cluster. + If the source DB instance is encrypted, the Multi-AZ DB cluster read replica must be encrypted using the same KMS key. + If the source DB instance uses General Purpose SSD (gp3) storage and has less than 400 GiB of allocated storage, you can't modify the provisioned IOPS for the Multi-AZ DB cluster read replica. + To perform a minor version upgrade on the source DB instance, you must first perform the minor version upgrade on the Multi-AZ DB cluster read replica. + When you perform a minor version upgrade on an RDS for PostgreSQL Multi-AZ DB cluster read replica, the reader DB instance doesn't switch to the writer DB instance after the upgrade. Therefore, your DB cluster might experience downtime while Amazon RDS upgrades the writer instance. + You can't perform a major version upgrade on a Multi-AZ DB cluster read replica. + You can perform a major version upgrade on the source DB instance of a Multi-AZ DB cluster read replica, but replication to the read replica stops and can't be restarted. + The Multi-AZ DB cluster read replica doesn't support cascading read replicas. + For RDS for PostgreSQL, Multi-AZ DB cluster read replicas can't fail over. # Creating a DB instance read replica from a Multi-AZ DB cluster You can create a DB instance read replica from a Multi-AZ DB cluster in order to scale beyond the compute or I/O capacity of the cluster for read-heavy database workloads. You can direct this excess read traffic to one or more DB instance read replicas. You can also use read replicas to migrate from a Multi-AZ DB cluster to a DB instance. To create a read replica, specify a Multi-AZ DB cluster as the replication source. One of the reader instances of the Multi-AZ DB cluster is always the source of replication, not the writer instance. This condition ensures that the replica is always in sync with the source cluster, even in cases of failover. **Topics** + [ ## Comparing reader DB instances and DB instance read replicas ](#multi-az-db-clusters-readerdb-vs-dbrr) + [ ## Considerations ](#multi-az-db-clusters-instance-read-replica-considerations) + [ ## Creating a DB instance read replica ](#multi-az-db-clusters-instance-read-replica-create) + [ ## Promoting the DB instance read replica ](#multi-az-db-clusters-promote-instance-read-replica) + [ ## Limitations for creating a DB instance read replica from a Multi-AZ DB cluster ](#multi-az-db-clusters-create-instance-read-replica-limitations) ## Comparing reader DB instances and DB instance read replicas A *DB instance read replica* of a Multi-AZ DB cluster is different than the *reader DB instances* of the Multi-AZ DB cluster in the following ways: + The reader DB instances act as automatic failover targets, while DB instance read replicas do not. + Reader DB instances must acknowledge a change from the writer DB instance before the change can be committed. For DB instance read replicas, however, updates are asynchronously copied to the read replica without requiring acknowledgement. + Reader DB instances always share the same instance class, storage type, and engine version as the writer DB instance of the Multi-AZ DB cluster. DB instance read replicas, however, don’t necessarily have to share the same configurations as the source cluster. + You can promote a DB instance read replica to a standalone DB instance. You can’t promote a reader DB instance of a Multi-AZ DB cluster to a standalone instance. + The reader endpoint only routes requests to the reader DB instances of the Multi-AZ DB cluster. It never routes requests to a DB instance read replica. For more information about reader and writer DB instances, see [Multi-AZ DB cluster architecture](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-overview). ## Considerations Consider the following before you create a DB instance read replica from a Multi-AZ DB cluster: + When you create the DB instance read replica, it must be on the same major version as its source cluster, and the same or higher minor version. After you create it, you can optionally upgrade the read replica to a higher minor version than the source cluster. + When you create the DB instance read replica, the allocated storage must be the same as the allocated storage of the source Multi-AZ DB cluster. You can change the allocated storage after the read replica is created. + For RDS for MySQL, the `gtid-mode` parameter must be set to `ON` for the source Multi-AZ DB cluster. For more information, see [Working with DB cluster parameter groups for Multi-AZ DB clusters](USER_WorkingWithDBClusterParamGroups.md). + An active, long-running transaction can slow the process of creating the read replica. We recommend that you wait for long-running transactions to complete before creating a read replica. + If you delete the source Multi-AZ DB cluster for a DB instance read replica, any read replicas that it's writing to are promoted to standalone DB instances. ## Creating a DB instance read replica You can create a DB instance read replica from a Multi-AZ DB cluster using the AWS Management Console, AWS CLI, or RDS API. **Note** We strongly recommend that you create all read replicas in the same virtual private cloud (VPC) based on Amazon VPC of the source Multi-AZ DB cluster. If you create a read replica in a different VPC from the source Multi-AZ DB cluster, Classless Inter-Domain Routing (CIDR) ranges can overlap between the replica and the RDS system. CIDR overlap makes the replica unstable, which can negatively impact applications connecting to it. If you receive an error when creating the read replica, choose a different destination DB subnet group. For more information, see [Working with a DB instance in a VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md). ### Console To create a DB instance read replica from a Multi-AZ DB cluster, complete the following steps using the AWS Management Console. 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**. 1. Choose the Multi-AZ DB cluster that you want to use as the source for a read replica. 1. For **Actions**, choose **Create read replica**. 1. For **Replica source**, make sure that the correct Multi-AZ DB cluster is selected. 1. For **DB identifier**, enter a name for the read replica. 1. For the remaining sections, specify your DB instance settings. For information about a setting, see [Settings for DB instances](USER_CreateDBInstance.Settings.md). **Note** The allocated storage for the DB instance read replica must be the same as the allocated storage for the source Multi-AZ DB cluster. 1. Choose **Create read replica**. ### AWS CLI To create a DB instance read replica from a Multi-AZ DB cluster, use the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html). For `--source-db-cluster-identifier`, specify the identifier of the Multi-AZ DB cluster. For Linux, macOS, or Unix: ``` aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --source-db-cluster-identifier mymultiazdbcluster ``` For Windows: ``` aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --source-db-cluster-identifier mymultiazdbcluster ``` ### RDS API To create a DB instance read replica from a Multi-AZ DB cluster, use the [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html) operation. ## Promoting the DB instance read replica If you no longer need the DB instance read replica, you can promote it into a standalone DB instance. When you promote a read replica, the DB instance is rebooted before it becomes available. For instructions, see [Promoting a read replica to be a standalone DB instance](USER_ReadRepl.Promote.md). If you're using the read replica to migrate a Multi-AZ DB cluster deployment to a Single-AZ or Multi-AZ DB instance deployment, make sure to stop any transactions that are being written to the source DB cluster. Then, wait for all updates to be made to the read replica. Database updates occur on the read replica after they occur on one of the reader DB instances of the Multi-AZ DB cluster. This replication lag can vary significantly. Use the `ReplicaLag` metric to determine when all updates have been made to the read replica. For more information about replica lag, see [Monitoring read replication](USER_ReadRepl.Monitoring.md). After you promote the read replica, wait for the status of the promoted DB instance to be `Available` before you direct your applications to use the promoted DB instance. Optionally, delete the Multi-AZ DB cluster deployment if you no longer need it. For instructions, see [Deleting a Multi-AZ DB cluster for Amazon RDS](USER_DeleteMultiAZDBCluster.Deleting.md). ## Limitations for creating a DB instance read replica from a Multi-AZ DB cluster The following limitations apply to creating a DB instance read replica from a Multi-AZ DB cluster deployment. + You can't create a DB instance read replica in an AWS account that's different from the AWS account that owns the source Multi-AZ DB cluster. + You can't create a DB instance read replica in a different AWS Region from the source Multi-AZ DB cluster. + You can't recover a DB instance read replica to a point in time. + Storage encryption must have the same settings on the source Multi-AZ DB cluster and DB instance read replica. + If the source Multi-AZ DB cluster is encrypted, the DB instance read replica must be encrypted using the same KMS key. + To perform a minor version upgrade on the source Multi-AZ DB cluster, you must first perform the minor version upgrade on the DB instance read replica. + The DB instance read replica doesn't support cascading read replicas. + For RDS for PostgreSQL, the source Multi-AZ DB cluster must be running PostgreSQL version 13.11, 14.8, or 15.2.R2 or higher in order to create a DB instance read replica. + You can perform a major version upgrade on the source Multi-AZ DB cluster of a DB instance read replica, but replication to the read replica stops and can't be restarted. # Setting up external replication from Multi-AZ DB clusters for Amazon RDS You can set up replication between a Multi-AZ DB cluster and a database that is external to Amazon RDS. External replication allows Multi-AZ DB clusters to replicate data between an RDS DB instance and an external database, either on-premises or in another cloud environment. It's beneficial for disaster recovery, data migration, and maintaining consistency between systems in different locations. The section covers the prerequisites for setting up replication, how to configure the process, and key considerations like replication latency, bandwidth, and compatibility with different database engines. ## RDS for MySQL To set up external replication for an RDS for MySQL Multi-AZ DB cluster, you must retain binary log files on the DB instances within the cluster for long enough to ensure that the changes are applied to the replica before Amazon RDS deletes the binlog file. To do so, configure binary log retention by calling the `mysql.rds_set_configuration` stored procedure and specifying the `binlog retention hours` parameter. For more information, see [binlog retention hours](mysql-stored-proc-configuring.md#mysql_rds_set_configuration-usage-notes.binlog-retention-hours). The default value for `binlog retention hours` is `NULL`, which means that binary logs aren't retained (0 hours). If you want to set up external replication for a Multi-AZ DB cluster, you must set the parameter to a value other than `NULL`. You can only configure binary log retention from the writer DB instance of the Multi-AZ DB cluster, and the setting is propagated to all reader DB instances asynchronously. In addition, we highly recommend enabling GTID-based replication on your external replica. Then, if one of the DB instances fails, you can resume replication from another healthy DB instance within the cluster. For more information, see [Replication with Global Transaction Identifiers](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html) in the MySQL documentation. ## RDS for PostgreSQL To set up external replication for an RDS for PostgreSQL Multi-AZ DB cluster, you must enable logical replication. For instructions, see [Setting up PostgreSQL logical replication with Multi-AZ DB clusters for Amazon RDS](USER_MultiAZDBCluster_LogicalRepl.md). # Deleting a Multi-AZ DB cluster for Amazon RDS You can delete a DB Multi-AZ DB cluster using the AWS Management Console, the AWS CLI, or the RDS API. The time required to delete a Multi-AZ DB cluster can vary depending on the following factors: + Thee backup retention period (that is, how many backups to delete). + How much data is deleted. + Whether a final snapshot is taken. Deletion protection must be disabled on the Multi-AZ DB cluster before you can delete it. For more information, see [Prerequisites for deleting a DB instance](USER_DeleteInstance.md#USER_DeleteInstance.DeletionProtection). You can disable deletion protection by modifying the Multi-AZ DB cluster. For more information, see [Modifying a Multi-AZ DB cluster for Amazon RDS](modify-multi-az-db-cluster.md). ## Console **To delete a Multi-AZ DB cluster** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**, and then choose the Multi-AZ DB cluster that you want to delete. 1. For **Actions**, choose **Delete**. 1. Choose **Create final snapshot?** to create a final DB snapshot for the Multi-AZ DB cluster. If you create a final snapshot, enter a name for **Final snapshot name**. 1. Choose **Retain automated backups** to retain automated backups. 1. Enter **delete me** in the box. 1. Choose **Delete**. ## AWS CLI To delete a Multi-AZ DB cluster by using the AWS CLI, call the [delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html) command with the following options: + `--db-cluster-identifier` + `--final-db-snapshot-identifier` or `--skip-final-snapshot` **Example With a final snapshot** For Linux, macOS, or Unix: ``` aws rds delete-db-cluster \ --db-cluster-identifier mymultiazdbcluster \ --final-db-snapshot-identifier mymultiazdbclusterfinalsnapshot ``` For Windows: ``` aws rds delete-db-cluster ^ --db-cluster-identifier mymultiazdbcluster ^ --final-db-snapshot-identifier mymultiazdbclusterfinalsnapshot ``` **Example With no final snapshot** For Linux, macOS, or Unix: ``` aws rds delete-db-cluster \ --db-cluster-identifier mymultiazdbcluster \ --skip-final-snapshot ``` For Windows: ``` aws rds delete-db-cluster ^ --db-cluster-identifier mymultiazdbcluster ^ --skip-final-snapshot ``` ## RDS API To delete a Multi-AZ DB cluster by using the Amazon RDS API, call the [DeleteDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html) operation with the following parameters: + `DBClusterIdentifier` + `FinalDBSnapshotIdentifier` or `SkipFinalSnapshot` # Limitations of Multi-AZ DB clusters for Amazon RDS A Multi-AZ DB cluster has a writer DB instance and two reader DB instances in three separate Availability Zones. Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower latency when compared to Multi-AZ deployments. For more information about Multi-AZ DB clusters, see [Multi-AZ DB cluster deployments for Amazon RDS](multi-az-db-clusters-concepts.md). The following limitations apply to Multi-AZ DB clusters. + Multi-AZ DB clusters don't support the following features: + IPv6 connections (dual-stack mode) + Cross-Region automated backups + Kerberos authentication + Modifying the port. As an alternative, you can restore a Multi-AZ DB cluster to a point in time and specify a different port. + Option groups + Point-in-time-recovery (PITR) for deleted clusters + Storage autoscaling by setting the maximum allocated storage. As an alternative, you can scale storage manually. + Stopping and starting the Multi-AZ DB cluster + Copying a snapshot of a Multi-AZ DB cluster + Encrypting an unencrypted Multi-AZ DB cluster + RDS for MySQL Multi-AZ DB clusters support only the following system stored procedures: + `mysql.rds_rotate_general_log` + `mysql.rds_rotate_slow_log` + `mysql.rds_show_configuration` + `mysql.rds_set_external_master_with_auto_position` + `mysql.rds_set_configuration` + RDS for PostgreSQL Multi-AZ DB clusters don't support the following extensions: `aws_s3` and `pg_transport`. + RDS for PostgreSQL Multi-AZ DB clusters don't support using a custom DNS server for outbound network access.