Java licensing

Java Licensing in the Cloud: AWS, Azure, OCI and Google Cloud Requirements

Java Licensing In The Clouds

Java Licensing in the Cloud: AWS, Azure, OCI & Google Cloud Requirements

Executive Summary:

Oracleโ€™s Java licensing rules donโ€™t vanish in the cloud. If anything, multi-cloud environments add new twists.

Running Java on Oracleโ€™s cloud (OCI) comes with a built-in license at no extra cost, but on AWS, Azure, and Google Cloud, enterprises must bring their own Java license.

Recent changes (like Oracleโ€™s per-employee licensing model) mean IT, procurement, and finance leaders need to rethink how they manage Java usage in the cloud to control costs and stay compliant.

In short, understand where Java is running, under what terms, and plan accordingly to avoid unexpected bills or compliance issues.

Cloud Adoption Doesnโ€™t Eliminate Java License Obligations

Insight:

Moving workloads to the cloud doesnโ€™t make Oracle Java โ€œfree.โ€ Oracle treats cloud servers the same as on-premisesย serversย when it comes to Java licensing requirements.

Many enterprises assume that using a public cloud automatically covers or negates their Java licensing needs. This is a costly misconception.

Real-World Example:

A global retailer migrated dozens of Java-based applications to AWS and Azure for agility. Months later, an Oracle license review discovered Oracleโ€™s JDK installed on those cloud VMs.

The company had unknowingly replicated its on-prem licensing gap in the cloud. They assumed the cloud providerโ€™s infrastructure or open-source alternatives were in use, but some instances still ran Oracle JDK, triggering a compliance issue.

Practical Takeaway:

Treat Java in the cloud the same way you would in your data center. If you use Oracleโ€™s Java (Oracle JDK) on an EC2 or Azure VM, you need a license for it โ€“ period.

Cloud vendors do not provide Oracle Java licensing for you. Include Java licensing checks in your cloud migration plans: either ensure only free OpenJDK distributions are deployed, or budget for Oracle Java subscriptions as part of your cloud operating costs. The cloud can simplify infrastructure, but it doesnโ€™t automatically solve software licensing obligations.

Oracle Cloud (OCI) โ€“ Free Java Licensing as a Cloud Perk

Insight:

Oracle Cloud Infrastructure (OCI) is the one exception where Java licensing is built-in. Oracle allows customers to use Oracle Java on OCI at no additional cost.

This is a strategic perk by Oracle โ€“ essentially saying, โ€œIf you run your workloads on our cloud, weโ€™ll include Java support for free.โ€ OCI services include the right to use Java as part of the service, removing the need for a separate Java SE subscription in that environment.

Real-World Example:

Consider a financial services firm deploying a microservices stack on OCI. They leverage the latest Oracle JDK and even Oracleโ€™s GraalVM for high performance. On OCI, all the Java updates and support are included in what theyโ€™re already paying for the cloud service.

If the same stack were on AWS, they would have to either pay for an Oracle Java SE subscription or use a non-Oracle Java distribution to stay compliant. Oracle utilizes this OCI inclusion toย sweeten the dealย for customers considering its cloud offerings.

Practical Takeaway:

If your enterprise uses OCI or is evaluating it, consider the potential savings on Java licenses. Running Java workloads on OCI can eliminate separate Java subscription fees, which can be significant for large deployments. However, donโ€™t let โ€œfree Java on OCIโ€ alone drive your cloud strategy.

Weigh the overall OCI proposition (performance, costs, multi-cloud needs) holistically. For organizations already in OCI, take full advantage of the included Java support โ€“ ensure your teams know they can run Oracle JDK there without incurring additional costs. Just remember: once you deploy Java on any non-Oracle cloud, that bring-your-own-license rule kicks in again.

AWS, Azure & Google Cloud โ€“ BYOL (Bring Your Own License) for Java

Insight:

