Cloud-based DR offers enterprises flexibility and resilience, but Oracle's licensing rules follow your software into every environment. This guide explains exactly how Oracle licences DR in AWS, Azure, OCI, and hybrid architectures, and how to avoid the compliance traps that catch most enterprises.
This article is part of the Oracle Licensing Guide for CIOs & Procurement Teams pillar series. Related DR guides include Negotiating Oracle DR Licence Agreements, Oracle Failover & DR Licensing, and The Oracle 10-Day Rule Explained.
Oracle's licensing position is absolute: any instance of Oracle Database software that is installed or running must be licensed, regardless of whether it serves production traffic, acts as a standby, or exists solely for disaster recovery. This rule does not change when you move to the cloud. A DR database in AWS requires the same licensing compliance as a production database in your data centre.
The challenge is that cloud environments make it trivially easy to provision Oracle infrastructure, and equally easy to create compliance exposure. A developer spinning up an Oracle AMI for testing, an auto-scaling group that launches additional instances during peak load, or a warm standby continuously applying Data Guard logs all represent licensable deployments. Unlike on-premises environments where physical servers are visible and inventoried, cloud instances can proliferate without centralised visibility.
| DR Model | Description | Licensing Requirement |
|---|---|---|
| Cold Standby | Oracle not installed or VM powered off. Generally no licence required until activated. | Safest approach for cost-conscious DR architectures. No licence required while dormant. |
| Warm Standby | Oracle running and receiving replication (e.g., Data Guard). Continuously active. | Requires full licensing, identical to production. No DR exemption exists. |
| On-Demand DR | No standing instance. Machine images or IaC templates deployed only during disaster. | Avoids licensing until launch, but increases RTO. |
| 10-Day Rule | Allows up to 10 days of unlicensed failover for spare servers in the same on-premises cluster. | Does not apply to cloud DR sites. On-prem clustered environments only. |
The 10-day failover rule is the most misunderstood provision in Oracle licensing. It applies exclusively to a passive spare server within the same clustered on-premises environment as the primary. A cloud DR site, in a different data centre, region, or cloud provider, is a separate environment and does not qualify. Any Oracle instance continuously running in the cloud for DR must be fully licensed from day one.
This means enterprises must make a deliberate architectural choice: accept the cost of fully licensing a warm cloud standby, or design a cold or on-demand DR approach that avoids having Oracle software actively deployed until a disaster strikes. Each approach carries different trade-offs between recovery time, licence cost, and operational complexity.
OCI provides the most licence-friendly environment for Oracle DR, offering mechanisms that directly reduce or eliminate standby licensing costs. This is not accidental. Oracle designed OCI to incentivise customers to run their Oracle workloads on Oracle's own cloud.
OCI Support Rewards double benefit. OCI's Support Rewards programme provides an additional financial incentive. For every dollar spent on OCI consumption, Oracle credits a percentage against your on-premises support renewal, effectively reducing support costs for your primary database. Using OCI for DR therefore delivers a double benefit: lower DR licensing costs and a reduction in your annual support bill.
Mini case study: Global retailer achieves OCI DR at 5% of traditional standby cost. A retailer needed Oracle Database Enterprise Edition DR with quarterly failover testing. Traditional approach: purchase matching Processor licences for the standby site, approximately $190,000 in licences plus $42,000/year in support. Solution: deployed DR on OCI using the licence-included Database Cloud Service. The standby VM was kept stopped between quarterly tests, each lasting approximately 8 hours. Result: total OCI DR cost was under $400/year (32 hours of OCPU consumption). Support Rewards from OCI usage reduced on-premises support by an additional $8,000 annually. Total DR cost: less than 5% of the traditional approach.
AWS and Azure are Authorised Cloud Environments under Oracle's licensing policy, meaning you can deploy Oracle software using BYOL. However, the licensing rules differ significantly from OCI, and several cloud-specific traps await unprepared enterprises.
| Cloud Instance | vCPUs | Oracle DB EE Licences | List Cost (Licences Only) |
|---|---|---|---|
| AWS m5.xlarge | 4 | 2 Processor | $95,000 |
| AWS m5.2xlarge | 8 | 4 Processor | $190,000 |
| Azure E4s_v5 | 4 | 2 Processor | $95,000 |
| Azure E8s_v5 | 8 | 4 Processor | $190,000 |
Oracle DB EE list price: $47,500/Processor. 2 vCPUs = 1 licence. On-premises core factors do NOT apply in public clouds.
Critical rules for AWS and Azure DR deployments.
No 10-day rule: A cloud DR site is a separate environment. Oracle's failover grace period does not apply. Any running Oracle instance must be licensed from the moment it starts.
All vCPUs count: You must licence every vCPU allocated to the VM, not just the vCPUs Oracle "uses." If Oracle runs on an 8-vCPU instance but typically consumes only 2 vCPUs, you still need 4 Processor licences.
No simultaneous use: A single BYOL licence cannot cover both your on-premises production server and a cloud DR instance simultaneously. If both are running, each requires its own licence allocation.
AMI and image traps: Storing Oracle binaries on a pre-built AMI or Azure VM image does not require licensing, provided the image is not instantiated as a running instance. However, if you restore an Oracle backup to an EBS volume with Oracle binaries and mount it as a standby, Oracle may treat that as an "installed" deployment.
The safest licensing approach for Oracle DR on AWS or Azure is to not have Oracle software installed on any running instance during normal operations. Maintain machine images and infrastructure-as-code templates that can deploy Oracle within your RTO window. This avoids any licensing obligation until a disaster actually occurs, at which point you either reassign existing licences from the failed primary or activate pay-as-you-go OCI as an interim measure.
Oracle testing allowance. Oracle permits backup restoration testing on an unlicensed server for up to 2 days per test, up to 4 times per year. This allowance applies to cloud instances as well. Enterprises should script their DR tests to launch the Oracle instance at the start of the test window and terminate it immediately after, with automated safeguards to prevent instances from being accidentally left running. CloudFormation templates, Terraform scripts, or Azure ARM templates with built-in TTL (time-to-live) configurations are essential for this approach.
Enterprise DR architectures increasingly span multiple environments: on-premises production with cloud DR, OCI primary with AWS secondary, or multi-region deployments across different cloud providers. Each environment running Oracle requires independent licensing, and there is no cross-cloud licence sharing or multi-cloud discount.
On-Premises to Cloud DR. The most common pattern. On-premises production uses core factor counting; cloud DR uses the 2 vCPU = 1 licence rule. Both sides must be independently licensed. When a disaster triggers failover to the cloud, the on-premises licences are freed (the primary is down) and can conceptually be reassigned to the cloud, but only if the cloud instance's vCPU count matches the licence quantity. Document this reassignment process and ensure it can be executed under pressure.
OCI Primary to AWS/Azure DR. If your primary runs on OCI using licence-included pricing, those licences are part of the cloud subscription and cannot be transferred to AWS or Azure. The DR site requires separately purchased BYOL licences. Consider using BYOL on OCI instead, so you own the licences and can reassign them to AWS DR if needed.
Multi-Cloud DR (OCI + AWS + Azure). Running standby instances across multiple clouds for maximum resilience is architecturally sound but financially punishing. Each active standby requires full licensing. The cost-effective approach: designate one cloud as your warm DR site (fully licensed or pay-as-you-go) and use additional clouds only for cold data backups (dump files, RMAN backups) without any running Oracle instances.
Oracle Data Guard is included with Oracle Database Enterprise Edition at no additional licence cost. A physical standby database receiving and applying redo logs is a standard Data Guard deployment, but the standby server itself still requires full Database Enterprise Edition Processor licensing. Data Guard's inclusion means you do not pay an extra option fee, but you absolutely pay for the base database licence on the standby.
Active Data Guard is a separately licensed option that allows the standby to be opened for read-only queries while still receiving redo. The option licence ($11,500 per Processor at list) must be purchased for the standby server. If your DR architecture uses Active Data Guard to offload reporting queries to the standby, budget for both the base database licence and the Active Data Guard option on the DR site.
Options and packs on DR standbys. Other Oracle options and packs used on the primary must also be licensed on the DR standby if they are installed and enabled. Common examples include Advanced Security (TDE encryption), Advanced Compression, Partitioning, and Diagnostics/Tuning Packs. If TDE is encrypting your production tablespaces and the standby receives encrypted redo, Oracle's position is that Advanced Security is "in use" on the standby and must be licensed there. Failing to licence options on DR systems is a frequent audit finding, and one of the easiest for Oracle LMS to identify, since option usage is recorded in the database's DBA_FEATURE_USAGE_STATISTICS view.
| Risk Level | Audit Finding | Description |
|---|---|---|
| High | Warm standby without licences | Running Data Guard or GoldenGate replication to a cloud instance without dedicated licences for the standby. The most common and most expensive audit finding. |
| High | Misapplying the 10-day rule | Claiming the failover exemption for a cloud DR site. Oracle rejects this categorically. The rule applies only to on-premises clusters. |
| Medium | Unlicensed options on DR | Production uses Advanced Security, Partitioning, or Diagnostics Pack but the DR site was provisioned without those option licences. Oracle auditors check DBA_FEATURE_USAGE_STATISTICS on all instances. |
| Medium | Forgotten test instances | DR test VMs left running after the test window. Oracle permits 2-day testing up to 4 times per year, but instances left running beyond that window require full licensing. |
| Medium | Auto-scaled instances | Instances that temporarily exceed licensed vCPU counts during failover or testing events. |
Oracle's LMS team now routinely requests cloud console access or usage reports from AWS and Azure during audits. This makes it essential to maintain timestamped evidence of when Oracle instances were running and the vCPU allocations at each point. Container or Kubernetes deployments where Oracle runs inside pods without proper hard partitioning also create audit exposure.
Use OCI for DR wherever possible. OCI's licence-included, pay-as-you-go model eliminates the need to purchase perpetual licences for intermittent DR. Keep instances stopped between activations. Billing stops when the instance is powered off.
Design cold standby for AWS/Azure DR. Maintain Oracle backups (RMAN, dump files) in cloud storage without a running Oracle instance. Use infrastructure-as-code to deploy the Oracle environment only during disaster or testing. Script automated termination after each test window to prevent accidental licence exposure.
Right-size DR instances. Use the smallest VM type that meets your recovery time objective. A 4-vCPU DR instance requires 2 Processor licences; an 8-vCPU instance requires 4. Plan to resize upward during actual failover only. Cloud infrastructure allows near-instant vertical scaling. Licence the smaller footprint for the standby and have a documented process to acquire or reassign additional licences during a real disaster.
Negotiate DR provisions in Oracle contracts. When negotiating licence agreements, ULAs, or cloud commitments, explicitly include DR rights. Some enterprises negotiate clauses permitting a specific number of DR activations per year without additional licensing, or reduced-rate "standby licences" for DR servers that are normally inactive. Oracle does not offer these terms by default. They must be specifically requested and documented in the ordering document.
Consider Named User Plus for DR. If your DR environment will only be accessed by a limited number of administrators during failover, NUP licensing (minimum 25 NUP per Processor for Enterprise Edition) may be cheaper than Processor licensing, particularly for larger instances. Ensure your primary and DR use the same metric (you cannot mix Processor and NUP for the same product deployment).
No. The 10-day rule applies exclusively to a passive standby server within the same on-premises clustered environment as the primary. A cloud DR site, in a different data centre, cloud region, or cloud provider, is a separate environment and does not qualify. Any Oracle instance running in the cloud for DR must be fully licensed regardless of duration.
Generally no. If the VM is stopped and no Oracle processes are running, licensing is not required. Oracle licences apply when software is installed and/or running. A stopped cloud VM with Oracle binaries on its attached storage is typically acceptable, but ensure it is genuinely stopped and not accidentally left in a running state. Maintain cloud logs as evidence.
A Data Guard standby that is continuously receiving and applying redo logs is considered an active Oracle deployment and requires full Processor licensing on the standby server. Data Guard itself is included with Enterprise Edition, but the standby database server still needs its own EE Processor licences, plus licences for any options in use (Active Data Guard, Advanced Security, etc.).
Not simultaneously. A single licence can only cover one running deployment at a time. During a disaster, when the on-premises primary fails and stops running, those licences can conceptually be reassigned to the cloud DR instance, provided the vCPU count matches. However, if both environments are running simultaneously (e.g., during a planned test with the primary still active), each requires independent licensing.
For intermittent DR, OCI is typically far cheaper because it offers licence-included pricing billed per OCPU-hour. You pay only when the instance runs. AWS and Azure require BYOL with perpetual licences, meaning you must purchase or allocate licences even for a standby that runs only a few hours per year. For 24/7 warm standby, the cost difference narrows but OCI's BYOL rates remain lower than purchasing additional perpetual licences.
Yes. Any Oracle option or pack that is installed and enabled on the DR server must be licensed, even if it is only "in use" because the standby receives encrypted redo (Advanced Security) or partitioned data (Partitioning). Oracle auditors check DBA_FEATURE_USAGE_STATISTICS on every instance. Ensure your DR deployment mirrors your production licence entitlements for all options.
During an active ULA, you can deploy unlimited Oracle instances, including DR copies, without counting individual licences. This is a significant advantage for DR. However, when the ULA ends and you certify, every DR instance counts toward your total deployment. Ensure all DR deployments are included in your certification to maintain compliance post-ULA.