Oracle disaster recovery cloud licensing. How each cloud counts your standby.

A standby database in OCI, AWS, Azure or Google Cloud for an on premises Oracle primary needs licenses from the day it is built. The design choice is how it is counted, and how small you keep it.

Does Oracle's ten day failover rule cover a cloud standby?

No. Oracle's failover concession allows an unlicensed spare node in a shared storage cluster to take over for up to ten separate days in a calendar year, with part days counting as whole days. A standby in OCI, AWS, Azure or Google Cloud never shares a disk array with an on premises primary, so the concession cannot reach it.

That makes a cloud standby licensable from the day it is built. A Data Guard standby keeps its own copy of the data, which fails the shared storage test even inside your own data center. The conditions, the evidence Oracle expects and how the rule plays out in an audit are covered in our Oracle DR licensing article.

Which Oracle data recovery rules apply to a cloud standby?

Oracle's data recovery licensing document describes three situations. Only the last one fits a replicated copy of your database running in someone else's cloud.

• Failover. An unlicensed spare in a shared storage cluster may run the programs for up to ten separate 24 hour periods a calendar year. Cloud standbys never qualify.
• Backup testing. A physical copy of backups may be restored on an unlicensed machine up to four times a year, for no more than two days each time.
• Standby and remote mirroring. Every Oracle program installed or running on the recovery server must be licensed, and the license metrics and options on the production and recovery servers must match. Real Application Clusters is the stated exception: it needs a license on the recovery server only if it is used there.

The mirroring rule governs Data Guard, GoldenGate and storage replicated targets, which covers every cloud standby discussed on this page.

How does each cloud count a standby for an on premises primary?

Each platform counts differently, and that difference sets the economics of the whole design. OCI offers a consumption path that leaves your entitlements untouched. AWS, Azure and Google Cloud count provisioned vCPUs against the licenses you own, under Oracle's authorized cloud environment policy.

How do the OCI license paths work for a standby?

On Base Database Service, a Data Guard standby is a second database system that bills its own compute. With license included, the whole DR tier becomes a service line on the cloud invoice. Under BYOL the standby draws entitlements exactly as an on premises server would, options included, and Oracle's BYOL guidance maps one processor license to two OCPUs.

The edition you pick on OCI decides what the standby may do. Active Data Guard is included in Enterprise Edition Extreme Performance and in Exadata Database Service, and is absent from Enterprise Edition High Performance. A standby you plan to open for reads needs the higher tier, or a BYOL Active Data Guard entitlement behind it.

What DR options does Autonomous Database offer?

Autonomous Database meters in ECPUs, with Oracle's published conversion of one OCPU to four ECPUs. It offers several DR options, each billed differently, and the wider service rules sit in the Autonomous Database licensing guide.

• Local Autonomous Data Guard. The peer bills the primary's base CPUs and storage a second time. Autoscaled CPUs on the primary are not billed again on the peer.
• Cross region Autonomous Data Guard. A second billed standby in another region, which roughly doubles the database compute spend.
• Local backup based DR. No additional charge, at the price of a longer recovery time than Data Guard.
• Cross region backup based DR. An additional charge for the copy held in the second region, with the same slower recovery.

Oracle publishes the billing rule for each peer type in the service documentation and does change it. Check it again between the design review and the order.

What is the arithmetic on AWS, Azure and Google Cloud?

The authorized cloud environment policy applies one set of rules to all three platforms. The core counting rules in that policy are short, and every line of them affects a standby.

• Enterprise Edition. Count two vCPUs as one processor license where hyperthreading is enabled, and one vCPU as one license where it is not.
• Standard Edition 2. Every four vCPUs, rounded up, count as one socket, and the edition's instance size limit of eight vCPUs applies. Licensed by named user, the minimum is 10 users per 8 vCPUs. The detail is in our note on SE2 vCPU limits.
• No core factor. The processor core factor table does not apply in authorized cloud environments. An Intel core that needs half a license on premises needs a full license in the cloud, because it appears as two vCPUs.
• Options and packs. Whatever the standby runs, whether Partitioning, Advanced Security, Active Data Guard or the diagnostics packs, must be entitled on the standby's count too. The broader platform rules are in Oracle database licensing on AWS.