In AWS, Microsoft Azure, and Google Cloud Platform (GCP), Oracle Java is not covered by the cloud providers. These environments are considered โ€œthird-partyโ€ clouds from Oracleโ€™s perspective, and Java there is strictly BYOL.

That means if you choose to use Oracleโ€™s Java on an AWS EC2 instance, an Azure VM, or a GCP VM, you must have an active Java SE subscription covering that usage. There is no special free use of Oracle Java just because youโ€™re on AWS/Azure/GCP.

Real-World Example:

An analytics company runs hundreds of Linux VMs on AWS to crunch data with Java-based apps. Under Oracleโ€™s old rules, they needed to count the virtual CPUs to determine how many Java licenses to purchase.

For instance, if they had an AWS instance type with eight vCPUs, Oracleโ€™s policy treats that as four processor licenses (since Oracle counts two vCPUs as one processor when hyper-threading is enabled).

The firm realized that dozens of such instances would require a large number of licenses โ€“ a budget shock they hadnโ€™t planned for.

Under the new Oracle Java licensing model (discussed next), they would instead count all employees, which for this company could either increase or decrease the cost burden depending on their headcount.

Practical Takeaway:

When running Java on AWS, Azure, or GCP, plan for licensing costs just as you would for on-premises deployments. In legacy licensing terms, every cloud VMโ€™s vCPUs must be measured against Oracleโ€™s licensing formula (typically two vCPUs = 1 license).

In the new licensing model, cloud instances donโ€™t change your count โ€“ you pay based on the total number of employees, which could simplify things but might also increase costs for large companies. Either way, include Java subscription fees in cloud TCO calculations.

Many savvy enterprises avoid this issue by standardizing on open-source Java distributions in the cloud (like Amazon Corretto on AWS or Azul Zulu on Azure), which require no Oracle license.

This approach can drastically cut costs, but ensure those alternatives meet your support and performance needs. If you do need Oracle JDK features or support, budget for BYOL on these clouds โ€“ thereโ€™s no free lunch outside OCI.

Oracleโ€™s New Employee-Based Licensing vs. Legacy Metrics

Insight:

Oracleโ€™s January 2023 switch to an employee-based Java SE subscription model has huge implications for cloud deployments. Instead of licensing Java per processor core or named user (the old metrics), Oracle now charges based on the total number of employees in your organization.

This means your Java license cost is decoupled from the number of servers or vCPUs you have in the cloud.

Whether you run 10 VMs or 1,000 VMs on AWS doesnโ€™t matter โ€“ the cost is driven by how many employees (including full-time, part-time, and contractors) your company has. This โ€œall you can eatโ€ style might simplify tracking, but it can dramatically increase costs for large enterprises.

Real-World Example:

A software company with 500 employees runs Java on about 200 cloud VM instances. Under the legacy model, they might have needed (hypothetically) 100 processor licenses for those instances.

If a processor license was, say, $25 per month, thatโ€™s $2,500/month. Under the new employee-based model, those 500 employees all need to be licensed.

If Oracleโ€™s price is, for example, $5 per employee per month (pricing is tiered), thatโ€™s $2,500/month โ€“ similar in this case.

But consider a larger enterprise: a bank with 20,000 employees might only have 1,000 Java VMs. Legacy model: maybe 500 processor licenses needed; new model: all 20,000 employees.

At $5 per employee, thatโ€™s approximately $100,000/month ($1.2 million per year) โ€“ potentially several times more than the old model.

In one real client scenario, an organization calculated that its cost would jump from under $ 500,000 a year to over $2 million a year due to the employee counting, despite its actual Java usage not growing.

Practical Takeaway: Understand which model youโ€™re under.

If you have an existing Java SE subscription with Named User Plus or Processor licenses, you may be grandfathered (for now) into renewing under those terms; however, Oracle is encouraging customers to transition to the employee metric.

Model your costs both ways: sometimes the new per-employee deal could be cost-effective for smaller companies or those with a huge cloud footprint relative to headcount.

