Oracle ULA Third-Party Cloud Restrictions: What Your Agreement Actually Permits on AWS, Azure & GCP

Oracle's Official Cloud Licensing Policy and the ULA

Oracle published its Authorized Cloud Environments policy in 2017, formalising rules that had existed informally in ULA and license agreements since at least 2013. The policy identifies specific cloud environments and infrastructure types where Oracle licenses — including ULA licenses — may be deployed. The practical effect is a two-tier system: Oracle Cloud Infrastructure (OCI) is unrestricted for Oracle license deployment; AWS, Azure, and a limited set of other providers are permitted under specific infrastructure configurations; and the remaining cloud market is effectively prohibited for production Oracle deployment under standard license terms.

For ULA holders, the cloud policy intersects with ULA deployment rights in a specific way. During the ULA term, the unlimited deployment grant covers deployment in authorized cloud environments — meaning ULA licenses can be deployed on AWS or Azure, but only on infrastructure configurations that Oracle considers license-compliant. At certification, deployments in cloud environments are counted under the same Processor metric rules as on-premises deployments, using Oracle's cloud core factor rules or the physical server count depending on the cloud provider's infrastructure type.

Oracle's commercial position behind the cloud policy is transparent once you understand Oracle's account team incentive structure. Restricting ULA deployment on competitor clouds serves two purposes: it pushes ULA-dependent enterprises toward OCI for cloud migration (where Oracle has a revenue interest in ULCs — Universal Credits), and it creates compliance leverage that Oracle's account teams can use in renewal conversations. "Your cloud infrastructure may not be ULA-compliant" is a powerful opening position in a ULA renewal negotiation, and Oracle's LMS team has the scripts to investigate it.

ULA Cloud Restriction Clauses: The Contractual Language

Standard Oracle ULA agreements from 2013 onwards typically contain a definition of "Authorized Deployment" or incorporate Oracle's cloud licensing policy by reference. The substantive restriction is that Oracle licenses may only be deployed in environments meeting Oracle's definition of "authorized cloud environment" — which, for third-party clouds, typically means environments where Oracle can confirm that license counting is possible under the standard Processor metric framework.

The specific language varies by agreement vintage and negotiation outcome, but the core provisions Oracle seeks to maintain are: a restriction on deploying ULA licenses in shared tenancy environments on third-party clouds where physical processor counts cannot be verified; a requirement that any third-party cloud deployment be on "authorized" hardware as defined by Oracle's published policy; and a right for Oracle's LMS team to request evidence of cloud deployment compliance during or after the ULA term.

The critical distinction in the contractual language is between "authorized" and "unauthorised" cloud configurations. Oracle does not prohibit all third-party cloud deployment — it requires specific infrastructure configurations that make Oracle's license counting methodology applicable. Shared, multi-tenant virtual machine configurations on AWS or Azure where physical processor counts cannot be isolated are typically not permitted. Dedicated instances — AWS Dedicated Hosts, Azure Dedicated Hosts — are permitted because they provide the physical isolation needed to apply Oracle's Core Factor Table calculation.

AWS: Authorized Infrastructure and ULA Deployment Requirements

Amazon Web Services is one of three cloud providers Oracle has formally recognized as an authorized deployment environment — but Oracle's recognition comes with specific infrastructure requirements that significantly constrain how ULA licenses can actually be used on AWS. The authorized configuration for Oracle Database on AWS under standard Oracle license terms is AWS Dedicated Hosts: bare-metal server instances that provide complete physical isolation from other AWS tenants, allowing Oracle's Processor metric to be applied to a known and verifiable core count.

Standard AWS EC2 instances — including those on Dedicated Instances (which provide hardware isolation from other customers but share physical cores within your own account) — are not authorized for Oracle Database deployment under standard Oracle license terms. The distinction between Dedicated Hosts (authorized) and Dedicated Instances (not authorized) catches many enterprises who believe that paying for Dedicated Instances satisfies Oracle's isolation requirement. It does not. Oracle requires that you can apply its Core Factor Table to identified physical cores — which requires Dedicated Host-level isolation, not Dedicated Instance-level isolation.

