Multi-AZ deployment for Amazon RDS Custom for Oracle

High availability and disaster recovery remain important concerns for organizations. Amazon RDS Custom for Oracle addresses these concerns through its Multi-AZ deployment feature, providing a robust solution for maintaining database availability and durability.

In this post, we explore the benefits and features of Multi-AZ for RDS Custom for Oracle and how it helps improve the resilience of your database.

Solution overview

RDS Custom for Oracle offers a unique blend of managed database services and customization flexibility, ideal for legacy, custom, and packaged applications that require access to the underlying operating system (OS) and database environment. This solution combines the automation benefits of Amazon RDS with the control and flexibility of Amazon Elastic Compute Cloud (Amazon EC2), so organizations can access and customize both the Oracle database and OS, install custom patches and packages, configure specific settings, and maintain legacy systems that require OS-level access. With RDS Custom, you can benefit from granular control while still using Amazon RDS automation for routine tasks, striking a balance for applications with specific OS or DB configuration needs, packaged software with OS dependencies, and legacy systems requiring specialized setups. Under the shared responsibility model, AWS manages the infrastructure, hardware, and basic RDS operations (like backups and high availability), while you take responsibility for the database customization, OS access and configuration, additional software installation, and ensuring your customizations don’t interfere with RDS automation through the automation boundary perimeter.

Multi-AZ deployment in RDS Custom for Oracle operates by maintaining a synchronized standby replica in a different Availability Zone. This setup makes sure your database remains accessible even if the primary instance or its Availability Zone experiences issues, by using synchronous storage replication that provides a Recovery Point Objective (RPO) of zero. In the event of primary instance failure, the standby will take control and fail over. The standby is not available for reads; it’s primarily for availability to quickly recover in the event of a primary failure. Multi-AZ deployment is available for both Standard Edition 2 and Enterprise Edition.

Enabling Multi-AZ for your RDS Custom for Oracle instance is a straightforward process, but requires careful consideration. You must use a custom engine version (CEV) created after June 30, 2025, with the latest service-provided AMI. The process can be initiated through the AWS Management Console or using the AWS Command Line Interface (AWS CLI) to modify your DB instance. In the following sections, we demonstrate how to set up Multi-AZ with a new instance and with a currently running instance.

Prerequisites

Before you create your RDS Custom for Oracle database and deploy your CEV and DB instances, complete the following prerequisite steps:

Create your Identity and Access Management (IAM) roles and policies, including AWSRDSCustomInstanceRole and AWSRDSCustomServiceRole. These roles provide the necessary permissions for RDS Custom to interact with other AWS services.
Set up Amazon Simple Storage Service (Amazon S3) permissions to access your installation media to build your CEV.
Set up your network infrastructure. Your environment needs a virtual private cloud (VPC) with private subnets and appropriately configured security groups.
Create VPC endpoints for following AWS services, including Amazon S3, Amazon EC2, AWS Secrets Manager, Amazon CloudWatch Logs, AWS Systems Manager, and Amazon EventBridge.

These steps will set up secure and efficient communication between the components of your RDS Custom environment. For more details, see Setting up your environment for Amazon RDS Custom for Oracle.

Configure prerequisites to modify a Single-AZ to a Multi-AZ deployment manually

Converting your Single-AZ setup to Multi-AZ has some additional prerequisites: an Amazon Simple Queue Service (Amazon SQS) endpoint, changes to IAM permissions for your role, and port 1120 added for inbound and outbound on your security group. Complete the following additional steps for the Multi-AZ capabilities:

On the Amazon VPC console, choose Endpoints in the navigation pane.
Choose Create endpoint.
For Service Category, choose AWS services.
For Services, search for and choose Amazon SQS.
For VPC, choose the VPC where your RDS Custom for Oracle DB instance is deployed.
For Subnets, choose the subnets where your RDS Custom for Oracle DB instance is deployed.
For Security Groups, choose the security group where your RDS Custom for Oracle DB instance is deployed.
For Policy, choose Custom.

