OCI vs AWS for Oracle licensing. Two conversion rules, one workload.

The same database server needs twice as many Oracle licenses on AWS as on OCI. The hardware does not change; Oracle applies one conversion rule to authorized clouds and a different one to its own.

Which clouds does Oracle's Authorized Cloud Environment policy cover?

Three providers: Amazon Web Services (both EC2 and RDS), Microsoft Azure and Google Cloud. Oracle Cloud Infrastructure is not on the list, and that exclusion is the fact most OCI versus AWS comparisons get wrong.

Oracle sets out the counting rules in its cloud licensing policy and names the qualifying providers in the authorized cloud environments list. OCI is governed instead by the service descriptions attached to your cloud order. The two documents were written for different purposes, and they produce different license counts for the same hardware.

Which three policy rules change the license count?

• The vCPU conversion. With hyperthreading enabled, two vCPUs count as one Processor license. Without it, one vCPU counts as one.
• No core factor. The policy states that the processor core factor table does not apply in an authorized cloud environment, so every core counts in full.
• An edition ceiling. Standard Edition 2 may only be licensed on instances up to 8 vCPUs, so the edition cannot follow a growing workload up the instance families. Each 4 vCPUs, rounded up, count as one socket.

None of these rules apply on Oracle's own cloud. The difference is deliberate. Oracle prices its own platform so that the licenses you already own cover twice as much cloud hardware there as on AWS, Azure or Google Cloud. See our core factor guide for how the 0.5 multiplier works on premises.

Do Named User Plus minimums still apply in the cloud?

Yes. User based licensing keeps its minimums, and the policy restates some of them in cloud terms instead of importing the on premises figure unchanged. For Standard Edition 2 the minimum is 10 Named User Plus licenses per 8 vCPUs on Amazon, Azure or Google Cloud.

For Enterprise Edition, the policy says standard Named User Plus rules apply, including minimums where applicable, counted against the Processor figure the vCPU rule produces. Read the current policy text for your edition before you reuse the number from your data center.

Where does the OCI ratio come from?

From Oracle's cloud service descriptions, not from the partitioning policy and not from the authorized cloud policy. The mapping to know is one Processor license per two OCPUs, and on x86 shapes an OCPU is one physical core presenting two vCPUs. Confirm the ratio for the exact service in your order.

Oracle publishes the conversion per service, and it differs between compute, the database services and the Exadata services. Autonomous Database, for example, allows up to 8 ECPUs per Enterprise Edition Processor license and up to 16 ECPUs per Standard Edition Processor license. Our OCI licensing guide covers the OCPU and ECPU rules service by service.

How many Oracle licenses does the same server need on OCI and on AWS?

Twice as many on AWS as on OCI, for identical physical hardware. This is the arithmetic that decides most platform comparisons, and business cases get it wrong in the same direction almost every time.

A worked example with 16 physical cores

• The requirement. A production Oracle Database Enterprise Edition workload that needs 16 physical x86 cores.
• In your data center. 16 cores at the 0.5 core factor is 8 Processor licenses.
• On AWS. Those 16 cores present 32 vCPUs. Divided by two, that is 16 Processor licenses, with no core factor to reduce it.
• On OCI. Those 16 cores are 16 OCPUs. At one Processor license per two OCPUs, that is 8 Processor licenses.
• The gap. 8 Processor licenses, which is $380,000 at the published Enterprise Edition list price of $47,500 per processor, plus 22 percent of that every year in support.

What does that gap cost over five years?

Say you already own the 8 Enterprise Edition Processor licenses that cover this server in your data center, with support active. The table below shows what each destination adds, at list price, before any discount.

The last row is the one teams forget. The support you pay on owned licenses does not change with the destination, so it belongs in every column. If the AWS option cannot absorb $798,000 in extra Oracle spend through lower infrastructure rates, the comparison is already decided.

Why turning hyperthreading off does not help

The policy changes the ratio when you change the threads. Disable simultaneous multithreading on a 16 core instance and you present 16 vCPUs instead of 32, but the conversion becomes one vCPU per Processor license, so you still need 16.

The number that matters is physical cores, whatever the thread setting. Reducing the number of active cores through the EC2 CPU options setting is a different matter, because it lowers the core count itself. Oracle's policy does not mention that setting, so keep launch records and configuration evidence if you rely on it.

Which instance types push the count up?

• Instance types without simultaneous multithreading. One vCPU is one core, so a 16 vCPU instance needs 16 Processor licenses rather than 8. The AMD based M7a, C7a and R7a families on AWS work this way, so a like for like vCPU swap from an older family doubles the count.
• Burstable and shared tenancy families. They work technically, but the capacity is hard to evidence and rarely suits a licensed database.
• Autoscaling groups. The license count follows the maximum the group can reach, not the average it usually runs at.
• Non production copies. Development and test instances are licensable unless a specific term says otherwise, and they are where cloud sprawl shows up first.

