Java SE cloud counting confuses most enterprises because two completely different rules apply at once. The current Java SE Universal Subscription counts your total employee headcount and ignores where Java runs — cloud or on-premises. Legacy Processor and NUP subscriptions, still active in thousands of contracts, count vCPUs on the cloud. Get the wrong model and you over-buy, or hand Oracle an audit claim.
Short answer: Java SE cloud counting depends on which subscription you hold. Under Oracle's current Java SE Universal Subscription, Oracle counts every employee in your organization and ignores cloud instances entirely. Under legacy Java SE Processor subscriptions, Oracle counts cloud vCPUs — typically 2 vCPUs per Processor license when hyper-threading is on.
Java SE cloud counting is hard because Oracle runs two licensing models in parallel, and they count the cloud in opposite ways. The Java SE Universal Subscription — Oracle's current offering since January 2023 — is the Employee Metric: a per-headcount license that does not care where Java runs. The legacy Java SE Subscription, sold from 2019 to 2022 on Named User Plus (NUP) and Processor metrics, is still live in thousands of multi-year contracts and counts the actual cloud cores Oracle JDK runs on.
A Processor license is a unit of Oracle licensing tied to the processing cores a program runs on. A Named User Plus license is tied to the number of distinct individuals authorized to use the software. The Employee Metric, by contrast, is tied to your total workforce. Which metric is in your contract decides every cloud counting question that follows — so the first step in any cloud Java review is reading the ordering document, not scanning the servers.
This split is why two enterprises running identical Java workloads on AWS can owe wildly different amounts. Our full Oracle Java Licensing Guide maps the history of these metric changes, and our Java Licensing service starts every engagement by confirming which model actually governs your contract before counting a single instance.
Under the Java SE Universal Subscription, the cloud is irrelevant to the count. Oracle licenses every employee in your organization once any Oracle Java SE is deployed anywhere, so 10,000 employees cost the same whether Java runs on two cloud containers or two thousand. This is the single most important fact in Java SE cloud counting, and most over-buying comes from teams trying to count cloud instances that Oracle never asked them to count.
The Java SE Universal Subscription is an employee-based license priced per total headcount, including full-time staff, part-time staff, and contractors performing services for the organization. Because the metric ignores deployment, moving Java workloads from on-premises to AWS, Azure, or Google Cloud changes nothing about the subscription quantity. Lift-and-shift migrations, cloud bursting, and adding new cloud regions all leave the Employee Metric count untouched.
The practical consequence is counterintuitive: under the Employee Metric, the only way the cloud reduces your Java cost is by eliminating Oracle JDK entirely. Removing Oracle JDK from 200 cloud VMs but leaving it on one on-premises server keeps you fully liable. We break the per-employee math down in detail in our Java SE Universal Subscription per-employee math article, and we define the headcount boundaries in what counts as an "employee" for Java SE.
The trap: Teams build elaborate cloud inventory counts to "right-size" a Universal Subscription. Oracle does not price the subscription on that inventory — it prices on headcount. Counting instances wastes effort and, worse, the inventory you hand Oracle becomes audit evidence of where Oracle JDK is running.
The wrong assumption costs six figures in either direction. Our Cloud & OCI advisory team reads your Java ordering documents and tells you exactly how Oracle will count your cloud estate — before Oracle does.
For legacy Java SE Processor subscriptions, Oracle counts cloud cores using its Cloud Computing Policy: on authorized public clouds, 2 vCPUs equal 1 Processor license when hyper-threading is enabled, and 1 vCPU equals 1 Processor when it is not. So an Oracle JDK workload on an 8-vCPU AWS instance with hyper-threading on requires 4 Java SE Processor licenses — and that count rises with every additional instance.
The Authorized Cloud Environment is Oracle's defined list of approved third-party clouds — currently AWS and Microsoft Azure — where this vCPU-to-Processor conversion applies. Google Cloud and other providers are not "authorized" under Oracle's policy, which means Oracle's standard on-premises core-factor rules can be argued to apply instead, generally producing a higher count. This distinction matters enormously for legacy Processor deals and is a frequent source of disputed audit findings.
| Scenario | vCPUs | Hyper-threading | Processor licenses required |
|---|---|---|---|
| AWS m5.2xlarge (authorized) | 8 | On | 4 |
| Azure D8s (authorized) | 8 | On | 4 |
| AWS instance, HT disabled | 8 | Off | 8 |
| GCP n2 (not authorized) | 8 | n/a | Core-factor rules may apply |
| Counting reflects Oracle's Cloud Computing Policy for authorized clouds. Confirm current policy text in your contract; Oracle has revised its authorized-cloud definitions over time. | |||
The key behavior to watch with legacy Processor deals is peak concurrency. Oracle counts the maximum number of vCPUs running Oracle JDK during the measurement period, not the average. An autoscaling group that bursts to 64 vCPUs for one hour a day can be counted at its peak, not its baseline — turning a modest steady-state footprint into a large license requirement. Pin Oracle JDK workloads to fixed, right-sized instances rather than elastic groups wherever a legacy Processor metric still governs.
Not reliably. Many AWS, Azure, and Google Cloud marketplace images ship with Oracle JDK preinstalled rather than a free OpenJDK build, and running Oracle JDK in production without a Java SE subscription is a license violation regardless of who built the image. Across our engagements, roughly one in three cloud Java estates runs Oracle JDK from a marketplace or vendor image that the customer assumed was free OpenJDK (Oracle Licensing Experts, 2026).
The risk compounds with infrastructure-as-code. A single base image with Oracle JDK baked in, deployed through Terraform or an auto-scaling launch template, can replicate an unlicensed Oracle JDK across hundreds of instances in days. Oracle's license measurement team treats every one of those instances as production commercial use. We document the broader pattern in our guide to Oracle Java licensing across AWS, Azure, GCP and OCI.
The defensive move is simple and cheap: standardize on a verified OpenJDK distribution — Amazon Corretto, Eclipse Temurin, Microsoft OpenJDK, or Azul Zulu — in your golden images, and add a build-time check that fails any image shipping Oracle-branded JDK. This single control eliminates the most common accidental Java SE cloud liability we see.
Sometimes, but not universally — and this is widely misunderstood. Oracle grants Java SE use rights on certain OCI compute and platform services, but Java running on OCI infrastructure you manage yourself can still require an Employee Metric subscription like any other environment. The bundled-Java assumption is one of the more expensive mistakes we correct on OCI estates.
OCI (Oracle Cloud Infrastructure) is Oracle's public cloud. Where a managed OCI service includes Java SE entitlement, that right typically covers Java used within that specific service — not Java you install on a general-purpose OCI compute VM and operate yourself. Treating one as the other leaves production Oracle JDK uncovered. Always confirm the exact entitlement for each OCI service in writing before relying on it, and keep that confirmation with your license records.
Because OCI commercial terms and bundled rights shift with each contract cycle, OCI Java entitlement is best validated as part of a broader cloud review. Our Cloud & OCI advisory service verifies which OCI services carry Java rights for your specific subscription, and cross-references it against the database and middleware licensing rules in our Oracle Database Licensing Guide.
The reduction lever depends entirely on your metric. Under the Employee Metric, the count only drops when Oracle JDK is removed from every environment, so the strategy is total migration to OpenJDK. Under legacy Processor subscriptions, the count drops every time you remove Oracle JDK from a cloud instance, so even partial migration cuts cost directly and immediately.
For most cloud-heavy enterprises, replacing Oracle JDK with a free OpenJDK distribution is the dominant strategy. Amazon Corretto, Eclipse Temurin, Microsoft OpenJDK, and Azul Zulu provide TCK-verified, production-grade Java runtimes at zero Oracle license cost, and migration from Oracle JDK is typically a drop-in replacement for Java 8, 11, 17, and 21 workloads. The technical effort is modest; the contractual saving under a legacy Processor deal is often the entire subscription line.
Before you negotiate any renewal, build a defensible inventory first — see our companion guide on building a Java estate inventory before renewal. For an example of how a disciplined inventory and migration plan dismantled an inflated cloud-Java claim, see the Telecom Java Audit Defense case study, where Oracle's claim was reduced from $4.2M to $0.
Counting the cloud wrong is the most common reason enterprises over-pay Oracle for Java. Our former-Oracle team counts it the way Oracle's LMS team will — then builds your reduction plan.
No. Under the current Java SE Universal Subscription, Oracle counts total employees, not cloud instances. A company with 5,000 employees pays for 5,000 employees whether Java runs on 5 cloud VMs or 5,000. Only legacy Processor and NUP Java subscriptions still count cloud cores or vCPUs.
On authorized public clouds, Oracle counts 2 vCPUs as 1 Processor license when hyper-threading is enabled, and 1 vCPU as 1 Processor when it is not. This follows Oracle's Cloud Computing Policy and applies only to legacy Java SE Processor subscriptions purchased before January 2023 that remain active.
Not always. Many AWS, Azure, and GCP marketplace images ship with Oracle JDK rather than OpenJDK. Running Oracle JDK in production without a Java SE subscription is a license violation regardless of who built the image. Always verify the bundled JDK vendor before deploying a marketplace image at scale.
Oracle provides Java SE use rights on some OCI compute and platform services, but not universally. Java running on OCI IaaS that you manage is treated like any other environment and may require an Employee Metric subscription. Confirm the specific service's entitlement in writing before relying on bundled Java rights.
Yes. Replacing Oracle JDK with Amazon Corretto, Eclipse Temurin, Microsoft OpenJDK, or Azul Zulu on cloud instances removes the Oracle subscription requirement for those workloads. Under the Employee Metric, you must remove Oracle JDK everywhere to drop the subscription; for legacy vCPU deals, partial migration reduces the count directly.
Under the Employee Metric, no — autoscaling cloud instances do not change an employee-based count. Under legacy Processor subscriptions, peak concurrent vCPU usage during the measurement period is what Oracle counts, so aggressive autoscaling of Oracle JDK instances can inflate the required license quantity.
Employee Metric calculation, legacy Processor vCPU counting, cloud marketplace traps, OpenJDK migration planning, and negotiation scripts — built from 600+ Oracle engagements. Download free.
Download Free Guide →Cloud counting changes, Employee Metric updates, OpenJDK migration guidance, and negotiation data from active engagements — every week, from former Oracle insiders.
Oracle Licensing Experts Team — Former Oracle licensing executives, LMS auditors, and contract managers, now working exclusively for enterprise buyers. Not affiliated with Oracle Corporation. About our team →