Oracle DR in the cloud. Counted, not conceded.

A standby database in OCI, AWS, or Azure for an on premises Oracle primary is licensable from the day it is built. This guide owns the cloud side of Oracle disaster recovery: how each cloud counts a standby, which DR pattern minimizes the licensed footprint, what a test really costs, and the cross cloud traps that surface at audit.

What does the on premises failover concession actually allow?

One narrow thing: an unlicensed spare node in a shared storage cluster may take over for up to ten separate days a year, part days counting whole. A Data Guard standby keeps its own data copy, fails the shared storage test, and is licensable from installation. Conditions, evidence, and audit defense live in the Oracle DR licensing article.

The cloud consequence is immediate. No standby in OCI, AWS, or Azure shares a disk array with an on premises primary, so the concession never applies across that boundary. Whatever runs in the cloud is a deployment, and deployments are counted.

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

Three different ways, and the differences set the economics of the whole design. OCI offers a consumption path that avoids touching your entitlements; AWS and Azure count provisioned vCPUs against the licenses you own under Oracle's authorized cloud environment policy.

The OCI paths in practice

On Base Database Service, a Data Guard standby is a second database system billing its own compute; license included prices the whole DR tier as a service line. Under BYOL the standby draws entitlements exactly as an on premises server would, options included.

On Autonomous Database, enabling Autonomous Data Guard adds a billed standby, and a cross region pair roughly doubles the database compute spend; verify current mechanics in the service documentation before budgeting. Autonomous meters in ECPUs, with Oracle's published conversion of one OCPU to four ECPUs; the wider service rules sit in the Autonomous Database licensing guide.

The AWS and Azure arithmetic

• Enterprise Edition: count two vCPUs as one processor license where hyperthreading is enabled, one vCPU as one license where it is not.
• Standard Edition 2: the policy counts in blocks of four vCPUs as one socket equivalent, with the edition's instance size limits applying in cloud sizes.
• No core factor: the processor core factor table does not apply in authorized cloud environments, which makes cloud cores more license expensive than most on premises cores.
• Options and packs: whatever the standby runs, Partitioning, Advanced Security, Active Data Guard, diagnostics packs, must be entitled on the standby's count too. The broader platform rules are in Oracle database licensing on AWS.

A worked counting example

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, planning to resize to 32 vCPUs on declaration.

The idle standby counts 8 vCPUs, which is 4 processor licenses with hyperthreading enabled. The declared failover shape counts 32 vCPUs, which is 16. The pilot light saves 12 licenses' worth of exposure every idle day, and creates a 16 license obligation on the day the runbook executes.

• The design question: hold entitlements for the failover shape, or accept a documented, time boxed exposure at declaration. Decide it on paper, in advance.
• The question for Oracle: 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.
• The trap either way: nobody recalculating when the standby shape changes. The arithmetic is trivial; the governance is the work.

White Paper · Oracle

Oracle CIO Complete Playbook

The five year plan to control Oracle spend. Read it free.

Read the white paper

Which DR pattern fits which recovery objective and budget?

Match the pattern to the recovery time you actually promised the business, because each step up in readiness roughly doubles the licensed or metered footprint. The cheapest compliant design is the smallest standby that still meets the recovery objective, reviewed whenever the objective itself changes.

One more sizing note: the standby inherits the primary's edition. An Enterprise Edition primary needs an Enterprise Edition standby, so the saving lever is shape and license path, never a quiet edition downgrade on the recovery side.

Pilot light: the arithmetic that makes it work

Because Oracle's cloud policy counts provisioned capacity, a standby applying redo on a small shape licenses the small shape, not the primary's size. The saving is real and recurring; the obligation it creates is a scaling plan whose target shape is entitled before a declared failover expands into it.

Where each cloud fits 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 and Azure: 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.

Replication transport does not change the counting

Data Guard, GoldenGate, storage replication, or backup shipping: the transport choice changes recovery characteristics and its own licensing, not the standby's status. A target that runs Oracle software is counted as a deployment however the bytes arrive.

GoldenGate adds its own license line on the capacity it runs on, worth pricing before choosing it for DR duty. 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, not just an operational one. Whatever the test provisions is counted while it runs: scaled up standby shapes on AWS or Azure count vCPUs against your shelf for the duration, and consumption platforms bill the test at the tested size.

Oracle's data recovery guidance separately permits testing a physical copy of backups a small number of times a year for short defined windows, four tests of up to two days each being the published shape. That concession covers restore tests of backup copies; it does not cover 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 paper.

How to run tests that survive an audit

• Schedule and log: date, duration, shapes provisioned, and shapes released, for every test. The log converts 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 test the runbook against a reduced shape you do hold.
• Tear down deliberately: the expensive DR test is the one that never scaled back down. Make de provisioning a signed step in the runbook, not an assumption.

What are the cross cloud DR traps that surface at audit?

