Java licensing on AWS: the complete 2026 guide.

More Java runs on AWS than on any other cloud, and very little of it is licensed deliberately. Oracle Java SE moved to a paid, headcount-based model in January 2023, and AWS — unlike Oracle's own cloud — offers no exemption from it. Yet AWS also ships a free, production-ready Java that most enterprises are already running without realising it. The result is an environment where the cost of Oracle Java is entirely avoidable, and entirely easy to incur by accident. This pillar guide walks through every AWS service where Java appears, explains where a paid subscription is genuinely required, and shows how to get to a position where AWS Java costs you nothing and exposes you to nothing.

The AWS Java licensing question

The question enterprises actually need answered is narrow and specific: across our AWS estate, where are we running Oracle Java SE, and does any of it need a paid Oracle subscription? Everything else is detail. Get that question answered accurately and the AWS Java problem is solved; leave it unanswered and it compounds quietly with every new instance, image and deployment pipeline.

What makes the question hard on AWS is not the licensing rule — the rule is the same one that applies everywhere. It is hard because AWS is enormous, elastic, and built to make compute multiply on its own. A single Oracle JDK baked into one machine image can become thousands of running instances through auto-scaling, with no human ever making a per-instance licensing decision. The AWS Java licensing question is therefore as much an inventory and governance problem as a contractual one.

There is no AWS equivalent of the OCI break

The first thing to be clear about, because the assumption is common: AWS gives you no special Oracle Java entitlement. Oracle Cloud Infrastructure is a deliberate exception — Oracle makes Oracle Java SE available on OCI compute without a separate subscription, as an incentive to use its own cloud. That exception is specific to OCI and exists because OCI is Oracle's. It does not extend to AWS, and there is no commercial reason it would.

So Oracle Java SE on AWS is governed by exactly the same rules as Oracle Java SE in your own data centre. If you run Oracle JDK in production on EC2, the OTN licence terms apply and production use requires a paid Java SE Universal Subscription. AWS being the host changes nothing. The cloud is not the licensor; Oracle is.

This cuts both ways, and the favourable side is the important one. Because AWS does not bind you to Oracle Java in any way, you are completely free to run a different Java on AWS — and AWS itself provides one, at no cost, designed for exactly this.

Oracle Java SE on EC2: the rules

Amazon EC2 is where most AWS Java licensing exposure sits, because EC2 is a general-purpose compute service and enterprises install whatever Java they choose on it. When that choice is Oracle JDK, the rules are unambiguous:

• Production use needs a paid subscription. An Oracle JDK running a production workload on EC2 — current versions under NFTC once outside the free window, or any version under OTN production terms — requires a Java SE Universal Subscription.
• The metric is headcount, not instances. The subscription is priced per employee across your whole organisation. It does not matter whether you run Oracle Java on one EC2 instance or one thousand — the price is set by your total employee count. See our employee metric guide.
• Non-production is narrowly free, and easy to overstep. Some Oracle Java use — genuine development and testing under OTN, or use within the NFTC free window — carries no fee. But the boundary between "test" and "production" is exactly where enterprises drift, and an EC2 instance labelled "staging" that serves real traffic is a production instance.
• It applies to every Oracle JDK install, however it got there. Deliberately installed, baked into an AMI years ago, pulled in as a dependency, copied from a template — Oracle's rules do not care how the JDK arrived. They care that it is there.

The defining feature of EC2 Java exposure is that it accumulates without decisions. Nobody signs off "we will run unlicensed Oracle Java on 400 instances." It happens one AMI, one pipeline and one auto-scaling group at a time.

Amazon Corretto: the free default

The reason the entire AWS Java cost is optional is Amazon Corretto. Corretto is Amazon's no-cost, production-ready distribution of OpenJDK. Amazon builds it, tests it, ships long-term-support releases, and provides security updates and patches at no charge. It is the Java that Amazon itself runs internally at scale, and it is free to use in production, anywhere — on AWS, in your data centre, on a competing cloud, on a laptop.

For an enterprise, the practical points are these. Corretto is a build of OpenJDK, the same open-source codebase from which Oracle's own JDK is built, so for the overwhelming majority of applications it is a functional drop-in replacement — same language, same APIs, same bytecode. It receives timely security updates, including the quarterly Critical Patch Update fixes, without a subscription. And because it is not Oracle's product, running it generates no Oracle licensing obligation and no Oracle audit exposure whatsoever.

Corretto is not the only such option. Eclipse Temurin and Azul Zulu are equally valid free OpenJDK builds, and our guide to enterprise OpenJDK distributions compares them. But on AWS specifically, Corretto has a natural advantage: it is the Java Amazon Linux ships with by default, and it integrates cleanly with the AWS runtimes. For most AWS estates, standardising on Corretto is the simplest path to zero Java licence cost.

