Whether your AWS, Azure, Google Cloud, or Oracle Cloud Infrastructure deployments count toward certification depends entirely on your contract. Many ULAs require public cloud to run 365 continuous days, some exclude it, and many are silent. Silence is not inclusion, so the language decides what you keep.
Cloud is the single most contract dependent area of a ULA certification, and the area where assumptions cost the most. A workload that runs happily in a public cloud all term can still fail to count if the contract sets a condition it did not meet, or excludes that platform entirely. Conversely, cloud that does count can add substantial defensible licenses. The only safe starting point is your own agreement. Read the cloud language first, then plan the estate around what it actually credits, well before the cutoff arrives.
It depends on your contract, and this is not a hedge but the central fact. Many ULAs include a specific clause governing authorized public cloud, commonly requiring instances in AWS or Azure to have run for a continuous period, often 365 days, before they count toward the certification baseline. Some agreements exclude public cloud from the count altogether, treating only on premises and Oracle Cloud Infrastructure deployments as countable. Many contracts say nothing about a given provider, frequently Google Cloud, and silence is not inclusion. The deployed quantity you can certify is whatever your contract credits, so the cloud clause, or its absence, sets the rules for that whole part of your estate.
Cloud counting is decided in the contract, not in the data centre. Read the clause first, then shape the estate to it. A workload that does not qualify is value you will not keep.
Where a ULA includes an authorized cloud provision, a common form requires that a public cloud deployment must have been running continuously for the 365 days immediately before certification to be counted. The intent is to credit established workloads rather than instances spun up at the last moment to inflate a number. The practical consequence is timing. A workload moved to AWS or Azure two months before exit would not satisfy a 365 day condition and would not count under that rule, even though it is genuinely deployed. Cloud workloads intended to contribute to the certification must therefore be live well ahead of the cutoff and evidenced across the whole qualifying period, not merely at the end. The exact threshold and wording vary, so the number and conditions in your own contract are what matter.
The table below is a general orientation only. Your contract overrides it in every case, and the specific language must be read before any decision.
| Platform | Common contract treatment | What to check |
|---|---|---|
| AWS and Azure | Often countable subject to a continuous run condition such as 365 days | The exact threshold and how instances are sized |
| Google Cloud | Frequently not named, so often silent | Whether silence means it is excluded for your agreement |
| Oracle Cloud Infrastructure | Usually treated favourably and countable | Whether moving workloads there before exit helps the count |
| On premises | Counts as standard deployment | Whether repatriation is the cleaner route for excluded cloud |
If your contract excludes a public cloud platform or does not credit it, the workloads are not lost, but they need handling before exit. Two routes are common. The first is repatriation, moving the workload back to on premises hosts that count as standard deployment. The second is migration to Oracle Cloud Infrastructure, which most agreements treat as countable. Either route only helps if it completes and is evidenced before the cutoff, so the decision belongs in the exit plan months ahead, not in the final weeks. The choice between them turns on operational fit, the time available, and the precise contract language, which is why this is a planning question rather than a last minute fix.
Consider an anonymized organisation running a meaningful share of its Oracle estate in a public cloud not named in its ULA. Read literally, those instances would not have counted, and the value would have walked out the door at certification. Identified early, the workloads were planned for migration to Oracle Cloud Infrastructure and on premises hosts ahead of the cutoff, with evidence captured across the move. The figures are indicative and the outcome turned on the contract, but a large block of deployment that the contract would not have credited in place became defensible certified licenses once it was positioned correctly and in time.
Cloud counting rewards reading the contract early and acting on it. Read cloud counting language to negotiate up front for the clauses worth securing at signing, and hybrid estates and the certification baseline for measuring a mixed estate. For the end to end exit, the ULA exit strategy guide places cloud counting in the full certification picture.
It depends on your contract. Many ULAs require public cloud instances in AWS or Azure to run for 365 continuous days to count toward the certification baseline, some exclude public cloud entirely, and many are silent on Google Cloud. Silence is not inclusion, so the contract language governs whether cloud counts.
Some ULAs only count authorized public cloud deployments that have run continuously for the 365 days before certification. Instances spun up close to the cutoff would not qualify under that rule, so cloud workloads intended to count must be live well before exit and evidenced across the full period.
Where the contract excludes or does not credit a cloud platform, the workloads can often be repatriated to on premises hosts or moved to Oracle Cloud Infrastructure before exit so they count toward the certification. The move must complete and be evidenced before the cutoff, so timing and the specific contract language are decisive.
Book a confidential assessment and we will read your cloud clause, position every workload to qualify, and evidence it before the cutoff.