In your custom policy, replace the AWS partition, Region, accountId, and IAM-Instance-role with your own values:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Condition": {
                "StringLike": {
                    "aws:ResourceTag/AWSRDSCustom": "custom-oracle"
                }
            },
            "Action": [
                "SQS:SendMessage",
                "SQS:ReceiveMessage",
                "SQS:DeleteMessage",
                "SQS:GetQueueUrl"
            ],
            "Resource": "arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:do-not-delete-rds-custom-*",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/{IAM-Instance-role}"
            }
        }
    ]
}

Update the instance profile with permission to access Amazon SQS. Replace the AWS partition, Region, and accountId with your own values:

{
    "Sid": "13",
    "Effect": "Allow",
    "Action": [
        "SQS:SendMessage",
        "SQS:ReceiveMessage",
        "SQS:DeleteMessage",
        "SQS:GetQueueUrl"
    ],
    "Resource": [
        {
            "Fn::Sub": "arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:do-not-delete-rds-custom-*"
        }
    ],
    "Condition": {
        "StringLike": {
            "aws:ResourceTag/AWSRDSCustom": "custom-oracle"
        }
    }
}

Update the RDS security group inbound and outbound rules to allow port 1120:
1. In Security groups, choose the group where your RDS Custom for Oracle DB instance is deployed.
2. For Inbound rules, create a custom TCP rule to allow port 1120 from the source group.
3. For Outbound rules, create a custom TCP rule to allow port 1120 to the destination group.

Create a new DB instance with Multi-AZ enabled

In this section, we highlight the key steps to enable Multi-AZ in a new DB database.

Create a new CEV

To enable Multi-AZ for RDS Custom for Oracle, you must first create a new CEV with this capability. Then you can deploy RDS Custom for Oracle instances with the Multi-AZ option enabled. For instructions, refer to Creating a CEV.

Create a new instance

The key step when creating a new instance to enable Multi-AZ is to select Create a standby instance to enable Multi-AZ deployment for high availability.

You can alternatively create the instance using the AWS API:

aws rds create-db-instance \
--db-instance-identifier <instance-identifiier> \
--db-instance-class <instance-class> \
--backup-retention-period <retention-period> \
--engine custom-oracle-se2  \
--master-username <master-username>\
--multi-az \
--master-user-password <master-password>\
--port <port> --license-model byol \
--allocated-storage <allocated-storage> \
--kms-key-id <kms-alias> \
--engine-version 1<engine-version>\
--region <region> \
--publicly-accessible \
--no-auto-minor-version-upgrade \
--custom-iam-instance-profile AWSRDSCustomInstanceProfile-eu-west-1

Use an existing DB instance

If you already have an RDS Custom for Oracle instance created before June 30th, 2025, it is not supported for converting Single-AZ instances to Multi-AZ deployments. DB instances created after June 30, 2025, can be converted from Single-AZ to Multi-AZ. To implement Multi-AZ, you must create a new DB instance following the steps in the previous section, then migrate your data using one of the available migration options. This process requires a separate migration strategy rather than an in-place conversion.

Migrate your database to a new RDS Custom for Oracle database with Multi-AZ configuration using the following methods:

Choose the method that best suits your availability requirements and database size.

Disable Multi-AZ

To disable Multi-AZ, complete the following steps:

On the Amazon RDS console, choose Databases in the navigation pane.
Choose your database.
Under Availability & durability, select Do not create a standby instance.
Choose Continue.
Under Schedule modifications, you can choose to make the change immediately by selecting Apply immediately or schedule it by selecting Apply during the next scheduled maintenance window.
Choose Modify DB instance.

You can alternatively disable Multi-AZ for the instance using the AWS API:

aws rds modify-db-instance —db-instance-identifier <instance-identifier> \
--no-multi-az \
--apply-immediately \
--region <region>

Multi-AZ in action

After Multi-AZ is enabled, your database operates with enhanced reliability through several key mechanisms. The primary instance maintains synchronous replication with the standby instance. This synchronization happens in real time, with every transaction being committed to both instances before being acknowledged to the application.

Automatic failover is an important feature of Multi-AZ deployments. When AWS detects issues with the primary instance or its Availability Zone, it automatically initiates a failover to the standby instance. This process typically completes within 60-120 seconds during which the DNS records are updated to point to the new primary instance.

