BYOL to the Cloud Done Right for Oracle Licensing

What does BYOL to the cloud mean for Oracle?

BYOL to the cloud means you apply Oracle licenses you already own to an authorized cloud environment such as AWS or Azure rather than buying cloud subscriptions from Oracle. The phrase stands for bring your own license, and the appeal is obvious: you have paid for Processor or Named User Plus entitlements, so you want to run them wherever the workload now lives. The catch is that the counting method changes the moment the database moves off your own hardware, and teams that assume their on premises math carries over tend to under license without realising it.

The complete framework for how Oracle treats virtual and cloud deployments sits in the Oracle virtualization licensing guide. BYOL is one path through that framework, and it is defensible when you size it from the right rule and keep the evidence to prove it.

How do you count vCPUs when you BYOL?

You count vCPUs under Oracle's authorized cloud policy, where 2 vCPUs equal 1 Processor license when hyperthreading is enabled and 1 vCPU equals 1 Processor license when it is not. This replaces the on premises method, where the core factor table converts physical cores into a licensable figure using a multiplier such as 0.5 for x86. In authorized cloud the table drops out, so the familiar halving you rely on for your own servers is not what produces the cloud number.

The practical effect is that instance selection becomes a licensing decision. A shape with hyperthreading enabled lets two vCPUs collapse to one license, while a shape without it counts each vCPU one for one and doubles the requirement for the same capacity. The detail is worked through fully in counting vCPUs on AWS and Azure, and it is the single most common place BYOL math goes wrong.

What records does a clean BYOL deployment keep?

A clean BYOL deployment keeps a dated record of every instance shape, its vCPU count, its hyperthreading state, and the licenses assigned to it, so the count can be reconstructed at any moment. Oracle does not see your cloud console, which means the burden of proof sits with you when a review arrives. A spreadsheet that ties each running database to a specific entitlement, refreshed when instances change, is the difference between a finding you can dismiss in an afternoon and one that drags on for weeks.

Keep the cloud provider specification sheets that confirm hyperthreading behaviour, the deployment dates, and any decommission dates, because Oracle counts what was deployed during the period under review, not only what runs today. This evidence discipline mirrors the approach in the cloud evidence file for audits, which sets out the full record set worth maintaining.

A worked BYOL example

Suppose you own 8 Processor licenses and move the workload to an AWS instance with 16 vCPUs and hyperthreading enabled. Under the authorized cloud policy, 16 vCPUs divided by 2 gives 8 Processor licenses, so your owned entitlement covers it exactly. Move the same workload to a shape with hyperthreading disabled and the 16 vCPUs count one for one as 16 Processor licenses, leaving you 8 licenses short for identical capacity.

Does the cloud policy override your contract?

The cloud policy does not override your contract, because it is a policy document Oracle can revise rather than a negotiated term in your signed agreement, and where the two differ the contract language governs. The same principle defends customers against cluster wide virtualization claims: the policy paper is often weaker than the agreement, and contract language beats policy. Before you accept any BYOL finding, read the authorized cloud policy alongside your Oracle Master Agreement and confirm which one actually binds your deployment. The mechanics of that policy are unpacked in the authorized cloud environment policy.

Your next step

BYOL done right protects your budget and removes an easy audit finding before it can form. An independent buyer side review recounts your cloud estate from the policy, checks it against your agreement, and sizes the deployment to the lowest defensible number. Read the pillar guide for the full virtualization and cloud framework.