Java on Cloud VMs: AWS, Azure & GCP Licensing

Moving Java workloads to AWS, Azure or Google Cloud feels like it should change the licensing picture. It usually does not. Oracle Java licensing follows the software, not the data centre — and on cloud virtual machines it introduces new ways to accumulate exposure without ever choosing to. This guide explains the rules for each provider and the cloud-specific traps to watch.

The cloud does not change the metric

The single most important fact is this: under the 2023 Java SE Universal Subscription, where Java runs is irrelevant to the price. The employee metric counts your total workforce. Whether your Java workload sits in an on-premise data centre, an AWS EC2 instance, an Azure VM or a GCP Compute Engine instance makes no difference to the subscription cost — it is the same per-employee figure either way.

That cuts both ways. You cannot reduce an employee-metric Java bill by moving workloads to the cloud. But equally, the cloud does not multiply the metric. The exposure on cloud VMs is therefore not primarily about the metric — it is about which build of Java ends up running there.

Legacy processor agreements and the cloud

If your organisation still holds a legacy processor-metric Java agreement, the cloud rules are different and matter a great deal. For deployments in recognised public clouds, Oracle's cloud licensing policy generally counts vCPUs rather than physical cores, with a defined relationship between vCPUs and Oracle processor licences. Oracle's "Authorized Cloud Environment" policy sets out how AWS and Azure are treated for counting purposes.

The practical risk under a processor agreement is elasticity. Cloud workloads scale up and down automatically; if your Java footprint can balloon to dozens of instances under load, the processor count Oracle could assert balloons with it. Legacy-agreement holders running Java in the cloud should model their peak vCPU footprint, not their average — see the processor vs employee metric guide.

The real cloud trap: accidental Oracle JDK

The most common way organisations create Java exposure in the cloud is not deliberate. It is the quiet inclusion of Oracle JDK in cloud images and services they spin up without checking.

Marketplace and base VM images

Cloud marketplaces are full of pre-built VM images — application stacks, middleware bundles, vendor appliances — and a meaningful number ship with Oracle JDK pre-installed. Launch such an image and you have an Oracle Java installation you never chose. Multiply that across an auto-scaling group and a single careless image selection becomes a fleet.

Managed services and bundled runtimes

Some managed services and platform components include a Java runtime. Where that runtime is an OpenJDK build provided and maintained by the cloud vendor, you are fine. Where it is Oracle JDK, you are not. The distinction is often invisible in the console — you have to check what is actually installed on the instance.

Auto-scaling and ephemeral instances

Auto-scaling is designed to create and destroy instances automatically. If the launch template or AMI behind a scaling group carries Oracle JDK, every instance the group spawns is another Oracle Java installation. Ephemeral does not mean unlicensed — a short-lived instance running Oracle JDK in production is still production use.

In the cloud, exposure rarely comes from a decision. It comes from a default — an image, a template, a base layer that nobody inspected.

Provider by provider

AWS

AWS publishes Amazon Corretto, a free, production-ready OpenJDK distribution with long-term support and quarterly security updates. Corretto is the natural default for any Java workload on EC2, ECS, EKS or Lambda. The compliance task on AWS is to confirm that marketplace AMIs and custom launch templates are not quietly carrying Oracle JDK instead.

Azure

Microsoft publishes the Microsoft Build of OpenJDK, free and supported, and it is the sensible default for Java on Azure VMs and Azure Kubernetes Service. As on AWS, the watch-point is marketplace images and third-party appliances that may include Oracle JDK.

Google Cloud

Google does not publish a first-party OpenJDK brand, so the standard choice on GCP is Eclipse Temurin from the vendor-neutral Adoptium project — free for any use, with official container images. Standardising Compute Engine images and GKE base images on Temurin removes the Oracle question entirely.

Oracle Cloud (OCI)

Oracle's own cloud is the one place where Oracle JDK use is sometimes included. Oracle bundles Java SE entitlement with certain OCI services, but the entitlement is specific to OCI and does not travel — running Oracle JDK on AWS or on-premise is not covered just because you also use OCI. Read OCI Java terms carefully rather than assuming a blanket entitlement.

A practical cloud Java checklist

1. Inventory. Identify every cloud VM, container and managed service running Java, and record which build it uses.
2. Audit your images. Inspect every base AMI, VM image and golden image for bundled Oracle JDK.
3. Fix the templates. Replace Oracle JDK with the provider's free OpenJDK build in all launch templates and image pipelines — this stops new exposure at the source.
4. Check marketplace appliances. Any third-party marketplace image is a candidate for hidden Oracle JDK; verify before relying on it.
5. Model peak footprint. If you hold a legacy processor agreement, count vCPUs at peak scale, not average.
6. Document OCI entitlements. If you use OCI, record exactly what Java entitlement applies and confirm it is not being relied on off-OCI.

Containers and Kubernetes in the cloud

Cloud and containers usually arrive together, and containers compound the cloud Java problem. A container image built on an Oracle JDK base layer carries Oracle's licence terms inside it. Every container started from that image is, in licensing terms, another Oracle Java installation — and in a managed Kubernetes service (EKS on AWS, AKS on Azure, GKE on Google Cloud) that scales to hundreds of pods, a single Oracle-based image can generate vast notional usage.

The risk is amplified by how container images propagate. One developer's base image becomes a team standard, gets copied into a dozen other Dockerfiles, and ends up underpinning services no one connects back to the original choice. If that base image carries Oracle JDK, the exposure spreads silently with it.

The fix is the same as everywhere else, and it is free. Eclipse Temurin publishes official, production-ready container images; Amazon Corretto and Microsoft both publish container-ready OpenJDK builds. Auditing your container registry for Oracle-derived base layers, and rebasing them onto OpenJDK, is one of the highest-value cloud compliance actions available — it removes exposure at the source rather than chasing it pod by pod.

Hybrid and multi-cloud Java

Few enterprises run in a single, tidy environment. The typical estate spans on-premise data centres, two or three public clouds, and a managed Kubernetes layer on top. For Java licensing this matters because exposure does not respect the boundaries of your architecture diagram.

Under the employee metric the spread is, at least, simple: one headcount-based subscription would cover Java everywhere, so the licensing question is binary — pay it, or eliminate Oracle JDK estate-wide. Under a legacy processor agreement the picture is harder, because each environment counts differently: physical cores on-premise, vCPUs in each cloud, with Oracle's interpretation of virtualisation layered on top.

The practical conclusion is that a hybrid estate needs a single, unified Java inventory that crosses every environment, not separate spreadsheets per platform. Oracle JDK that is cleaned up on-premise but left running in one cloud region is still a live liability. A multi-cloud estate is only as compliant as its least-governed corner.

A cloud Java governance model

Because cloud environments change continuously, cloud Java compliance is not a project with an end date — it is a control that has to run permanently. A workable model has three layers.

Standardise. Choose one OpenJDK build per cloud, bake it into every golden image and base container, and remove Oracle JDK from all image pipelines. This makes the compliant choice the default choice.

Enforce. Use the tools the clouds already provide — image scanning, infrastructure-as-code policy checks, registry controls — to detect and block Oracle JDK before it reaches production. Catching an Oracle base image in a pull request is far cheaper than finding it in an audit.

Verify. Re-scan the running estate on a schedule. Cloud estates drift; a marketplace appliance or an updated image can reintroduce Oracle JDK at any time. Periodic verification turns governance from a hope into a fact — the essence of continuous Java management.

Frequently asked questions

Related reading