Demo Setting up AWS RDS Multi AZ Cluster Deployment with Read Replicas

Welcome to this comprehensive guide on deploying an AWS RDS multi-AZ PostgreSQL cluster with read replicas. In this walkthrough, you will learn how to create a high-availability PostgreSQL database using Amazon RDS, configure it across multiple availability zones, and set up additional read replicas to boost read performance.

We start on the Amazon RDS dashboard, where no databases have been configured yet.

Creating the Database Cluster

In this demonstration, you will deploy a clustered PostgreSQL instance. Unlike single-instance deployments, a multi-AZ cluster features a primary instance accompanied by two read-only standby instances distributed across different availability zones.

Scroll down to select the PostgreSQL engine. This guide exclusively uses PostgreSQL, and at the time of this writing, the available version is 16.3 R2.

Review the engine version options provided:

Select the production template to ensure a high-availability configuration. In a single-instance deployment, no standby exists; however, in a multi-AZ cluster deployment, you get one primary along with two read replicas across separate availability zones. Remember, a standard multi-AZ deployment’s standby instance is not available for read requests, making a cluster deployment the ideal choice for both high availability and enhanced read capacity.

Provide a name for the database cluster (e.g., "RDS PGTAZ") and set the access credentials. The master username is set as "Postgres" with the password also set as "Postgres" for demonstration purposes.

When configuring credentials, the option to manage passwords using AWS Secrets Manager is intentionally left as self-managed to facilitate easier modifications during the demonstration.

Proceed to the instance configuration section. For this demonstration, we select the standard M5D large instance class. Although other classes like M6GD or M6ID are available, using a large instance simplifies the setup. Our storage is configured with provisioned IOPS and an allocation of 100 GB. (Note that provisioned IOPS requires a minimum ratio of 1000 IOPS per storage size.)

Select provisioned IOPS to meet performance requirements. This example demonstrates a temporary selection of provisioned IOPS to get the setup up and running quickly.

Review the storage settings to ensure they meet your application requirements:

Next, navigate to the network and security configuration. Choose the default VPC and subnet group, and leave public access disabled unless external exposure is necessary. For security groups, the default configuration is used, though this can be customized or integrated with RDS Proxy if needed.

In subsequent configuration screens, you can also integrate RDS Proxy, which helps improve failover handling and connection pooling. For this demonstration, proxy configuration is skipped, and the remaining settings such as certificate authority, tags, IAM authentication, Kerberos, and performance insights are maintained at their default values (with performance insights enabled on the free tier for seven days).

Additional options for backups, maintenance, and parameter groups are available. In this demonstration, automated backups are set for a seven-day retention period, and the default KMS key is applied.

Database Creation, Failover, and Monitoring

After verifying all configuration options, click "Create Database." AWS will begin provisioning the cluster by launching three virtual machines across different availability zones. During this process, you might be presented with additional options such as creating an ElastiCache cluster or integrating with RDS Proxy. For simplicity, these extra options are skipped in this demonstration.

While the cluster is initializing, the primary instance is set up as the writer, and the remaining instances function as readers. The dashboard will display statuses like "active creating" until provisioning completes.

After the cluster is established and a backup is initiated on the primary instance, you have the option to force a failover. To initiate a failover, select the appropriate option from the "Actions" menu. During a forced failover, connectivity may be interrupted for 3 to 30 seconds. With RDS Proxy integrated, this interruption can be significantly reduced.

During the failover process, note the following:

• The dashboard first continues to display a writer instance.
• In the cluster details, you'll see separate endpoints for write (writer) and read (reader) operations.

The endpoint configuration is crucial as it enables you to direct application traffic correctly; one endpoint always handles writes, while another serves read-only requests regardless of underlying instance changes. Although IAM authentication is not available in multi-AZ clusters, alternative integrations such as EC2, Lambda, or additional proxy endpoints are still supported.

Monitor performance and logs via the dashboard. During a backup, the failover event might not appear immediately in the logs. However, once the backup completes, the dashboard will reflect the new writer instance.

Additional details displayed on the dashboard include:

• Performance Insights status and retention details
• Automated backup configuration
• Maintenance schedules and other pertinent metadata

After the failover, confirm that the writer instance has switched (for example, from instance one to another instance).

Creating a Read Replica

Once the cluster is fully operational and the initial backup process is complete, you can enhance read capacity by creating a read replica. From the "Actions" menu, select "Create read replica" and configure it with similar parameters to the primary instance, including instance size, storage type, and authentication settings. This replication process mirrors credentials and key configurations from the source instance.

Assign a name to your read replica (for example, "RDSPG-reader1"). Since this replication is asynchronous, there may be a brief delay before data written to the writer instance fully propagates to the read replica. You can monitor the replication lag using the dashboard metrics.

After the read replica is operational, your database configuration will include:

• A distinct writer endpoint for write operations
• A designated reader endpoint for read operations

This dual-endpoint setup allows your application to seamlessly route read and write traffic while the cluster handles instance failover and load distribution.

Upon completing these steps, you will have a fully functional multi-AZ PostgreSQL cluster with enhanced read performance and improved fault tolerance.

Thank you for following along with our guide on setting up an AWS RDS multi-AZ cluster deployment with read replicas. Explore the robust capabilities of your new database cluster and consider experimenting with advanced features like RDS Proxy and custom endpoint configurations for even greater performance and resilience.

Happy deploying!