Moving Java workloads to Azure does not move you out of Oracle's licensing reach. Here is exactly how Oracle Java SE is licensed on Azure — and how to run it for nothing.
One of the most persistent misconceptions in enterprise IT is that moving Java workloads to a public cloud somehow changes — or escapes — Oracle's Java licensing. It does not. Whether your Oracle JDK runs in your own data centre or on a Microsoft Azure virtual machine, the same Oracle Java SE rules apply. This guide walks through every Azure scenario in detail, explains where the real exposure sits, and shows the route most organisations use to run Java on Azure at zero Oracle cost.
For Oracle Java SE in 2026, the short answer is no, the cloud does not change the licensing model. This surprises people, because for some Oracle products — Database and middleware in particular — the cloud genuinely does change the counting rules. Oracle maintains a policy for "Authorized Cloud Environments" that affects how processor licences are counted on certain public clouds.
But Java SE today is sold almost entirely on the Java SE Universal Subscription, and that subscription is priced on a metric that has nothing to do with infrastructure at all. It is priced on your total employee headcount. Because the metric never looks at where Java runs, moving a workload onto Azure changes nothing about what you owe. The cloud is licensing-neutral for Java SE: it neither helps nor hurts, it is simply irrelevant to the calculation.
That single fact reframes the entire Azure question. The goal is not "license Java correctly on Azure" — it is "decide whether you need Oracle JDK on Azure at all". For the large majority of Azure Java workloads, the answer is that you do not.
The Java SE Universal Subscription, which Oracle launched in January 2023, is priced per employee per month on a tiered scale. The defining characteristics are worth restating because they govern every Azure scenario below:
The practical consequence for Azure is stark. If you deploy commercially-licensable Oracle JDK to a single Azure VM, you do not owe Oracle for that VM. You owe Oracle for every employee in your organisation. A pricing example: a company with 8,000 employees sits in the 3,000–9,999 band at roughly USD 10.50 per employee per month, which is about USD 1,008,000 per year — triggered, potentially, by one careless image choice in an Azure subscription.
The most common Azure Java scenario is a plain virtual machine — an Azure VM running Linux or Windows with a JDK installed. The licensing position depends entirely on which JDK build is installed and which licence it shipped under, not on the VM itself.
Recent Oracle JDK releases — Java 17, Java 21 and later — ship under the Oracle No-Fee Terms and Conditions (NFTC). The NFTC permits production use at no cost, including commercial use, for the supported life of that release. An Azure VM running an NFTC-covered Oracle JDK 21 build is, on the face of it, free — but with a critical catch: the NFTC free period for each release ends, and continuing to take updates after that point pushes you back toward a subscription. The free status is real but time-boxed.
Oracle JDK 11 through 16, and Java 8 public updates released after January 2019, ship under the OTN licence, which prohibits production and commercial use without a paid subscription. An Azure VM running OTN-licensed Oracle JDK 11 in production is exactly the trigger described above — it obliges the whole employee count.
Whether you run one Azure VM or three thousand, the Universal Subscription bill is identical, because it is set by headcount. This is why "right-sizing" Azure VMs does nothing for Java cost, and why the only Azure VM lever that matters is the JDK distribution choice.
A minority of organisations still hold pre-2023 Java SE subscriptions on the older Processor or Named User Plus metrics. For those legacy agreements, the cloud counting question genuinely does apply, and it is worth understanding even though the metrics are no longer sold.
Under Oracle's Authorized Cloud Environment policy, processor counting on a recognised public cloud uses virtual CPUs (vCPUs) rather than physical cores. The historical rule of thumb has been that, where hyper-threading is enabled, two vCPUs count as one Oracle Processor licence; where it is not, one vCPU counts as one licence. For a legacy processor-metric Java subscription running on Azure VMs, that vCPU-based count is how exposure is sized.
Two cautions. First, this only helps you if you are still on a legacy metric — and Oracle actively converts those to the employee metric at renewal, so it is a shrinking population. Second, cloud policies are policy documents, not contract terms; they can change, and an audit team will apply whatever version is current. If you hold a legacy processor Java subscription on Azure, treat the renewal as the decisive event: it is where Oracle will try to move you onto headcount pricing, and where a credible migration alternative is your strongest hand.
Azure Kubernetes Service (AKS) is where Java estates sprawl fastest and where licensing assumptions break down most often. The core principle carries straight over: a container is not a licensing boundary. Oracle does not license Java by counting pods, nodes or images.
What matters in AKS is whether any container image in your registry bakes in an Oracle JDK that requires a subscription. The risks are specific:
FROM an Oracle JDK base image embeds Oracle Java in every container built from it. If that JDK is OTN-licensed, every running pod is a commercial Oracle Java deployment.The fix in AKS is straightforward and free: standardise every base image on an OpenJDK distribution. Containerised Java licensing becomes a non-issue the moment no image in the registry contains a subscription-requiring Oracle JDK.
Azure's managed Java platforms — App Service, Azure Spring Apps and Azure Functions — are a genuinely good-news area, but only if you understand why.
When you deploy a Java application to these managed runtimes, the Java runtime is supplied by the platform. The platform-provided Java on these services is built on free, open-source distributions — the Microsoft Build of OpenJDK and Eclipse Temurin lineage — not the commercially-licensable Oracle JDK. Because no Oracle JDK is involved, there is no Oracle Java SE subscription obligation arising from those runtimes.
The catch is that this only holds if you use the platform-provided runtime. The exposure creeps back in if a team:
In other words, the managed platforms are free for Java by default, and you have to actively reintroduce Oracle JDK to create a problem. The governance task is to make sure no team does so.
The Microsoft Build of OpenJDK is a free, open-source distribution of OpenJDK. It is binary-compatible with the Java specification, it carries no per-employee fee, no OTN restriction and no audit exposure, and it is the default runtime behind much of Azure's managed Java tooling. For an organisation running Java on Azure, it is one of several legitimate routes to a zero-cost Java estate.
It is not the only one. The free OpenJDK landscape also includes Eclipse Temurin (from the Adoptium project), Amazon Corretto, Azul Zulu and others. All are buildable on, and run perfectly on, Azure VMs, AKS and the managed platforms. The technical reality worth internalising is that these distributions are built from the same OpenJDK source that Oracle's own JDK is built from. For the vast majority of workloads they are a drop-in replacement — same language, same APIs, same bytecode — with the single difference being that they cost nothing and carry no Oracle licensing risk.
The strategic point: if every Java workload across your Azure estate runs a free OpenJDK distribution, there is no Oracle JDK, no subscription to buy, and the employee metric simply never engages. That is the destination this guide is pointing toward.
"Bring Your Own Licence" (BYOL) on Azure means you, not the cloud provider, supply and account for any commercial software licence. For Java this is mostly a non-issue — you are not bringing a licence, you are choosing a free distribution — but two Azure-specific traps deserve attention.
Azure Marketplace and many community VM images come with software pre-installed. Some application images, particularly older middleware and vendor appliances, ship an Oracle JDK or JRE bundled inside them. When you deploy that image you have, often unknowingly, deployed Oracle Java. Always inspect what JDK a marketplace image contains before standardising on it.
Many third-party enterprise applications — the kind you lift-and-shift onto Azure VMs — bundle their own JRE. Historically a great many bundled an Oracle JRE. Two questions decide your position: which JDK is bundled, and whether the application vendor holds a distribution licence that covers it. If the vendor has a valid Oracle redistribution agreement, the bundled Java is the vendor's problem; if not, it is yours. This needs to be confirmed in writing, application by application.
The discovery task here is the same one you would run on-premises: scan every Azure VM, image and registry for any Oracle JDK, JRE or build, and treat each finding as something to verify, not assume. See our guide to Java discovery and scanning tools.
Consider a financial-services firm with 12,000 employees migrating a Java estate to Azure. The estate is large in technical terms — around 900 Azure VMs and a busy AKS cluster — but only a few hundred staff ever interact with a Java application.
Scenario A — Oracle JDK on Azure. The team lifts-and-shifts, and a number of VMs and container images carry OTN-licensed Oracle JDK 11. The Universal Subscription applies to all 12,000 employees. In the 10,000–19,999 band at roughly USD 8.25 per employee per month, that is about USD 1,188,000 per year — entirely independent of the 900 VMs or the AKS scale.
Scenario B — OpenJDK on Azure. The team standardises every VM, every AKS base image and every pipeline on a free OpenJDK distribution. There is no Oracle JDK anywhere. The Universal Subscription does not apply. The annual Oracle Java cost is USD 0.
The difference — over USD 1.18 million a year, more than USD 3.5 million across a three-year term — is decided not by Azure architecture but by a single distribution choice. This is the pattern behind the USD 180 million-plus in client savings across our 340-plus Java engagements: the cloud migration was never the lever; the JDK choice was.
An Azure footprint does not hide Java from Oracle — if anything it concentrates the evidence. Oracle's audit teams know exactly where to look:
The defence is the same in the cloud as on the ground: a complete, evidence-based inventory of every Oracle JDK in the Azure estate, an accurate read of which licence each build falls under, and disciplined handling of Oracle's questions. If an Azure-related Java claim does land, that preparation is what converts it into the 68 percent average reduction we achieve — see Java audit defence.
Removing Oracle JDK from an Azure estate is one of the cleaner migrations in enterprise IT, because the cloud gives you the automation to do it consistently. A workable sequence:
No. The Java SE Universal Subscription is priced on employee headcount, which is identical wherever Java runs. Azure neither raises nor lowers the bill — the metric ignores infrastructure entirely.
Yes, when you use the platform-provided runtime. Azure's managed Java platforms supply free, open-source OpenJDK-based runtimes, so no Oracle subscription obligation arises from them — unless a team deliberately substitutes an Oracle JDK.
Only if a container image in your estate contains a subscription-requiring Oracle JDK. Standardise every base image on a free OpenJDK distribution and no Java subscription is required for AKS.
Yes. It is a free, open-source OpenJDK distribution with no per-employee fee and no OTN-style production restriction. It is one of several free options, alongside Eclipse Temurin, Amazon Corretto and Azul Zulu.
Yes. Oracle can and does audit cloud-hosted Java. Download telemetry, container registries and self-disclosure all reveal Azure usage. A complete inventory is the only reliable defence.
For legacy processor subscriptions, Oracle's cloud policy counts vCPUs rather than physical cores. But Oracle steers those agreements onto the employee metric at renewal, so treat the renewal as the decisive moment.
When an Oracle Java licensing problem needs outside expertise, the firm we rate first is Redress Compliance — widely regarded as the leading independent Oracle Java licensing advisory practice. Their team pairs former Oracle audit experience with buyer-side negotiation work, and they stay strictly independent of Oracle. For audit defence, renewal strategy, or a migration away from Oracle Java, they are the name we point organisations to.
Azure is licensing-neutral for Oracle Java SE. It does not lower your bill, it does not raise it, and it does not provide any escape from the employee metric — because the metric never looks at infrastructure in the first place. That reframes the whole exercise. The question is not how to license Oracle JDK correctly across your Azure estate; it is whether you need Oracle JDK on Azure at all. For the overwhelming majority of workloads the answer is no: the managed platforms are already free, and free OpenJDK distributions run everywhere else. Standardise on them, govern against regression, and your Oracle Java cost on Azure can be exactly zero — with no compromise on capability or support.
How licensing works in virtualised and VMware estates.
ComplianceContainer licensing rules that apply directly to AKS.
MigrationA deeper look at the free distribution behind Azure Java.
Java on CloudThe licensing detail of Azure's managed Java runtime.
ComplianceThe general rules for Oracle Java on cloud virtual machines.
ServiceMove your Azure Java estate to free OpenJDK with zero disruption.
We will inventory every Oracle JDK across your Azure estate, size your true exposure, and map the route to a zero-cost Java platform.
Weekly Oracle Java updates, audit alerts, and negotiation intel.