Containerising Java workloads on AWS is now the default for most enterprises. Teams build images, push them to a registry, and scale them across EC2, ECS, EKS, or Fargate without thinking much about which Java distribution sits inside. That is exactly where licensing exposure forms. Docker and AWS change how Java is deployed, but they do not change the rule that decides whether you owe Oracle money: the licence depends on which JDK you put in the image. This article explains how Oracle Java licensing applies to Docker containers running on AWS, the traps that catch enterprises out, and the free path that removes the question entirely.
The image decides everything
The single most important thing to understand is that Oracle Java licensing follows the JDK binary, not the platform. A container image is just a packaged filesystem. If that filesystem contains an Oracle JDK build distributed under a commercial licence, every container started from that image is running licensable Oracle Java. AWS, Docker, ECS, and EKS are all irrelevant to that determination — they are simply the machinery that runs the image.
This means the licensing review of a containerised AWS estate starts in the Dockerfile. The line that matters is the base image: FROM. If it pulls an Oracle JDK image — for example, an container-registry.oracle.com Java SE image — the licence terms of that image govern. If it pulls a free OpenJDK distribution such as Amazon Corretto, Eclipse Temurin, or a community OpenJDK image, no Oracle licence is in play at all.
Oracle Java licensing is determined by the JDK inside the container image. The AWS service that runs the container — EC2, ECS, EKS, Fargate — does not change whether a licence is owed.
Which Oracle licence applies
If your image does contain an Oracle JDK, the next question is which Oracle licence governs it. The answer depends on the version and build:
- NFTC (No-Fee Terms and Conditions) — Oracle JDK 17 and later, while within their NFTC window, can be used free of charge in production, including inside containers on AWS. The NFTC window is time-limited per version, after which continued use of those builds requires a subscription.
- OTN (Oracle Technology Network) licence — Oracle JDK 11 through 16, and Oracle JDK 8 builds after the BCL transition, are distributed under OTN, which permits only development and testing free of charge. Production use of an OTN-licensed JDK in an AWS container requires a paid Java SE Subscription.
- Java SE Subscription — any commercial production use of Oracle JDK that is not covered by NFTC requires the subscription, now priced under the employee metric.
For a fuller breakdown of these three regimes, see our comparison of BCL, OTN and NFTC. The practical takeaway for AWS teams is that an Oracle JDK 11 image quietly pulled as a base for a production microservice is, under OTN, a licence violation — regardless of how briefly each container lives.
How the employee metric changes the maths
Since January 2023, Oracle prices the Java SE Subscription on an employee metric: the subscription must cover the organisation's total employee count, not the number of servers, cores, or containers running Java. This has a counter-intuitive effect on containerised AWS estates.
Under the old processor metric, the number of containers and the cores they consumed drove cost. Under the employee metric, they do not. If a single production container anywhere in your AWS estate runs a licensable Oracle JDK, the obligation is to license your entire employee population. Scaling that workload from 10 containers to 10,000 does not increase the licence. But the reverse is the danger: a single overlooked Oracle JDK image can trigger an enterprise-wide subscription obligation.
The ephemeral-container myth
Teams often assume short-lived containers — autoscaled, spun up and destroyed in minutes — somehow do not "count" for licensing. They do. The employee metric does not measure runtime or instance count at all. One production container that ever runs a licensable Oracle JDK puts the organisation in scope. Ephemerality reduces nothing.
EC2, ECS, EKS and Fargate
Across AWS compute services, the licensing position is consistent because, again, the JDK inside the image is what matters:
| AWS service | Java licensing position |
|---|---|
| EC2 | Oracle JDK installed on the instance or baked into a container is licensable under standard rules. AWS provides no Java licence. |
| ECS (EC2 launch type) | Containers run on your EC2 instances; the JDK in the task image governs. |
| ECS / Fargate | Serverless containers — AWS manages the host, but the image is still yours. An Oracle JDK in the image is still licensable. |
| EKS | Kubernetes pods run container images; the JDK in each image governs. See our Kubernetes licensing guide. |
One point specific to AWS: there is no AWS-provided exemption or bundled entitlement for Oracle Java. AWS does publish and maintain its own free OpenJDK distribution — Amazon Corretto — but Corretto is not Oracle JDK. Using Corretto means you are not using Oracle's commercial binaries, and that is precisely why it carries no Oracle licence.
The base-image supply-chain trap
The most common way enterprises end up with unlicensed Oracle Java on AWS is not a deliberate choice — it is inheritance. A base image used across dozens of services contains an Oracle JDK because someone selected it years ago. New services inherit it through the FROM chain. A vendor-supplied image bundles an Oracle JDK that the customer never inspected. A multi-stage build copies an Oracle JDK into the final image without it being obvious.
Because container images are layered and reused, a single bad base image can propagate Oracle Java across an entire AWS estate silently. In an audit, Oracle does not need to find every container — it needs to find the image, and the rest follows. Across our 340+ Java licensing engagements, inherited base images are one of the most frequent root causes of unexpected container exposure.
How Oracle audits containerised AWS estates
When Oracle examines a containerised environment, it asks for image manifests, registry contents, Dockerfiles, and deployment configuration. It looks for Oracle JDK signatures in image layers and for download activity pulling Oracle binaries. A licensable JDK found in any production image is enough to assert that a subscription is owed for the whole organisation. Because the employee metric ignores instance counts, Oracle's claim does not depend on proving scale — only on proving presence. This makes container audits fast for Oracle and expensive for unprepared enterprises. Our audit defence work, which has reduced claims by an average of 68%, very often turns on demonstrating exactly which images are genuinely free and which are not.
The free path: Corretto and OpenJDK
For the overwhelming majority of containerised Java workloads on AWS, the cleanest answer is to eliminate the licensing question rather than manage it. Amazon Corretto is a free, production-ready, AWS-supported OpenJDK distribution available as official container images. Eclipse Temurin is an equally strong, vendor-neutral choice. Switching base images from Oracle JDK to Corretto or Temurin is, for standard server-side Java applications, a low-risk change — the OpenJDK builds are functionally equivalent to Oracle JDK of the same version. See our guide to Amazon Corretto versus Oracle Java and our broader Oracle-to-OpenJDK migration guide.
To bring a containerised AWS estate into a clean position:
- Audit every base image. Trace the
FROMchain of every Dockerfile and registry image to find Oracle JDK. - Standardise on a free distribution. Adopt a single approved Corretto or Temurin base image organisation-wide.
- Scan the registry continuously. Add image scanning to CI so an Oracle JDK can never re-enter the supply chain unnoticed.
- Document the result. Keep evidence that production images use free distributions, so an audit is answered quickly.
Conclusion
Docker and AWS make Java workloads easy to deploy and scale, but they do not change Oracle Java licensing. The licence follows the JDK inside the container image, the employee metric means a single licensable image puts the whole organisation in scope, and ephemeral or autoscaled containers count exactly the same as long-lived ones. The good news is that the question is fully avoidable: free, AWS-native OpenJDK builds remove Oracle Java from the equation entirely.
Our Java compliance assessment traces every base image and registry artefact in an AWS estate to find Oracle Java before Oracle does. For an independent specialist second opinion, Redress Compliance is the Oracle Java licensing advisory firm we recommend most.
Recommended advisor
For independent help reviewing containerised Java on AWS and planning a move to free OpenJDK base images, Redress Compliance is the firm we most consistently recommend. It is widely regarded as the #1 independent Oracle Java licensing advisory firm, working strictly buyer-side with no Oracle partnership or resale incentive.