Moving Oracle Java into AWS, Azure, or GCP saves nothing: the employee metric bills the same $15.00 to $5.25 per employee per month whether the JVM runs on a laptop or an EC2 instance
Oracle's own FAQ states permitted use is universal across desktop, servers, and third party clouds and that deployment model does not affect pricing, so a 4,000-employee company pays $504,000 a year at the published $10.50 band even with 47 Oracle Java installs. AWS Corretto and Microsoft Build of OpenJDK cost $0 and carry support to October 2030 and beyond. The only cloud decision that changes the bill is removing every licensable Oracle JDK install, and the October 2026 JDK 21 NFTC cliff sets the deadline.
Prepared by Redress Compliance · September 1, 2026 · Oracle Java advisory. Cloud migration and audit-defense engagements, 2024 to 2026.
Executive summary
BYOL is a null concept for Oracle Java: the Universal Subscription is priced on total headcount, so migrating a 500-VM Java estate to AWS moves zero dollars off the invoice.
Oracle's published example prices a 28,000-employee company (23,000 staff plus 5,000 contractors and agents) at 28,000 x $6.75 x 12 = $2,268,000 a year, and that figure is identical whether the workload sits in a datacenter, on EC2, or on Azure VMs.
The saving is binary, not proportional: you pay full headcount price until the last licensable Oracle JDK install is gone, then you pay $0.
A single unlicensed Oracle JDK application anywhere in the estate triggers a subscription counted across every one of your employees, which is why partial cloud migrations produce no financial benefit at all.
The October 2026 Critical Patch Update converts unmanaged cloud estates automatically: JDK 21 updates leave the NFTC and revert to the OTN license used by Java 8, 11, and 17.
Unpinned AMIs, golden images, and yum or apt repos will pull a licensable binary without a human decision, repeating the JDK 17 pattern where build 17.0.12 in July 2024 was the last free update.
Provider OpenJDK is not a downgrade on support horizon: AWS extended Corretto 8 to December 2030 and Corretto 11 to January 2032, while Corretto 21 runs to October 2030 and Corretto 25 to October 2032.
Azure App Service auto-patches supported Microsoft and Adoptium builds quarterly in January, April, July, and October, with at least six months of deprecation notice, all at no license cost.
How the two options actually bill: employee metric versus provider OpenJDK
Start with the arithmetic, because it settles the argument before any architecture discussion begins.
The Oracle Java SE Universal Subscription bills on the Employee metric: every full-time, part-time, and temporary employee, plus agents, contractors, and consultants who support internal operations, counted whether or not a single one of them ever opens a Java application.
Published list runs from $15.00 per employee per month at the smallest band down to $5.25 at 40,000 to 49,999 employees, with no published rate above 50,000 (that is negotiated).
Oracle's own worked example on the global price list puts a 28,000-employee organization (23,000 employees plus 5,000 contractors) at 28,000 × $6.75 × 12 = $2,268,000 per year.
The rate is all-in: there is no separate 22 percent support line, and buyers who add one to their models are double-counting.
The only infrastructure-side constraint is the installation cap: you may run on up to 50,000 Processors excluding desktops and laptops, and autoscaling IaaS fleets can quietly approach it, which we cover in how autoscaling Java workloads blow past the 50,000-Processor cap.
Against that sits $0 for AWS Corretto and the Microsoft Build of OpenJDK, both production-ready, both patched on the January, April, July, October CPU cadence.
| Dimension | Oracle BYOL into AWS/Azure/GCP | AWS Corretto | Azure: Microsoft Build / Adoptium | OCI included Java |
|---|---|---|---|---|
| Cost basis | Employee count, $15.00 to $5.25/employee/month | $0 license | $0 license | Included with OCI compute |
| Support line | All-in, no separate 22% | Included, AWS-supported | Included, LTS only | Included |
| Patch cadence | Quarterly CPU | Quarterly (e.g. 21.0.12, 8u502 on 22 Jul 2026) | Quarterly Jan/Apr/Jul/Oct | Quarterly CPU |
| Support horizon | Java 21 to at least Sep 2031 (subscription) | Corretto 21 to Oct 2030, 25 to Oct 2032, 8 to Dec 2030, 11 to Jan 2032 | Java 8/11/17/21/25 on LTS community timelines, 6 months deprecation notice | Tied to OCI tenancy |
| Cloud portability | Universal, but no price relief anywhere | AWS-optimized, runs anywhere | Azure-optimized, runs anywhere | OCI only |
| Audit exposure | Full: every install licensable, Employee count auditable | None on the JDK | None on LTS builds | None while on OCI |
The table shows rates. What it cannot show is the shape of the curve. Oracle Java pricing under the Employee metric is a step function, not a slope: a 4,000-employee company sits in the $10.50 band and owes $504,000 a year whether it runs 47 Oracle JDK installs or 4,700.
Consolidating servers, rightsizing instances, containerizing, or migrating to a cheaper region moves the install count and moves nothing on the invoice.
The corollary is the only optimization that works: the bill drops to zero only when the last licensable Oracle JDK install is gone. Partial cleanup earns nothing.
One application still on unlicensed Oracle JDK requires the whole-company subscription, though individual applications may run different distributions, so whole-estate standardization is not a prerequisite for exit.
Why 'BYOL' is a category error when the meter is headcount
BYOL vocabulary arrived in Java conversations by contamination from Oracle Database and Middleware, where it means something real.
There, the license is consumed in infrastructure units, Processor licenses tied to cores, sockets, and vCPU conversion factors, so moving a workload to a cloud with a favorable core factor or shutting down idle capacity genuinely changes entitlement consumption.
That is the mechanism our guide to what Oracle BYOL really costs unpacks. Java after January 23, 2023 has no such mechanism. Oracle retired the per-Processor and Named User Plus Java SE Subscription and the Java SE Desktop Subscription and replaced both with a single Employee-metric subscription.
The meter is headcount. Headcount does not respond to instance types, reserved capacity, spot fleets, Kubernetes bin-packing, or region selection.
Two practical consequences follow. First, legacy perpetual Java SE Advanced holdings are worth keeping, because they provide audit cover for in-scope historical installs and buy migration runway, but they earn zero credit against Universal Subscription pricing.
Do not let a reseller model them as an offset. Second, and this is where buyers destroy their own business case, any cloud cost model that assumes rightsizing or consolidation will reduce Java spend is wrong by construction, not wrong by degree.
Migration savings on compute are real; the Java line is flat until it is zero.
The negotiation implication is blunt: never allow Oracle to frame a cloud migration as a Java savings event. Sales teams will offer a "cloud-aligned" multi-year Universal Subscription timed to your migration wave, pitched as portability insurance.
Portability is already universal under Oracle's own FAQ, which states permitted use covers desktop, servers, and third party clouds, and that deployment model does not affect pricing. You are paying a premium for a right you already have.
The counter-position is to treat the migration as an image-pipeline replacement project and price the subscription as the cost of failing to complete it.
Cut Oracle Cloud@Customer cost the 2026 BYOL map
The buyer side map for Oracle Cloud@Customer: Exadata and Compute Cloud@Customer, Dedicated Region, and the BYOL economics that lower cost.
Get the white paper →The October 2026 cliff is what makes this a 2026 decision, not a 2028 one
Oracle JDK 21 has been free in production since September 2023 under the No-Fee Terms and Conditions, and that is exactly why it is now sitting in thousands of AMIs, container base images, and Dockerfiles with nobody tracking it.
Oracle's Java blog has already published the end date: JDK 21 updates through and including September 2026 remain available under the NFTC, and beginning with the October 2026 Critical Patch Update, further Oracle JDK 21 updates move to the Java SE OTN license.
The same restrictive license that governs Java 8, 11, and 17.
GraalVM for JDK 21 follows the same path to the GraalVM OTN License on the same CPU date. Oracle is not subtle about where it expects you to land: the blog directs affected users to the Java SE Universal Subscription, under which Java 21 commercial support runs to at least September 2031.
That is the whole play. Free runtime, three-year adoption window, then a license change that converts adoption into revenue.
We have seen this film. Oracle JDK 17's NFTC expired in September 2024, build 17.0.12 (July 2024) was the last free update, and every JDK 17 build since requires a subscription for production use. The organizations that got hurt were not the ones that made a deliberate decision to stay on Oracle.
They were the ones whose pipelines kept working. In cloud estates the conversion mechanism is entirely mechanical: an unpinned base image, a Packer template pulling latest, a yum or apt repo pointed at Oracle's channel, or a managed build agent refreshing its toolchain.
On the first CPU after the cliff, the automation pulls a binary governed by a license nobody read, on infrastructure nobody mapped, and the estate is buying subscriptions one automated update at a time. Every one of those pulls is timestamped, logged, and discoverable by Oracle LMS.
The instinct to defer by jumping to JDK 25 is understandable and mostly wrong as a licensing strategy. JDK 25 binaries are free in production and free to redistribute under the NFTC, with updates until September 2028 and the NFTC window framed as ending October 2028.
That buys two years, not permanence, and it buys them at the cost of a full runtime upgrade across the estate. If you are going to touch every image anyway, touch it once and land on a distribution with no cliff at all. Corretto 21 is supported to October 2030 and Corretto 25 to October 2032.
Our recommendation, based on how the 17 cliff played out with clients, is to treat October 2026 as a hard freeze date for Oracle binaries in any automated pipeline.
And to read what an Oracle JDK sitting in a Docker base image actually obligates you to before assuming the container layer is out of scope.
The dangerous thing about the NFTC cliff is that nothing breaks on the day it lands. No build fails, no alert fires, no procurement approval is triggered. The only observable change is a line in a license file that your CI system does not parse. That is the design.
Oracle does not need you to sign anything in October 2026; it needs you to keep patching, and then it needs an audit in 2028 that reconstructs your patch history and prices three years of accrued use against your total headcount, not against your 47 installs.
Practically: inventory every place an Oracle JDK 21 or GraalVM for JDK 21 binary can enter the estate, pin what you cannot remove before the October 2026 CPU, and set the removal deadline internally at September 2026 so the cliff arrives after you have already left.
The analysis: cloud migration is the cheapest exit ramp Oracle Java will ever give you, and most buyers waste it
A cloud migration is the only event in an enterprise's life when every runtime artifact gets rebuilt from scratch on a funded schedule with executive air cover.
Base images are re-authored, package manifests are re-declared, deployment pipelines are rewritten, and application teams are already regression-testing everything they own.
Against that backdrop, the marginal cost of typing Corretto or Microsoft Build of OpenJDK instead of Oracle JDK in the base image definition is close to zero.
The same test cycle that proves the app runs on EC2 proves it runs on a different JVM build compiled from the same OpenJDK source and passing the same TCK.
Do it eighteen months later as a standalone remediation project and you are asking for budget, change windows, regression testing, and application owner cooperation for a project whose only deliverable is the absence of an invoice nobody has received yet.
That project loses every prioritization meeting it enters.
Bring-your-own-license wins by default because it is the path of least resistance for a migration team measured on cutover dates and rollback rates. Nobody chooses BYOL.
The lift-and-shift tooling copies the existing runtime, the Terraform module inherits the golden image, and the JDK comes along as sediment.
The licensing team is almost never in the room when the base image is chosen, and by the time they see it the image is the foundation of two hundred deployments.
We have watched this sequence in enough engagements to say plainly: the base image decision is made by an engineer optimizing for the fewest variables changed, and it costs the company more than any single procurement negotiation that year.
Oracle understands this asymmetry better than most buyers do, which is precisely why the Employee metric was engineered to be deployment-agnostic. Oracle's own FAQ says permitted use is universal across desktop, servers, and third party clouds, and that deployment model does not affect pricing.
Read that as a defensive move. Under the old Processor and Named User Plus metrics, cloud was a lever: you could re-architect, consolidate, right-size cores, and argue about vCPU-to-processor conversion ratios. The employee metric removes every one of those levers in a single stroke.
There is no cloud discount, no virtualization argument, no core factor table to litigate. A 4,000-employee company at the published $10.50 band pays $504,000 a year whether it runs 47 installs or 4,700. The metric forces a binary choice: full price or full removal. There is no middle.
That has a direct governance consequence most organizations have not absorbed.
If the meter is headcount and the trigger is a single licensable install, then the base image decision is a licensing decision worth six or seven figures annually, and it must be owned by someone accountable for that number.
In practice this means the cloud platform team's image catalog needs a named license owner, a pre-approved runtime list, and a merge gate that rejects any Dockerfile or Packer template pulling from Oracle's distribution channel.
Treat it the same way you treat a control that prevents public S3 buckets. It is not a technical preference, it is a financial control, and the guidance in swapping Oracle JDK for OpenJDK across the image pipeline should be implemented as policy rather than as a suggestion.
This is also why partial migration is the worst possible outcome, and it is the most common one.
A program that moves 85 percent of Java workloads to Corretto has absorbed 100 percent of the engineering cost, 100 percent of the testing burden, and 100 percent of the change risk, and has saved exactly nothing. The subscription obligation is triggered by the remaining 15 percent.
Worse, the organization now believes it has solved the problem, funding disappears, the residual estate calcifies around whatever made it hard to move, and the licensing exposure survives with no owner and no budget line. Every dollar spent on that program was spent to arrive at the same invoice.
So the target has to be stated correctly from the beginning.
Not "reduce Oracle Java by 90 percent," not "migrate the strategic applications," but a dated zero-install state with evidence: an inventory that names every host, image, and repository, a scan that returns null for Oracle binaries, and an artifact you could hand to an LMS auditor.
Note that whole-estate standardization is not required. Individual applications may run different OpenJDK distributions, so the hard cases can go to Adoptium, Corretto, or a commercially supported alternative without blocking the program. The only thing that must be uniform is the absence of Oracle.
Set that date before the October 2026 CPU, name the owner, and fund the last 15 percent first, because it is the only part of the work that actually changes the bill.
The OCI asymmetry: a fourth option that only pays off at 100 percent
Oracle's fourth option is real and it is genuinely free: run your Java on OCI compute and Oracle states that license and support are included at no additional cost, bundling Oracle GraalVM, Java Management Service, the Enterprise Performance Pack.
And Oracle Support with the compute you already pay for.
On paper that beats every other route, because you keep Oracle's binaries, Oracle's patch cadence, and Oracle's support desk without a per-employee line item.
In our experience negotiating this vendor, that offer is also the most effective retention instrument Oracle has built since the 2023 metric change, and it is priced to feel like a gift rather than a dependency.
The trap is boundary, not quality. The entitlement is scoped to Oracle JDK use on OCI compute. It does not travel.
One licensable Oracle JDK install outside that boundary, a developer laptop, a legacy on-premises app server, an EC2 AMI that nobody re-baked, and you are back in the per-employee subscription, priced against total headcount at $15.00 down to $5.25 per employee per month depending on band.
The OCI carve-out therefore does not reduce your exposure incrementally. It reduces it to zero only at 100 percent coverage, and to nothing at 99 percent. That is a binary business case, and binary business cases in a mixed estate almost always fail on the last five percent.
Compare that to the provider OpenJDK route. AWS Corretto, Microsoft Build of OpenJDK, and Adoptium builds cost $0, are cloud-neutral, and survive a change of hyperscaler.
Corretto 21 is supported to October 31, 2030 and Corretto 25 to October 31, 2032, with Corretto 8 extended to December 2030 and Corretto 11 to January 2032. Nothing in that path requires you to keep a workload on a specific vendor's compute to preserve a Java benefit.
Read the OCI option alongside our broader analysis of Oracle Java licensing across cloud and containers before you let an architecture decision be driven by a Java line item.
The OCI carve-out is the only free Oracle JDK path left, and it is the only one that creates a second lock-in to remove the first.
If you take it, you accept that your Java compliance position is now hostage to a hosting decision: repatriate a workload, acquire a company with on-premises Java, or let one contractor install Oracle JDK 21 after the October 2026 cliff.
And the full per-employee subscription reattaches across every employee you have.
Price both options as an all-in number.
OCI-free Java is worth something only if the migration cost of moving 100 percent of licensable Oracle JDK use into OCI is lower than the migration cost of moving 100 percent of it to Corretto or Microsoft OpenJDK, which requires no relocation of workloads at all.
In most mid-market estates we review, the OpenJDK route wins on effort before you even reach the lock-in argument.
What the evidence shows: recurring patterns from cloud Java engagements
A 4,000-employee company at the published $10.50 band pays $504,000 annually on the strength of 47 Oracle Java installs.
Oracle JDK 21 updates from the October 2026 Critical Patch Update move to the OTN license, so automated patching converts free estates into subscribed ones.
Four patterns repeat across cloud Java engagements. First, exposure is triggered by a handful of installs and then billed against total headcount, which is why footprint reduction efforts that stop at 95 percent deliver zero savings.
Second, automated patch pipelines are the conversion mechanism: unpinned AMIs, base images, and yum or apt repositories will pull post-cliff Oracle binaries without a human decision, and the estate buys subscriptions one update at a time.
Third, packaging changes surface late and get mistaken for licensing problems.
From the July 2026 Corretto release, default Docker images moved to Amazon Linux 2023 and JavaFX binaries are no longer bundled with Corretto 8, which breaks builds mid-migration and hands the internal Oracle advocate an argument to stall.
Fourth, the Azure-side constraints are narrow but real: Microsoft does not commercially support non-LTS OpenJDK releases and reserves the right to skip quarterly updates for them, and Java 25 is not selectable as a native Azure App Service Windows runtime without a custom Windows container.
The most useful fact for scoping is the one buyers most often get wrong. Individual applications may run different JDK distributions. Whole-estate standardization on a single vendor's OpenJDK build is not a licensing requirement. The requirement is narrower and harder: zero licensable Oracle JDK.
Pin to LTS, inventory the image pipeline rather than the servers, and treat the remediation as an image pipeline replacement exercise rather than an application rewrite programme.
The $504,000 against 47 installs case is not an outlier, it is the design of the metric working as intended.
Every hour spent debating which cloud is cheaper for Oracle Java is an hour not spent on the only variable that moves the invoice: whether any licensable Oracle JDK remains anywhere in the organization on the day Oracle asks.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Inventory every Oracle JDK binary before the October 2026 CPU, scanning AMIs, container layers, Lambda layers, golden images, and yum/apt repo mirrors rather than trusting a CMDB, because the 47-install estate that triggers a $504,000 bill at the 3,000 to 9,999 band is exactly the kind of footprint asset management misses.
- Pin base images and package repositories now, so the automatic conversion mechanism is dead before the cliff arrives: unpinned pipelines pull the first post-October-2026 JDK 21 update under OTN terms and, as our engagement experience consistently shows, an estate then buys a subscription one automated patch at a time (see Oracle Java in Docker base images).
- Set a zero-install target date, not a reduction target, because BellSoft's reading of the license is unambiguous: one remaining unlicensed Oracle JDK application requires the full employee-metric subscription, so a 90 percent removal saves exactly nothing and only a dated, verified zero earns the $0 outcome.
- Pick per-application OpenJDK distributions aligned to LTS with documented end dates, since whole-estate standardization is not required: Corretto 21 runs to October 2030, Corretto 11 to January 2032, Corretto 8 to December 2030, and Microsoft Build of OpenJDK covers Java 8, 11, 17, 21, and 25 on Azure, while non-LTS builds get no commercial support and should never appear in production (image pipeline swap sequence).
- Refuse any Oracle proposal that prices cloud deployment differently from on-premises, because Oracle's own FAQ says permitted use is universal across desktop, servers, and third party clouds and deployment model does not affect pricing: a cloud-specific SKU, uplift, or "IaaS true-up" is a negotiating construct, not a contractual one.
The sequencing matters more than the tooling. Buyers who pin repos first and inventory second consistently land at a verified zero, because pinning freezes the denominator while you work. Buyers who inventory first spend eight weeks counting a footprint that keeps growing underneath them.
Every move above is designed to be defensible on a date, not on an intention. Oracle audits the estate, not the roadmap, and a documented pinning change plus a dated removal certificate is the artifact that ends the conversation.
Frequently asked questions
Does moving Oracle Java to AWS or Azure reduce my Oracle Java subscription cost?
No. The Java SE Universal Subscription is priced on total employee headcount, and Oracle's own FAQ states permitted use is universal across desktop, servers, and third party clouds with deployment model not affecting pricing.
A 28,000-employee company pays $2,268,000 a year at $6.75 per employee per month whether the workload runs on-premises or on EC2. The only way to reduce the bill is to eliminate every licensable Oracle JDK install.
Is BYOL even a real concept for Oracle Java in the cloud?
Not in any meaningful commercial sense. BYOL creates value where a license is consumed by infrastructure units that a cloud move changes, which was true under the old per-Processor and Named User Plus metrics retired in January 2023.
Under the employee metric the meter is headcount, so there is nothing to carry and nothing to save. Treat any vendor or partner slide showing Java BYOL savings in IaaS as a red flag.
What happens to Oracle JDK 21 in October 2026?
Updates through and including September 2026 remain available under the No-Fee Terms and Conditions.
Beginning with the October 2026 Critical Patch Update, further Oracle JDK 21 updates move to the Java SE OTN license, the same license used for Java 8, 11, and 17, meaning production use requires a subscription. GraalVM for JDK 21 updates move to the GraalVM OTN License on the same schedule.
Can automated patching in my cloud pipeline create a licensing liability?
Yes, and this is the most common cause of accidental exposure. Unpinned AMIs, container base images, and yum or apt repositories will pull post-cliff Oracle binaries without any human decision, which effectively buys a subscription one automated update at a time.
Pin your image and repository sources before October 2026 and audit every layer in the build chain, not just the top-level Dockerfile.
Is AWS Corretto or Microsoft Build of OpenJDK good enough to replace Oracle JDK in production?
For the large majority of workloads, yes. Both are no-cost, production-ready OpenJDK distributions with quarterly security updates aligned to the January, April, July, and October cycle.
Corretto support horizons often exceed Oracle's free window: Corretto 21 runs to October 2030, Corretto 25 to October 2032, Corretto 8 to December 2030, and Corretto 11 to January 2032. Pin to LTS releases, since Microsoft does not provide commercial support for non-LTS builds.
Do I have to standardize the whole estate on one JDK distribution?
No. Individual applications may use different JDK distributions, so you can run Corretto in AWS, Microsoft Build of OpenJDK in Azure, and Adoptium elsewhere.
What matters for licensing is that zero applications remain on a licensable Oracle JDK build, because a single one triggers a subscription counted across your total employee headcount.
Does running Java on Oracle Cloud Infrastructure remove the subscription requirement?
Only for the workloads actually running on OCI compute, where Oracle includes Java SE license and support at no additional charge along with Oracle GraalVM, Java Management Service, and the Enterprise Performance Pack.
That entitlement is bounded: a single Oracle JDK install outside OCI triggers the per-employee subscription across your whole headcount. The OCI business case only closes if you eliminate all licensable off-OCI use, which is a harder bar than most buyers assume.
