The provider-shipped Java runtimes on the big three clouds are OpenJDK builds under GPLv2 with Classpath Exception, so they carry no Oracle fee. The exposure moves to what you bring, what your ISVs bundle, and the handful of services where you still pick the runtime yourself.
The provider-shipped Java runtimes on the big three clouds are OpenJDK builds under GPLv2 with Classpath Exception, so they carry no Oracle fee. The exposure moves to what you bring, what your ISVs bundle, and the handful of services where you still pick the runtime yourself.
The question buyers keep asking is whether running Java on a hyperscaler's managed service quietly hands them an Oracle Java SE Universal Subscription liability. The short answer: no, not from the provider's own runtime. AWS, Microsoft, and Google all ship OpenJDK builds licensed under GPLv2 with the Classpath Exception, which means zero per-employee fee to Oracle. The longer answer is where money and audit exposure actually live: in the workloads you bring yourself, in the private JREs your third-party software drags along, and in the specific services where the provider hands the runtime decision back to you. This is a provider-by-provider analysis, not a distribution beauty contest. For the distribution mechanics, see our Corretto versus OpenJDK comparison.
Understand the scale of what a mistake costs before deciding whether the cloud shields you. Oracle's Java SE Universal Subscription is priced per employee, not per install and not per server. List pricing starts at $15 per employee per month for 1 to 999 employees, drops to $12 for 1,000 to 2,999, $10.50 for 3,000 to 9,999, and reaches as low as $5.25 per month for organizations above 50,000 employees. The metric is linear with headcount, not with usage. A 25,000-person firm running the same Java footprint as a 5,000-person firm still pays roughly five times as much.
The definition of "employee" is the trap. Oracle counts all full-time, part-time, and temporary employees, plus all full-time, part-time, and temporary employees of your agents, contractors, outsourcers, and consultants that support your internal business operations. Oracle's own price list example: a company with 28,000 total counted employees (23,000 staff plus 5,000 contractors) pays 28,000 times $6.75 times 12, or $2,268,000 per year. That is the number a single unlicensed Oracle JDK install can put in play, because Oracle prices the whole organization once you are non-compliant anywhere.
One unlicensed Oracle JDK on a managed service can trigger a per-employee bill sized to your entire workforce, not to the workload.
Amazon Corretto is a GPLv2-with-Classpath-Exception build of OpenJDK with Amazon-provided long-term support and patches, TCK-certified against the Java SE standard. On AWS-managed services, Corretto is the default and it carries no Oracle obligation. The July 22, 2026 quarterly release shipped Corretto 26.0.2, 25.0.4, 21.0.12, 17.0.20, 11.0.32, and 8u502, which tells you the patch cadence is current and maintained.
The LTS windows matter for planning. Amazon extended Corretto 8 support to May 2026 and Corretto 11 to September 2027, with Corretto 17 supported until September 2028. Two operational notes for 2026: JavaFX binaries are no longer included with Corretto 8 from the July 2026 release, so any app depending on bundled JavaFX needs a remediation plan; and Corretto 8 support has now lapsed, so estates still on 8 need to move. Where AWS runs Corretto for you (Lambda's default runtime, managed images), the license risk is Amazon's problem. Where AWS lets you bring your own runtime on EC2, EKS, or ECS, the risk is entirely yours. See serverless Java and Oracle subscriptions for the Lambda specifics.
Microsoft draws a cleaner line than most buyers realize. On a defined set of managed services, Microsoft builds, supports, and deploys the runtime by default, and the Oracle risk sits with Microsoft, not you. That list includes Azure App Service on Windows and Linux, Azure Functions, Azure Spring Apps, Azure Service Fabric, Azure HDInsight, Azure Cognitive Search, Azure Cloud Shell, Azure DevOps, Azure Managed Instance for Apache Cassandra, and Azure Cosmos DB for Apache Cassandra. On everything else (Virtual Machines, AKS, ACI, ACA, Azure Red Hat OpenShift, App Service Web App for Containers), the choice of runtime is yours, which means the license risk is yours.
The Microsoft Build of OpenJDK ships under GPLv2 with Classpath Exception and is patched quarterly in January, April, July, and October. Two Azure-specific traps: first, Java 8 is not Microsoft's own build. For the limited services offering Java 8, Microsoft relies on Eclipse Temurin, and Microsoft does not provide commercial support for non-LTS releases. Second, if you pinned an app to an earlier minor version, you may be silently running the deprecated Azul Zulu for Azure binaries. You can keep using them, but security patches flow only to newer OpenJDK builds. Pinned versions are a stale-runtime risk, not an Oracle-license risk, but they matter for audit-defensible patching hygiene.
| Provider | Default managed runtime | License | Where risk returns to you |
|---|---|---|---|
| AWS | Amazon Corretto | GPLv2 + CPE | EC2, EKS, ECS, any BYO runtime |
| Azure (managed list) | Microsoft Build of OpenJDK (Temurin for Java 8) | GPLv2 + CPE | VMs, AKS, ACI, ACA, ARO, Web App for Containers |
| GCP App Engine standard | Google-maintained OpenJDK 17/21 | GPLv2 + CPE | GCE, GKE, any BYO runtime |
| GCP (general recommendation) | Eclipse Temurin | GPLv2 + CPE | Anything you build and deploy yourself |
Google is the least prescriptive of the three but no less safe on license. Eclipse Temurin is Google's recommended OpenJDK distribution for use with Google Cloud: open-source licensed, Java SE TCK-certified, tested for production. On App Engine standard, Google runs your app in a gVisor-secured container on an up-to-date Ubuntu image with a supported openjdk-17-jdk or openjdk-21-jdk runtime, and App Engine maintains the base image and updates the OpenJDK package without requiring you to redeploy. That is Google owning the runtime and the risk. On Compute Engine and GKE, the runtime decision, and therefore the risk, is yours. The pattern across all three clouds is identical: managed and provider-maintained means their problem; bring-your-own means yours.
The rule is the same on all three clouds. Provider-maintained runtime, provider's risk. Bring-your-own, your risk.
The shield only covers the provider's runtime. Oracle Java reappears through four routes, and every one of them lands the liability squarely on you regardless of which cloud you run on.
The ISV question is genuinely unsettled and it is where buyers most often pay twice. You must confirm with each application vendor whether their license covers the bundled Java. Some vendors are now stripping Java from their installers and requiring you to download and license the JDK separately; others are switching their bundle to OpenJDK. Without clear written confirmation, you risk either paying Oracle for coverage you already have via the ISV, or facing a compliance finding during an audit for a runtime you assumed was covered. Get the answer in writing per vendor, and keep it in your audit file.
Even when you are correctly running provider OpenJDK, one legacy Oracle assumption can still bite. Buyers who negotiated an older Oracle Java processor-based agreement, rather than the current employee metric, need to watch elastic workloads. Autoscaling Java fleets can breach the 50,000-processor cap that some legacy structures assume, and cloud burst capacity is exactly where that happens silently. If any part of your estate still runs a legacy Oracle Java metric, read how autoscaling can blow past the 50,000-processor cap before you let a managed Kubernetes cluster scale unbounded.
A related nuance: running Java on Oracle's own cloud does not automatically neutralize your subscription position the way some Oracle sellers imply. If OCI is in your mix, confirm what it does and does not change in does running Java on OCI change your subscription position.
Treat the provider runtime as safe and spend your effort on the four creep-in routes. In priority order:
The reassuring conclusion is that the hyperscalers have already solved the runtime license problem for you at the platform layer. The uncomfortable one is that Oracle's per-employee metric turns any residual Oracle JDK, anywhere, into a whole-organization bill. Managed services shift the runtime risk to the provider on the services they maintain. Everything you bring, everything your ISVs bring, and every legacy metric you still hold remains yours to prove clean.
Yes. Corretto is a GPLv2-with-Classpath-Exception build of OpenJDK with Amazon support and no Oracle subscription requirement. The only way Oracle fees return on AWS is if you bring your own Oracle JDK, or if a third-party application bundles an Oracle-licensed private JRE. Note that Corretto 8 support has now lapsed and JavaFX left Corretto 8 in the July 2026 release.
On Azure App Service (Windows and Linux), Azure Functions, Azure Spring Apps, Service Fabric, HDInsight, Cognitive Search, Cloud Shell, DevOps, Managed Instance for Apache Cassandra, and Cosmos DB for Apache Cassandra, Microsoft builds and maintains the runtime by default. On VMs, AKS, ACI, ACA, Azure Red Hat OpenShift, and Web App for Containers you choose the runtime, so the license risk is yours.
No. App Engine standard runs a Google-maintained OpenJDK 17 or 21 runtime and updates the base image without redeployment, all under open-source license. Google's general recommendation across Google Cloud is Eclipse Temurin, which is also TCK-certified and carries no Oracle fee. On Compute Engine and GKE the runtime choice, and the risk, returns to you.
Four routes: an Oracle 8u211+ or Oracle JDK 11 binary baked into a golden image, a bring-your-own Oracle JDK you installed, a private JRE bundled inside a third-party application, and a jlink-built runtime derived from an Oracle JDK. All four leave the liability with you regardless of provider, and bundled JREs are often invisible to registry-based scanning.
It depends on the vendor's license, and it is genuinely unsettled. Some ISVs cover the bundled Java under their own agreement, some now strip it out and require you to license a JDK separately, and some ship OpenJDK. Get a written statement per vendor. Without it you risk paying Oracle twice or failing an audit for a runtime you assumed was covered.
Only if you still hold a legacy Oracle Java processor-based agreement. Autoscaling clusters on AKS, EKS, or GKE can breach an assumed 50,000-processor cap during burst events, silently. If you are on the current employee-based metric the cap is not your issue, but any legacy processor structure combined with elastic scaling needs monitoring.
Oracle Cloud at Customer enterprise licensing framework. Buyer side framework across OCI Dedicated Region, Exadata Cloud at Customer, autonomous database.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
