The authorized cloud clause
Oracle's licensing policy defines certain public clouds, principally Amazon Web Services and Microsoft Azure, as authorized cloud environments, and provides rules for how Oracle software may be licensed when run on them. Within a ULA, the critical question is whether deployments in those environments may be counted toward the certification quantity at term end. Many standard ULAs answer no: they contain a clause that explicitly excludes authorized cloud deployments from the certified count, so that only on premises and, in some cases, Oracle Cloud deployments contribute to the perpetual entitlement.
The clause is easy to miss because it sits among the certification provisions rather than the headline terms, and its consequence only materialises three years later. A customer focused on the fee and the product list at signature can accept it without realising that it has just agreed to forfeit the certification value of any cloud migration it undertakes during the term. Understanding this clause before signing is the difference between a ULA that supports a cloud strategy and one that quietly punishes it. The structural context is in the Oracle ULA pillar guide.
The value at stake
The value at stake is the certification value of everything the customer deploys in the cloud during the term. For an organisation executing a serious cloud migration, that can be the majority of its Oracle estate. If the contract excludes cloud counting, those deployments are real and running but cannot be certified, so the perpetual entitlement the customer takes away reflects only what remains on premises, often a small and shrinking fraction of the total.
A cloud counting exclusion turns a successful migration into a certification disaster. The more you move to cloud, the less you can certify.
The perverse incentive this creates is stark. Under an exclusion, the customer that executes its cloud strategy most successfully certifies the least, because it has moved the most workloads to environments it cannot count. The customer is effectively penalised for doing exactly what its broader IT strategy demands. Recognising this trap reframes the ULA decision for any cloud bound organisation, and connects directly to the cloud and OCI licensing strategy that should be coordinated with the ULA rather than considered separately.
AWS, Azure, and the exclusion
For deployments on AWS and Azure, the licensing mechanics under Oracle's policy already differ from on premises, with the count based on virtual cores or vCPUs according to Oracle's cloud policy rather than physical cores and the core factor. Within a ULA, the prior question of whether these deployments count at all governs everything. Where the contract permits counting, the customer must understand the cloud measurement basis and apply it correctly. Where the contract excludes counting, the measurement basis is moot because the instances simply do not contribute to certification.
A customer that has already deployed to AWS or Azure under a ULA with an exclusion has limited remedies at certification, which is why the issue must be addressed at entry or, failing that, at the first renewal. Attempting to certify excluded cloud instances invites a dispute Oracle is well placed to win, while leaving them out forfeits their value. The only sound positions are to have negotiated counting rights upfront or to have planned the deployment around the exclusion, neither of which is available to a customer that discovers the clause at term end. The certification mechanics that this interacts with are detailed in the certification guide.
Oracle Cloud Infrastructure
Oracle Cloud Infrastructure is generally treated more favourably than third party clouds within a ULA, which is no accident. Oracle uses the contrast to steer ULA customers toward OCI, offering counting treatment and incentives for OCI deployments that it withholds from AWS and Azure. For a customer genuinely planning to use OCI, this can be advantageous, allowing cloud deployments to count toward certification where third party cloud deployments would not.
The caution is that favourable OCI counting is a lever Oracle pulls to deepen the customer's commitment to its own cloud, and the customer should weigh the certification benefit against the strategic cost of OCI lock in. A cloud strategy built around OCI purely to preserve ULA certification value is being driven by the licensing tail rather than the technology, and that is rarely the right basis for a cloud platform decision. The interaction between ULA terms and OCI commitments is part of the broader cloud and OCI advisory, and should be negotiated as a connected whole.
Negotiating cloud counting rights
Cloud counting rights are negotiable, and securing them is among the highest value moves in a ULA negotiation for any cloud bound customer. The objective is a clause that permits counting public cloud deployments toward certification on a defined and workable basis, ideally aligned with the cloud measurement rules so the count is unambiguous. Oracle resists because the exclusion protects both its renewal leverage and its OCI incentives, but customers with credible migration plans, competitive alternatives, and disciplined negotiators routinely win at least partial rights.
Where full counting rights cannot be won, the fallback is to plan the deployment around the contract, keeping certifiable workloads in environments that count and timing the cloud migration relative to certification. This is a second best outcome that constrains the cloud strategy to fit the licensing, but it is far better than discovering the exclusion after the migration is complete. The clause by clause approach to winning these rights is set out in the ULA negotiation strategy.
If you already signed an exclusion
Many customers discover the cloud counting exclusion not at signature but partway through the term, once a cloud migration is already underway. The position is more constrained then, but it is not hopeless, and the worst response is to ignore it and hope the issue does not surface at certification. It will, because certification is precisely where Oracle examines what can and cannot be counted, and a customer that has deployed heavily to an excluded cloud will certify far below what it expected.
The first option is to plan the deployment around the exclusion for the remainder of the term. Workloads that the customer wants to certify can be kept in, or moved back to, environments that count, while genuinely cloud native workloads proceed in the public cloud with the understanding that they will be licensed separately afterward. This constrains the cloud strategy to fit the licensing, which is not ideal, but it preserves the certification value of the workloads that can be counted and avoids the surprise of a collapsed certification.
The second option is to raise cloud counting at the next contractual opening, whether a renewal, a support negotiation, or a broader cloud discussion. Oracle's appetite to add counting rights rises when it has something else it wants from the customer, such as an OCI commitment or a renewal, and a customer that links the two can sometimes secure the rights it failed to negotiate at entry. The third option, where the numbers justify it, is to model an early certification or a restructured agreement, taking advice on whether the contract permits certifying ahead of term end on favourable terms. None of these is as clean as having negotiated counting rights upfront, which is why the issue belongs in every entry negotiation, but a customer that confronts an existing exclusion deliberately, with the help of the ULA negotiation service, recovers far more value than one that lets certification arrive unexamined.
The buyer side view
The practical takeaway is that the cloud counting clause can decide the entire value of a modern ULA, and it must be read and negotiated at entry rather than discovered at certification. For any organisation with a cloud strategy, accepting Oracle's standard exclusion means agreeing to forfeit the certification value of the migration the rest of the business is committed to executing. The clause is invisible to a fee focused negotiation and devastating at term end.
Read the cloud clause before signing, negotiate explicit counting rights, and coordinate the ULA with the cloud platform decision rather than treating them separately. If counting rights cannot be secured, plan the deployment around the exclusion deliberately. To address cloud counting on your own agreement, read the ULA pillar guide and the negotiation strategy, and engage the ULA negotiation service before the contract is signed.
Oracle ULA: frequently asked questions
Can you count AWS deployments at Oracle ULA certification?
Only if the contract permits it. Many Oracle ULAs exclude counting deployments in authorized cloud environments such as AWS and Azure, in which case those instances cannot be certified. Cloud counting rights must be secured at entry. See the ULA pillar guide.
Why does Oracle exclude cloud from ULA certification?
The exclusion protects Oracle's renewal leverage and steers customers toward Oracle Cloud Infrastructure, which is treated more favourably. It penalises customers that migrate to third party clouds during the term by preventing them from certifying those deployments.
Is OCI counted differently in a ULA?
Yes. Oracle Cloud Infrastructure is generally treated more favourably than AWS or Azure, often allowing OCI deployments to count toward certification. Oracle uses this contrast to encourage OCI commitments, so the benefit should be weighed against lock in. See cloud and OCI licensing.
How do I protect cloud value in a ULA?
Negotiate explicit cloud counting rights at entry, coordinate the ULA with your cloud platform decision, and if counting rights cannot be won, plan the deployment around the exclusion. The negotiation approach is in the ULA negotiation strategy.