Why One Oracle Processor License Buys Differently on AWS

Oracle put Exadata Database Service on Exascale Infrastructure onto Oracle AI Database@AWS this month. Database@AWS itself went generally available in July 2025. That launch is last year’s file. The metric is this year’s file. For BYOL on Database@AWS, Oracle’s PaaS and IaaS Universal Credits Service Descriptions set the conversion from an on-prem processor license to cloud ECPUs. On RDS or EC2, Oracle’s Authorized Cloud Environments policy still counts two vCPUs as one processor license when multithreading is on. Those are different documents, different units, and different placements.

That’s the problem.

The question in the room is not “do you want Exadata on AWS.” It is what one processor license buys on Database@AWS versus on RDS or EC2, what compute and storage cost on the other side of that ratio, and whether you have your own count before the salesperson walks in with theirs.

Oracle put Exadata on AWS. The metric is what changed.

The AWS Database Blog announced general availability of Oracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS) for Oracle AI Database@AWS. That adds the engineered Exadata stack (RAC, Smart Scan, Hybrid Columnar Compression) to a service that went live for lower-level databases in July 2025.

You start a VM cluster at 8 ECPUs and 300 GB of storage. Compute and storage scale independently. There is no dedicated rack to stand up. License Included (Enterprise Edition with all options) and BYOL are both supported, through a public or private AWS Marketplace offer. Pricing, AWS says, matches Exadata Database Service on Exascale Infrastructure on OCI.

The service can connect to EC2, AWS Analytics, and AWS AI and machine learning. Oracle’s FAQ is equally clear on the commercial edges: usage qualifies toward existing AWS commitments; it does not burn down an OCI Universal Credits commitment; BYOL is available for eligible supported licences, including ULAs; licences on third-party support are not eligible for BYOL.

Do not let that reframe the meeting as “are you modernizing Oracle on AWS.” The meeting is about how the same processor licenses get counted in two AWS placements, and what you pay for infrastructure once the count looks cheaper.

Oracle Database@AWS license metrics are not the RDS ratio

Licensing Oracle Software in the Cloud Computing Environment is the policy that covers Amazon EC2 and RDS. Count two vCPUs as one Oracle processor license if multithreading is enabled, and one vCPU as one processor license if it is not. The Core Factor Table does not apply. That document is a policy, not a contract, and Oracle can change it.

Database@AWS is not that policy. It is an Oracle-managed service running OCI hardware inside AWS data centers. BYOL conversion for that service is in the Oracle PaaS and IaaS Universal Credits Service Descriptions (the same family of documents Oracle points to for Exadata Exascale on Azure and on OCI). Oracle’s public BYOL-to-PaaS FAQ still uses the high-level map of one processor license to two OCPUs for older shapes; Exascale is billed in ECPUs. Get the conversion that applies to the SKU in front of you, in writing, from that service description. Do not import the RDS 2-vCPU rule onto an ECPU quote, and do not treat 8 ECPUs as 8 vCPUs of work.

That is a licensing comparison, not a claim that the units are interchangeable. The ratio is what changes how far a processor license stretches. Treat them as the same compute and you are already doing the salesperson’s arithmetic.

Then the other side of the invoice. Database@AWS can look cheaper in processors required than RDS. Compute and storage are a different bill. ExaDB-XS starts at 8 ECPUs. License-included and BYOL are different rates. Price both paths against this estate.

This is not a criticism of the teams who hear a friendlier ratio and start a placement slide. Traditional SAM tools prove what is deployed. They do not recast the same processor pool as an ECPU position, a 2-vCPU position, and an infrastructure premium before Friday.

If that feels familiar, the problem is not your team’s maturity. A metric conversation is being answered with a “we have Oracle licenses” slide.

A vendor sentence is not a license position

Oracle has long said that running Database on generic authorized-cloud compute can take more processor licenses than running it on Oracle’s own shapes. The Authorized Cloud Environments policy is how that sentence gets its arithmetic: no core factor, two vCPUs per license. Database@AWS is how the other sentence gets its arithmetic: a service-description conversion on ECPUs, plus infrastructure you buy through Marketplace.

Those are commercial objects. They are not your count.

Your job is not to pick a narrative. Your job is to recast the same licences under both metrics, plus the infrastructure delta, plus a written stay-or-move.

“Twice as many licenses” is a vendor sentence. It is not your count.

What to model before you move a processor

Picture the room. Your CIO forwards the Exadata-on-AWS note. Procurement hears license savings. FinOps hears that compute starts at 8 ECPUs and is billed as a different product from RDS. You can pull an Oracle processor total and an AWS bill. You cannot, by Friday, recast the same licenses under both metrics, plus the infrastructure delta, plus a written stay-or-move.

That is how a ratio becomes exposure.

Do this in the next thirty days, as a decision pack rather than a project. The event is the next placement conversation, not the announcement.

Can a non-specialist brief the CIO in fifteen minutes from the pack you have today? If the answer is no, you do not have a Database@AWS position. You have a library.

Put four numbers on one page: processor licenses you hold and where they sit; what that pool covers under the Database@AWS service description versus the 2-vCPU policy; whether those licences are still on Oracle support (the FAQ bars third-party support from BYOL); and compute plus storage on each path, including minimums you cannot shrink. Oracle and AWS do not publish a single list price that answers that page. Price both paths against this estate.

If part of the estate is still locked to a legacy Exadata agreement, say so.

The decision layer, not another Oracle inventory

You already have discovery data, an Oracle processor file, and an AWS bill. The gap is not another inventory. The gap is turning that estate into a decision: what the same licenses consume under the service-description conversion versus the 2-vCPU policy, whether the infrastructure premium eats the stretch, and what should happen next. LICENSEWARE sits on the inventory and ITSM tools you already run. It is not a rip-and-replace SAM suite. Oracle processor metrics are encoded expertise: a salesperson’s comparison turned into a position you can walk in with. Oracle Database Manager and Oracle Entitlement Manager recast the same processor pool as an ECPU position and a 2-vCPU position. Audit Defense is the ELP, not the AWS bill. We have seen this math before: a $3M Oracle exposure on the wrong placement, and NEO’s Oracle DB Optimization report is the pack that makes the ratio briefable.

If you are heading into a Database@AWS conversation and your current tools still need three weeks to turn “we have Oracle licenses” into an ECPU versus 2-vCPU number, book an Audit Readiness Review. You can also start on the free plan and run the analysis on your own data.

The question to walk in with

Do not let Oracle frame this as “generic cloud costs twice as many licenses.” Do not let the announcement frame it as modernization. The right question is: what does this estate consume under the Database@AWS service-description conversion versus one processor license per 2 vCPUs, and does the infrastructure premium erase that stretch against the contract you already have. That is a data question, not a sales question.

The vendor will walk in with a number. The only question is whether you have yours first: current, defensible, and tied to the contract in front of you.