Multi-AZ RAC: the missing part in Oracle MAA Reference Architectures

Oracle Maximum Availability Architecture (MAA) defines architectural blueprints with several levels (Bronze, Silver, Gold, Platinum) that have certain capabilities for minimizing downtime, RTO, and RPO in various scenarios, such as planned maintenance, unexpected failures, and disasters. However, the current set of MAA blueprints is lacking the Multi-AZ clustering architecture. This is not surprising. The concept of Availability Zones did not exist in the traditional on-premises architectures, while Oracle Cloud (and by extension the Oracle Database @ AWS/Azure/Google Cloud offerings) do not have the capability for Multi-AZ clustering. On the other hand, competing solutions, such as Amazon Aurora, leverage Multi-AZ database clustering to its fullest (even though they lack the unique active-active clustering capabilities that Oracle RAC boasts).

In this article, we will compare the Multi-AZ clustering architecture to other architectures and will discuss its unique benefits specifically for Oracle databases on AWS, Azure, and Google Clouds.

Cloud Availability Zones vs. Regions

As a reminder, availability zones (AZs) in a public cloud region are discrete data centers housed in separate facilities, each with redundant power, networking, and connectivity. Because each AZ is physically separate, local disasters like fires or flooding would affect only one AZ.

One important feature of availability zones is the low network latency between AZs in the same region. In AWS, Azure, and Google Cloud, the inter-AZ latency typically ranges from 0.2 to 2 ms (milliseconds) and is usually less than 1 millisecond, depending on the cloud region and the specific pair of AZs. Such low latency enables synchronous data replication or mirroring between AZs, even with high-performance databases. Synchronous data replication or mirroring is critical for having Zero RPO when one of the AZs experiences an outage.

A cloud region is a collection (typically 3+) of availability zones located in proximity to each other within the same geography or country. Distance between regions is typically large enough that synchronous replication between regions is not practical due to prohibitive latencies.

Oracle RAC: The Baseline for Database HA

Oracle RAC is an integral part of Silver, Gold, and Platinum levels in Oracle MAA reference architectures. Oracle RAC provides a unique active-active database HA capability with zero-RPO (using shared storage), near-zero RTO for database node failures, and zero-downtime maintenance. In this article, we consider only those architectures that utilize Oracle RAC.

Single-AZ vs. Multi-AZ Clustering

A Single-AZ RAC cluster in the cloud is similar to a RAC cluster in a traditional data center. It provides protection against failures of servers, network, and storage components with zero RPO and near-zero (seconds) RTO. Importantly, it also provides zero downtime maintenance capability. However, a Single-AZ RAC by itself does not protect against failures of the entire data center (or AZ in the context of a public cloud). While such failures are relatively rare, they do happen for various reasons (e.g. cooling or power failures or network misconfiguration) and may last for hours. To protect against such AZ failures, Oracle MAA reference architectures offer placing Standby clusters either in a different AZ and/or in a different region.

In contrast, a Multi-AZ RAC cluster protects against an AZ failure by spreading its nodes across AZs instead of adding Standby clusters. Importantly, in case of an AZ outage there is still zero RPO and near-zero RTO. Essentially, AZ outages are handled the same way as failures of individual database nodes or disks. There is no need for a database failover since the database nodes across the AZs run in active-active mode.

Single-Region vs. Multi-Region Architectures

While this article focuses on Single-AZ vs. Multi-AZ clustering, we also need to discuss how these two options work within Single-Region or Multi-Region architectures because Oracle MAA Reference Architectures suggest cross-region replication as a possible way to mitigate AZ failures.

Regional outages are very rare thanks to failure isolation between AZs and the HA mechanisms used for regional services. This allows many organizations to use a single region for their entire application stack and rely on data backup in a different region (or even a different cloud) to mitigate the low risk of a major disaster destroying the entire region.

However, those organizations that cannot accept the risk of a prolonged downtime in case of a regional outage must implement a Multi-Region architecture. The primary mechanisms for implementing Oracle Database in a Multi-Region configuration are (Active) Data Guard physical replication or Oracle GoldenGate logical replication.

Single-Region Architecture Options

A single-region architecture may be used in cases where the very low risk of a regional outage is acceptable. The main options for implementing MAA within a single region are summarized in the following table and discussed further in this section:

	Single-AZ RAC	Two Single-AZ RAC clusters in different AZs	Multi-AZ RAC *
