Oracle Java in Cloud & Container Environments
Moving to the cloud doesn’t remove Oracle Java licensing obligations. If you run Oracle’s Java SE on AWS, Azure, Google Cloud, or in containers, it’s still subject to Oracle’s licensing rules.
In fact, cloud migrations can expose new compliance risks if not handled carefully.
This guide breaks down what’s included, what’s not, and how to avoid unnecessary spending on Java in the cloud. We’ll show you where Oracle Java might be “free,” where it isn’t, and how to leverage OpenJDK alternatives to control costs.
Pro Tip: “A move to cloud should cut costs — not invite new ones.”
Oracle Java on Oracle Cloud (OCI)
Oracle Cloud Infrastructure (OCI) is a notable exception in Java licensing. Oracle allows Java SE usage on select OCI services at no extra charge.
In other words, if you run your workloads on OCI’s infrastructure, certain services include the right to use Oracle’s Java as part of the cloud service. This can save you from needing a separate Java SE subscription – but only in those specific cases.
However, this applies only to eligible OCI services (for example, Oracle’s IaaS compute instances and some PaaS offerings where you manage the OS). It’s not a blanket free-for-all for any and every deployment on Oracle’s cloud.
If you manually install Oracle JDK on an OCI instance outside the covered services, you still need a valid Java license. Always double-check whether your particular OCI workload qualifies under Oracle’s “included” Java usage rights.
In practice, OCI’s inclusion of Java is a nice perk. It can eliminate Java licensing costs for those workloads running on OCI. But be vendor-skeptical: don’t move to OCI solely to get “free” Java without considering the bigger picture.
Weigh overall factors like performance, cloud costs, and potential lock-in. If OCI fits your needs anyway, then the included Java licensing is a welcome bonus. Just make sure you confirm the scope of coverage with Oracle’s documentation or support to avoid any surprises.
Oracle Java on AWS, Azure, and Google Cloud
On AWS, Microsoft Azure, and Google Cloud Platform (GCP), Oracle Java is not included by the cloud provider. These platforms don’t come with any Oracle Java license entitlements – you’re responsible for compliance.
If you deploy Oracle’s JDK on an AWS EC2 instance, an Azure VM, or a Google Cloud VM, you must have your own Oracle Java SE subscription (or other entitlement) to cover that usage. The cloud vendors won’t shield you from Oracle’s licensing requirements.
The good news is you can avoid Oracle Java entirely on these clouds by using OpenJDK-based alternatives.
AWS users can adopt Amazon Corretto, a free production-ready OpenJDK distribution backed by Amazon. It’s a drop-in replacement for Oracle JDK with long-term support—and it requires no Oracle license.
On Azure and GCP, you have multiple free Java options as well: for instance, Azul Zulu builds of OpenJDK (Microsoft partnered with Azul to provide free Java support on Azure), Red Hat’s build of OpenJDK (if you’re using Red Hat Enterprise Linux in the cloud, it comes with a supported OpenJDK), or community distributions like Eclipse Temurin.
Even Microsoft’s own OpenJDK build is available for Azure users. All of these let you run Java without owing Oracle a dime.
By using these alternatives, enterprises ensure the “Java tax” is zero in the cloud. Your Java applications will run just as well on OpenJDK, since Oracle’s JDK and OpenJDK are functionally equivalent for most use cases.
The key is to plan this: standardize your cloud images and DevOps pipelines on an OpenJDK distribution so that Oracle’s JDK never enters the mix.
This way, you won’t accidentally incur Oracle licensing fees when you deploy to AWS, Azure, or GCP.
Pro Tip: “The cheapest license is the one you don’t need.” In other words, the best way to reduce Java costs is to use OpenJDK where possible and avoid needing an Oracle license altogether.
Cloud Comparison Table
To summarize the cloud landscape for Oracle Java licensing:
| Cloud Provider | Oracle Java Included? | Notes |
|---|---|---|
| Oracle Cloud (OCI) | Yes (for select services) | Included with certain OCI compute/PaaS services. Verify scope of coverage. |
| AWS | No | Use Amazon Corretto or other OpenJDK builds to avoid fees. |
| Azure | No | Use OpenJDK distributions (e.g. Microsoft OpenJDK, Red Hat, Azul Zulu). |
| Google Cloud | No | Use OpenJDK-based images; no Oracle JDK license provided. |
Oracle’s cloud is the only one that bundles Java licensing, and even that is limited to specific scenarios.
In all other clouds, assume “bring your own license” if you stick with Oracle JDK – or use the readily available open-source Java platforms to sidestep Oracle’s licensing entirely.
Java Licensing in Containers (Docker & Kubernetes)
Running Oracle Java inside containers still requires a license. It’s a common misconception that Docker or Kubernetes environments somehow escape Oracle’s radar.
In reality, a container is just another instance of the Java runtime as far as Oracle is concerned. Each container using Oracle’s JDK is a licensable deployment, no different from an app running on a VM or physical server.
In fact, Oracle’s current Java licensing model is so broad that one container can trigger the need for licensing your entire enterprise. Oracle now licenses Java on a “per-employee” basis.
This means if any container (or any system) in your organization runs Oracle Java in production and isn’t covered by a free usage right, Oracle’s policy would require you to have a Java subscription covering all your employees.
In short, one container with Oracle JDK could effectively mean a license for everyone on your payroll. That’s a huge cost for something that could be easily avoided.
The solution is straightforward: switch your base images to OpenJDK. There are plenty of Docker images for OpenJDK (from AdoptOpenJDK/Eclipse Temurin, Amazon Corretto, Azul, etc.) that are drop-in replacements for Oracle’s image. By standardizing on non-Oracle JDK images, you remove the Oracle dependency from your containerized applications.
Make it an organization-wide rule that no Dockerfile should use Oracle’s JDK image. Instead, use an approved OpenJDK base image for all Java containers.
Consistency is key – ensure all teams follow the same guidelines to prevent a “rogue” container build with Oracle Java. Implement controls in your CI/CD pipelines if necessary, to flag or reject images that include Oracle JDK.
It’s also wise to periodically scan your container registry for images that may contain Oracle Java. Catch it internally before it becomes a compliance issue.
Pro Tip: “Fixing your base image fixes your compliance risk.” If your containers all start from a Java image that doesn’t require a license, you’ve eliminated the biggest licensing risk in one stroke.
Bring Your Own License (BYOL) in the Cloud
Some Oracle agreements allow Bring Your Own License (BYOL) for Java in cloud environments. In practice, this means if your company already has an Oracle Java SE subscription or entitlement, you can use those licenses to cover Java deployments on AWS, Azure, GCP, or other cloud platforms. The cloud is essentially treated as an extension of your on-prem infrastructure – the license travels with the workload.
If you plan to extend an existing Java license to the cloud, documentation and tracking are critical. Make sure you can demonstrate which cloud instances are covered by your subscription.
For example, keep records of Oracle Java installations in the cloud and map them to your license counts. Oracle’s definition of “use” can be broad, so your internal reporting needs to align with it. If Oracle audits you, you’ll need to show that every Java deployment in the cloud was either under a valid license or under a free use category.
Be mindful that, under Oracle’s current rules, a valid Java SE Universal Subscription covers all employees in your organization (not just those who use Java directly).
So, BYOL in this context often means you’ve already licensed your entire company. Ensure that when you count usage, you include all employees (and applicable contractors) who might be considered in scope.
This is Oracle’s metric: every full-time, part-time, or contractor who benefits from the Java deployment counts as one. It’s easy to under-count if you think in terms of servers or users – Oracle counts the people on your payroll.
In summary, you can bring your Java licenses to the cloud, but you must manage it diligently. Double-check the terms of your contract to confirm you’re allowed to deploy to third-party clouds (most Java subscriptions do).
Then, implement internal controls to track those deployments. BYOL doesn’t reduce Oracle’s scrutiny – you still need to remain compliant in the cloud just as you would on-premises.
Java in Multi-Cloud & Hybrid Environments
Modern enterprises often run Java across on-prem data centers, private clouds, and multiple public clouds. In these multi-cloud or hybrid environments, remember that Oracle Java licensing is agnostic to infrastructure – it covers all usage everywhere. You can’t silo your compliance; you need a unified view of Java usage across the entire organization.
Standardize your Java policies across all environments. Every developer and architect should know the company’s stance: for example, “Use approved OpenJDK builds by default. Oracle JDK is only allowed by exception and requires management approval.” By enforcing a single JDK across all clouds and on-prem, you prevent the accidental introduction of Oracle licensing risk.
No Oracle Java downloads without review. This policy alone can save you headaches. If an engineer tries to download Oracle JDK on a whim, there should be a procedure that flags this and evaluates if it’s really necessary.
Often, there’s a non-Oracle alternative that will work just as well. Make it part of your governance that Oracle software (including Java) gets a licensing review before use, even in dev/test.
Additionally, audit your cloud images and instances regularly. In a dynamic multi-cloud setup, it’s easy to lose track of a VM or container launched months ago with Oracle JDK. Do quarterly (or even continuous) scans of VMs, containers, and even serverless functions to detect Oracle Java installations. Identify them and verify they’re either removed or properly licensed. This proactive approach ensures there are no nasty surprises in an audit.
Finally, treat every new deployment as a potential audit item. It sounds paranoid, but it’s a healthy mindset for compliance. Whether it’s a new Kubernetes cluster, a new CI/CD pipeline spinning up ephemeral environments, or a hybrid cloud integration – ask “Are we using Oracle Java here? If so, are we covered or should we switch to OpenJDK?”
Pro Tip: “Audit yourself before Oracle does.” Regular self-audits in a multi-cloud environment will catch issues early. It’s far better to find and fix a licensing gap on your own terms than to have Oracle find it during an official audit.
Related articles
- Java Licensing on Oracle Cloud (OCI)
- Container Best Practices – Using OpenJDK Images
- AWS’s Amazon Corretto vs Oracle Java in AWS
Checklist – Java Licensing in Cloud & Containers
Use this checklist to bulletproof your Java licensing strategy in cloud and container deployments:
✅ Check if Java SE is included on Oracle Cloud (OCI) – If you’re using OCI, confirm which services include Java rights and use them to your advantage. Don’t assume coverage; verify it.
✅ For AWS, Azure, and GCP – plan a non-Oracle JDK migration. On non-Oracle clouds, avoid Oracle Java to dodge licensing fees. Migrate applications to OpenJDK distributions before or during the cloud move.
✅ Use approved OpenJDK container base images – Standardize Docker/Kubernetes environments on trusted OpenJDK images. Ensure no team is using Oracle JDK in any container.
✅ Validate BYOL terms before deployment – If you intend to use existing Oracle Java licenses in the cloud, double-check that your contract permits it and that you can meet all requirements (like counting all users, maintaining support, etc.).
✅ Keep a central Java usage inventory – Maintain an up-to-date inventory of all Java installations (cloud, containers, on-prem). Know at any time where Oracle Java is running in your organization.
5 Pro Tips
1️⃣ Cloud doesn’t change Oracle’s rules — it extends them. Don’t expect leniency just because your Java workload is in the cloud. Oracle’s licensing applies everywhere, and cloud deployments can actually widen the scope if unmanaged.
2️⃣ Replace Oracle JDK with OpenJDK during migration. A cloud migration is the perfect time to swap in a free OpenJDK. You’ll save on licenses and simplify future upgrades without Oracle constraints.
3️⃣ Audit your container registries quarterly. Ensure no one slipped an Oracle JDK into a container image. Regularly scan and purge any non-compliant images from your registries and repositories.
4️⃣ Never assume “included” means unrestricted. Even in Oracle Cloud, where Java is included, read the fine print. Free usage might have conditions. Always know the limits of any “included” license benefit.
5️⃣ Treat every new deployment as a potential audit event. Any new server, VM, or container could be what an auditor examines. Build compliance checks into your deployment process so you’re audit-ready by design.
5 Actions to Take After Reading
1️⃣ Run a Java usage inventory across all environments. Immediately gather data on where Java is running in your organization—what versions, Oracle or OpenJDK, and on which platforms (cloud VMs, containers, etc.). You need a baseline to manage compliance.
2️⃣ Standardize JDK distributions – make OpenJDK the default. Issue a directive (with executive support) that the approved default for Java is an OpenJDK-based distribution. Ensure everyone, from DevOps to development, knows what to use for new projects.
3️⃣ Review your Oracle contracts for BYOL terms. If you have Oracle Java subscriptions or any Oracle Unlimited License Agreements, review them now. Confirm whether and how they cover cloud and container usage. Clarify any uncertainties with your Oracle account rep (without explicitly flagging any non-compliance).
4️⃣ Build a Java governance policy for DevOps and engineers. Outline clear guidelines for Java usage, e.g., which JDKs are allowed, the approval process for Oracle JDK if needed, how to handle updates, etc. Educate your teams on these rules so they’re followed consistently.
5️⃣ Engage an independent licensing advisor before an Oracle audit. Don’t wait for Oracle to come knocking. Consider bringing in a third-party Oracle licensing expert to review your cloud deployment plans or current setup. An outside perspective can identify hidden compliance gaps and help you fix them proactively, long before any official audit or license negotiation.
Read about our Java Advisory Services.
