Oracle Audit for Cloud Environments:
OCI, AWS, Azure & GCP Rules

The Rise of Oracle Cloud Audits

Oracle's LMS team expanded its audit scope to cloud environments in earnest from 2021 onwards, coinciding with the rapid enterprise migration of Oracle workloads to public cloud platforms. The trigger for this expansion was Oracle's commercial observation that enterprises migrating Oracle Database to AWS and Azure were doing so under the assumption that cloud BYOL rules applied — often without the infrastructure configurations required to make BYOL valid under Oracle's policy.

The financial stakes in cloud audit findings are high. An enterprise running Oracle Database EE on standard AWS EC2 instances — without Dedicated Host configuration — is not eligible for BYOL under Oracle's published licensing policy. If that deployment is running on a 64-vCPU instance type, Oracle's audit claim calculates the licence obligation based on the entire underlying physical processor count of the AWS server, not the EC2 vCPU allocation. The resulting claim can be orders of magnitude larger than the customer's internal licence count.

Oracle's audit programme targets cloud deployments through a combination of mechanisms: LMS script deployment via remote access requests, cloud platform API-based discovery tools, and — increasingly — intelligence gathered from Oracle cloud services console data when customers have any Oracle services running in OCI alongside their on-premises estate. Our Oracle audit defence team assesses cloud deployment compliance as an integrated part of every engagement, not as a separate track.

OCI: Oracle's Own Cloud Platform

Oracle Cloud Infrastructure is the platform for which Oracle has published the most complete and customer-favourable cloud licensing rules. Oracle's motivation is transparent: OCI needs to compete with AWS and Azure, and providing clear, economical licensing rules for Oracle software on OCI is a key competitive differentiator.

For Oracle Database BYOL on OCI, the licence is measured per OCPU (Oracle Compute Unit), where one OCPU corresponds to two vCPUs. This is significantly more favourable than on-premises processor counting — an OCI deployment on a 16-OCPU instance requires 16 processor licences, whereas the equivalent on-premises deployment on a physical server might require 64 processor licences based on the Core Factor Table applied to all physical cores.

OCI also offers the Oracle Support Rewards programme, which credits 25–33% of Oracle on-premises support spend as OCI Universal Credits. For organisations spending $5M+ annually on Oracle on-premises support, this represents $1.25–1.65M of annual OCI credit — which can substantially offset OCI infrastructure costs. The catch: Support Rewards credits are only available on active Oracle support agreements, creating a dependency on continued 22% annual support payments.

Oracle's Database cloud service on OCI (Autonomous Database, ExaDB-D, ExaDB-C@C) uses a pure subscription model rather than BYOL — which eliminates licence compliance risk for those service tiers at the cost of a higher per-unit price. These services are audit-proof by design. Our Oracle cloud advisory service provides detailed OCI platform selection analysis, including the BYOL versus subscription economics for each Oracle workload type.

AWS: Authorised Cloud Infrastructure Rules

Oracle has published specific licensing policy for Oracle software on AWS through its "Authorized Cloud Environments" documentation. The core rule: Oracle Database on AWS is supported for BYOL only on AWS Dedicated Hosts or AWS Dedicated Instances — not on standard EC2 instances, AWS RDS, or any other shared infrastructure.

The compliance trap that catches a significant proportion of enterprises is the migration pathway. When organisations lift-and-shift Oracle Database from on-premises to AWS EC2 to save infrastructure cost, they typically deploy on standard EC2 instances without Dedicated Host configuration — because Dedicated Hosts cost significantly more than standard instances. The result is an Oracle deployment that is running on AWS but has no valid BYOL coverage, because the deployment fails the Dedicated Host requirement.

Oracle's audit position for this scenario is that the customer must licence Oracle Database based on the entire physical processor count of the AWS server hosting the EC2 instance — information that Oracle obtains from USMM output which reports underlying hardware configuration. For a large EC2 instance type on a modern AWS server, this physical processor count may be 48–96 cores, generating a licence obligation that the customer never anticipated and that bears no relationship to the EC2 vCPU count they provisioned.

Amazon RDS for Oracle is an AWS-managed service that includes Oracle licence costs in the service price for some instance types. BYOL on RDS uses the same Dedicated Host requirement as EC2. Oracle Marketplace listings on AWS that include Oracle licence are also available, which provide Oracle-authorised deployment without separate BYOL compliance management — at a premium price.

Azure: BYOL and Dedicated Host Requirements

Oracle's BYOL policy for Azure mirrors the AWS approach: BYOL Oracle Database is only supported on Azure Dedicated Host infrastructure, not on standard Azure virtual machines. The calculation methodology on Azure Dedicated Host applies per vCPU on the dedicated host, with the same 2-vCPU-to-1-processor-licence ratio as AWS Dedicated Host.

Microsoft and Oracle have an interoperability partnership that provides interconnection between Azure and OCI data centres, enabling hybrid architectures where Oracle applications run on Azure while Oracle Database runs on OCI under standard BYOL terms. This architecture — supported through Oracle Interconnect for Azure — is technically viable but adds network latency that must be evaluated for each application workload.

Azure has a broader ecosystem of Oracle-related services than AWS, including Oracle Database on Azure (a new jointly-managed service announced in 2023) that provides Oracle-managed Oracle Database on dedicated infrastructure within Azure data centres. This service uses Oracle's OCPU-based pricing model, making it more licence-economical than BYOL on standard Azure VMs and providing a supported path for Oracle workloads in Azure environments without the Dedicated Host compliance complexity.

