Oracle's cloud licensing rules differ across providers — and understanding those differences before migrating is critical. This step-by-step guide covers BYOL policies, vCPU counting on OCI vs AWS vs Azure, options and packs licensing, common compliance pitfalls, and a strategic decision framework for choosing the right approach.
Oracle's cloud licensing rules for Oracle Database differ across providers. In Oracle's own cloud (OCI), the licensing is more customer-friendly with favourable CPU ratios. Running Oracle on AWS or Azure involves stricter virtual CPU (vCPU) conversions that can increase licence requirements significantly.
Read our ultimate Oracle Database Licensing Guide for foundational context on editions, options, and metrics.
Bring Your Own License (BYOL) allows you to transfer existing Oracle Database licences from on-premises to cloud environments. BYOL doesn't change the fundamental licensing metrics or rules — it simply relocates your licences. If you needed four processor licences on-prem, you'll still need four in the cloud (though how processors are counted will differ by provider).
| Component | Requirement | Impact on Cloud Use |
|---|---|---|
| Existing licences | Must be properly licensed & valid | Only legitimate licences can be BYOL — no expired or unlicensed usage |
| Support | Active support contract required | If support lapses, you lose BYOL eligibility and compliance footing |
| Licence metric | Same as on-prem (Processor or NUP) | Cloud doesn't change your metric — count processors or users as before |
| Options/Packs | Must be licensed in addition | Add-on features (RAC, Tuning Pack) require equivalent licences in cloud |
BYOL doesn't change how you count licences; it just moves them to a new environment. You remain responsible for ensuring sufficient licences for cloud CPUs and users — and for tracking and reporting usage just as diligently as on-premises.
Read about metrics: Named User Plus vs Processor Licensing (Oracle DB). Read about DR: Oracle Failover Licensing and Disaster Recovery Guide.
OCI offers the most favourable licensing rules for Oracle Database. Each OCPU equals one full Oracle-licensable core — a straightforward 1:1 ratio that is often cheaper than equivalent computing on AWS or Azure.
| Metric | OCI Conversion | Notes |
|---|---|---|
| Processor (CPU) | 1 OCPU = 1 Processor licence | Most favourable ratio — each core is one licence |
| Named User Plus | 1 OCPU = 2 NUP minimum | Lower minimums than on-prem (usually 25 NUP per processor) |
| Options/Packs | Same ratio as database | Options still need separate licences — no free ride on OCI |
OCI is deliberately optimised to reduce Oracle licensing costs, giving you more compute per licence than any other cloud. If cost is a major concern and you want to maximise existing Oracle licences, OCI is the go-to choice. Oracle also offers Support Rewards — up to 33% of OCI spend credited against on-prem support bills.
On AWS, Oracle's licensing rules become stricter and more costly. Oracle counts 2 AWS vCPUs as equivalent to 1 Oracle processor licence (assuming hyper-threading enabled). This means you may need twice as many licences for the same number of virtual cores compared to OCI.
| Metric | AWS Conversion | Impact |
|---|---|---|
| Enterprise Processor | 2 vCPUs = 1 Processor | Effectively doubles licence requirements per vCPU count |
| Standard Edition (SE2) | 4 vCPUs ≈ 1 SE2 licence | Max 8 vCPUs per instance for SE2; exceeding violates compliance |
| Named User Plus | NUP allowed (per user) | Viable for small user bases; hard to manage at scale |
There is no concept of a core factor in AWS. Oracle doesn't allow the on-prem core factor table to reduce licence counts in the cloud. Every core is a full-core licence. If your on-prem hardware required fewer licences due to core factors, moving to AWS can substantially increase your Oracle licensing needs.
Azure's rules are essentially identical to AWS. Oracle uses the same 2 vCPU = 1 licence formula. BYOL is the model — no "licence included" options exist for Oracle on Azure. The critical difference: Azure won't enforce Oracle's licensing constraints for you. It's entirely on the customer to ensure compliance.
| Metric | Azure Conversion | Notes |
|---|---|---|
| Processor (EE) | 2 vCPUs = 1 Licence | Same rule as AWS; no core factor applies |
| Standard Edition (SE2) | 4 vCPUs ≈ 1 licence increment | SE2 limited to max 8 vCPUs per VM |
| Named User Plus | Allowed (user-based) | Customer must track user counts; Azure doesn't enforce limits |
Azure won't stop you from deploying Oracle SE2 on a 16-vCPU VM, but doing so violates Oracle's licensing rules (SE2 max is 8 vCPUs in any cloud instance). No Azure Hybrid Benefit exists for Oracle — your on-prem Oracle licences are the only cost relief. Approach Oracle licensing on Azure with the same rigour as AWS.
Migrating Oracle Database to the cloud? Get an independent licensing assessment first.
Oracle Licence Management →Moving to the cloud doesn't simplify licensing for database options and management packs — they must still be licensed separately, just as on-prem. Many customers get caught off guard because it's easy to enable an option in RDS or spin up a database with features and forget it silently triggers a licence requirement.
| Feature / Option | Separate Licence? | Notes |
|---|---|---|
| Partitioning | Yes | Same metric as database; common in data warehousing — don't forget when on cloud |
| Oracle RAC | Yes | Only practical on OCI; not supported on AWS/Azure. All nodes fully licensed |
| Advanced Security | Yes | Includes TDE encryption, Data Redaction — unless cloud bundle explicitly includes |
| Diagnostics & Tuning Packs | Yes | Using OEM performance pages or AWR reports in cloud still triggers these licences |
| Active Data Guard | Yes | Readable standby requires ADG licences for standby cores; EE only |
| Database In-Memory | Yes | Per-processor licence required; often accidentally enabled |
Options and packs are the most common source of unexpected compliance claims in cloud deployments. Teams assume that if the database is running in the cloud, Oracle might not notice Diagnostics Pack or Partitioning usage. But audit scripts and Oracle management tools expose these instantly. Run a usage scan before and after migration to verify no additional features have been accidentally enabled.
In practice, many pitfalls lead to non-compliance. Oracle's rules for counting processors in virtualised environments are strict, and the cloud is essentially a giant virtualised environment.
| Mistake | Example Scenario | Consequence |
|---|---|---|
| Counting only active usage | 8-vCPU VM at 50% CPU = assume 4 licences | Non-compliant — Oracle requires all 8 vCPUs licensed |
| Not licensing DR/standby | Multi-region standby on 8 vCPUs, no licences | Additional licences needed — standby must be licensed |
| SE2 on too large VM | SE2 on a 12-vCPU Azure VM | Licensing breach — violates SE2 max 8-vCPU limit |
| Assuming soft partitioning | EC2 limited to 2 cores in software, but type has 8 vCPUs | Ignored by Oracle — counts all 8 vCPUs of the instance type |
| Ignoring multi-AZ setups | Failover instance in another zone "inactive" | Must be licensed if running or can be opened/read |
Always licence to the worst-case scenario (maximum cores, all active instances) unless you have a written exemption from Oracle. Cloud providers do not actively manage your Oracle licence compliance — that's on you. Build guardrails: restrict Oracle DB deployments to instance sizes you know you can licence, and require a licence check before spinning up any new Oracle environment.
| Goal / Scenario | Best Cloud Choice | Why |
|---|---|---|
| Minimise Oracle licence cost | Oracle Cloud (OCI) | 1:1 OCPU ratio and potential extra discounts — lowest cost per core |
| Avoid vendor lock-in | AWS or Azure | Broad ecosystem integration; accept higher Oracle costs for flexibility |
| Heavy Oracle feature usage | Oracle Cloud (OCI) | Full RAC, Data Guard, all options natively supported and optimised |
| Maximise existing licences | Any cloud (BYOL) | Use BYOL wherever you deploy to avoid repurchasing |
| Sunsetting Oracle | Licence-included services | Avoid long-term licence investments if Oracle use is declining |
Often a hybrid approach works best: keep large Oracle instances on OCI for cost efficiency, but smaller ones on AWS for proximity to an application. Cost isn't the only factor — performance, available features, cloud vendor relationships, and avoiding over-reliance on one vendor also matter. A strategic view of both technical requirements and licence position will guide the optimal mix.
Oracle Cloud was engineered to minimise licence requirements (1 OCPU per licence), making it generally cheaper for Oracle workloads.
In non-Oracle clouds, every two virtual cores count as one licence, with no core factor discounts.
Extra features are never free in the cloud — every option still needs its own licence coverage.
Bringing your own licences is usually the only economically sensible way to run Oracle on non-Oracle clouds.
Keep close tabs on DR sites, test instances, and scaled-out copies — each needs proper licensing.
Download our independent guide on Oracle Database licensing across OCI, AWS, and Azure — including BYOL calculations and compliance checklists
Share your deployment details and target cloud platform, and we'll provide an independent licence mapping — including BYOL calculations, options audit, and cost comparison across OCI, AWS, and Azure — typically within 48 hours.