How do you check what you are running today?

Count cores and threads from the platform itself, because a sizing spreadsheet will not satisfy an auditor. Each source below is built into the cloud platform, the guest operating system or the database.

1. Amazon EC2. The describe instances call in the AWS CLI returns CpuOptions with CoreCount and ThreadsPerCore for each instance.
2. Inside the guest. Running lscpu on Linux shows threads per core, cores per socket and sockets, which confirms what the hypervisor presents.
3. OCI. The shape and OCPU count appear on each instance and database system in the console, and in the compute and database APIs.
4. The database itself. DBA_FEATURE_USAGE_STATISTICS and V$OPTION show which options and packs are installed and used, which sets the option license count on either cloud.

What have we seen in recent Oracle cloud platform comparisons?

Between 2024 and 2025 we built roughly 25 to 35 Oracle platform comparisons for clients choosing between OCI and one of the authorized clouds. In most of them the decision was first made on infrastructure rates, then reopened when someone counted the licenses.

The error almost always runs in one direction. Teams size the AWS database tier with the on premises licenses they already hold, and the doubling only surfaces when procurement or an auditor recounts in vCPUs.

Why we disagree with choosing the cloud on infrastructure rates first

The usual advice is to pick the cloud with the better infrastructure rate and treat licensing as a detail to settle later. We disagree, because in most of the models above the license line was the largest one, and Oracle's policy fixes it before a single rate is negotiated.

A discount on compute cannot recover a doubled license count. Count the licenses under each platform's rule first, then negotiate rates against that number.

The rate card is negotiable. The conversion ratio is not, which makes the license count the only number in the model neither vendor will change for you.

What does OCI give you that AWS, Azure and Google Cloud do not?

Three things: a conversion that keeps your on premises arithmetic intact, a managed database tier you can run owned licenses against, and access to Real Application Clusters.

Bring your own license into a managed service

On OCI you can apply owned perpetual licenses to the managed database services and pay the lower infrastructure rate, as described on Oracle's bring your own license page. The nearest equivalent on AWS is a self managed database on EC2, or Amazon RDS under its own rules.

Whether bring your own license is cheaper for you than license included is a separate calculation. We work it through in the bring your own license versus license included comparison, and our Oracle on Azure and AWS BYOL white paper shows how to count the Oracle cloud license before you commit.

What do you give up by moving to OCI?

• Commercial concentration. Database, infrastructure and support all sit with one vendor at the same renewal, which weakens your negotiating position at each one.
• Consumption commitments. Oracle's credit model is prepaid and unused credit is generally forfeited, so the commitment size becomes its own negotiation. Our guide to Oracle cloud contracts and credits covers the terms.
• Application tier economics. The license advantage applies to Oracle software. It does not follow your application servers, object storage or data pipeline.
• Regional coverage. Check the region list for the specific service you plan to use. The region list for the cloud as a whole can be longer.
• Support repricing risk. Oracle's support policies allow it to reprice support on the licenses you keep when you drop support on part of a license set. That makes retiring licenses after a move more expensive than the license count suggests.

Can you run Oracle RAC on AWS, or only on OCI?

Oracle supports RAC only on its own infrastructure: OCI, Exadata Cloud@Customer, your own data center, and Oracle operated services inside the hyperscalers. Oracle states that it does not support Real Application Clusters on non Oracle public clouds, and no license budget changes that, so an architecture that depends on RAC narrows the platform list before any cost model opens.

Moving to OCI for clustering does not make RAC free. Under bring your own license you still need licenses for every option you switch on, so a clustered database needs Real Application Clusters licenses, at $23,000 per processor list, on top of Enterprise Edition.

Data Guard is the usual answer when the requirement is availability rather than clustering. If the standby is open read only for reporting while it keeps applying redo, it needs Active Data Guard licenses on both sides, at $11,500 per processor list.

The Amazon RDS edition limit

Amazon RDS for Oracle offers a license included model, and it covers Standard Edition 2 only. Enterprise Edition on Amazon RDS for Oracle requires you to bring your own licenses. That removes the plan most teams assume exists: retiring owned Enterprise Edition licenses by moving to a managed service.

That single line has redirected several migration plans we have reviewed. Check it before the business case is signed. Our Oracle on AWS licensing guide covers RDS license models, replicas and Multi AZ standby counting.

How Oracle Database@Azure, Google Cloud and AWS change the comparison

Oracle now runs its own database hardware inside the other clouds. Oracle Database at Azure came first, with Google Cloud and AWS equivalents following, and all of them place Oracle managed Exadata in a hyperscaler region.