Often for big enterprises, itโ€™s a steep hike. If the employee model exceeds your budget, consider negotiating with Oracle forย discounts or phased approaches, or explore non-Oracle Java alternatives.

Also, be mindful of the definition of โ€œemployeeโ€ in Oracleโ€™s contract โ€“ it typically counts every staff member and contractor, not just IT staff or Java developers.

This broad definition means even employees who never directly use Java still count, a point you may need to negotiate (for example, excluding certain groups) or factor into your cost calculations.

Cost Pitfalls and Audit Triggers in Multi-Cloud Java Environments

Insight:

Cloud flexibility โ€“ spinning up instances, auto-scaling, container orchestration โ€“ can inadvertently increase your Java licensing exposure.

The ease of deploying new server instances across multiple clouds makes it harder to track where Oracle JDK might be installed. Oracleโ€™s auditors are aware of this and have begun to focus on cloud deployments as a potential source of non-compliance.

Common pitfalls include forgetting to include Java on transient test VMs, using Oracle JDK base images from a cloud marketplace without a valid license, or assuming that a managed service includes Java when it doesnโ€™t.

Real-World Scenario:

A multinational manufacturing company received an Oracle audit notice that specifically called out Java installations. Oracle had records of the companyโ€™s developers downloading Oracle JDK installers on cloud-based CI/CD servers.

During the audit, Oracle requested details of all AWS and Azure instances to determine where those Java versions were running. It turned out the companyโ€™s DevOps team had spun up containers with Oracle Java for testing, then left some of those containers running in Kubernetes clusters.

Even though each container was short-lived, Oracle argued that each active instance (whether a container or a VM) required licensing.

The result was an audit claim in the millions of dollars.

The company negotiated it down by showing plans to rapidly uninstall Oracle Java and transition to OpenJDK, but it was a stressful and costly lesson.

Practical Takeaway: Governance is critical.

In a multi-cloud environment, establish controls to prevent unlicensed Java usage. Some best practices:

  • Standardize golden images and containers on approved open-source JDKs (e.g., AdoptOpenJDK, Amazon Corretto, Microsoft Build of OpenJDK) to avoid Oracle JDK creeping in.
  • Utilize cloud management or software asset management tools toย regularly inventory Java installationsย across all your instances.
  • Educate your developers and IT staff: no one should pull Oracle JDK from the internet โ€œjust to get things workingโ€ without approval.
  • If you must use Oracle JDK for certain applications, consider isolating them to specific servers andย tracking their usage closely. You may also use Oracleโ€™s Java Management Service or similar tooling for enhanced visibility.
  • Additionally, review your contracts to ensure you have clarity on audit rights and data access. Cloud audits can be tricky โ€“ Oracle may request access to your cloud usage data. You want to have an internal process in place to respond, and contractually, itโ€™s wise to limit audit scope and require reasonable notice.

Being proactive with these steps can save you from unwelcome surprises.

Oracleโ€™s growing attention to Java means enterprises should assume that sooner or later, Java usage will be scrutinized. Itโ€™s far better to clean house on your terms than during a vendor audit.

Table: Java Licensing Pitfalls in the Cloud and How to Mitigate Them

