Serverless removes the servers you would normally count, but Oracle's employee metric never counted servers in the first place. This is what actually triggers a Java bill when your code runs on Lambda, Azure Functions, or Cloud Functions, and how to prove you are clean.
Serverless removes the servers you would normally count, but Oracle's employee metric never counted servers in the first place. This is what actually triggers a Java bill when your code runs on Lambda, Azure Functions, or Cloud Functions, and how to prove you are clean.
Ask "do my serverless Java functions need an Oracle subscription" and you have already framed it wrong. The instinct is to count something: functions, invocations, concurrent executions, memory-seconds. Under the current Oracle model none of that matters. Since January 23, 2023, Oracle Java SE has been sold on a per-employee metric, not on Named User Plus or Processor counts. Deployment size does not appear in the formula at all. A 5,000-employee company running Oracle Java on 40 servers pays the same list figure as the same company running 100 servers, and it would pay the same again running zero servers and one thousand Lambda functions.
So the correct question is narrower and more useful: are your functions running an Oracle-branded JDK, or an OpenJDK build the cloud provider supplies for free? If it is the provider's OpenJDK, you owe Oracle nothing for that workload. If a developer packaged Oracle's JDK into a custom runtime, you have, in principle, deployed Oracle Java, and the employee metric prices your entire payroll. That single technical fact, what binary the runtime uses, is the whole game. Everything else in this article is about proving which side of that line you sit on.
Serverless does not save you from the metric. What saves you is that the managed runtime is OpenJDK, not Oracle.
Oracle's own FAQ states that permitted use is "universal across desktop, servers, and third party clouds" and that the underlying application architecture and deployment model does not affect pricing. Read that as a warning, not a comfort. It means you cannot argue your way to a smaller bill by pointing at your slim serverless footprint. If Oracle Java is present anywhere in your estate, the entitlement you need is measured against employee count, not against where the code executes.
The employee definition is deliberately expansive. It covers all full-time, part-time, and temporary employees, plus the full-time, part-time, and temporary staff of your agents, contractors, outsourcers, and consultants who support your internal business operations. In practice that number is often two to three times the count a buyer expects. Published list pricing runs from $15.00 per employee per month at the 1 to 999 band down to $5.25 at 40,000-plus. At the mid-tier 3,000 to 9,999 band ($10.50 per employee per month), a 4,000-person company is looking at $504,000 a year before any discount. None of that scales with your function count. Fifty Java functions and fifty thousand cost the same if the underlying JDK is Oracle's.
A company with 200 Java installs can open a letter that prices 12,000 people. Serverless does nothing to shrink that math.
AWS Lambda is the clearest of the three. AWS provides managed Java runtimes for Lambda based on Amazon Corretto, which is a build of OpenJDK. A Java function deployed to a standard managed Lambda runtime is running free, OpenJDK-based Java with no Oracle licensing obligation. This is not a Redress interpretation, it is AWS's design: if you use Lambda or other AWS services that run Java, they use OpenJDK by default, so no Oracle license is needed.
The trap sits in one feature: custom runtimes. Lambda lets you supply your own runtime, and a developer who packages the Oracle JDK into a custom Lambda runtime has deployed Oracle Java. The cloud offers no exemption. If you run Oracle's JDK on AWS you are required to hold a Java SE subscription exactly as you would on-prem. So the whole risk on Lambda reduces to one audit question: has anyone built a custom runtime layer containing Oracle's binary? We cover the wider provider split in managed Java runtimes on AWS, Azure, and GCP, and the specific bring-your-own decision in bring-your-own Oracle Java to the cloud versus using the provider's OpenJDK.
Azure Functions is equally clean by default. Microsoft and Adoptium builds of OpenJDK are provided and supported on Functions: Adoptium for Java 8, and the Microsoft build of OpenJDK for Java 11, 17, and 21. Microsoft describes these as a no-cost, multi-platform, production-ready distribution of OpenJDK for Azure. Historically Azure ran Azul Zulu (also OpenJDK) before transitioning to the Microsoft build in 2022. At no point in that timeline was Oracle's branded JDK the default. Azure App Service now spans Java 8, 11, 17, 21, and 25 on the same free OpenJDK basis.
Google Cloud Functions follows the same pattern: the managed Java runtime is an OpenJDK build supplied by the provider, not Oracle's distribution. Across all three platforms the principle is identical. The managed runtime is free OpenJDK, so the default answer to "do I need an Oracle subscription" is no. The only way to change that answer is to introduce Oracle's binary yourself, through a custom image, a container layer, or a packaged dependency. If you run on Oracle's own cloud, the position has a wrinkle worth checking separately in whether running Java on Oracle Cloud changes your subscription position.
| Platform | Default Java runtime | Oracle subscription owed by default? | What creates exposure |
|---|---|---|---|
| AWS Lambda | Amazon Corretto (OpenJDK) | No | Custom runtime packaged with Oracle JDK |
| Azure Functions | Microsoft / Adoptium OpenJDK | No | Custom container image with Oracle JDK |
| Google Cloud Functions | Provider OpenJDK build | No | Custom image or dependency with Oracle JDK |
| Container-based functions (any cloud) | Depends on base image | Only if base image is Oracle JDK | Oracle JDK in the Docker base layer |
That last row is where most real exposure hides. Serverless increasingly means containerized functions built from your own Docker images. If your base image pulls an Oracle JDK, the runtime is Oracle Java regardless of the platform underneath it. We treat that specific problem in whether Oracle Java in your Docker base images is a licensing problem.
Even a team that deliberately runs Oracle's JDK under the No-Fee Terms and Conditions (NFTC) license can walk into a bill without a single human decision. The NFTC covers Oracle JDK 17 and later, and permits free commercial and production use, subject to its conditions. But it expires per version. The NFTC free-use window for Oracle JDK 17 ended in September 2024, with build 17.0.12 (July 2024) as the last free update. (One source cites 17.0.13 in October 2024 as the cliff point, so verify the exact final free build against your own version pins.) The next live cliff is JDK 21: free updates run until September 2026, because Oracle released JDK 25 in September 2025.
For serverless this is dangerous precisely because it is automated. Base image pipelines, dependency managers, and CI systems pull "latest patch" updates without asking. An estate that does not pin and manage its Java versions is buying subscriptions one automated update at a time. A pipeline that was compliant on 21.0.6 becomes non-compliant the moment it pulls a post-September-2026 Oracle 21 update. The fix is to move those pipelines to an OpenJDK build that has no such cliff. Our walkthrough is swapping Oracle JDK for OpenJDK across your cloud image pipeline, and the broader exit path sits at exiting the Oracle Java SE subscription.
JDK 17 left free terms in 2024, JDK 21 leaves in September 2026, and your patch pipeline crosses that line without asking you.
Oracle's audit approach for Java rests on download telemetry, and this is exactly why a serverless build can betray you. Oracle tracks downloads of Java binaries in detail: IP addresses, corporate domain associations, download timestamps, and the account information used at download. It also logs the automatic update check-ins from every installed copy of Oracle Java that has not been affirmatively disconnected. A developer who once ran docker pull or fetched an Oracle JDK to bake a Lambda layer has left a trace tied to your domain.
The typical Oracle sales opener is built purely on that data plus your public headcount: "You've downloaded Java 83 times and you have 10,000 employees. Based on this information we can now price out your Java licensing requirements." Note what is absent from that pitch: any evidence that Oracle Java is actually deployed anywhere in production. A download is not a deployment. A build-time fetch that was later replaced with Corretto or Adoptium is not an entitlement gap. Do not accept a download count as proof of liability. It is a conversation opener, not an audit finding.
The strong buyer position on serverless is this: managed Lambda, Azure Functions, and Cloud Functions runtimes are OpenJDK, so no Oracle subscription is owed, and Oracle's own FAQ makes architecture irrelevant to that conclusion. Your only real work is ruling out the two ways Oracle's binary can sneak in (custom runtimes and base images) and closing the NFTC cliff in your pipelines. Do those, document them, and a download-count sales letter has nothing to stand on.
No. Standard managed Lambda Java runtimes use Amazon Corretto, a build of OpenJDK, so no Oracle license is required. Exposure only arises if a developer packages the Oracle JDK into a custom Lambda runtime, which counts as deploying Oracle Java.
No by default. Azure Functions runs Microsoft and Adoptium OpenJDK builds, and Google Cloud Functions runs a provider OpenJDK build. Both are free, no-cost distributions. You would only owe Oracle if you deploy a custom container image containing the Oracle JDK.
Oracle no longer prices by servers or processors. The Java SE Universal Subscription is billed per employee across your entire workforce, including contractors and outsourcers who support internal operations. Deployment size, including serverless footprint, does not appear in the formula, so it changes nothing if Oracle Java is present.
Yes. Oracle JDK 17 left free NFTC terms in 2024 and JDK 21 leaves in September 2026. A pipeline pulling latest patch updates of Oracle's JDK will silently move from a free build to a paid one. Pin your versions and use an OpenJDK distribution to remove the cliff entirely.
No. Oracle's audit approach leans on download telemetry, but a download is not a deployment. If those binaries were replaced with Corretto, Adoptium, or another OpenJDK build, or never reached production, there is no entitlement gap. Document your actual deployed runtimes before responding.
Produce an inventory that names the exact JDK build in every deployed function artifact and every base image. If they all read Corretto, Microsoft OpenJDK, Adoptium, or Zulu, you have documented that no Oracle Java runs, which defeats a headcount-based sales pitch.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