• The counting rules follow the service. These are Oracle services, so the service description governs, and the authorized cloud vCPU conversion does not apply.
• Clustering comes back. Because the hardware is Exadata, the capability gap largely closes for the workloads that fit.
• The contract is with Oracle. That affects who audits you and where the commercial weight sits, even when you buy through the hyperscaler marketplace.
• Region coverage is uneven. Availability is expanding, so confirm the current list for your regions before relying on an older slide.

We cover the commercial shape of these arrangements in the Oracle multicloud licensing guide.

Is OCI or AWS cheaper for Oracle workloads?

OCI is usually cheaper for the Oracle database tier, and AWS is usually cheaper for everything around it. A comparison that produces a single winner for a mixed environment has probably answered the wrong question.

How does company size change the answer?

A small Standard Edition 2 shop often does well on AWS, because Amazon RDS offers SE2 license included. Under bring your own license, a 4 core database presents 8 vCPUs, sits at the ceiling and counts as 2 sockets, or $35,000 at the $17,500 list price. Growth past 8 vCPUs on an authorized cloud means Enterprise Edition.

A large Enterprise Edition buyer with 100 or more processors of owned licenses sees the conversion gap multiply across every server. At that size the OCI license saving usually outweighs the infrastructure rate difference, and the negotiation shifts to credit commitment size and exit terms. Our Standard Edition 2 guide covers the edition limits in detail.

The three lines most models leave out

• Support on the owned licenses. If you keep perpetual licenses alive to use them in a cloud, the annual support line follows them there.
• The migration itself. Data movement, testing and parallel running is routinely the third largest line in a five year model and the first one omitted.
• The commitment you sign to get the rate. Both vendors price against a spend commitment, and an unmet commitment becomes a cost in its own right.

How to keep both vendors honest

Run the comparison in license units first and currency second. Once the license count is settled you are negotiating rates against a fixed denominator, which is the only way competing quotes become comparable.

Which contract terms should you ask for before you choose?

Ask for terms that fix the counting rule and limit the commitment risk on both sides. Oracle's cloud policy describes itself as educational guidance that cannot be incorporated into a contract and can change without notice.

The current version carries a September 4, 2026 date. Oracle still audits against it, so treat it as the rule you will be measured by and write any counting rule you depend on into the order.

• The BYOL ratio by service. Name each OCI service and its Processor to OCPU or ECPU ratio in the ordering document, so a later service description change cannot alter your count mid term.
• Credit rollover or ramp. Ask for unused Universal Credits to roll into the next period, or for a ramped commitment that matches your migration schedule.
• Support price protection. Ask Oracle to confirm in writing that retiring licenses you no longer need will not reprice the support on the ones you keep.
• A shortfall remedy on AWS. If you sign an AWS spend commitment, negotiate what happens when you miss it, and whether Oracle purchases through AWS Marketplace count toward it.
• Audit scope for multicloud services. For Oracle Database@Azure, Google Cloud or AWS, confirm which party audits which layer, and which price list governs any true up.

Which seven questions decide the platform?

Answer these in order. Most companies find that the first three settle the question before anyone opens a pricing tool.

1. Do you own perpetual Enterprise Edition licenses with support active? If yes, the conversion difference is real money and OCI starts ahead.
2. Does the architecture need clustering? If yes, the authorized clouds are out for that workload.
3. Is the database staying on Oracle for five years? If not, optimize for exit speed over license efficiency.
4. What is the edition? Standard Edition 2 runs into the 8 vCPU ceiling on authorized clouds and needs a growth plan.
5. Where does the rest of your infrastructure already run? Data gravity and an existing spend commitment carry costs that belong in the model.
6. What does a missed commitment cost? Price the shortfall on each side before you compare discounts.
7. Who audits you afterwards? Concentrating database, infrastructure and support with one vendor changes your position at every future renewal.

What to do next

1. Inventory. Pull the perpetual license inventory, confirm which lines have active support, and note the options and packs attached to each.
2. Count twice. Convert the target workload to physical cores, then apply each platform's rule separately and write both license counts down.
3. Check editions. Test every workload against the 8 vCPU ceiling and the managed service edition limits.
4. Separate clustering from availability. Confirm which workloads need RAC, and which need availability that Data Guard can deliver.
5. Price the hidden lines. Put migration and parallel running into the model, then add the support line on any license you are keeping alive for cloud use.
6. Stress the commitments. Model the downside of both spend commitments next to the discounted rate each vendor quotes.
7. Read and decide. Read the Oracle cloud licensing policy guide and the Oracle on AWS licensing guide, then take independent advice before signing either contract.

Frequently asked questions