Oracle Licensing on Azure for High Availability and Disaster Recovery

Oracle on Azure: The Authorised Cloud Environment Foundation

Microsoft Azure is an Oracle Authorised Cloud Environment. This means Oracle applies its cloud-specific licence counting rules — specifically, the 2 vCPU to 1 Oracle Processor licence ratio — to Oracle deployments on Azure Virtual Machines. The on-premises Core Factor Table does not apply. A VM with 16 vCPUs requires 8 Oracle Processor licences, regardless of the underlying physical hardware in Azure's data centres.

This is the same ACE framework that applies on AWS EC2. The counting methodology is identical between Azure and AWS for Oracle licensing purposes. The critical differences between Azure and on-premises Oracle licensing arise not in the vCPU counting rule, but in the HA and DR licensing rules — specifically, the way Oracle's 10-day failover rule and standby licensing requirements apply differently in cloud versus on-premises environments.

Oracle Data Guard on Azure: Licensing Fundamentals

Oracle Data Guard is Oracle's native HA and DR technology, providing synchronous or asynchronous log shipping from a primary database to one or more standby databases. Data Guard is included in Oracle Database Enterprise Edition at no additional licence cost — the technology itself does not require a separate licence. However, the standby database instance that Data Guard maintains is a separate Oracle installation that runs on Azure infrastructure and, in most configurations, requires its own Oracle Processor licences.

Physical Standby Database Licensing

A physical standby database receives redo data from the primary and maintains a physically identical copy of the primary database. In a standard configuration (Maximum Performance or Maximum Availability mode without Active Data Guard), the physical standby is in a mounted, not open, state. It cannot serve queries, cannot be used for reporting, and cannot be accessed by users except during a failover event.

On-premises, Oracle has historically provided a provision for an unlicensed passive physical standby in specific shared storage cluster configurations, subject to the 10-day rule (described below). On Azure, this provision does not apply in the same way. The physical standby on an Azure VM is an Oracle installation on a licensed platform, and Oracle requires it to be licensed unless it qualifies for the specific passive standby exception — which has limited applicability in public cloud environments.

Active Data Guard Licensing

Active Data Guard (ADG) is a separately licensed Oracle Database option that allows a physical standby to be opened read-only while continuing to receive redo from the primary. ADG enables reporting workloads, query offloading, and block-change tracking on the standby without interrupting its role as a failover target. ADG is widely used in Azure deployments because it effectively doubles the available compute for Oracle workloads at the cost of an additional ADG option licence.

If you enable Active Data Guard on a standby instance — including enabling it for testing purposes — both the primary and standby environments require an ADG licence. ADG licensing is per Processor on both the primary and standby. For an Azure deployment with a primary VM of 16 vCPUs (8 Processor licences) and a standby VM of 16 vCPUs (8 Processor licences), ADG requires 16 ADG Processor licences in total — 8 for primary and 8 for standby.

ADG has a related feature called Far Sync, which provides a mechanism for zero data loss protection without the full overhead of synchronous redo shipping to a distant standby. Far Sync requires ADG licences on both the primary and standby environments. Enabling Far Sync without holding ADG licences for both sides is a common Oracle audit finding in Azure HA deployments.

The 10-Day Rule: What It Is and Why It Doesn't Apply on Azure

Oracle's 10-day rule is a provision in Oracle's failover licensing policy that allows customers running Oracle in certain on-premises configurations to maintain an unlicensed standby node for up to 10 separate 24-hour periods per calendar year. During each 24-hour window, the standby node may become the primary (due to failover) and run Oracle actively without requiring a Processor licence for that node. This provision is intended to accommodate brief failover events during maintenance, hardware failures, or testing without requiring full licence coverage of the standby.

The critical restriction: Oracle's 10-day rule applies specifically to on-premises configurations using shared storage clusters where the failover technology meets Oracle's specific policy requirements. Oracle explicitly excludes public cloud environments — including Azure, AWS, and GCP — from the 10-day rule. On Azure, the 10-day failover provision does not apply to standby instances.

The practical implication: any Oracle standby instance deployed on Azure Virtual Machines that could become a primary database — whether through Data Guard failover, Azure Site Recovery, or any other mechanism — must be fully licensed with the same Oracle Processor licence count as the primary instance. There is no 10-day exception to lean on.

Organisations that designed their Azure Oracle DR architectures based on on-premises DR policy assumptions — believing the standby does not need to be licensed because it is "only for DR" — are typically non-compliant and face significant retroactive licence claims when Oracle audits their Azure deployments.

Azure HA Architectures and Their Oracle Licensing Implications

Azure offers several HA and DR patterns for Oracle Database workloads, each with distinct Oracle licensing implications.

Availability Sets and Availability Zones

Azure Availability Sets distribute VMs across fault domains and update domains within a single data centre. Azure Availability Zones deploy VMs across physically separate data centres within an Azure region. For Oracle licensing purposes, each VM in an availability set or availability zone configuration that runs Oracle software requires the appropriate Processor licence based on its vCPU count. The HA architecture itself does not create additional licence obligations — the obligation is per VM running Oracle, regardless of how those VMs are distributed across fault or update domains.

