As enterprises migrate infrastructure to cloud platforms, one critical question emerges: does your Oracle ULA cover cloud deployments? Oracle's answer depends entirely on which cloud platform you're using and what your ULA contract actually says — not what Oracle's account team implies. Former Oracle insiders explain the specific cloud deployment rules for OCI, AWS, Azure, and GCP under a ULA, what counts toward certification, and how cloud migrations can create either significant ULA value or significant compliance exposure depending on how you approach them.
The fundamental question for cloud deployments under a ULA is whether Oracle's Processor metric — which is the basis for most ULA licence calculations — applies to cloud virtual machine instances using the same Core Factor Table rules as physical on-premises servers, or whether Oracle imposes different rules for cloud infrastructure. The answer, as is typical in Oracle licensing, depends on which cloud platform you're using, your ULA contract language, and what deployment model you're using within that cloud.
Oracle's general position is that cloud deployments require separate licensing treatment — and that Oracle Cloud Infrastructure (OCI) receives the most favourable treatment, incentivising enterprises to move workloads to OCI. Deployments on third-party cloud platforms (AWS, Azure, GCP) face Oracle's standard policy position that cloud virtual machines do not constitute "hard partitioning" for Processor metric purposes, which means — under Oracle's interpretation — the entire physical host underlying a cloud VM must be counted as licensable, not just the vCPUs allocated to your instance.
This policy position, if applied at ULA certification, could dramatically increase the licence count you must certify for cloud-deployed Oracle products — far beyond the vCPU count of your actual workloads. Understanding this risk before migrating Oracle ULA-covered workloads to cloud is essential. The detailed technical framework is covered in our guide to Oracle audit rules for cloud environments.
Critical Timing Warning: If you are planning a cloud migration during your ULA term, resolve the cloud deployment counting rules with Oracle in writing before the migration begins — not at certification. By the time you reach certification, the deployment is already done. Oracle's position at that point will be whatever maximises their revenue from the certification count.
Oracle's own cloud platform, OCI, receives the most favourable ULA deployment treatment. Oracle's policy for OCI deployments under a ULA typically allows licence counting based on the number of Oracle CPUs (OCPUs) consumed by the Oracle Database or other ULA-covered product, rather than the entire underlying physical host. This makes OCI the only major cloud platform where the standard Core Factor Table logic applies predictably to ULA deployments — each OCPU counts as one Oracle Processor licence in OCI's current configuration.
The OCI advantage creates a significant commercial incentive for Oracle to recommend OCI migrations during the ULA term. Oracle's account team will frequently suggest that moving Oracle workloads to OCI "maximises your ULA value" — which is partially true (you can deploy more Oracle instances in OCI without the compliance risk of third-party cloud), but also serves Oracle's goal of migrating your infrastructure to Oracle's cloud platform and creating new cloud contract commitments that outlast the ULA itself.
BYOL (Bring Your Own Licence) on OCI is the standard mechanism for deploying ULA-covered products on OCI infrastructure. Under BYOL, your ULA licences are applied to OCI compute instances running Oracle Database or other covered products. The deployment counts toward ULA certification in the same way as on-premises deployment. Oracle's Support Rewards programme — which credits Oracle Cloud spending against on-premises support costs — adds an additional financial incentive layer to OCI BYOL deployments. See our detailed analysis of Oracle Cloud & OCI advisory considerations for enterprises evaluating this migration path.
Amazon Web Services is the most problematic cloud environment for Oracle ULA deployments because Oracle's policy position on AWS physical host counting is the most stringent Oracle applies to any cloud platform. Oracle's licensing policy states that on AWS (and Azure, GCP), because these cloud platforms use hypervisor technologies that Oracle does not recognise as "hard partitioning," Processor licences must cover all virtual CPUs on the underlying physical host — not just the vCPUs allocated to the Oracle workload.
In practical terms, if your Oracle Database EE runs on an AWS EC2 instance with 4 vCPUs, but the underlying AWS physical host has 128 vCPUs (a common configuration on AWS Nitro instances), Oracle's policy position is that you need licences for the equivalent of 128 vCPUs × Core Factor, not 4 × Core Factor. This multiplies the licence count by 32x compared to what the actual Oracle workload requires.
Oracle's policy: licence the entire physical host. vCPU count of Oracle instance does not limit licence requirement. Core Factor Table applied to physical host core count.
Using AWS Dedicated Hosts gives you exclusive access to the underlying hardware. Oracle may accept Core Factor calculation based on the dedicated host's physical core count rather than shared infrastructure. Requires contractual documentation.
AWS RDS Oracle is a licensed Oracle product — Oracle maintains a reseller relationship with AWS for RDS Oracle. Standard Oracle Database Processor licences apply. Your ULA may or may not cover RDS deployments depending on specific ULA contract terms.
Oracle's preferred deployment path. OCPU-based counting, favourable Core Factor treatment, Support Rewards available. ULA deployments on OCI count toward certification on OCPU basis under current policy.
The contractual reality is that Oracle's policy documents are not automatically part of your ULA contract. If your ULA does not specifically incorporate Oracle's cloud licensing policies by reference, those policies are not binding contract terms. They represent Oracle's preferred interpretation — which Oracle will assert aggressively at certification, but which can be challenged with specific contractual language analysis. Engage the Oracle Audit Defence service before accepting Oracle's cloud host counting position.
Our Oracle ULA Advisory service reviews your ULA contract's cloud deployment provisions, models the certification count implications of your migration plan, and negotiates written clarification with Oracle before you move a single workload to cloud.
Microsoft Azure faces the same Oracle partitioning policy challenge as AWS. Oracle's position on Azure deployments under a ULA applies the same physical host counting logic — unless the Azure deployment uses dedicated hardware configurations that Oracle recognises as analogous to hard partitioning. Azure's dedicated host offering provides similar options to AWS Dedicated Hosts, and the same analysis applies.
One Azure-specific consideration is Microsoft's Oracle Database integration on Azure. Oracle and Microsoft have a commercial relationship that includes cross-cloud connectivity between Azure and OCI, and a co-marketing arrangement for Oracle Database deployments on Azure. This relationship creates some nuance: Oracle may be more willing to accept reasonable counting positions for Azure deployments where the enterprise is also an Oracle cloud customer, because the joint commercial relationship with Microsoft creates reputational costs for Oracle in being overly aggressive on Azure ULA counting.
This does not mean Azure deployments are safe from Oracle's physical host counting policy — it means the negotiating dynamics are slightly different from pure AWS deployments. Any Azure deployment of Oracle ULA-covered products should be documented with the same rigour as on-premises deployments, and the certification report should address Azure deployments with explicit contractual basis for the counting methodology used.
Google Cloud Platform (GCP) deployments of Oracle Database face Oracle's standard third-party cloud policy. GCP Sole-Tenant Nodes — which provide dedicated physical servers within GCP — offer the closest equivalent to hard partitioning available on GCP for Oracle licensing purposes. Where a ULA deployment uses GCP Sole-Tenant Nodes with a clearly defined processor allocation, there is a contractual argument for counting Oracle licences based on the allocated physical processors rather than the entire underlying GCP host.
GCP's market share for Oracle Database workloads remains smaller than AWS and Azure. Oracle's enforcement posture toward GCP deployments has historically been less aggressive than toward AWS deployments, partly because the commercial stakes are lower. However, this is not a reliable risk management strategy — as GCP's Oracle workload share grows, Oracle's attention will follow. The safest approach for any GCP ULA deployment is to obtain written agreement from Oracle on the counting methodology before deployment, not after.
Bring Your Own Licence (BYOL) is the mechanism by which on-premises Oracle perpetual licences are applied to cloud deployments. In the context of a ULA, BYOL on cloud platforms means that Oracle ULA deployment rights are used to licence Oracle products running on cloud instances — rather than paying the cloud provider's licensed instance pricing (which would be an additional Oracle charge layered on top of your ULA). Understanding whether your ULA covers BYOL on specific cloud platforms requires reading the ULA's product schedule and deployment clause carefully.
Most ULAs define covered deployment locations as the enterprise's own data centres or colocation facilities. "Third-party cloud infrastructure" may or may not be explicitly addressed. Where it is not addressed, the enterprise must determine whether its interpretation of the deployment clause covers cloud BYOL, and whether Oracle's interpretation of the same clause agrees. This is best resolved in writing with Oracle before the deployment, not after. The Oracle Cloud Licensing Guide provides the full framework for BYOL analysis across cloud platforms.
Oracle's Support Rewards programme — which provides OCI credits in exchange for Oracle Cloud spending against on-premises support costs — is separate from BYOL but interacts with it strategically. Enterprises that deploy Oracle ULA licences on OCI via BYOL can accumulate Support Rewards that reduce their on-premises support obligations, effectively using cloud migration to reduce the 22% support cost that will persist after ULA certification. This is one genuine financial benefit of an OCI-first cloud migration strategy during the ULA term.
The optimal cloud migration strategy during a ULA term balances three objectives: maximising the deployment count for certification purposes, managing the compliance exposure of cloud deployments on restricted platforms, and positioning the enterprise's cloud infrastructure for long-term cost efficiency independent of Oracle's preferred OCI path.
For enterprises actively planning cloud migration during a ULA term, the recommended approach is: first, identify which Oracle workloads are ULA-covered and which require separate licences; second, model the certification count impact of migrating each workload to each cloud platform under Oracle's current policy; third, negotiate written clarification from Oracle on counting methodology for your specific migration plan before migration begins; fourth, execute the migration on the agreed basis with documentation; fifth, include cloud deployments with full methodology documentation in the certification report.
Enterprises that migrate Oracle workloads to AWS or Azure without pre-negotiating counting rules with Oracle frequently discover at certification that Oracle intends to count the full physical host — creating a certification count far higher than expected. This is not necessarily Oracle's contractual right, but it becomes Oracle's opening position. Defending that position at certification, months after the migration is complete, is significantly harder than negotiating it before the migration begins. The Oracle Compliance Review service assesses your current cloud deployment position and the certification exposure it creates.
When the ULA certification report includes cloud deployments, the evidence requirements are higher than for on-premises deployments. Oracle's LMS or GLAS review team will scrutinise cloud deployment documentation for three specific elements: the cloud provider configuration documentation showing the underlying physical infrastructure, the Oracle software discovery output showing what is installed on the cloud instances, and the contractual basis for the counting methodology applied.
For OCI BYOL deployments, Oracle typically accepts OCPU-based counting with OCPU allocation documentation from OCI's console. For AWS and Azure deployments, Oracle will challenge any counting methodology that does not account for the physical host and will require detailed justification for any deviation from their physical host counting policy. The justification must reference specific ULA contract language — not Oracle's general licensing policies, which Oracle can change unilaterally at any time and which do not bind the enterprise's contractual rights.
The case studies that inform this area of practice include our energy sector engagement where we successfully defended an AWS-deployed Oracle Database EE count of 96 Processor licences against Oracle's challenge that the full physical host (256 Processor licences) applied. The defence rested on specific ULA deployment clause language that defined "licensable environment" by reference to the enterprise's logical server partition, not the underlying physical infrastructure. The dispute was resolved in the enterprise's favour after six weeks of written negotiation with Oracle's GLAS team. See the full case in our Energy OCI Cloud Migration case study.
Our team has defended cloud deployment counting challenges from Oracle's GLAS and LMS teams across AWS, Azure, and GCP environments. We respond with contractual evidence and defend every position in writing.
Download our Oracle Cloud Migration Licensing Guide — the complete framework for BYOL, ULA cloud deployment rules, OCI vs AWS licence mechanics, and Support Rewards optimisation.
Download Free →Oracle cloud licensing rule changes, ULA cloud deployment strategies, and BYOL optimisation tactics — delivered weekly to enterprise Oracle stakeholders.
Oracle Licensing Experts Team — Former Oracle executives, LMS auditors, and contract managers with 25+ years of experience working exclusively for enterprise buyers. Not affiliated with Oracle Corporation. About us →
Free Research
Download our Oracle OCI Licensing Guide — expert analysis from former Oracle insiders, 100% buyer-side.
Download the OCI Licensing Guide →Free Research
Download our Oracle BYOL on AWS and Azure Guide — expert analysis from former Oracle insiders, 100% buyer-side.
Download the BYOL on AWS & Azure Guide →Free Research
Download our Oracle Licensing in Public Cloud Guide — expert analysis from former Oracle insiders, 100% buyer-side.
Download the Public Cloud Licensing Guide →