Impact on key operations

In this section, we explore how Multi-AZ deployments affect critical database operations and maintenance tasks.

Instance scaling

When scaling your RDS Custom for Oracle instance, the system employs a two-stage failover process:

Scale the secondary instance.
Initial failover to the scaled secondary instance.
Scale the old primary instance.
Perform a final failover back to the original (now scaled) instance.

This mechanism preserves critical customizations so that specialized configurations within the root or binary volumes of your original instance remain intact.

OS patching process through CEV upgrade

When an OS patch needs to be applied through a CEV with a new AMI, a similar approach is implemented. The patching process first targets the secondary instance. After it’s successful, a controlled failover shifts your workload to this newly patched instance, maintaining continuous database operations. The original primary instance then receives the same update, followed by a final failover that returns operations to their original configuration. This methodical approach makes sure your custom configurations remain intact while keeping your OS current and secure.

Database patching through CEV upgrade

In a Multi-AZ configuration, the primary and secondary instances receive database patches simultaneously, and no failover is required during this process. This approach differs from OS patching, because the parallel nature of database patching alleviates the need for instance role switching. This approach provides version consistency across your database infrastructure, avoiding potential discrepancies between instances.

Pausing automation

The Multi-AZ configuration’s automated failover capabilities require special attention when using the pause automation feature in RDS Custom for Oracle. When you pause automation to perform advanced customizations or troubleshooting, this action temporarily suspends the automatic failover mechanism. If the primary instance encounters issues during this period, the system will not automatically transition your workload to the secondary instance, even though it’s available. This design choice helps prevent unexpected behavior while you’re performing sensitive operations that require precise control over your database environment.

Storage scaling

The Multi-AZ configuration for RDS Custom for Oracle introduces a streamlined approach to storage management through synchronized scaling operations. When you increase the storage capacity of your primary instance, the same modification is automatically applied to the secondary instance, providing storage parity between your Multi-AZ pairs. This synchronized scaling alleviates the need for separate storage management operations and helps maintain consistent performance and behavior across both instances.

Best practices and recommendations

To maximize the benefits of Multi-AZ deployment, consider the following best practices:

Regularly validate that both primary and secondary instances maintain identical configurations
Test failover scenarios to maintain smooth transitions
Limit the duration of paused automation to the minimum time necessary
Monitor both instances closely during the pause period
Maintain regular backups despite having a standby instance, for an additional layer of protection

Limitations

Multi-AZ support in RDS Custom for Oracle has certain differences and limitations compared to traditional Amazon RDS for Oracle:

Read replica support is not offered with the Multi-AZ deployment in RDS Custom for Oracle.
Scale compute will observe two failovers to preserve OS configuration.
OS patching will also observe two failovers to preserve the OS config changes.
We recommend using Systems Manager to make OS config changes and automate applying the OS config between primary and secondary. For more information, see Automate tasks in Amazon RDS Custom for Oracle using AWS Systems Manager documents.
Backups in RDS Custom for Oracle with Multi-AZ will be performed on the primary to preserve the OS config because these backups consist of AMI, database binaries, and data volume.
Flash recovery area is not supported.
Make sure your IAM instance profile has the required permissions. We recommend using AWS CloudFormation to create your IAM instance profile.

Clean up

When you are done using this solution, clean up the resources you created to avoid ongoing charges if you do not need the resources.

Conclusion

Multi-AZ deployment for RDS Custom for Oracle represents a significant advancement in database high availability and disaster recovery. Although it requires careful planning and additional investment, the benefits of increased availability and data durability make it an invaluable feature for organizations running mission-critical databases. By understanding its functionality and following best practices, organizations can enhance their database infrastructure’s resilience and reliability.

Regular review and updates of your Multi-AZ configuration can make sure it continues to meet your evolving business requirements and performance needs. As with any critical infrastructure component, staying informed about new features and best practices is essential for maintaining optimal database operations. Try out Multi-AZ with RDS Custom for Oracle, and share your feedback in the comments.

AWS Database Blog