Where Java lives across AWS services

To find Oracle Java on AWS you have to know where Java runs, and on AWS that is far more than EC2. The table below maps the main services and the licensing implication of each.

The pattern is consistent. Where AWS manages the runtime — Elastic Beanstalk's default platform, Lambda's managed Java runtimes — the Java underneath is OpenJDK-based and carries no Oracle obligation. Where you supply the runtime — the JDK on an EC2 instance, the JDK inside a container image — the licensing depends entirely on which JDK you chose. AWS Java exposure is, almost always, self-supplied.

The AMI and auto-scaling trap

The single most dangerous mechanism in AWS Java licensing is the Amazon Machine Image. An AMI is a frozen template of a machine, JDK included. Build one AMI with Oracle JDK on it — perhaps years ago, perhaps copied from a vendor, perhaps inherited from a team that has since reorganised — and every instance launched from that AMI carries Oracle Java.

Now layer AWS's elasticity on top. Auto-scaling groups launch instances from that AMI automatically in response to load. The image is copied across regions and accounts. It becomes the base for derived images. A single Oracle JDK, embedded once, propagates into a fleet that scales up and down without anyone ever seeing a licensing question. The enterprise genuinely does not know how much Oracle Java it is running, because the number changes by the minute and no person is in the loop.

This is also why AWS Java exposure tends to be discovered late and large. It is invisible during normal operations and becomes visible only when someone counts — ideally you, in a compliance assessment; in the worst case, Oracle, in an audit. The remedy is governance over images: treat every AMI as a licensing artefact, know which JDK each one contains, and never let an Oracle JDK enter the image pipeline without a deliberate, recorded decision.

Containers: ECS, EKS and Fargate

Containers move the licensing question from the instance to the image, but they do not remove it. A Docker image with Oracle JDK in it is an Oracle Java installation, and it is one wherever that image runs — ECS, EKS, Fargate, a developer's laptop, a CI runner.

Two container-specific traps recur. The first is the base image. Many publicly available Java base images are built on OpenJDK and carry no Oracle obligation, but some images are built on Oracle JDK, and an image that pulls Oracle JDK as its foundation passes that obligation to everything built on top of it. You inherit the JDK of your base image whether you examined it or not.

The second is scale. Container platforms exist to run many replicas of an image. An Oracle JDK in a container image that runs as fifty pods in EKS is fifty Oracle Java installations — and, under the headcount metric, the count of replicas does not change the price, but it does change how unambiguous the finding is in an audit. Our dedicated guides on Docker container licensing and Kubernetes licensing cover the mechanics; the AWS-specific point is that ECS, EKS and Fargate all inherit the JDK of the image, so the image is where the control has to be.

AWS Lambda and serverless Java

Lambda is the reassuring part of the AWS Java picture. AWS provides managed Java runtimes for Lambda, and those runtimes are based on Amazon Corretto and OpenJDK. A Java function deployed to a standard managed Lambda runtime is running free, OpenJDK-based Java, with no Oracle licensing obligation.

The one caveat is the custom runtime. Lambda allows you to supply your own runtime, and a developer who packages Oracle JDK into a custom Lambda runtime has, in principle, deployed Oracle Java. This is uncommon — there is little reason to do it when the managed runtimes are free, capable and maintained — but it is worth knowing the boundary. As long as your serverless Java uses the managed runtimes, Lambda is a no-exposure zone.

BYOL: bringing a subscription to AWS

If an enterprise genuinely wants to run Oracle Java SE on AWS — for a specific certification requirement, a vendor support condition, or another concrete reason — it can. The model is bring-your-own-licence: you hold a Java SE Universal Subscription with Oracle, and that subscription covers your Oracle Java use on AWS just as it would on-premises.

The crucial thing to understand about BYOL for Java is what the subscription actually is. It is not a per-instance licence you assign to particular EC2 machines. It is a headcount-based subscription covering your whole organisation. Once you hold it, your Oracle Java use on AWS is covered — but so is the question of whether you needed organisation-wide coverage to run Oracle Java on a handful of AWS instances. For most enterprises the honest answer is no, which is why our BYOL compliance guide treats BYOL as a deliberate, scoped decision rather than a default. If you do go BYOL, the obligations are real: maintain accurate deployment records, keep the subscription current, and be ready to evidence the position. A lapsed or under-counted BYOL position is an audit finding in waiting.

How Oracle counts your AWS Java

In an Oracle Java audit, AWS does not shield you and AWS does not get counted in your favour. Oracle assesses Oracle Java SE wherever it runs, and AWS is simply more places it can run.