Under a ULA, the processor count for AWS Dedicated Host deployments is calculated using the physical cores on the host multiplied by the applicable Core Factor. AWS Dedicated Hosts provide specific core counts depending on the instance family, and Oracle's Core Factor Table is applied to determine the Processor metric license requirement. This calculation often makes AWS Dedicated Host deployments significantly more expensive on a per-workload basis than equivalent shared infrastructure — which is precisely Oracle's commercial intent.

For ULA holders migrating workloads to AWS, the practical implication is that production Oracle Database deployments must run on Dedicated Hosts during the ULA term to be compliant, and those Dedicated Host deployments will count toward the certified processor total at certification. This should inform ULA maximisation strategy: AWS Dedicated Host deployments are legitimate ULA deployments that increase the certified count, which may or may not be beneficial depending on whether the enterprise wants to maximize or minimize its certified processor total.

Azure: Dedicated Host and the BYOL Compliance Framework

Microsoft Azure's authorized Oracle deployment configuration mirrors AWS: Azure Dedicated Host is the required infrastructure for Oracle Database deployment under standard Oracle license terms, including ULA licenses. Azure Dedicated Hosts provide physical server isolation — the entire bare-metal server is dedicated to a single Azure customer — allowing Oracle's Processor metric and Core Factor Table to be applied to a verifiable physical core count.

Azure's standard VM infrastructure — including Standard, Premium, and even Isolated VM sizes — is not authorized for Oracle Database deployment under standard Oracle licensing. This is a commercially significant restriction because Azure's standard VM estate is typically much less expensive than Dedicated Host configurations, and many enterprises have attempted to run Oracle Database on standard Azure VMs under the assumption that "cloud BYOL" means bring your own license to any cloud instance. Oracle's position is that BYOL applies to authorized infrastructure only — and standard Azure VMs are not authorized.

The Oracle Database Licensing on Azure guide details the full compliance framework for Azure deployments. For ULA holders specifically, the relevant question is whether Azure Dedicated Host deployments during the ULA term should be counted toward or excluded from the certified processor total. The answer depends on the ULA's specific language, the enterprise's maximisation strategy, and the post-certification support cost implications of a higher certified count.

GCP: Oracle's Least Permissive Position

Google Cloud Platform occupies the most restrictive position in Oracle's cloud authorization framework. Unlike AWS and Azure, where Oracle has identified specific infrastructure configurations (Dedicated Hosts) that meet its licensing requirements, Oracle's published policy does not include GCP as an authorized deployment environment for Oracle Database under standard license terms.

This does not mean Oracle Database cannot be deployed on GCP — it means that standard Oracle licenses, including ULA licenses, do not cover GCP deployments under Oracle's published policy without a separate written authorization from Oracle. In practice, Oracle has granted individual written authorisations for specific GCP deployments, typically through its Global Cloud Licensing Agreement or under specific contractual carve-outs negotiated in the ULA Order Form. However, absent specific written authorization, deploying Oracle Database on GCP under a ULA creates an unlicensed deployment that is not covered by the ULA's unlimited grant.

The commercial logic behind Oracle's GCP restriction is straightforward: Google is Oracle's competitor in both cloud infrastructure and enterprise database (through Google Cloud Spanner, AlloyDB, and BigQuery). Restricting Oracle license deployment on GCP reduces the attractiveness of GCP for Oracle-dependent enterprises and pushes Oracle customers toward OCI or toward the more expensive Dedicated Host configurations on AWS and Azure. For Oracle account teams, GCP compliance questions are a direct competitive weapon.

Enterprises with existing Oracle Database deployments on GCP — or planning GCP migrations — must either obtain specific written authorization from Oracle, restructure those workloads to use non-Oracle databases, or accept that those deployments are potentially out of compliance with their ULA or standard license terms. Our Oracle Cloud Advisory team regularly assists enterprises in resolving GCP compliance positions, including negotiating retrospective authorisations where warranted.

OCI's Commercial Advantage in ULA Structures

