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.
This guide is part of our Oracle Database licensing series. For foundational context on editions, options, and metrics, see Oracle Database Licensing Guide. For BYOL specifics across all cloud providers, see Oracle BYOL Guide. For the broader cloud comparison, see Oracle Licensing: OCI vs AWS vs Azure vs GCP.
Bring Your Own License (BYOL) allows you to transfer existing Oracle Database licences from on-premises to cloud environments. BYOL does not change the fundamental licensing metrics or rules. It simply relocates your licences. If you needed four processor licences on-prem, you will 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 and valid | Only legitimate licences can be used for 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 does not 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 the cloud |
Eligible BYOL workloads include Oracle Database Enterprise Edition, Standard Edition 2 (within size limits), all options and packs (with matching licences), dev/test/production workloads, and standby databases (which must be licensed if active). Active support is required to maintain BYOL eligibility throughout the cloud deployment.
BYOL moves your licences to a new environment. It does not reduce them. You remain responsible for ensuring sufficient licences for cloud CPUs and users, and for tracking and reporting usage just as diligently as on-premises. The most common BYOL mistake is assuming that moving to the cloud somehow simplifies or reduces licence requirements. It does not. The counting rules change by provider, and in most cases they become more demanding, not less.
For metrics details, see Named User Plus vs Processor Licensing. For DR licensing, see Oracle Failover and Disaster Recovery Licensing.
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. Oracle designed OCI specifically to make its own licensing economics attractive.
| 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 |
BYOL is supported on all OCI Database services, including Autonomous Database, Exadata Cloud Service, and standard DB System instances. Oracle also offers Support Rewards, crediting up to 33% of OCI spend against on-premises support bills, which further reduces total cost of ownership.
OCI gives you more compute per licence than any other cloud. The 1:1 OCPU ratio, reduced NUP minimums (2 per OCPU vs 25 per processor on-prem), and Support Rewards credits make OCI the default choice when minimising Oracle licence spend is a priority. However, "cheapest for Oracle licensing" does not automatically mean "best cloud strategy." Evaluate OCI against your broader cloud portfolio, application architecture, and vendor diversification goals before committing. The licence savings are real but should not be the only factor in your cloud platform decision.
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 licence | Effectively doubles licence requirements per vCPU count |
| Standard Edition (SE2) | 4 vCPUs = 1 SE2 licence increment | Maximum 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 |
Enterprise Edition requires BYOL on AWS. RDS licence-included options exist only for Standard Edition, and RDS limits some Oracle features (no RAC, limited packs). Running Oracle EE on AWS without BYOL is not an option.
There is no concept of a core factor in AWS (or any public cloud). Oracle does not allow the on-prem core factor table to reduce licence counts in the cloud. Every core is a full-core licence. If your on-premises hardware required fewer licences due to core factors (for example, Intel x86 with a 0.5 factor), moving to AWS can substantially increase your Oracle licensing requirements. This is the single most underestimated cost factor in Oracle cloud migrations. Model the licence impact before committing to AWS instance sizes.
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 will not enforce Oracle's licensing constraints for you. It is 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 maximum 8 vCPUs per VM |
| Named User Plus | Allowed (user-based) | Customer must track user counts. Azure does not enforce limits |
Azure will not stop you from deploying Oracle SE2 on a 16-vCPU VM, but doing so violates Oracle's licensing rules. SE2 maximum is 8 vCPUs in any cloud instance. No Azure Hybrid Benefit exists for Oracle. Your on-premises Oracle licences are the only cost relief.
Unlike Microsoft's own licensing where Azure Hybrid Benefit and licence-included options provide guardrails, Oracle licensing on Azure is entirely self-governed. Azure provides the infrastructure. Oracle provides the rules. And neither party will proactively flag compliance gaps. This means your ITAM team must establish internal controls: restrict Oracle deployments to pre-approved instance sizes, require licence verification before provisioning, and conduct periodic compliance scans. The most expensive Azure-Oracle compliance findings come from developers spinning up oversized instances without understanding the licensing implications.
Moving to the cloud does not 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 is 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. Do not forget when migrating to cloud |
| Oracle RAC | Yes | Only practical on OCI. Not supported on AWS or Azure. All nodes must be fully licensed |
| Advanced Security | Yes | Includes TDE encryption and Data Redaction. Required unless cloud bundle explicitly includes it |
| Diagnostics and 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. Enterprise Edition only |
| Database In-Memory | Yes | Per-processor licence required. Often accidentally enabled during cloud provisioning |
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. The most dangerous scenario is a cloud migration where the DBA enables TDE encryption "because it is best practice" without realising Advanced Security requires a separate per-processor licence. One click can create a six-figure compliance gap.
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. The following mistakes are the ones we see most frequently in cloud Oracle deployments.
| Mistake | Example Scenario | Consequence |
|---|---|---|
| Counting only active usage | 8-vCPU VM at 50% CPU utilisation. Team assumes 4 licences needed | Non-compliant. Oracle requires all 8 vCPUs licensed regardless of utilisation |
| Not licensing DR/standby | Multi-region standby on 8 vCPUs with no licences allocated | Additional licences needed. Standby must be licensed if running or mountable |
| SE2 on too large VM | SE2 deployed on a 12-vCPU Azure VM | Licensing breach. Violates SE2 maximum 8-vCPU limit immediately |
| Assuming soft partitioning | EC2 limited to 2 cores in software, but instance type has 8 vCPUs | Ignored by Oracle. All 8 vCPUs of the instance type must be licensed |
| Ignoring multi-AZ setups | Failover instance in another availability zone marked "inactive" | Must be licensed if running or can be opened/read. "Inactive" is not a licensing term |
Always licence to the worst-case scenario: maximum configured cores, all active instances, all availability zones with running databases. Cloud providers do not actively manage your Oracle licence compliance. That responsibility is entirely yours. Build guardrails into your cloud governance: restrict Oracle DB deployments to instance sizes you know you can licence, require a licence check before spinning up any new Oracle environment, and tag all Oracle workloads for automated compliance monitoring. The cost of over-provisioning a few vCPUs is always less than the cost of an Oracle audit finding.
| 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 for Oracle workloads |
| Avoid vendor lock-in | AWS or Azure | Broad ecosystem integration. Accept higher Oracle costs for platform 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 licences |
| Sunsetting Oracle | Licence-included services | Avoid long-term licence investments if Oracle use is declining |
Often a hybrid approach delivers the best outcomes: keep large Oracle instances on OCI for cost efficiency, but run smaller ones on AWS for proximity to other applications. Cost is not the only factor. Performance, available features, cloud vendor relationships, and avoiding over-reliance on one provider all matter. A strategic view of both technical requirements and licence position will guide the optimal mix. Do not let Oracle licensing economics alone dictate your cloud architecture. But do not ignore them either. The licence cost difference between OCI and AWS for a large Oracle estate can be millions of dollars per year.
1. OCI offers the most favourable licensing ratios. Oracle Cloud was engineered to minimise licence requirements (1 OCPU per licence), making it generally cheaper for Oracle workloads. If Oracle licence cost is your primary concern, OCI is the default choice.
2. AWS and Azure use 2 vCPUs per processor, effectively doubling licence costs. In non-Oracle clouds, every two virtual cores count as one licence, with no core factor discounts. Model the licence impact before committing to instance sizes on either platform.
3. Options and packs must be licensed separately in all clouds. Extra features are never free in the cloud. Every option still needs its own licence coverage. Partitioning, Advanced Security, Diagnostics Pack, Tuning Pack, and Active Data Guard all require separate licences regardless of cloud provider.
4. BYOL is essential for cost control on AWS and Azure. Bringing your own licences is usually the only economically sensible way to run Oracle on non-Oracle clouds. Without BYOL, the cost of acquiring new Oracle licences for cloud deployment is prohibitive for most enterprises.
5. Compliance requires accurate tracking across all cloud regions. Keep close tabs on DR sites, test instances, and scaled-out copies. Each needs proper licensing. Cloud makes it easy to spin up new instances and forget about them. Every running Oracle database, in every region and availability zone, counts.
1. Inventory all Oracle Database cloud deployments. Document every Oracle instance across OCI, AWS, and Azure. Include instance types, vCPU counts, editions, and environment classification (production, DR, dev, test). Map these against your current licence entitlements.
2. Calculate licence requirements per cloud provider. Apply the correct vCPU-to-licence conversion for each provider: 1:1 for OCI, 2:1 for AWS and Azure. Remember that no core factor applies in any cloud environment. Compare required licences against your BYOL pool.
3. Audit options and packs usage. Run Oracle's feature usage tracking queries (DBA_FEATURE_USAGE_STATISTICS) on every cloud database instance. Identify any options or packs that are enabled but not licensed. Disable what you do not need. Procure licences for what you do.
4. Validate DR and standby licensing. Confirm that every standby database, multi-AZ failover instance, and DR copy is properly licensed. If a database can be opened or read, it needs licences. Document your DR architecture and the licensing coverage for each component.
5. Establish cloud governance for Oracle workloads. Implement controls that prevent unlicensed Oracle deployments: pre-approved instance sizes, mandatory licence checks before provisioning, automated tagging of Oracle workloads, and periodic compliance scans. Make Oracle licensing a gate in your cloud provisioning workflow, not an afterthought.
Oracle's audit teams are increasingly sophisticated about cloud deployments. They know customers are migrating to AWS and Azure, they know the common compliance gaps (oversized instances, unlicensed options, missing DR coverage), and they have tools to quantify the exposure. Completing this checklist proactively, before an audit letter arrives, gives you the ability to remediate on your own terms, at negotiated prices, instead of under audit pressure at list price with backdated support. The ROI on a few days of compliance work is typically six to seven figures.
No. Oracle does not allow the on-premises core factor table to reduce licence counts in any public cloud, whether OCI, AWS, Azure, or GCP. Every core in the cloud is a full-core licence. This is one of the most common misunderstandings and frequently leads to under-licensing during cloud migrations. If your on-prem estate benefited from a 0.5 core factor on Intel processors, expect your licence requirements to effectively double when moving to the cloud.
Yes. SE2 is limited to a maximum of 8 vCPUs per cloud instance on AWS, Azure, and similar providers. Deploying SE2 on a larger VM violates Oracle's licensing rules and puts you out of compliance immediately. On OCI, SE2 is limited to 8 OCPUs (16 vCPUs). Cloud providers will not prevent you from exceeding this limit. It is entirely your responsibility to enforce the constraint.
Generally yes. If a standby database is running, mounted, or can be opened/read, Oracle requires it to be fully licensed. The only exception is a completely powered-off backup copy. Active Data Guard (readable standby) always requires separate ADG licences covering all standby cores. See our Oracle Failover and Disaster Recovery Licensing Guide for full details on standby and DR licensing rules.
No. Oracle RAC requires shared storage and cluster interconnects that are only available on Oracle Cloud Infrastructure (OCI) or specialised setups like Oracle Exadata. RAC is not supported on standard AWS EC2 or Azure VM deployments. If you need RAC for high availability or scalability, OCI is effectively your only public cloud option. On AWS and Azure, consider alternative HA approaches such as Data Guard for failover.
BYOL on OCI uses a 1:1 OCPU-to-licence ratio, meaning one existing processor licence covers one OCPU. You transfer your existing on-prem licences to OCI without purchasing new ones. Active support is required. NUP minimums are reduced to 2 per OCPU (vs 25 per processor on-prem). Oracle also offers Support Rewards, crediting up to 33% of your OCI spend against on-prem support bills. See our Oracle BYOL on OCI Guide for step-by-step BYOL calculations.
The five biggest risks are: (1) losing the core factor discount and underestimating licence requirements, (2) accidentally enabling options or packs (Diagnostics Pack, Advanced Security, Partitioning) without licences, (3) deploying SE2 on oversized instances exceeding the 8-vCPU limit, (4) failing to licence DR/standby instances across availability zones and regions, and (5) assuming cloud providers will manage Oracle compliance on your behalf. Each of these creates immediate non-compliance that Oracle's audit team can quantify precisely.
Redress Compliance provides independent Oracle licensing assessments for cloud migrations, including BYOL licence calculations, options and packs audit scans, vCPU-to-licence mapping for OCI/AWS/Azure, and compliance gap analysis. We ensure you are properly licensed before migration, during operation, and in the event of an Oracle audit. Our assessments typically identify six-figure savings opportunities and compliance gaps before Oracle does. See our Oracle Licence Management Services.
Share your deployment details and target cloud platform, and we will provide an independent licence mapping, including BYOL calculations, options audit, and cost comparison across OCI, AWS, and Azure, typically within 48 hours.
Oracle Licence AssessmentIndependent licence mapping. BYOL calculations. Options audit. Cost comparison across OCI, AWS, and Azure. 100% vendor-independent.