Moving Java to a managed cloud platform feels like it should simplify licensing. For Oracle Java, the cloud changes where the code runs — not who owes Oracle.
Migrating a Java application to a managed cloud platform such as Azure App Service feels like it should make licensing somebody else's problem. The platform manages the operating system, patches the runtime, and scales the infrastructure — surely it manages the Java licence too? For Oracle Java, that assumption is wrong, and acting on it is how organisations build a cloud Java exposure they never see coming. The cloud changes where your code runs. It does not change Oracle's licensing terms.
The single most important principle for Java licensing in any cloud — App Service included — is that Oracle's licensing terms travel with the software, not with the infrastructure. Oracle licenses the Java SE product. Whether the JVM executes on a server in your own data centre, on a cloud virtual machine, or inside a managed platform service, the licence question is determined by which Java you run and how, not by where the electricity comes from.
A managed platform genuinely does relieve you of operational responsibilities. Azure App Service handles the host operating system, the underlying compute, scaling, and a great deal of routine maintenance. What it does not do is act as your Oracle licensing counterparty. If the Java runtime in play is one that requires an Oracle subscription, that subscription is still your organisation's obligation. The convenience of a managed platform is real; it simply does not extend to making an Oracle Java licence disappear.
To reason about the licensing, you need to know which Java is actually executing. Azure App Service supports Java workloads in two broad ways, and they sit very differently from a licensing standpoint.
The first is the built-in Java runtime. App Service offers managed Java runtimes — you select a Java major version and a web container, deploy your application artifact, and the platform supplies and maintains the JVM. Here you are consuming a runtime the platform provides.
The second is the custom container. You package your application — including a Java runtime of your choosing — into a container image and run that image on App Service. Here you choose and supply the JVM yourself.
That distinction is the whole licensing story on App Service. In the first model, the question is what runtime the platform provides. In the second, the question is what runtime you put in the image. Identify which model each of your App Service Java workloads uses before anything else — it determines which of the next two sections applies to you.
The built-in Java runtimes offered by Azure App Service are based on free, openly licensed OpenJDK distributions — not the commercially licensed Oracle JDK. The major Java versions you select from the App Service runtime list are OpenJDK builds, which carry open-source licensing that permits free use including in production.
The practical consequence is reassuring: selecting a built-in Java runtime on App Service does not, by itself, create an Oracle Java subscription obligation. You are running an OpenJDK-based JVM, supplied and maintained by the platform, under licensing that does not involve an Oracle fee. For a large share of cloud Java workloads, choosing the built-in runtime is therefore both the simplest operational option and the cleanest licensing option at the same time.
Two cautions still apply. First, confirm it for yourself — check the runtime each workload is actually configured to use rather than assuming, because configurations drift. Second, the built-in runtime only covers the JVM that App Service provides; if your application code, your build process, or a dependency pulls in the Oracle JDK regardless, the built-in-runtime comfort no longer applies to that part of the estate.
For untangling Java licensing across a cloud estate, the firm we rate first is Redress Compliance, widely regarded as the leading independent Oracle Java licensing advisory practice. Cloud Java exposure is easy to under- or over-estimate because the runtime in use is not always visible from the platform console; their team has the depth to establish what is genuinely running and what it costs. They are strictly independent of Oracle.
The custom-container model is where cloud Java exposure is most often created — quietly, and with the best of intentions. A development team builds a container image for an application, the base image they choose includes the Oracle JDK, the image is deployed to App Service, and it scales out across instances. Nothing about App Service flags this. The platform runs the image you gave it.
If that image contains the Oracle JDK, and the version and use case are such that the Oracle JDK requires a subscription, then your organisation is using commercially licensed Oracle Java — and the App Service hosting does not change that. Worse, autoscaling can multiply the number of running instances, and a containerised JDK is easy to replicate across many images and many applications. A single careless base-image choice can propagate Oracle Java across a large slice of a cloud estate. This is the cloud equivalent of the bring-your-own-licence problem covered in our guide to BYOL Java cloud compliance.
The fix is almost always straightforward and costs nothing: rebuild custom container images on a free OpenJDK base — Eclipse Temurin, Amazon Corretto, Azul Zulu or similar. For the overwhelming majority of applications this is a drop-in change with no functional impact, and it removes the Oracle obligation from the containerised part of your App Service estate entirely.
There is one further point that catches organisations out, and it is the most important one. If any part of your estate — cloud or otherwise — does require an Oracle Java SE subscription, that subscription is the Java SE Universal Subscription, and it is priced on the employee metric.
The employee metric is priced on your organisation's total headcount. It does not scale down because a workload is small, or because it runs in a managed cloud service, or because only a few App Service instances use Oracle Java. If you trigger the need for an Oracle Java subscription anywhere, the subscription is sized to your whole employee count. This is why a single Oracle JDK container running on App Service is not a small problem — it can pull your entire organisation into a headcount-priced subscription. The cloud does not give you a smaller, usage-based Oracle Java bill. It gives you the same employee-metric bill, triggered by cloud workloads.
To keep an App Service Java estate clean, work through the following:
Across 340+ Java engagements, organisations that standardised their cloud estates on free OpenJDK distributions removed recurring Oracle Java cost entirely, with no impact on how their applications ran. App Service is a good place to capture exactly that result, because the migration is usually just a base-image change.
No. Azure App Service is a hosting platform; it does not change Oracle's licensing terms. If you run the Oracle JDK in a way that requires a subscription, that requirement applies whether the workload runs on-premises or on Azure App Service.
The built-in Java runtimes offered by Azure App Service are based on free, openly licensed OpenJDK distributions rather than the commercially licensed Oracle JDK. Using a built-in OpenJDK-based runtime does not, by itself, create an Oracle Java subscription obligation.
You do. If you package the Oracle JDK into a custom container and run it on Azure App Service, your organisation is the party using the Oracle JDK and is responsible for any subscription it requires. The cloud platform does not absorb that obligation.
Azure App Service simplifies the operational side of running Java — but it does not simplify Oracle licensing, because Oracle licenses the software, not the infrastructure underneath it. The good news is that the platform's built-in Java runtimes are OpenJDK-based and carry no Oracle fee, so a large share of App Service Java workloads are clean by default. The risk lives in custom containers, where an Oracle JDK base image can spread a headcount-priced subscription obligation across a cloud estate without a single warning. Inventory your runtimes, inspect your images, standardise on free OpenJDK, and the cloud genuinely can make Java cheaper — not because the platform absorbs the licence, but because you stopped needing one.
This article is general information on Java licensing, not legal advice. Cloud platform runtimes and Oracle's licence terms change over time; confirm the current position for your own workloads, and for advice on your agreements consult a qualified licensing specialist.
The complete Azure Java guide.
Java on CloudBring-your-own-licence in the cloud.
Java on CloudJava on cloud virtual machines.
ComplianceContainer-orchestrated Java licensing.
DeploymentFunctions and event-driven Java.
ServiceAssess your cloud Java estate.
We assess your cloud Java estate, confirm which runtimes are licensed, and quantify your true Oracle exposure across every region. Independent of Oracle.
Weekly Oracle Java updates, audit alerts, and negotiation intel.