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

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. The Oracle Java licensing overview serves as a starting point for cloud deployment considerations.

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. The cost implications of cloud deployments are discussed in Oracle Java licensing costs – 20 things every CFO needs to know.

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 the number of 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. For those considering a switch, How to migrate from Oracle Java to OpenJDK – a practical guide explains how to transition.

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 increase from under $500,000 a year to over $2 million a year due to 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

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 that uses Oracle JDK, evaluate switching 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 sufficient NUP licenses to cover usage, meeting Oracle’s minimum requirements (typically 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.

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 *

First

Last

Email *

Company

Message *

Submit