What does a pilot light standby on Azure cost in licenses?

Take an on premises primary on a two socket, 32 core Intel server. With the 0.5 core factor, that is 16 Enterprise Edition processor licenses. The team builds an Azure standby on an 8 vCPU shape to apply redo, and plans to resize it to 32 vCPUs when a disaster is declared.

The idle standby counts 8 vCPUs, which is 4 processor licenses with hyperthreading enabled. The failover shape counts 32 vCPUs, which is 16. Say the primary also runs Partitioning and Diagnostics Pack. The table prices each state at Oracle's current list prices, license only, before support and discounts.

While the standby stays small, it needs 12 fewer licenses of each product than the failover shape, worth $798,000 at list across the three. It also creates a 16 license obligation on the day the runbook executes. Discounts change the dollar figures, never the counts.

Which decisions does the pilot light force?

• The failover entitlement. Hold licenses for the failover shape, or accept a documented, time boxed exposure at declaration. Decide it on paper, in advance, and have the owner of the Oracle budget sign it.
• The question for Oracle. Ask how a declared disaster affects counting on both sides while the primary is down. Get the answer in writing and file it with the runbook.
• Recalculation. The trap either way is a standby shape that changes without anyone recounting. Tie the license count to the change ticket for every resize.

How does the answer change with the size of your Oracle footprint?

A smaller Oracle customer with one or two production databases rarely has spare licenses. For them, license included on OCI or a backup and restore design usually beats buying new processor licenses for a standby that may never carry production load.

A larger customer often holds unused licenses from consolidations or retired projects. Pointing them at the cloud standby can cost nothing new. Check two things first: the licenses must still be on support, and their metric and options must match the primary's, as the mirroring rule requires.

Which DR pattern fits which recovery objective and budget?

Match the pattern to the recovery time you promised the business. Each step up in readiness roughly doubles the licensed or metered footprint, so the cheapest compliant design is the smallest standby that still meets the objective. Review the choice whenever the objective itself changes.

The standby also inherits the primary's edition. An Enterprise Edition primary needs an Enterprise Edition standby, so the savings come from shape and license path. Data Guard is an Enterprise Edition feature, and a Standard Edition 2 copy cannot serve as its standby.

Why does a pilot light standby license only the small shape?

Oracle's cloud policy counts provisioned capacity. A standby applying redo on a small shape licenses that small shape, whatever the size of the primary. The saving recurs every month, and the obligation it creates is a scaling plan whose target shape is entitled before a declared failover expands into it.

Where does each cloud fit the pattern?

• OCI. The natural standby home for an Oracle primary. License included prices DR as pure consumption, and scaling at failover is a service operation. The platform trade is covered in OCI versus AWS for Oracle workloads.
• AWS, Azure and Google Cloud. Workable BYOL homes when the organization has standardized there, priced in entitlements you must already own at the failover shape.
• A Cloud at Customer rack. Standby VM clusters meter like primaries, activation floors included. The drawdown detail is in the ExaCC billing article.

Does the replication method change the licensing?

Data Guard, GoldenGate, storage replication and backup shipping each change recovery characteristics and carry their own licensing. None of them changes the standby's status under the mirroring rule described above.

GoldenGate adds its own license line on the capacity it runs on, so price it before choosing it for DR duty. Our GoldenGate licensing guide covers the metric. The standby stays counted either way.

What does a DR test actually cost in the cloud?

A cloud DR test is a metering and entitlement event as well as an operational one. Whatever the test provisions is counted while it runs. A scaled up standby on AWS or Azure counts its vCPUs against your licenses for the duration, and consumption platforms bill the test at the tested size.

Does Oracle's backup testing allowance cover a standby test?

No, the backup testing allowance does not help here. It covers restore tests of physical backup copies, four tests a year of up to two days each, and says nothing about a running replicated standby.

On license included OCI tiers the test is purely a metering event. The scaled shape bills for the hours it runs, and the exposure ends at teardown. That predictability is itself an argument for putting the DR tier on consumption terms.

How do you run DR tests that survive an audit?