Pitfall / RiskMitigation Strategy
Assuming โ€œCloud = Free Javaโ€ โ€“ Believing that running on AWS/Azure/GCP covers Java licensing automatically.Treat Java as BYOL: Explicitly account for Java in cloud projects. If using Oracle JDK, budget for a subscription; otherwise, stick to approved free OpenJDK distributions. Educate teams that cloud infrastructure doesnโ€™t include Oracle licenses.
Untracked Instances & Auto-Scaling โ€“ Dynamic cloud instances or containers with Oracle JDK spin up without oversight, multiplying license needs.Implement Controls & Monitoring: Use automation to enforce only licensed or approved JDK images. Tag VMs/containers running Oracle Java and monitor them. Consider tools like Oracleโ€™s Java Management Service or third-party asset managers for cloud environments.
Legacy License Misalignment โ€“ Having a legacy Java license (NUP/processor) but deploying in the cloud without applying proper vCPU counting, or assuming the old contract covers new cloud usage.Align and Update Licensing: If on legacy metrics, apply Oracleโ€™s public cloud core factor rules (typically 2 vCPUs = 1 license). Ensure your renewals or new purchases reflect your actual deployment (maybe negotiate a transition to the employee model if it benefits you). Donโ€™t ignore contract terms โ€“ confirm that your legacy license extends to cloud use (most do, given Oracleโ€™s cloud policy, but you must still count correctly).
Broad Audit Exposure โ€“ Standard Oracle Java contracts give Oracle broad audit rights, including cloud usage, which can lead to wide-ranging compliance reviews.Negotiate Contract Clauses: Where possible, tighten audit provisions โ€“ e.g., require reasonable notice and scope, and clarify how cloud data will be reviewed. Internally, prepare a detailed record of Java deployments (on-prem and cloud) to confidently respond. Being organized can shorten audits and reduce their impact.
Relying on โ€œNo Supportโ€ as a Strategy โ€“ Thinking you can run Oracle Java in production without a support contract and be safe (forgoing updates to avoid fees).Adopt True Free Alternatives or Stay Current with Free Releases: If you donโ€™t want to pay Oracle, donโ€™t use Oracle JDK in production beyond whatโ€™s allowed. Either use OpenJDK distributions with third-party support or track Oracleโ€™s free release timeline (e.g., use the latest LTS during its no-fee period, then upgrade timely). Running Oracle JDK without support still requires a license for commercial use โ€“ thereโ€™s no free ride for long-term production use of older versions.

Recommendations for IT Procurement and Cloud Teams

1. Inventory Java Usage Across All Environments: Gain a full picture of where Java is running โ€“ on-premises, AWS, Azure, GCP, and OCI. This inventory should distinguish Oracle JDK from other distributions. A clear inventory is the foundation for any licensing strategy.

2. Leverage OCI if Strategically Viable: If your organization already uses Oracle Cloud Infrastructure, consolidate Java workloads there to capitalize on the included Java licensing. However, ensure this makes sense overall; donโ€™t move to OCI just for โ€œfree Javaโ€ without considering performance, cost, and vendor lock-in implications.

3. Optimize Your Java Distribution Strategy: Strongly consider standardizing on non-Oracle Java distributions for cloud deployments. For example, use Amazon Corretto in AWS or Azul Zulu in Azure. These are TCK-compliant, free to use, and can drastically cut your reliance on Oracle licensing. Just make sure you have a plan for timely security updates (either in-house or via third-party support vendors).

4. Evaluate the New Java SE Universal Subscription Carefully: If you must use Oracleโ€™s Java (e.g., for specific application compatibility or support reasons), model the cost under the new per-employee subscription vs. your old model. Use Oracleโ€™s pricing tiers to calculate what โ€œall employeesโ€ would cost. Negotiate aggressively โ€“ large enterprises can often secure significant discounts off the list price or concessions, such as excluding certain populations (e.g., part-time interns) from the employee count.

5. Include Java in Cloud Governance Policies: Update your cloud governance or DevOps pipeline policies to enforce guidelines around Java. For instance, forbid the use of Oracle JDK Docker images in Kubernetes without approval, or have your cloud templates default to open-source Java. Make Java compliance a checklist item in cloud architecture reviews.

6. Monitor Oracleโ€™s Java Licensing Announcements: Oracle licensing policies can evolve (e.g., the introduction of the free NFTC license for new versions, changes in support roadmaps, etc.). Keep an eye on Oracleโ€™s updates or work with licensing advisors to stay current. An upcoming change could present an opportunity to save money (or signal an impending audit campaign). Being forewarned lets you adjust your strategy proactively.

