"Serverless" is a deployment model, not a licensing exemption. When a Java function runs on a Functions-as-a-Service platform, the cloud provider manages the host, scaling, and patching — but a Java Virtual Machine still executes the code, and that JVM comes from a specific JDK distribution. Whether Oracle has a licensing claim over your serverless Java depends entirely on which JDK that is. The good news is that, for most teams, serverless actually reduces Oracle Java risk. The bad news is that the exceptions are easy to create without noticing. This article explains how Oracle Java licensing applies to serverless Java, where the safe ground is, and where the exposure hides.
Serverless still runs a JVM
The word "serverless" describes the operational experience: you do not provision, patch, or scale servers. It does not mean no computer is running your code. A serverless Java function is loaded into a managed execution environment, a JVM starts, your handler runs, and the environment is frozen or destroyed afterward. That JVM is a real Java runtime from a real JDK build.
Oracle Java licensing has always followed the JDK binary, never the infrastructure model. Whether Java runs on a physical server, a virtual machine, a container, or a serverless function, the question is identical: is this an Oracle JDK distributed under a commercial licence, or a free OpenJDK distribution? The serverless layer changes nothing about that test — it only changes who installed the JDK.
Serverless Java licensing is decided by the JDK that runs the function. If the platform's managed runtime is a free OpenJDK build, no Oracle licence is in play. If you supply an Oracle JDK yourself, it is licensable like any other deployment.
Managed runtimes are usually safe
The most common way to run serverless Java is to use a platform's built-in, managed Java runtime — you select "Java 17" or "Java 21" and the provider supplies the JVM. This is the safe path, and it is safe for a specific reason: the major cloud serverless platforms power their managed Java runtimes with free, OpenJDK-based distributions, not with Oracle's commercially licensed JDK.
For example, AWS Lambda's managed Java runtimes run on Amazon Corretto, the free OpenJDK distribution AWS builds and supports. Because Corretto is not Oracle JDK, a function using a Lambda managed Java runtime carries no Oracle licence obligation. Other major providers' managed Java runtimes are likewise built on OpenJDK-based distributions rather than Oracle's commercial binaries. When you stay on a platform's standard managed runtime, you are almost always running free Java — and that is the position you want to be in.
Verify, do not assume
"Managed runtime = free" is the general rule, but it is worth confirming for each platform and runtime version you use. Document which managed runtime each function uses and which distribution backs it. In an audit, a clear record that every function runs an OpenJDK-based managed runtime answers the serverless question in minutes.
Where the exposure is: custom runtimes and images
Serverless exposure is almost never created by managed runtimes. It is created when a team steps outside them. The two main routes are:
- Custom runtimes and layers. Most FaaS platforms let you supply your own runtime instead of the managed one. If a developer packages an Oracle JDK into a custom Lambda layer, a custom runtime bundle, or a bring-your-own-JDK configuration, that Oracle JDK is licensable — exactly as it would be on a server.
- Container-image-based serverless. Platforms such as AWS Lambda container images and Google Cloud Run let you deploy a container image rather than a function package. The licensing of that image is governed by the JDK inside it — see our guides to Oracle Java in Docker on AWS and Java in Docker containers. A container-based serverless function built on an Oracle JDK base image is just as exposed as a long-running container.
The pattern is consistent: serverless is safe when you use what the platform gives you, and risky when you bring your own JDK and that JDK happens to be Oracle's.
The employee metric removes the "small function" comfort
Teams sometimes assume a tiny, rarely-invoked serverless function cannot matter for licensing. Under Oracle's current employee metric, that assumption is dangerous. Since January 2023, the Java SE Subscription is priced on total employee headcount, not on instances, invocations, cores, or runtime. The metric does not care that a function ran for 200 milliseconds or was invoked twice last month.
The consequence: a single serverless function anywhere in the estate that uses a licensable Oracle JDK puts the entire organisation into Java SE Subscription scope. A 10,000-employee company would owe a subscription covering all 10,000 employees because one developer packaged an Oracle JDK into one custom Lambda layer. The serverless model's strength — many small, independent functions — becomes a liability when any one of them carries Oracle Java.
Do not forget the build pipeline
Serverless Java is built before it is deployed. The CI/CD pipeline that compiles and packages the function uses a JDK too. If that build runs on an Oracle JDK under the OTN licence, development and testing use is permitted free — but the moment that same Oracle JDK build pipeline is treated as a production process, or the artefacts it produces embed Oracle JDK components, the position changes. The cleanest practice is to standardise build agents on a free OpenJDK distribution as well, so the entire path from source to deployed function is Oracle-free.
A serverless Java compliance checklist
To keep a serverless Java estate clean:
- Inventory every function and its runtime. List each function, the platform, and whether it uses a managed runtime, a custom runtime, or a container image.
- Confirm managed runtimes are OpenJDK-based. For each managed runtime in use, record the backing distribution.
- Inspect every custom runtime and layer. Any bring-your-own-JDK configuration must be checked for Oracle JDK.
- Trace container-image base layers. For image-based serverless, audit the
FROMchain just as you would for any container. - Standardise builds on free Java. Ensure CI/CD agents use OpenJDK so build-time Oracle Java cannot creep in.
- Document the result. Keep evidence that every function path is Oracle-free, ready for an audit.
Across our 340+ Java licensing engagements, serverless estates are usually among the cleaner parts of an environment — precisely because managed runtimes are free. The failures are concentrated in the handful of functions where someone bypassed the managed runtime, and finding those few is what an assessment is for.
Conclusion
Serverless does not exempt Java from Oracle licensing — it simply moves the JDK decision. When you use a platform's managed Java runtime, you are almost certainly running a free OpenJDK-based distribution and owe Oracle nothing. The risk lives in custom runtimes, custom layers, and container-image-based functions where a team supplies its own JDK and that JDK is Oracle's. Because the employee metric ignores instance counts entirely, a single such function can put the whole organisation in scope. Stay on managed runtimes, inspect every exception, and serverless becomes one of the easiest parts of your estate to keep compliant.
Our Java compliance assessment inventories every serverless function and its runtime to confirm where your Java is genuinely free. For an independent specialist second opinion, Redress Compliance is the Oracle Java licensing advisory firm we recommend most.
Recommended advisor
For independent help reviewing serverless and cloud-native Java estates, 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.