• Schedule and log. Record the date, duration, shapes provisioned and shapes released for every test. The log turns an auditor's assumption of continuous use into a documented window.
• Test at the entitled shape. If the failover plan scales to 32 vCPUs, hold entitlements for 32 vCPUs before the first full test, or run the test against a reduced shape you do hold.
• Tear down deliberately. The expensive DR test is the one that never scaled back down. Make the teardown a signed step in the runbook.

What have we seen in recent Oracle cloud DR reviews?

Across roughly 30 to 40 Oracle customers whose disaster recovery licensing I reviewed in 2024 and 2025, the cloud standby was the least governed asset in the architecture. Three patterns kept repeating.

• Unlicensed after a replatform. In 40 to 50 percent of hybrid environments, the cloud standby carried no licenses at all after a move to AWS or Azure. The team usually assumed a DR exception traveled with the workload.
• Oversized standbys. Standby instances were sized to match the primary when the recovery objective only justified a pilot light, doubling the licensed footprint for no recovery benefit.
• Undocumented tests. DR tests scaled the standby to full size with no record of dates or duration, leaving nothing to answer an auditor's usage question with.

Ownership made the difference. Where a named person owned the standby's numbers, audit findings were usually small corrections to the license position. Where no one did, findings more often ended in new license purchases.

Which cross cloud DR traps surface in an Oracle audit?

Eight traps account for nearly every cloud DR finding we have seen. Each one is checkable, and each is cheaper to fix before an audit letter than after it. Walk the list against your own architecture diagram; most organizations find at least two, and the second one is usually the expensive one.

1. The inherited exception. Teams assume the ten day concession travels to the cloud standby. It cannot, because the shared storage condition ends at the firewall.
2. The unlicensed replatform. A standby rebuilt in AWS or Azure during a migration is never added to the license position. This was the single most common gap in our reviews.
3. Options drift. The primary runs Partitioning and Diagnostics Pack. The standby inherits the workload at failover but was never entitled for the options.
4. Read only ambitions. Opening the cloud standby for reporting turns a recovery asset into an active node. Under BYOL that brings Active Data Guard into scope on the standby and on the primary.
5. Unreviewed resizes. An instance class change on the standby changes the vCPU count, and the license position ages without anyone deciding anything.
6. Forgotten named user minimums. Named user minimums follow the processor count on the standby, and cloud vCPU counts move the minimums.
7. ULA certification surprises. Public cloud deployments may be excluded or restricted when a ULA certifies, stranding the DR environment outside the certified number. The mechanics are covered in Oracle ULA and AWS licensing.
8. Two policies, one architecture. The primary counts under on premises rules and the standby under the cloud policy, and the audit reads each side by its own rules. Reconcile both counts in one document before Oracle does it for you.

Why we reject the claim that cloud DR costs almost nothing while idle

The common advice says put DR in the cloud because the standby costs almost nothing while it idles. We disagree with that premise. Under BYOL on AWS or Azure, the standby's cost is the entitlements it holds while idling, at the same license and support value as production hardware. The idle compute was never the expensive part.

Believing it is one way a standby ends up unlicensed after a replatform, which was the most common gap in our reviews. The designs that were cheap in practice were pilot light shapes and license included OCI tiers, chosen on purpose, with the failover shape entitled and the test windows logged.

The concession stops at your firewall. Everything on the cloud side of the replication link is a counted deployment, sized by your own design choices.

How do you check your own cloud DR licensing position?

Start from the cloud accounts, work back to the databases, then compare the result with your entitlements. Each platform shows the numbers you need without extra tooling.

• AWS. The EC2 DescribeInstances call returns the instance type and the CPU options, core count and threads per core, for every EC2 standby. The RDS DescribeDBInstances call gives the instance class and license model for RDS standbys.
• Azure. az vm show returns the VM size of each standby. Microsoft publishes the vCPU count for every size, and that count is what Oracle's policy uses.
• Google Cloud. gcloud compute instances describe returns the machine type, which fixes the vCPU count.
• OCI. The console and the oci db system get command show each DB system's shape, its OCPU or ECPU count and whether it runs license included or BYOL.
• Inside the database. V$DATABASE shows the database role and open mode. An open mode of READ ONLY WITH APPLY means real time query is in use, which is an Active Data Guard feature.