Eight traps account for nearly every cloud DR finding we have seen. Each one is boring, checkable, and cheaper to fix before the audit letter than after it. Walk the list against your own architecture diagram; most estates 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; the shared storage condition dies at the firewall.
2. The unlicensed replatform: a standby rebuilt in AWS or Azure during a migration and 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, with Active Data Guard implications under BYOL tiers.
5. Silent resizes: an instance class change on the standby quietly changes the vCPU count, and the license position ages without anyone deciding anything.
6. NUP arithmetic forgotten: named user minimums follow the processor count on the standby, and cloud vCPU counts move the minimums.
7. ULA certification surprises: deployments in public clouds may be excluded or restricted when a ULA certifies, stranding the DR estate 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, the standby under the cloud policy, and the audit reads each side by its own rulebook. Reconcile both counts in one document before Oracle does it for you.

Where the common advice on Oracle disaster recovery cloud licensing is wrong

The common advice says put DR in the cloud because the standby costs almost nothing while it idles. We disagree with the premise doing the work in that sentence. Under BYOL on AWS or Azure, the standby's cost is the entitlements it consumes while idling, which run at the same license and support value as production metal; the idle compute was never the expensive part. In roughly 6 of 10 hybrid estates we reviewed, the cheap idle story had quietly become an unlicensed standby story. The genuinely cheap designs were pilot light shapes and license included OCI tiers, chosen deliberately, with the failover shape entitled and the test windows logged. Cloud DR is cheap when the counting is designed, not when it is ignored.

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.

What buyer side levers cut cloud DR licensing cost?

Seven levers recur in the estates that run cloud DR cheaply and cleanly. None require negotiating anything with Oracle; all require somebody to own the standby's numbers.

• Shape to the objective: pilot light unless the promised recovery time genuinely demands warm; the standby's size is the cost.
• 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: one page listing every option and pack on the primary, and its coverage on the standby's count.
• Freeze the shape: put the standby's instance size under change control so resizes become licensing decisions.
• Log every test: dates, durations, shapes; keep the log with the entitlement map.
• Reconcile both rulebooks: one document counting the on premises side and the cloud side of the same architecture.
• Time ULA moves: if a ULA is in play, decide where DR sits before certification, not during it.

Give the position an owner

Every trap on this page shares one root cause: the DR estate 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.

In our reviews, estates with a named owner had findings measured in corrections. Estates without one had findings measured in invoices. The role costs a few days a year and pays for itself the first time a resize request crosses the desk.

What should a buyer do next?

1. Inventory every replication target in every cloud account, including the ones the DR team built and nobody registered.
2. Write down each standby's platform, shape, vCPU or ECPU count, and license path.
3. Map primary side options and packs against standby entitlements and close the gaps.
4. Reprice the DR tier as pilot light and as license included consumption, and compare against today's design.
5. Confirm entitlements exist for the failover shape, not just the idle shape.
6. Start the test log with the next scheduled test, and put standby resizes under change control.
7. Bring independent Oracle advisory in before an audit response or a ULA certification touches the DR estate.

Frequently asked questions

Is a cloud standby for an on premises Oracle primary free?

No. The failover concession requires a shared storage cluster, which a cloud standby can never join, so the standby is licensable from the day it is built. The design choice is which license path it uses, not whether it needs one.

How is an Oracle standby counted on AWS or Azure?

By provisioned vCPUs under Oracle's authorized cloud environment policy: two vCPUs per Enterprise Edition processor license where hyperthreading is enabled. The core factor table does not apply, and named user minimums follow the resulting processor count.

Does the standby need the same options as the primary?

Under BYOL, yes: every option and pack the standby runs or inherits at failover must be entitled on its count. Options drift between primary and standby is one of the most common cloud DR audit findings.

What is the cheapest compliant cloud DR design?

Usually a pilot light standby: a minimal shape applying redo, licensed or metered at its small size, with a scaling plan whose target shape is already entitled. It beats warm standby whenever the recovery objective allows it.

Do DR tests in the cloud consume licenses?

A test counts whatever it provisions for as long as it runs; a scaled up standby counts at the scaled size on BYOL platforms. Oracle's separate backup testing concession covers restore tests of backup copies in short windows, not a running standby.

Can Active Data Guard be avoided on a cloud standby?

Yes, by keeping the standby closed and using it strictly for recovery. Opening it for reads or reporting brings Active Data Guard into scope under BYOL, or requires the OCI service tier that includes it.

How does a ULA interact with cloud DR?

Carefully. Public cloud deployments may be excluded or limited when the ULA certifies, which can strand a cloud standby outside the certified number. Decide where the DR estate sits before certification and document it.

Where does the ten day failover rule apply?

Only inside an on premises shared storage cluster, one spare node, up to ten separate days a calendar year. It never applies across a replication link to a cloud standby, whatever the standby's size or duty cycle.