Deploying Amazon RDS on AWS Outposts for Multi-AZ High Availability

More Info

Amazon Relational Database Service (Amazon RDS) has recently introduced support for highly available configurations featuring Multi-AZ instance deployments for PostgreSQL and MySQL on AWS Outposts. In this article, we will walk you through the process of setting up an RDS database instance with Multi-AZ instance deployments.

Understanding Multi-AZ Deployments

With Multi-AZ deployments on Outposts, Amazon RDS establishes two database instances across separate Outposts. Each Outpost operates on distinct physical infrastructure and connects to different Availability Zones within a Region to ensure high availability. By utilizing a customer-managed local connection, Amazon RDS oversees synchronous replication between the primary and standby database instances. In the event of a software or infrastructure failure, Amazon RDS automatically promotes the standby instance to the primary role and updates the DNS record to direct traffic to the new primary. This automatic transition is known as failover, and the database service resumes promptly after the failover process is complete. Application traffic is seamlessly rerouted to the new primary instance as indicated by the DNS updates. The former primary instance is then demoted to standby status after necessary repairs, re-entering service afterward. The accompanying diagram illustrates this architecture.

In a Multi-AZ setup, both the primary and standby instances maintain separate data copies. When a database write request is made, the data is initially written to the Amazon Elastic Block Store (Amazon EBS) volume of the primary instance, followed by replication to the standby instance’s EBS volume over the local network. A successful response is sent back to the requesting application only after the data is written to both EBS volumes. The diagram below depicts the data flow during a database write operation.

The performance of the interconnection between Outposts is crucial for minimizing latency during remote writes and acknowledgments. In Multi-AZ deployments on Outposts, the total database write latency is equal to the combined latency of local write and acknowledgment plus remote write and acknowledgment.

Replication Local Network

For RDS Multi-AZ deployments on Outposts, a customer-managed local connection is required between the two Outposts, serving as the replication local network. During the installation of Outposts, AWS utilizes the information you provide about your local network to establish an address pool, referred to as a customer-owned IP address pool (CoIP pool). This pool is then assigned to the local gateway (LGW) for usage and advertisement back to your local network via Border Gateway Protocol (BGP). A CoIP pool must adhere to the following requirements:

• The address must be routable within your network.
• The CIDR block must have a minimum size of /26.

For additional information, check out the guidelines on local network connectivity for Outposts Racks.

Customer-owned IP (CoIP) addresses enable local or external connectivity to resources within your Outpost subnets through your local network. Amazon RDS allocates CoIP addresses from the CoIP pools for replication across the local network, utilizing CoIP routing to manage the replication traffic between primary and standby instances. When configuring the customer-managed replication local network, keep the following points in mind:

• The roundtrip time (RTT) latency between the Outpost hosting your primary database instance and that of the standby instance significantly impacts write latency. Aim for low single-digit millisecond RTT latency between the Outposts, ideally under 5 milliseconds, although specific requirements may vary.
• You can monitor the impact on network latency using Amazon CloudWatch metrics for WriteLatency; for further details, visit the Amazon CloudWatch metrics for Amazon RDS.
• The reliability of the connection between Outposts is vital for the overall availability of your database instances. Ensure redundant network connectivity between the Outposts.

Prerequisites

Before proceeding, you should be familiar with using the AWS Management Console and have the following prerequisites:

• Two Outposts, each with its own LGW, situated in different Availability Zones within an AWS Region.
• Each LGW must have a configured CoIP pool available for its route table.
• Two Outposts connected to a customer-managed local network through an LGW, with LGW route tables set up for CoIP routing.
• An AWS account that has access to the Outposts.
• One customer VPC.

For more details about the prerequisites for Multi-AZ deployments, refer to the section on Prerequisites.

Setting Up Subnets on Outposts

The first step in deploying Amazon RDS on Outposts is creating the Outpost subnets that will host your database. You can extend a VPC in the Region to Outposts by adding an Outpost subnet.

1. In the Outposts console, select Outposts from the navigation pane.
2. Ensure your two prerequisite Outposts are installed and have networking properly configured.
3. Choose your first Outpost, and from the Actions menu, select Create subnet.
4. For VPC ID, select your VPC (for this example, we will use an existing VPC called wanhe-demo-vpc).
5. Enter a name for the Subnet (for this example, we will use wanhe-demo-snOutpost1).
6. Specify the IPv4 CIDR block.
7. Under Tags, add the key Name with the subnet value.
8. Click Create subnet.
9. Repeat these steps to create a subnet on the second Outpost, named wanhe-demo-snOutpost2.

Associating Your VPC to LGW Route Tables

Amazon RDS requires associating your VPC with the LGW route tables, as it relies on this association to determine which CoIP pools to allocate CoIP addresses for replication.

1. In the Outposts console, go to Local gateway route tables in the navigation menu.
2. Select the Outpost and choose Associate VPC from the Actions menu.
3. For VPC ID, select the VPC you wish to deploy your database to.
4. Click Associate VPC.
5. Repeat these steps to associate the VPC with the second Outpost.

Creating a DB Subnet Group

To set up Amazon RDS with Multi-AZ instance deployments on Outposts, you must create a DB subnet group that includes Outpost subnets covering at least two Availability Zones, thereby ensuring that both Outposts are specified (each Outpost corresponds to one Availability Zone only).

1. In the Amazon RDS console, click on Subnet groups in the navigation pane.
2. Select Create DB subnet group.
3. Provide a name and description.
4. For VPC, choose your VPC.
5. Select the Availability Zones to include.
6. Choose the subnets you have created.
7. Click Create.

Deploying the Database with Multi-AZ

To deploy your database, follow these steps:

1. In the Amazon RDS console, select Databases from the navigation menu.
2. Click Create database.
3. For Database location options, select On-premises.
4. Under On-premises database options, choose RDS on Outposts.
5. For Virtual private cloud, select your VPC.
6. For Subnet group, choose Existing and select your subnet group.
7. Input your database port.
8. For Engine type, select your desired engine (in this example, we will choose PostgreSQL).
9. For Version, choose your PostgreSQL version.
10. For DB instance identifier, enter a name (for this example, we will use wanhe-demo-maz).
11. Under Credential Settings, provide your primary username and password.
12. For Multi-AZ deployments, select Create a standby instance.
13. For Backup target, select your desired option.

By following these steps, you will successfully deploy Amazon RDS on AWS Outposts with Multi-AZ high availability.