The employee metric follows you to the cloud
The instinct that the cloud changes everything about licensing is usually right for infrastructure software and wrong for Java. Oracle's Java SE Universal Subscription is priced on a count of your total workforce, and that count does not care whether the Java it covers runs in your own data centre, on an AWS EC2 instance, in an Azure virtual machine, or inside a Google Cloud managed service. If you use Oracle's commercially licensed JDK anywhere, the subscription obligation attaches to your whole organisation, and migrating the workload to a hyperscaler does not shrink it. This article sits beneath the Oracle Java licensing pillar.
This is the same structural point that governs Java on VMware. Because the licensable quantity is headcount rather than compute, the placement of the workload, whether on physical servers, virtual machines, or cloud instances, is irrelevant to the price. The cloud is a deployment decision, not a licensing one, for any organisation already inside the employee model.
What BYOL really means for Java
Bring your own license, or BYOL, is a familiar concept for Oracle Database in the cloud, where customers apply owned processor licenses to cloud cores under defined conversion rules. Java buyers often assume an equivalent mechanism exists. In practice the employee subscription is not a per instance entitlement that you carry to a cloud host. It is an organisation wide right to use Oracle JDK across your estate, so there is nothing instance specific to bring.
In the cloud you do not bring a Java license to an instance. You either hold the workforce subscription or you do not.
The effect is that BYOL for Java collapses into a single question: does your organisation hold a current Java SE Universal Subscription? If it does, you may run Oracle JDK on any cloud you like at no incremental license cost. If it does not, no amount of cloud architecture creates an entitlement, and running Oracle JDK on a cloud instance is as much a subscription trigger as running it on a laptop, unless it falls within the time limited No Fee Terms and Conditions. The cost mechanics are worked through in the Java pricing guide.
The free OpenJDK builds the cloud providers ship
The most important fact about Java in the cloud is that every major provider gives you a production grade, free OpenJDK distribution, specifically so you never need Oracle's subscription. Amazon publishes Corretto, Microsoft publishes the Microsoft Build of OpenJDK, and Google's environments default to open source builds. These are fully supported, regularly patched, and binary compatible with Oracle's JDK for the overwhelming majority of workloads.
| Distribution | Provider | License cost |
|---|---|---|
| Oracle JDK | Oracle | Employee subscription required |
| Amazon Corretto | AWS | Free, no Oracle fee |
| Microsoft Build of OpenJDK | Azure | Free, no Oracle fee |
| Eclipse Temurin | Adoptium | Free, no Oracle fee |
| Azul Zulu | Azul | Free build available |
Because these builds exist and are free, the cloud is often where a migration off Oracle Java is easiest to execute. The deeper comparison of Oracle JDK against open builds is in the OpenJDK versus Oracle JDK guide, and the migration mechanics are in the migration guide.
Managed services and hidden Oracle JDK
Cloud managed services introduce a subtler risk. Many platform services, container base images, and marketplace appliances bundle a Java runtime, and some of those bundles are Oracle JDK rather than an open build. When that runtime is Oracle's, the customer can incur a subscription obligation without ever consciously choosing Oracle Java, simply by deploying a service that happens to embed it.
This is the cloud equivalent of the contaminated VMware template. The defensible response is the same: inventory the actual Java binaries running in your cloud estate, including those inside container images and managed runtimes, and confirm the vendor of each. Distinguishing an embedded Oracle JDK from an embedded OpenJDK is exactly the kind of evidence Oracle relies on in an audit or soft audit, which is why our Oracle audit defence work treats container and image scanning as a first order task.
Does moving Java to the cloud reduce Oracle licensing?
No. Moving Java to AWS, Azure, or Google Cloud does not reduce Oracle Java licensing, because the Universal Subscription is priced on your total employee count rather than on compute. The cloud changes where Java runs and who operates the infrastructure, but it leaves the licensable quantity exactly as it was on premises.
What the cloud does offer is an easy route away from the subscription entirely, because every major provider ships a free, supported OpenJDK build. The cost reduction comes not from the move to cloud but from the switch of distribution that the cloud makes convenient. To quantify the saving, establish your true number using the employee metric guide, then compare it against the zero license cost of a provider OpenJDK build.
The shared responsibility gap for Java in the cloud
Cloud governance is built around a shared responsibility model, in which the provider secures the infrastructure and the customer secures what runs on it. Java licensing falls into an awkward seam in that model, because the provider supplies the convenience of pre built images and managed runtimes, yet the licensing consequence of what those images contain rests entirely with the customer. A team can provision a marketplace appliance in minutes without ever seeing which JDK it embeds, and the licensing liability attaches all the same.
This gap is widened by the speed and decentralisation of cloud adoption. In a traditional data centre, a central team controlled what software was installed. In the cloud, dozens of teams spin up workloads independently, each capable of pulling an Oracle JDK into production without a procurement conversation. The result is that Oracle Java can enter a cloud estate through many doors at once, and no single person has visibility of all of them.
Closing the gap requires treating Java distribution as a governed standard rather than a per team choice. Organisations that define an approved, free OpenJDK build, bake it into their base images, and block Oracle JDK at the pipeline level remove the liability at source. Those that leave the choice to individual teams accumulate exposure they cannot see, which is why cloud Java governance is now a standing item in our Java advisory engagements.
Containers, base images, and embedded Oracle JDK
Containerisation multiplies the embedded runtime problem because a container image bundles its own JDK, and that JDK is inherited by every container started from the image. A single base image built on an Oracle JDK can seed thousands of running containers, each one a separate instance of commercial Java use. Because container images are layered and frequently rebuilt from public bases, the provenance of the embedded Java is easy to lose track of.
The defensible response is to standardise base images on a known free build and to scan images in the registry, not just running workloads, for embedded Oracle binaries. Most major OpenJDK distributions publish official container images precisely so that teams never need to start from an Oracle base. Adopting one of these as the organisational standard converts an uncontrolled risk into a single, auditable decision.
The same scanning discipline that protects a VMware estate applies here, extended to the image registry and the container orchestration layer. Inventorying the actual Java inside images is the cloud equivalent of scrubbing a golden image, and it is the evidence an organisation needs to demonstrate, in any Oracle audit, that its containerised estate runs free OpenJDK rather than licensable Oracle JDK.
Why a cloud migration is the moment to switch
There is a timing argument that makes cloud migration the natural moment to leave Oracle Java behind. During a migration, applications are already being repackaged, retested, and redeployed, which means the marginal cost of also swapping the Java runtime is unusually low. The testing effort that would otherwise be the main barrier to a Java migration is largely being incurred anyway, so folding the distribution change into the same project captures most of the benefit at little extra cost.
The financial case reinforces the timing. An organisation that lifts and shifts Oracle JDK to the cloud locks in the employee subscription for the life of the deployment, paying a workforce based fee indefinitely for software it could run for free. An organisation that uses the migration to standardise on a provider OpenJDK build eliminates that recurring cost permanently. Over a typical multi year cloud commitment, the difference compounds into a very large number.
To make the decision on evidence rather than assumption, quantify the subscription using the employee metric guide and the pricing guide, then weigh it against the one time testing cost of the switch. For most organisations migrating to the cloud, the analysis points clearly toward a free build, and the migration window is the cheapest time to act on it.
Oracle Java on OCI and the BYOL question
Oracle's own cloud, OCI, is a special case worth isolating, because Oracle uses Java entitlements there as an incentive to move workloads onto its platform. Certain OCI services include Java SE support as part of the service, meaning a customer running eligible workloads on OCI may receive Java updates and support without a separate Java subscription. This is a deliberate commercial lever: Oracle gives away on its own cloud what it charges for elsewhere, to make OCI more attractive than competing platforms.
The catch is that this benefit is tied to OCI consumption and to the specific services that include it, so it is not a general escape from Java licensing. A customer with most of its estate on AWS or Azure cannot rely on an OCI Java entitlement to cover those external workloads, and the moment a workload leaves the qualifying OCI service, the entitlement does not travel with it. The benefit is real but narrow, and it should be read precisely rather than assumed to be broad.
For buyers, the OCI Java incentive is best treated as one input into a platform decision rather than a reason to standardise on Oracle Java. The durable, platform neutral position remains a free OpenJDK build that carries no entitlement strings on any cloud. Where OCI is genuinely part of the strategy, the included Java support is a bonus to quantify, not a foundation to build on, and our Java advisory service models it alongside the alternatives.
The buyer side view
The practical takeaway is that the cloud is licensing neutral for Oracle Java under the employee model and licensing dangerous only where Oracle JDK hides inside images and managed services. Any plan that assumes a lift and shift to a hyperscaler will cut the Java bill is mistaken, because the bill never depended on where Java ran.
Use the cloud migration as the moment to standardise on a free OpenJDK build, since the providers hand you one at no cost and the switch is rarely difficult for modern workloads. Scan your cloud estate for embedded Oracle JDK so discovery does not surprise you, then make the distribution decision deliberately. Start with the Java licensing pillar, use the Java advisory service to map your estate, and brief stakeholders with the Java licensing white paper.
Oracle Java in the cloud: frequently asked questions
Does Oracle Java cost less in the cloud?
No. The Java SE Universal Subscription is priced on your total employee count, so running Oracle JDK on AWS, Azure, or GCP costs the same as on premises. The cloud does not change the licensable quantity.
Can I use BYOL for Java in the cloud?
There is no instance level BYOL for the Java employee subscription, because it is an organisation wide right rather than a per server entitlement. If your organisation holds the subscription you may run Oracle JDK on any cloud; if not, no architecture creates an entitlement.
Which free Java should I use in the cloud?
Each provider ships a free OpenJDK build, such as Amazon Corretto on AWS and the Microsoft Build of OpenJDK on Azure, and Eclipse Temurin works everywhere. All avoid the Oracle subscription and are production supported.