7. Negotiate Audit Terms and Be Audit-Ready: Donโ€™t sign Oracleโ€™s cloud licensing or Java subscription agreements without scrutinizing the audit clause. Aim to insert reasonable limits (e.g., one audit per year, 45 days’ notice, and Oracle’s cooperation with your security policies on cloud data). Simultaneously, prepare for the worst โ€“ have a Java usage report ready and a plan to respond if you receive the audit letter. Showing Oracle that youโ€™re in control of your deployments can sometimes discourage in-depth analysis.

8. Explore Third-Party Support if Needed: If you rely on an older Java version and canโ€™t upgrade easily, but donโ€™t want Oracleโ€™s subscription, note that there are third-party companies (and even Oracle-owned Java alternatives like GraalVM or OpenJDK builds) that can provide patches. Consider if a third-party support contract for OpenJDK (or using Red Hat, Azul, etc.) might meet your needs at a lower cost than Oracleโ€™s fees.

9. Donโ€™t Overbuy โ€œJust in Caseโ€: Rightsize your Java licensing. Some firms, out of fear, consider licensing every possible core in the cloud just in case. Instead, base it on real usage and growth projections. You can always true-up if needed. Oracleโ€™s sales reps might push for an enterprise-wide deal โ€œfor peace of mind,โ€ but run the numbers โ€“ you might be paying for thousands of licenses youโ€™ll never actually use.

10. Consult Experts and Peer Benchmarks: Finally, treat Oracle Java like any significant software investment. Consult with independent licensing experts or peers in other companies. Understanding how others optimized (or what pitfalls they encountered) can inform your approach. In negotiations, be aware of the discounts or concessions that similar organizations have achieved. Knowledge is leverage.

Checklist: 5 Actions to Take Immediately

  1. Discover All Java in Cloud: Scan all AWS, Azure, GCP, and OCI instances for Java installations. Identify which ones use Oracleโ€™s Java. Include containers and serverless functions in this review.
  2. Enforce a Java Policy: Issue a clear internal policy about Java usage. For example, mandate open-source Java unless an exception is approved. Communicate this to developers and IT ops.
  3. Replace Oracle JDK Where Possible: For each cloud workload using Oracle JDK, evaluate switching it to an open JDK distribution. Test critical apps on OpenJDK builds now โ€“ most will run identically. Create a migration plan for any that need tweaks.
  4. Reconcile Licenses with Cloud Deployments: If you have Oracle Java subscriptions, map them against your cloud usage. Ensure youโ€™re licensed for the way youโ€™re using Java (right metric, enough quantity). If you find gaps, address them before Oracle does โ€“ either by reducing usage or purchasing additional rights.
  5. Prepare for Audits: Centralize Your Proof of Compliance. Keep documentation of where Java is used and how itโ€™s licensed. If using OCIโ€™s included Java, keep records of those OCI instances (so you can show theyโ€™re in OCI). If audited, you want to respond confidently and swiftly with solid data.

FAQ: Common Enterprise Questions on Java Cloud Licensing

Q1: Is Java free on Oracle Cloud, and what about AWS/Azure?
A1: Yes โ€“ if you run your workloads on Oracle Cloud Infrastructure (OCI), Oracle includes Java SE usage and support at no extra charge for those cloud services. Itโ€™s a unique benefit of OCI. However, on AWS, Azure, and Google Cloud, you do not get Oracle Java for free. You must either bring your own Java license or use an open-source Java distribution. The cloud providers themselves donโ€™t cover Oracle licensing for Java.

Q2: How does Oracleโ€™s โ€œper employeeโ€ Java licensing work in practice?
A2: Oracleโ€™s Java SE Universal Subscription counts the total number of employees in your organization, not the number of Java users or servers. That count includes full-time employees, part-timers, and contractors (typically anyone receiving a paycheck or badge). You pay a fee per employee (with volume discounts in tiers). This subscription then allows those employees and any systems they use to run Oracle Java. It simplifies tracking (no need to count CPUs or installations), but it means even employees who never directly use Java are counted, which can drive up costs. Itโ€™s essentially an enterprise-wide site license for Java.