Oracle Cloud Infrastructure is Oracle's preferred outcome for any ULA holder considering cloud migration — and Oracle's commercial and contractual structure is deliberately designed to make OCI the most attractive option. Under Oracle's Authorized Cloud Environment policy, OCI is unrestricted for Oracle license deployment: any OCI compute shape, any tenancy model, and any OCI infrastructure configuration is authorized for Oracle Database deployment without the Dedicated Host requirements that apply on AWS and Azure.

Beyond deployment freedom, Oracle offers specific commercial incentives for ULA holders migrating to OCI. The ULA-to-OCI pathway typically involves converting perpetual license entitlements into OCI Universal Credits, which can be used for any OCI service including Autonomous Database, Exadata Cloud Service, and standard compute. Oracle's Support Rewards program offers credits against OCI spend for ongoing Oracle support payments — effectively reducing the OCI bill for enterprises with large support obligations. For ULA holders with large certified processor counts generating significant annual support fees, Support Rewards can make OCI economics genuinely competitive.

The commercial reality, however, is that OCI's advantages over AWS and Azure in raw price-performance are limited outside Oracle-specific workloads. Enterprises with multi-cloud strategies or workloads spanning Oracle and non-Oracle infrastructure often find that OCI's benefits are primarily relevant for Oracle Database workloads, while AWS and Azure remain more cost-effective for non-Oracle applications. The ULA cloud restriction should not drive cloud architecture decisions that compromise the broader enterprise technology strategy — but it should be factored into the full cost comparison.

Negotiating Cloud Deployment Rights in a ULA

The most effective approach to Oracle ULA cloud restrictions is to negotiate specific deployment rights into the ULA before signing or at renewal. Oracle's standard ULA template restricts third-party cloud deployment to Dedicated Host configurations — but this restriction is negotiable, particularly in large-value deals where Oracle has strong renewal motivation.

Specific cloud deployment rights that enterprises can negotiate include: explicit authorization for standard (non-Dedicated Host) VM deployment on specific cloud providers, subject to a Named User Plus or alternative metric that does not require physical core isolation; a broader definition of "authorized cloud environment" that includes additional providers or infrastructure types; and a contractual right to count cloud deployments under an alternative processor calculation methodology (such as the OCI-equivalent vCPU counting rules) on AWS and Azure.

These concessions are more achievable in specific contexts: large-value ULA renewals where Oracle wants to retain the account; multi-product deals where Oracle is bundling Database, Java, and Middleware under a single unlimited agreement; and situations where the enterprise has a credible migration alternative (such as moving Oracle Database workloads to PostgreSQL) that creates genuine commercial pressure on Oracle's deal team. Our Contract Negotiation service has successfully negotiated cloud deployment expansions into ULA agreements across multiple enterprise engagements.

Cloud Deployments at ULA Certification: Counting and Compliance

At ULA certification, cloud deployments on authorized infrastructure are counted using Oracle's standard methodology for that environment. AWS Dedicated Host deployments use the physical core count of the Dedicated Host multiplied by the Core Factor Table value. Azure Dedicated Host deployments use the same methodology. OCI deployments typically use OCI's vCPU-to-OCPU ratio with the relevant Core Factor applied.

Cloud deployments on non-authorized infrastructure create a specific certification problem: they are potentially unlicensed, which means they cannot be included in the certified ULA count — but they also represent a compliance exposure that Oracle's LMS team may identify if they have visibility into the enterprise's cloud infrastructure. The risk of non-authorized cloud deployments at certification is therefore twofold: the deployment does not contribute to maximizing the certified count, but it does create a compliance exposure that Oracle could use as back-license leverage post-certification.

The pre-certification audit for enterprises with cloud infrastructure should specifically map all cloud Oracle deployments against Oracle's authorized environment list, identify any deployments on non-authorized infrastructure, and develop a remediation plan — either migrating non-authorized deployments to authorized infrastructure before certification, or obtaining retrospective written authorization from Oracle. For deployments that cannot be remediated before certification, the risk should be quantified and factored into the certification negotiation strategy.