GCP: The Most Restrictive Cloud Option

Google Cloud Platform is the most restrictive of the major public cloud providers for Oracle BYOL deployments. Oracle does not publish GCP as an "Authorized Cloud Environment" in the same category as AWS and Azure. Oracle's position is that running Oracle software BYOL on GCP standard infrastructure is not authorised — meaning customers running Oracle on standard GCP virtual machines have no valid BYOL path and are potentially running unlicensed Oracle software.

Oracle has made exceptions for specific GCP deployment architectures, including GCP Sole-Tenant Nodes (equivalent to Dedicated Hosts), where BYOL may be permitted under specific conditions. However, the published guidance is less clear than for AWS and Azure, and customers should obtain explicit written confirmation from Oracle before relying on GCP-based BYOL in an audit context.

The practical implication for enterprises running Oracle workloads on GCP is significant: unless the deployment is on GCP Sole-Tenant Nodes with documented Oracle authorisation, there is material audit exposure if Oracle's LMS team identifies Oracle Database installations on GCP infrastructure. Our cloud advisory service includes GCP compliance assessment and, where needed, migration planning to compliant infrastructure.

BYOL: The Compliance Traps Everyone Hits

Beyond the cloud-specific infrastructure requirements, BYOL creates a category of compliance traps that apply across all cloud platforms and that Oracle's LMS team has become increasingly sophisticated at identifying.

The first trap is simultaneous use: when an organisation migrates Oracle Database from on-premises to cloud, the BYOL arrangement requires that the on-premises licences are no longer in active use. A phased migration where on-premises systems remain active while cloud deployments ramp up creates a period of simultaneous use that violates the BYOL terms. Oracle's audit specifically looks for evidence of simultaneous on-premises and cloud deployment using the same licence set.

The second trap is support continuity: BYOL requires active Oracle support on the on-premises licences being brought to cloud. If a customer has moved to a third-party support provider for their on-premises Oracle environment — using the licence savings to fund cloud migration — they have broken the support chain that BYOL requires. Oracle's position is that BYOL licences must have Oracle-provided support (not third-party support) to be valid for cloud deployment.

The third trap is licence type eligibility: not all Oracle licence types are eligible for BYOL on all cloud platforms. Named User Plus licences, Application-specific licences, and licences with specific use restrictions may not qualify for BYOL on competing cloud platforms under Oracle's policy. Full Processor licences provide the broadest BYOL eligibility, but even these are subject to the platform-specific infrastructure requirements.

Our Oracle licence optimisation service includes a BYOL eligibility audit that identifies which licences in your estate qualify for cloud use, on which platforms, under what conditions — and the documentation framework to demonstrate compliance to Oracle's audit team.

How LMS Audits Target Cloud Deployments

Oracle's LMS audit methodology for cloud environments has evolved significantly. Early cloud audits relied on the same USMM scripts deployed against cloud VMs — which provided Oracle with installation data but not the physical infrastructure context needed to calculate the full licence obligation. Current LMS methodology combines USMM with cloud infrastructure discovery tools that can identify underlying host configuration on Dedicated Host and shared infrastructure, enabling Oracle to build claims that account for the full physical processor exposure.

For AWS and Azure, Oracle's cloud audit approach typically involves requesting that the customer run USMM on all cloud instances running Oracle software, alongside providing infrastructure reports from the cloud console showing instance types, host configurations, and placement information. This combination gives Oracle the data it needs to identify Dedicated Host gaps — instances running Oracle on shared infrastructure — and build claims accordingly.

Oracle has also begun using data from its own cloud services to inform audits of on-premises and competing cloud environments. Organisations with OCI tenancies that also run Oracle on-premises may find that Oracle cross-references OCI licence usage data with on-premises USMM output to identify dual-use patterns. This represents a significant expansion of Oracle's audit intelligence capability that organisations running hybrid Oracle estates must account for in their compliance strategy.

Cloud Audit Defence Strategy

Defending against Oracle cloud audit claims follows the same evidence-based framework as on-premises defence, with additional emphasis on infrastructure documentation. The key elements of a cloud audit defence are: documented proof of Dedicated Host configuration for all BYOL deployments; BYOL licence eligibility confirmation for each cloud-hosted Oracle product; evidence of no simultaneous on-premises use; and active Oracle support documentation for all BYOL licences in use.

Proactive compliance architecture is even more important in cloud environments than on-premises, because cloud infrastructure changes frequently — instances are created, modified, and terminated as part of normal operations — and BYOL compliance requires that all Oracle-running instances are at all times on eligible infrastructure. A single CI/CD pipeline that creates a standard EC2 instance with Oracle Database for a development environment can create an audit liability in seconds if the BYOL policy is not implemented as an infrastructure guardrail.

The most effective cloud Oracle compliance framework we have implemented in client environments includes: infrastructure-as-code templates that enforce Dedicated Host placement for Oracle workloads; automated compliance scanning that flags any Oracle installation on non-compliant cloud infrastructure; CMDB integration that tracks licence assignments to cloud instances in real time; and quarterly compliance reviews that validate BYOL eligibility across the estate. Read our complete Oracle cloud licensing guide for the full framework.

If your organisation is already in an Oracle cloud audit, contact our audit defence team immediately. Cloud audit claims are among the fastest-escalating in Oracle's programme — the gap between notification and Oracle presenting a claim is often shorter for cloud audits than for on-premises, and the technical defence must be assembled quickly to be effective. Our team can provide an independent cloud compliance assessment and begin the technical dispute within days of engagement.