Oracle account teams pitch Database@AWS, Database@Azure and Database@Google Cloud as an exit from audit risk. The pitch is wrong. Five audit surfaces survive intact into the Database@Hyperscaler programs: BYOL pool reconciliation, option consumption on the cloud deployment, the customer's wider on-premise estate, Java SE Universal Subscription, and the application-tier Oracle products running alongside the database. LMS has refined three audit patterns against multi-cloud Oracle customers through 2025 and 2026, with average findings of $400K to $8M at list. This article walks the surfaces, the patterns, the data Oracle has access to inside the deployment, and the defensive posture that turns a seven-figure finding into a six-figure settlement.
The pitch from Oracle account teams is that Database@AWS, Database@Azure and Database@Google Cloud move customers out of audit risk. The reasoning: Oracle controls the database stack, Oracle bills the consumption, so what is there for License Management Services to audit. The reasoning is wrong. Database@Hyperscaler deployments carry their own audit exposure, on different surfaces from on-premise but with similar financial impact. Customers who treat the move as audit-elimination rather than audit-shift walk into seven-figure findings.
This article maps the audit surfaces that survive into the Database@Hyperscaler programs, the LMS audit patterns we have seen during 2025 and 2026, the data Oracle has access to inside the multi-cloud deployment, and the defensive posture that keeps the exposure bounded. For the wider audit-defence framework, see the Oracle Audit Guide.
The shift in audit posture matters because the customer's defensive position is different. On-premise audits hit Processor licence counts, VMware partitioning, options usage and indirect access. Database@Hyperscaler audits hit BYOL portability, options consumption on the cloud deployment, ECPU/OCPU sizing, and the customer's broader on-prem estate to validate that BYOL licences are not double-counted. Different audit, different defence.
Five audit surfaces persist on Database@Hyperscaler deployments. Knowing these is the first step in defending against them.
Surface 1: BYOL licence pool reconciliation. When a customer applies Processor licences to Database@AWS BYOL, LMS retains the right to verify that those same licences are not concurrently applied to other deployments. The audit pattern: LMS asks for the customer's BYOL register, then runs Oracle's own scripts against the customer's on-premise estate and other cloud paths to find concurrent application. This is the most common Database@Hyperscaler audit finding in 2026.
Surface 2: Option consumption on the cloud deployment. The licence-included base bundle on Database@Hyperscaler covers EE, Diagnostics, Tuning and basic multitenant. Customers using options outside the base bundle (Active Data Guard, GoldenGate, Real Application Testing, Database Vault, Advanced Security, In-Memory) pay per-OCPU rates for each. LMS audits the cloud deployment for option flags and reconciles against the ordering document; flags that light without an option SKU on the order are a finding.
Surface 3: Customer's wider estate to validate BYOL. Even though the audit triggers at the cloud workload, Oracle audits the customer's entire estate to verify that BYOL licences are genuinely free for cloud application. If the customer's on-premise environment still uses the same licences, the cloud BYOL application is invalid. This is where most multi-cloud customers have unmodelled exposure.
Surface 4: Java SE Universal Subscription. Java SE runs separately from the database stack. A Java SE deployment on the application tier of a Database@AWS workload still carries Java SE Universal Subscription exposure under the Employee Metric. The Java audit team operates separately from the database audit team; one cloud deployment can attract two audits. See Oracle Java licensing guide.
Surface 5: Application-tier products with embedded Oracle. EBS, Fusion Middleware (WebLogic, SOA, Service Bus, OAM), Hyperion, Siebel — these application-tier products often run on EC2 / Azure VM / GCE alongside the Database@Hyperscaler deployment, and they carry their own audit exposure under the Authorized Cloud Environment framework. LMS audits these alongside the database; the customer is exposed across the full application stack, not only the database tier.
Three audit patterns have emerged from LMS engagements with Database@Hyperscaler customers in 2025 and 2026. Each follows a predictable structure.
Pattern 1: The BYOL reconciliation audit. LMS opens a friendly soft audit (USMM script request) on the customer's on-premise estate, citing the recent Database@Hyperscaler BYOL adoption. The customer runs USMM and provides the output. LMS reconciles the on-premise USMM result against the BYOL register provided to the Database@Hyperscaler ordering team. Mismatches (licences used in both places, or licences applied to BYOL that are also under active on-prem use) become findings. Average finding: $2.4M to $5.6M at list, settling at 25 to 40 percent of list after negotiation. Defence: a centralised BYOL register with movement events documented in writing.
Pattern 2: The option consumption audit on the cloud deployment. LMS pulls DBA_FEATURE_USAGE_STATISTICS data from the Database@Hyperscaler deployment directly through Oracle's privileged access. Flags that light without an option SKU on the cloud ordering document become findings. Average finding: $400K to $2.1M at list, settling at 30 to 50 percent of list. Defence: pre-deployment option footprint analysis and option pre-licensing inside the cloud ordering document.
Pattern 3: The Java-database cross audit. The Java audit team approaches the customer to ask about Java SE deployment, often citing the recent database cloud move as evidence of an actively-managed Oracle estate. The audit finds Java SE installations on application-tier servers outside the Universal Subscription, triggers Employee Metric pricing across the customer's full enterprise, and produces a finding much larger than the database side. Average finding: $1.8M to $8M at list, settling at 35 to 55 percent of list. Defence: enterprise-wide Java inventory and migration plan to Eclipse Temurin, Amazon Corretto or Microsoft OpenJDK on the non-Universal-Subscription footprint.
Independent assessment of your Database@Hyperscaler audit exposure, BYOL register quality, option footprint and Java cross-exposure. Identifies findings before LMS does. Fixed-fee.
Oracle has structural data access to the Database@Hyperscaler deployment that it does not have on a pure on-premise estate. Customers signing the ordering document often miss this.
The data Oracle sees by default:
What Oracle does not have access to by default:
The asymmetry is the audit defence point. Oracle has rich data on the cloud deployment itself, weak data on the customer's wider estate. Most BYOL findings come from extracting the wider-estate data through soft-audit USMM scripts. Decline soft USMM requests where contract permits, run USMM internally first to know what would be returned, and engage advisory help before any audit response. See Oracle audit guide and Oracle audit defence service for the formal response framework.
The list looks long; in practice it is the same checklist a well-run on-premise Oracle estate already runs, extended to the cloud surface. Customers who already have an Oracle estate management discipline find the multi-cloud overlay is incremental work. Customers who move to multi-cloud Oracle without that discipline build it under audit pressure, which is the worst possible time.
The economic case for the discipline is straightforward. We see Database@Hyperscaler audit findings settle at 30 to 50 percent of list. A well-prepared customer typically settles at 8 to 15 percent of the initially-quoted finding. The difference on a $4M finding is $1.4M to $1.8M, which buys 8 to 12 years of the defensive discipline at typical engagement rates.
No. The audit surfaces shift but do not disappear. Five audit surfaces persist: BYOL licence pool reconciliation, option consumption on the cloud deployment, the customer's wider on-prem estate (audited to validate BYOL), Java SE Universal Subscription on the application tier, and application-tier Oracle products like EBS or WebLogic running alongside the database. Customers who treat the cloud move as audit elimination walk into seven-figure findings.
LMS pulls DBA_FEATURE_USAGE_STATISTICS data directly from the cloud deployment through Oracle's privileged operations access. Flags that light without an option SKU on the ordering document become findings. LMS also requests USMM output from the customer's wider on-premise estate to reconcile BYOL licence claims, and may audit Java SE deployment across the enterprise as a separate parallel exercise.
Oracle has read access to DBA_FEATURE_USAGE_STATISTICS, OCPU/ECPU consumption, edition and version, RAC/ADG/GoldenGate enablement flags, multitenant tenant counts, and patch-level and SR ticket history. Oracle does not have access to customer data inside the database, application code, or the customer's wider on-premise estate by default - those have to be requested through formal audit processes.
Three patterns dominate: BYOL reconciliation findings average $2.4M to $5.6M at list, settling at 25-40 percent. Option consumption findings on the cloud deployment average $400K to $2.1M at list, settling at 30-50 percent. Java-database cross-audit findings average $1.8M to $8M at list, settling at 35-55 percent. A well-prepared customer typically settles at 8-15 percent of the initial quoted finding.
Some early ordering documents do preserve LMS audit rights that arguably should not apply to a cloud service. Review the audit clause before signing and narrow it. Cloud services are typically audited through consumption reconciliation rather than LMS scripting, and the ordering document should reflect that. Push for an audit clause that limits LMS to the BYOL portion only, not to the consumption side that Oracle already meters.
Twice a month. Oracle pricing moves, audit-defence tactics, GenAI Service rate changes. Written by former Oracle insiders.
No spam. Unsubscribe any time. Independent — not affiliated with Oracle Corporation.