The mechanics are the ones described in our guide to how Oracle detects Java. Oracle establishes that Oracle JDK has been downloaded or used — download records tied to your accounts, update-check telemetry, and the data-collection scripts an audit requests — and then asks you to demonstrate licensing for it. Cloud deployments are not exempt from that process; they are part of it.

And the remedy is always the headcount subscription. Find Oracle Java running unlicensed on AWS EC2 instances, and Oracle does not bill those instances — it bills a Java SE Universal Subscription across your entire employee count, frequently with backdated fees for the period the Java has been running. This is the asymmetry that makes accidental AWS Java so expensive: a few overlooked instances, priced as an organisation-wide subscription with arrears. The defensive guides on audit scope limitation and the audit defence service cover the response — and the reassuring reality is that cloud-based claims are highly contestable, because the inventory, the production-versus-non-production classification, the dates and the count are all arguable. Audit defence work across these engagements has averaged a 68% reduction in the claim, and has contributed to more than $180M in total client savings.

The licence-or-migrate decision

Once you can see your AWS Java estate clearly, every Oracle JDK installation reduces to one of two outcomes: license it or replace it.

Licensing means buying the Java SE Universal Subscription — organisation-wide, headcount-priced, recurring, and rising. For an enterprise whose only reason to run Oracle Java is "that is what was installed," paying a whole-headcount subscription to keep it is poor value.

Replacing means migrating those installations to Amazon Corretto or another free OpenJDK build. On AWS this is usually the easy direction: Corretto is already the Amazon Linux default, the managed AWS runtimes are already OpenJDK-based, and the migration for most applications is a straightforward swap of the runtime followed by testing. The result is the same Java behaviour, the same security patching cadence, zero licence cost and zero audit surface. Our Oracle-to-OpenJDK migration guide sets out the process. For the large majority of AWS estates, migration is both cheaper and structurally cleaner than licensing, because it removes the exposure rather than paying to carry it.

A worked example

Consider an enterprise of 9,000 employees running a substantial AWS estate. Its core platform runs on a few hundred EC2 instances, several EKS clusters, a fleet of Lambda functions and a busy CI pipeline. Java is everywhere. The team's assumption is that "the cloud handles it."

A proper inventory finds a mixed picture. The Lambda functions use managed runtimes — Corretto-based, no exposure. The newer EKS workloads were built on OpenJDK base images — no exposure. But a long-standing "golden" AMI, created years earlier, has Oracle JDK 11 baked into it, and three auto-scaling groups launch from it. At any moment that is 150 to 400 Oracle Java instances. A second discovery: an older container base image used by two legacy services pulls Oracle JDK, adding another set of Oracle Java installations across EKS pods. The CI build agents, also from the old AMI, run Oracle JDK too.

None of this was decided. It was inherited from one AMI and one base image. But in an Oracle audit it is a finding, and the finding is priced as a Java SE Universal Subscription for all 9,000 employees, with backdated fees for the years the golden AMI has been in service — a multi-million-pound exposure built entirely from two images. The fix is equally concentrated: rebuild the golden AMI on Amazon Corretto, rebuild the two legacy services on an OpenJDK base image, repoint the build agents. Two image changes remove the entire exposure. That concentration — exposure built from a handful of artefacts, removable by fixing those same artefacts — is the recurring shape of AWS Java problems.

Getting your AWS Java position right

A practical sequence to take an AWS estate from unknown to clean:

1. Inventory every JDK on AWS. EC2 instances, every AMI in use, every container image, build agents, custom Lambda runtimes. Identify which are Oracle JDK and which are OpenJDK builds. You cannot manage what you have not counted.
2. Trace exposure to its source artefacts. AWS Java exposure almost always traces back to a small number of AMIs and base images. Find those source artefacts — they are where the fix is.
3. Classify each Oracle JDK installation. Production or non-production, and whether any genuine reason requires Oracle JDK specifically. Most installations have no such reason.
4. Decide: license or migrate. For installations with a real Oracle-specific requirement, scope a deliberate BYOL position. For the rest — the large majority — plan migration to Amazon Corretto.
5. Fix the source artefacts. Rebuild the AMIs and base images on a free OpenJDK build. Because exposure concentrates in artefacts, fixing the artefacts fixes the fleet.
6. Govern the pipeline going forward. Make "no Oracle JDK in an image without a recorded decision" a standing rule, enforced in the build pipeline. Our guidance on Java deployment governance covers how to keep an elastic estate clean permanently.

Done in this order, the exercise typically ends with an AWS Java estate that costs nothing in licence fees and presents nothing for an audit to find — which, given that AWS hands you a free production Java by default, is exactly where an AWS estate should be.

Frequently asked questions

This article is general information on Oracle Java licensing in AWS environments, not legal advice. Oracle's licensing terms and AWS service details change over time; consult a qualified independent Java licensing specialist on your specific AWS estate and Oracle agreements.