Cloud DR and the certification count.

Two rule sets, one deployment

Why cloud DR is its own question

Disaster recovery is one of the most commonly missed sources of legitimate count, and cloud DR is the trickiest version of it. The difficulty is that it falls under two sets of rules at once. The first is the cloud clause, which governs whether deployments in AWS, Azure, or another public cloud count toward the certified baseline, often subject to a continuous running requirement. The second is the way DR is measured, which depends on whether the standby is dormant or active and on how the agreement treats failover. A cloud DR environment has to satisfy both, and the two interact in ways an on premises standby does not.

The practical consequence is that you cannot reason about cloud DR using on premises intuition. On premises, organisations sometimes rely on a dormant failover treatment, where a standby that is not actively running may be handled differently under the agreement. In public cloud, DR is almost never dormant in that sense. It is a continuously running standby, fully provisioned, often kept in sync in real time, precisely so it can take over quickly. That makes it a live deployment, and a live deployment in the cloud is squarely subject to the cloud counting rules.

Does disaster recovery in the cloud count toward ULA certification?

It can, and where it does it is valuable, but the answer runs through your contract twice. First, the cloud clause has to permit public cloud to count. If your agreement excludes public cloud, the cloud DR estate will not count as it stands, and the option is to relocate it, on premises or to Oracle Cloud Infrastructure, before exit. Second, if the clause permits cloud counting, the standby must meet whatever conditions apply, such as a 365 continuous day threshold, and it must be evidenced as a running deployment across that period. A cloud DR site that has only recently been built may fail the duration test even though it is genuine.

The label disaster recovery carries no special weight on its own. Oracle counts deployed software, and a running standby is deployed software. What changes the outcome is not the purpose of the environment but its state, its location, and the wording that governs both. This is why cloud DR has to be analysed deliberately rather than assumed to count or assumed not to.

Where cloud DR goes wrong at certification

The failures cluster in a few predictable places, and each is avoidable with early planning.

• Assumed dormant. Treating a continuously running cloud standby as if it were a dormant failover, and therefore under counting or mishandling it against the agreement.
• Built too late. Standing up cloud DR close to the window, so it cannot meet a continuous running threshold and counts for nothing despite being real.
• Excluded by the clause. Running DR in a public cloud the agreement excludes, with no plan to relocate it before exit.
• Under evidenced. Lacking the records that prove the standby ran continuously across the required period, so a counting deployment cannot be defended.
• Active Data Guard overlooked. Missing that an active standby may use the Active Data Guard option, which is its own named product to count where the ULA includes it.

A cloud DR scenario, indicative

The table below shows how the same cloud DR estate reaches different outcomes depending on the clause and the timing for an anonymized example. The figures are indicative and exist to show the logic, not to represent any real engagement, and the real outcome depends entirely on the specific agreement.

Indicative only. The figures depend entirely on the estate, the cloud clause, and the wording of the specific agreement. The point is that cloud DR can be substantial permanent value or nothing at all, and the difference is decided well before the window.

How to handle cloud DR before exit

The handling is straightforward once the framing is right, and it has to start early because the most common failure is timing.

• Read the cloud clause first. Establish whether public cloud counts and under what conditions, because that decides whether cloud DR is even a candidate.
• Measure the standby as live. Treat the cloud DR environment as the running deployment it is, and count it on the processors it occupies.
• Check the duration. Confirm the standby has run long enough to meet any continuous running threshold, and if not, decide whether to relocate or accept the gap.
• Capture the option. Where an active standby uses Active Data Guard and the ULA names it, count the option alongside the database.
• Evidence continuously. Keep records that prove the standby ran across the required period, so a counting deployment is defensible at certification and later.

The next step

Cloud DR is where the cloud rules and the DR rules meet, and getting both right turns a standby estate into permanent entitlement rather than a missed line. Read the clause, measure the standby as the live deployment it is, and evidence it across the full period. For the AWS specific reading, see does AWS count toward your certification, learn the full reading method in auditing your cloud clause before exit, and ground the approach in our ULA exit strategy guide.