Then check which options follow the workload. Run the feature usage report on the primary, and check the CONTROL_MANAGEMENT_PACK_ACCESS parameter on both sides, since it decides whether the Diagnostics and Tuning packs are enabled.

Put the results on one page per standby: platform, shape, vCPU or ECPU count, license path, options enabled and the entitlements that cover them. That page is the entitlement map the rest of this article refers to.

What will Oracle say about a cloud standby, and how should you answer?

Cloud DR usually comes up with Oracle during an audit or a renewal, and the same points recur. Prepare the replies before the meeting, with the documents that support them.

• "The standby must be licensed at the primary's size." In an authorized cloud, the policy counts provisioned vCPUs. Show the shape history of the standby and the count it produces for each period.
• "Your test ran at full size, so we assume full size all year." Produce the test log with dates, shapes and teardown times. The exposure is the tested window, and the log proves its length.
• "The standby was open for reporting, so Active Data Guard is due." If it was, accept the finding and negotiate the price. If it was only mounted, show the feature usage record for Active Data Guard real time query, which Oracle's own usage statistics track on the primary.
• "Cloud deployments fall outside your ULA certification." Point to the contract's terms on public cloud counting, which you should have settled before certification began.
• "Move the DR tier to license included OCI and the problem goes away." Sometimes it does. Price it against a BYOL pilot light on your current cloud and decide on the numbers.

Which contract terms and controls cut cloud DR licensing cost?

The customers that run cloud DR cheaply and cleanly share seven internal controls, and none of them needs Oracle's agreement. A short list of written terms, covered after them, is what you negotiate.

• Shape to the objective. Use a pilot light unless the promised recovery time demands a warm standby, because the standby's size drives its license count.
• Prefer consumption for the DR tier. License included on OCI turns standby licensing into a monthly service decision that can be resized or ended.
• Map options to the standby. Keep one page listing every option and pack on the primary, and how each is covered on the standby's count.
• Freeze the shape. Put the standby's instance size under change control, so every resize becomes a licensing decision.
• Log every test. Dates, durations and shapes, kept with the entitlement map.
• Reconcile both sets of rules. Use one document to count the on premises side and the cloud side of the same architecture.
• Time ULA decisions. If a ULA is in play, decide where DR sits before certification starts, not during it.

What should you ask Oracle to put in writing?

1. Counting during a declared disaster. How the primary and the cloud standby are counted while the primary is down, so the failover week does not become a double count.
2. Public cloud counting under a ULA. Whether and how deployments in AWS, Azure or Google Cloud count at certification, agreed before the ULA ends.
3. The BYOL ratio on OCI. The processor license to OCPU or ECPU conversion that applies to your order, stated in the ordering document.
4. Named DR servers. A list of the standby systems covered by specific licenses, which removes any argument later about what the licenses were meant for.

Who should own the cloud DR license position?

Every trap on this page shares one root cause. The DR setup sits between the infrastructure team, the DBA team and licensing, and belongs to none of them. Name an owner for the standby's counts, entitlements and test log, and review the position twice a year.

The role costs a few days a year and pays for itself the first time a resize request crosses the desk. When DR is one part of a wider effort to control Oracle spend, the Oracle CIO white paper sets out the five year plan around it.

What to do next

1. Find every target. Inventory every replication target in every cloud account, including the ones the DR team built and never registered.
2. Record the facts. Write down each standby's platform, shape, vCPU or ECPU count and license path.
3. Close option gaps. Map the options and packs on the primary against the standby's entitlements and fix the gaps.
4. Reprice the DR tier. Price it as a pilot light and as license included consumption, and compare both with today's design.
5. Cover the failover shape. Confirm entitlements exist for the shape you scale to at failover, as well as the idle shape.
6. Control changes. Start the test log with the next scheduled test, and put standby resizes under change control.
7. Get help early. Bring in independent Oracle advisory before an audit response or a ULA certification touches your DR setup.

Frequently asked questions