Planned maintenance of database nodes	Zero downtime	Zero downtime	Zero downtime
Failures of individual storage volumes, database nodes, or database instances	RPO: zero RTO: seconds	RPO: zero RTO: seconds	RPO: zero RTO: seconds
AZ outage: failure of an entire data center or multiple resources, or a local disaster	No protection	RPO: zero RTO: seconds to minutes	RPO: zero RTO: seconds
Regional outage: failure of a critical regional service or a major disaster affecting more than one AZ	No protection	No protection	No protection
Complexity	Low	Medium	Low
Cost of cloud resources	Low	Medium	Low

* As of July 2025, Multi-AZ RAC capability is not available in Oracle Cloud. It is available in AWS, Azure, and Google Cloud with FlashGrid Cluster software.

Single-AZ RAC cluster

This is the simplest architecture for achieving basic database HA. However, it is not recommended for mission-critical databases because it provides no protection against outages at the AZ or region level. This option qualifies only for the Silver level of Oracle MAA.

Two Single-AZ RAC clusters in different AZs

This option protects against AZ outages by implementing Data Guard replication between AZs. Thanks to the low latency between AZs, the replication can be synchronous, thus ensuring zero RPO in case of an AZ outage. For shorter RTO (seconds to minutes), implementing Data Guard Fast-Start Failover (FSFO) is required. An FSFO observer instance must be placed in a separate AZ. While lacking a comprehensive cross-regional DR capability, this option may be suitable for many mission-critical applications where the relatively low risk of a regional outage is acceptable.

This option is suggested by Oracle as a MAA Gold DR Architecture with Oracle Database@Azure.

Multi-AZ RAC cluster

This architecture protects against AZ outages in addition to the basic database HA. Importantly, in case of an AZ outage there is zero RPO and near-zero RTO. Essentially, AZ outages are handled the same way as failures of individual database nodes or disks.

There is no need for a “failover” since the database nodes across the AZs work in active-active mode. While lacking a comprehensive cross-regional DR capability, this option may be suitable for many mission-critical applications where the relatively low risk of a regional outage is acceptable.

Compared to Two Single-AZ RAC clusters in different AZs, this architecture requires half of the resources (compute + storage) and avoids the extra complexity of managing two RAC clusters plus Data Guard FSFO.

Multi-Region Architecture Options

A multi-region architecture must be used in cases where a prolonged downtime in case of a regional outage is not acceptable. The main options for implementing MAA across two regions are summarized in the following table and discussed further in this section:

	Single-AZ RACs, cross-region replication	Single-AZ RACs, cross-region Far Sync replication	Multi-AZ RACs, cross-region replication *	Single-AZ RACs, cross-AZ and cross-region replication
Planned maintenance of database nodes	Zero downtime	Zero downtime	Zero downtime	Zero downtime
Failures of individual storage volumes, database nodes, or database instances	RPO: zero RTO: seconds	RPO: zero RTO: seconds	RPO: zero RTO: seconds	RPO: zero RTO: seconds
AZ outage: failure of an entire data center or multiple resources, or a local disaster	RPO: non-zero RTO: minutes to hours **	RPO: non-zero RTO: minutes to hours **	RPO: zero RTO: seconds	RPO: zero RTO: seconds to minutes
Regional outage: failure of a critical regional service or a major disaster affecting more than one AZ	RPO: non-zero RTO: minutes to hours **	RPO: zero*** RTO: minutes to hours **	RPO: zero*** RTO: minutes to hours **	RPO: zero*** RTO: minutes to hours **
Complexity	Medium	High	Medium	High
Cost of cloud resources	Medium	Medium	Medium	High

* As of July 2025, Multi-AZ RAC capability is not available in Oracle Cloud. It is available in AWS, Azure, and Google Cloud with FlashGrid Cluster software.

** Implementing Fast-Start Failover (FSFO) for automated cross-regional failover has the potential to reduce the failover time down to minutes. However, due to the complexities of detecting a regional failure and failing over the entire application stack, implementing FSFO for automatic cross-regional failover may not be practical in many cases. Manual failover requires human involvement and coordination, hence increasing the RTO to hours.

*** Because cross-region replication is asynchronous with some lag, additional actions are required to maintain zero RPO (no data loss) in case of a regional outage:

• A regional disaster that has potential for disrupting more than one AZ:
  Switchover to the secondary region must be performed before more than one AZ fails. The probability of simultaneous failure of more than one AZ in a region is very low even in the case of a regional disaster.
  
• Failure of a regional cloud service that is critical of the application stack (e.g. object store or IAM):
  Database switchover to the secondary region must be performed. Database operation and replication do not depend on regional cloud services and should be able to perform switchover with no data loss.
  
• A region-wide network failure that disrupts the application stack and prevents database replication to the secondary region:
  A decision must be made about either failing over with some data loss or having application outage until the network operation is restored.

Single-AZ RACs, cross-region replication

This option protects against AZ and regional outages by implementing Data Guard replication between regions. The replication must be asynchronous because of the high latency between regions. Due to the lag in the replication, an abrupt failure of the entire AZ in the primary region will create a difficult choice between no failover (and potentially prolonged outage) and failover with some data loss.

This option is suggested by Oracle as a MAA Gold DR Architecture with Oracle Database@Azure and Oracle Database@Google Cloud. However, we do not recommend this architecture because of the substantial risks in case of an abrupt failure of an entire AZ.

Single-AZ RACs, cross-region Far Sync replication

This architecture protects against AZ and regional outages by implementing Active Data Guard for Far Sync replication between regions. It protects against data loss in case of an abrupt AZ failure by having synchronous replication to a Far Sync instance in a different AZ of the same region. The Far Sync instances must have HA configuration, preferably spanning two AZs for better protection (the diagram shows one AZ for Far Sync instances).

Compared to the Multi-AZ RAC, this option adds significant complexity of having to manage the Far Sync instances and replication to/from them.

Multi-AZ RACs, cross-region replication

This option protects against AZ outages by spreading database nodes and storage between AZs. Additionally, it protects against regional outages by implementing (Active) Data Guard replication between regions. The replication between regions must be asynchronous, thus creating some replication lag. However, the risk of data loss in case of a regional outage is mitigated by having zero-RPO protection between AZs within each region.

Single-AZ RACs, cross-AZ and cross-region replication

This option protects against AZ outages by implementing synchronous Data Guard replication between AZs. Additionally, it protects against regional outages by implementing replication between regions. The replication between regions must be asynchronous, thus creating some replication lag. However, the risk of data loss in case of a regional outage is mitigated by having zero-RPO protection between AZs within each region.

Further in this section we discuss the three main sub-options for implementing such architecture.

2 + 1 Single-AZ RACs with Data Guard (asymmetrical)

This sub-option has only one RAC cluster in the secondary region, which allows saving some costs. The main shortcoming of this architecture is that it is asymmetrical. The secondary region must be used for DR only. This architecture should not be used if role switching between regions is expected or desirable in scenarios other than DR. This architecture is suggested by Oracle as MAA Gold Multiple Standby Databases.

2 + 2 Single-AZ RACs with Data Guard (symmetrical)

This sub-option has two RAC clusters in each region, thus making it symmetrical and suitable for routine role switching between regions. The main shortcomings of this architecture are the higher complexity (more clusters, two levels of replication, FSFO) and the higher cost of the required cloud resources.

2 + 2 Single-AZ RACs with GoldenGate

This sub-option implements Oracle GoldenGate logical replication between the regions that allows eliminating downtime for migrations, application upgrades, and database upgrades. The replication can be uni-directional or bi-directional. While having higher costs and the highest complexity, this architecture offers some unique benefits for the most critical databases. This architecture is suggested by Oracle as MAA Platinum.

Summary

For Oracle Database in the cloud in both single- and multi-region configurations, Multi-AZ RAC enables simpler and more cost-efficient MAA architectures than the alternatives based on Single-AZ RAC. Thanks to the low latency between AZs, Multi-AZ RAC enables zero RPO in case of an AZ failure without the extra complexity and cost of additional local physical Standby clusters and FSFO.

Multi-AZ RAC in combination with cross-region (Active) Data Guard replication meets the requirements of the Gold level of Oracle MAA Reference Architectures for mission-critical databases. It complements Oracle MAA Gold architectures based on Single-AZ RAC clusters by providing the commonly required fault tolerance while avoiding excessive complexity and costs.

FlashGrid Cluster enables Oracle RAC on AWS, Azure, and Google Clouds in both Single-AZ and Multi-AZ configurations.

Note: To keep the architectural diagrams simple, we are not showing locations of database backup storage, which is nevertheless a critical part of MAA.