Oracle Data Guard in a Two-VM Configuration

The most common Oracle HA deployment on Azure uses two VMs — one primary, one standby — with Data Guard providing log shipping between them. This configuration requires Oracle Processor licences for both the primary and standby VMs, calculated on the vCPU count of each VM at the 2:1 ratio. If both VMs have the same vCPU count, the total licence requirement is double what the primary alone would require.

If the standby VM is deployed in passive mode (physical standby, not open, no ADG), it still requires Oracle Processor licences in the Azure public cloud context. The licence requirement exists from the moment Oracle Database software is installed on the standby VM and the Data Guard configuration is established — not from the moment of actual failover.

Azure Site Recovery for Oracle DR

Azure Site Recovery (ASR) replicates Azure VMs to a secondary region for disaster recovery. For Oracle workloads protected by ASR, Oracle requires that the replicated VMs in the secondary region be licensed if Oracle software is installed on them and they are capable of running Oracle workloads. ASR failover VMs are powered off in the secondary region until a failover event occurs, but Oracle's licensing position is that installation equals use for licence purposes — the secondary region VMs require licences regardless of powered-on status.

Organisations using ASR for Oracle DR should review each secondary region Oracle VM's vCPU configuration and confirm licence coverage for the full set of secondary VMs. The licence requirement applies to the secondary region VMs regardless of whether a failover has ever occurred.

Cross-Region Data Guard

Some organisations deploy Oracle Data Guard with the primary in one Azure region and the standby in a different Azure region for geographic redundancy. From Oracle's licence perspective, this is a straightforward two-database deployment requiring full Processor licence coverage for both the primary and standby, regardless of which Azure region they are in. Cross-region does not change the standby licence obligation.

Cost-Optimised Azure Oracle HA Architectures

The full-licence requirement for Azure standby instances significantly increases the Oracle licence cost of HA deployments compared to what many organisations budget. Several architectural approaches can reduce the incremental licence cost of Azure Oracle HA and DR while maintaining acceptable availability levels.

Size Standby VMs Smaller Than Primary

For DR configurations where the standby is only needed to handle reduced-capacity operations during a failover event, deploying the standby VM with fewer vCPUs than the primary reduces the standby licence requirement. A primary VM with 32 vCPUs (16 Processor licences) with a standby VM with 8 vCPUs (4 Processor licences) reduces the standby licence cost by 75 percent compared to a symmetrical configuration. The trade-off is that post-failover capacity is lower — an acceptable trade-off for many DR scenarios where the failover period is expected to be brief.

Deploy Standby in Oracle Cloud at Customer or OCI

Oracle's Cloud at Customer and OCI BYOL programmes apply the same 2:1 vCPU counting rule as Azure, but OCI may offer favourable support pricing or ULA scope extensions for customers who move DR workloads from Azure to OCI. For organisations with large perpetual Oracle licence estates, using OCI as the DR target rather than a secondary Azure region can be commercially advantageous — particularly if Oracle includes OCI DR deployments in a ULA or PULA scope at reduced incremental cost.

Use Oracle SE2 for DR Where EE Features Are Not Required During Failover

In some deployments, the DR standby only needs to support basic read/write operations during a failover period, without requiring EE-only features such as RAC, Partitioning, or Advanced Security. In these cases, maintaining a DR environment on SE2 licensing (at approximately 25 percent of EE licence cost) is a significant saving — provided the primary EE instance can failover to SE2 licensing for the limited features used during the DR period. This approach requires careful application validation to confirm the application functions correctly without EE-only features.

Oracle Azure Licensing: Key Compliance Checklist

All Azure VMs running Oracle Database require Processor licences based on vCPU count at 2:1 ratio. This includes primary, standby, test, and dev instances.

The 10-day failover rule does not apply in Azure. All standby instances must be licensed regardless of whether failover has occurred.

Active Data Guard requires option licences on both primary and standby. Enabling ADG without option licences for both sides is a common audit finding.

Far Sync triggers ADG licence requirements. If Far Sync is configured, ADG licences are required on both the primary and standby environments.

ASR replicated VMs require licences even when powered off. Secondary region Oracle VMs protected by Azure Site Recovery require Processor licences from the time Oracle is installed, not from the time of failover.

Support fees on Azure BYOL escalate at 8% per year. Moving Oracle workloads to Azure does not freeze or reset the Oracle SULS escalation. The compounding support cost applies to the full perpetual licence base regardless of deployment platform.

Organisations planning Oracle HA and DR architectures on Azure should conduct an independent Oracle licence review before finalising their architecture design. The licence cost of a two-VM Data Guard configuration, a multi-AZ deployment, or a cross-region DR setup is a material input to the total cost of ownership calculation that should be known before infrastructure commitments are made.