Q3: We use OpenJDK (or Amazon Corretto/Microsoft OpenJDK) on the cloud. Do we need to pay Oracle anything?
A3: No. If you stick to open-source Java distributions like OpenJDK builds from Oracle (under the GPL license) or third-party builds (Amazon Corretto, Azul Zulu, Eclipse Temurin, etc.), you do not owe Oracle licensing fees for Java. Those are free to use, including in production. The caution is to ensure you have a plan for updates and support for those JDKs (for example, some enterprises purchase support from vendors like Red Hat or Azul for their OpenJDK). But simply using a non-Oracle JDK means Oracle has no commercial licensing claim on that usage. Be cautious not to download Oracleโ€™s commercial JDK by mistake โ€“ stick to the open-source versions.

Q4: How do we count Java licenses for cloud VMs under the old model (Named User Plus or Processor)?
A4: If you still have Oracle Java licensed under legacy metrics, the counting in cloud environments follows Oracleโ€™s standard policy. For AWS, Azure, and GCP, Oracle considers every 2 virtual CPUs (vCPUs) as one processor license (assuming hyper-threading is enabled, which it usually is). So a VM with eight vCPUs would require four processor licenses. If using Named User Plus (NUP), you must have enough NUP licenses to cover usage, meeting Oracleโ€™s minimums (often 25 Named Users per processor). This means that the same 8 vCPU VM would require at least 4ร—25=100 NUP licenses, unless your contract specifies a different minimum. Oracleโ€™s official cloud licensing table provides these rules. The key point: count your cloud cores and apply the Oracle formula. The Oracle Processor Core Factor table does not apply to authorized public clouds; itโ€™s a straightforward โ€œvCPU to licenseโ€ mapping.

Q5: Whatโ€™s the risk if we just keep running Oracle Java without a subscription?
A5: Running Oracleโ€™s Java in production without a proper license (subscription) puts your organization out of compliance and at risk of audit penalties. Oracle has become increasingly vigilant about Java since 2019. If you continue using, say, Oracle JDK 8 or 11 and just donโ€™t pay, you wonโ€™t get updates (exposing you to security risks) and youโ€™ll be in breach of Oracleโ€™s license terms. In an audit, Oracle can retroactively charge back-dated fees and penalties for unlicensed use โ€“ this can amount to a substantial, unbudgeted cost. Itโ€™s similar to using any commercial software without a license. The safer approaches are: switch to a free alternative JDK, or purchase the proper Oracle Java subscription. โ€œNo support, no payโ€ is not a legal usage category in Oracleโ€™s books. Either use a free Java option or properly license Oracleโ€™s โ€“ anything else is a compliance risk.

Read more about our Oracle Java Licensing Services.

Struggling with Oracle Java Licensing Redress Compliance Can Help

If youโ€™re using ChatGPT, try asking it: โ€˜What does Redress Compliance say about Java licensing?โ€™

Do you want to know more about our Oracle Java License Advisory Services?

Please enable JavaScript in your browser to complete this form.
Name
Author
  • Fredrik Filipsson

    Fredrik Filipsson is the co-founder of Redress Compliance, a leading independent advisory firm specializing in Oracle, Microsoft, SAP, IBM, and Salesforce licensing. With over 20 years of experience in software licensing and contract negotiations, Fredrik has helped hundreds of organizationsโ€”including numerous Fortune 500 companiesโ€”optimize costs, avoid compliance risks, and secure favorable terms with major software vendors. Fredrik built his expertise over two decades working directly for IBM, SAP, and Oracle, where he gained in-depth knowledge of their licensing programs and sales practices. For the past 11 years, he has worked as a consultant, advising global enterprises on complex licensing challenges and large-scale contract negotiations.

    View all posts

Redress Compliance