Oracle public cloud audit: AWS and Azure.

Oracle workloads on AWS and Azure sit under the authorised cloud environment policy. The policy permits a favourable counting ratio for Oracle Database, Application Server, and certain other programs running on listed cloud providers. The favourable ratio sounds simple on paper but produces complex audit findings in practice because the instance types and the BYOL evidence rarely match Oracle's expectations. This piece walks through the rules, the audit position, and the buyer side defence that holds for AWS and Azure Oracle deployments.

1. The authorised cloud policy.

Oracle's authorised cloud environment policy lists AWS, Microsoft Azure, and Google Cloud Platform as recognised cloud providers. Workloads running on these clouds are counted using a vCPU based ratio rather than the on premise processor core formula. For Oracle Database Enterprise Edition, two vCPUs equate to one processor licence when hyperthreading is enabled. For Standard Edition products, the ratio is four vCPUs to one licence.

The policy sounds favourable. In practice the audit position uses the policy as a floor, not a ceiling, and contests the qualifying conditions aggressively. The buyer side defence depends on understanding the policy text precisely and documenting the qualifying conditions thoroughly. See our Oracle on AWS compliance note for the detailed AWS framework.

2. The instance type discipline.

The cloud counting ratio applies only when hyperthreading is enabled and the instance type is one that Oracle accepts as supporting the ratio. AWS metal instances, dedicated hosts with specific configurations, and certain Azure instance families do not qualify for the ratio. Workloads running on non qualifying instance types are counted at one vCPU equals one processor licence, doubling or quadrupling the licence requirement.

The audit team examines instance types carefully and challenges any instance that does not match the expected pattern. The buyer side response is to document instance types from the deployment date forward, maintain change records, and prepare evidence that the qualifying conditions were met throughout the audit period. See our Oracle Database product page for the Database licensing context.

3. The BYOL evidence requirement.

Oracle workloads on AWS and Azure run as BYOL by default. The buyer must prove ownership of the licences that cover the cloud deployment. The proof requires evidence of the original perpetual licence purchase, evidence of continuous support, and evidence that the licences are not double allocated to on premise deployments.

The audit position often challenges the BYOL evidence by claiming that the licences in question are allocated to other deployments or that support has lapsed. The buyer side defence is to maintain a clear licence allocation register, with explicit mapping between perpetual entitlements and cloud workloads. Without that register, the audit position holds.

4. The Oracle policy is not contract.

The same principle that applies to VMware applies to the cloud licensing policy. The authorised cloud document is a policy publication, not a contractual amendment. Unless the policy has been incorporated by reference into the Oracle Master Agreement, it is not contractually binding on either party.

In practice, both sides usually treat the policy as the operating framework because the alternative is litigation. But the contract versus policy distinction matters in audit. Oracle's audit findings rely on the policy. The buyer's leverage in commercial settlement comes from the recognition that the policy is non binding. See our VMware audit defence note for the parallel framework.

5. The mobility theory.

Oracle's audit position on public cloud also includes a mobility theory similar to the VMware vMotion theory. The position is that any workload that could be moved to a non qualifying instance type requires licensing for the non qualifying configuration. The theory is even less defensible than the VMware version because cloud mobility is a feature of the cloud platform, not a configuration choice by the buyer.

The buyer side response is to document deployment policy, demonstrate that the mobility capability is not actively used, and reject the theoretical counting position. The defence works when the operational evidence supports the deployment discipline. See our audit defense service for the negotiation framework.

6. The container and Kubernetes complication.

Workloads running in containers, Kubernetes clusters, and serverless configurations on AWS and Azure introduce additional audit complexity. Oracle's published guidance on container licensing is limited and often outdated. The audit position varies by audit team and by region. Some auditors apply the cluster wide approach used for VMware. Others apply the vCPU ratio for the actual container resources.

The buyer side defence depends on the architecture. Containers with bounded resource allocation can be defended at the bounded count. Unbounded containers are harder to defend. Kubernetes deployments with namespace level isolation and resource quotas are defensible. Unconstrained Kubernetes deployments are not. The defence work happens at the architecture stage, not the audit stage.

7. The commercial settlement pattern.

Public cloud audit findings are typically settled with a combination of new licence purchase, support uplift, and forward operating policy changes. The settlement often includes commitments to specific instance types, BYOL discipline, and ongoing reporting to Oracle. The forward commitments are negotiable. The historical findings are normally settled at a meaningful discount to the initial finding.

The settlement framework that works requires three principles. The settlement should reflect actual deployment, not theoretical mobility. The settlement should produce licences the buyer actually needs going forward. The settlement should close the audit cleanly with a release of historical claims. See our audit defense pillar and the Oracle Audit Defense Handbook for the broader settlement framework.

8. What disciplined buyers do.

• Pin instance types. Deploy only on instance types that qualify for the favourable ratio.
• Document BYOL allocation. Maintain a register mapping perpetual licences to cloud workloads.
• Verify support continuity. Confirm that support is current on every licence allocated to cloud.
• Limit container scope. Use bounded resource configurations for containerised Oracle workloads.
• Reject mobility theory. Hold the contract line on actual deployment versus theoretical configuration.
• Engage independent advisory. External advisory changes the negotiation dynamic in commercial settlement.
• Document architecture changes. Maintain a change log for instance type modifications and migrations.

For the broader cloud framework see our cloud negotiation pillar, the BYOL deal page, the Oracle Database product page, and the audit defense pillar.