Oracle Multitenant Licensing on AWS, Azure, and Oracle Cloud
Oracle Multitenant licensing remains critical as enterprises shift databases to the cloud. This article guides CIOs and cloud architects through the licensing considerations for Oracle Multitenant across AWS, Microsoft Azure, and Oracle Cloud (OCI).
It explains how licensing works in cloud environments (including bring-your-own-license vs. license-included models), highlights platform-specific constraints like AWS RDS’s one-PDB limit, and provides best practices for managing licenses in hybrid cloud scenarios.
The goal is to help IT leaders avoid compliance pitfalls and optimize costs when extending Oracle databases to the cloud.
Multitenant Licensing in the Cloud vs. On-Premises
Moving Oracle databases to the cloud does not eliminate Oracle’s licensing requirements – it simply adds new variables:
- Bring Your Own License (BYOL): In AWS or Azure, you can use your existing Oracle licenses on cloud VMs or services, but you must allocate the correct number of licenses based on cloud CPU cores. Oracle’s policy for authorized cloud environments (like AWS/Azure) typically counts two vCPUs as 1 Oracle processor license (assuming hyper-threading). This cloud core conversion is critical for compliance and cost estimation.
- License-Included Services: Some cloud offerings let you pay for Oracle software as part of the service. For example, Oracle’s cloud (OCI) and certain Azure/AWS cooperative services offer Oracle Database on a subscription basis, where the cost of the Oracle license (including options like Multitenant) is embedded in the hourly/monthly rate.
- Same Rules Apply: Importantly, the fundamental Oracle licensing rules for Multitenant (e.g., up to 3 PDBs free, license required for 4+ PDBs, matching metrics with the database license) apply in the cloud just as on-prem. Using Oracle on someone else’s infrastructure doesn’t change Oracle’s policies – it remains your responsibility to comply.
The cloud changes the deployment location, not Oracle’s licensing obligations. However, each platform (AWS, Azure, OCI) has nuances in how you deploy and manage those licenses.
Read Oracle Multitenant Licensing Compliance: Audit and Best Practices for Enterprises.
AWS: Oracle Multitenant on EC2 and RDS
On Amazon AWS, you have a couple of primary ways to run Oracle databases, each with different implications:
- Oracle on EC2 (BYOL): Running Oracle Database on Amazon EC2 (or VMware Cloud on AWS) is similar to running on your hardware. You have full control, meaning you can create multiple PDBs in a CDB as needed, and if you go beyond 3 PDBs, you must have the Multitenant licenses to cover that usage. Be sure to count vCPUs properly for licensing: for example, an EC2 VM with eight vCPUs would need four processor licenses for the base database and, if >3 PDBs are used, another 4 for the Multitenant option. Remember, AWS won’t prevent you from creating extra PDBs – it’s your responsibility to remain compliant.
- AWS RDS: Oracle’s managed database service currently allows only one PDB per Oracle instance, so you cannot exceed the free PDB limit on RDS. You typically don’t need a Multitenant license for RDS unless AWS changes this restriction. In other words, RDS (whether in license-included or BYOL mode) effectively disables the Multitenant option beyond what’s free – a benefit for compliance. Still, it also means you can’t consolidate multiple databases on one RDS instance.
- RDS Custom: AWS’s RDS Custom for Oracle gives you more control (essentially a managed EC2 with Oracle). You could create multiple PDBs in RDS Custom, so Oracle’s standard rules apply: if you exceed 3 PDBs in a CDB, you need to have Multitenant licensed for that instance. Treat RDS Custom like EC2 from a licensing standpoint.
One key point: AWS has no special agreement with Oracle to cover licensing. If you BYOL, you are fully responsible for proper licensing. Always use Oracle’s official cloud policy for AWS to calculate how many licenses you need for a given EC2/RDS configuration.
Azure: Oracle on Azure Environments
Microsoft Azure does not have a native Oracle managed service analogous to RDS, but you can run Oracle databases on Azure infrastructure:
- Oracle on Azure VMs (BYOL): Running Oracle Database on an Azure VM requires using your licenses, just like AWS. The same conversion (typically 2 Azure vCPUs = 1 Oracle processor license) applies. There are no Azure-provided Oracle licenses, so ensure you have enough processor or NUP licenses before deploying an Oracle multitenant CDB on Azure VMs.
- Oracle Database Service for Azure: This Oracle-Microsoft partnership offering integrates Azure with Oracle’s cloud. If you use it, the Oracle databases run on Oracle Cloud (OCI) but are tied into your Azure environment. Licensing in this case follows OCI’s rules – you might choose a license-included model or BYOL when setting up the service. You’re using Oracle’s cloud through Azure, so it’s not Azure-specific licensing.
Running Oracle in Azure is essentially a BYOL scenario (similar to AWS) unless you explicitly utilize Oracle’s cloud through Azure’s interconnect services. Azure doesn’t give any Oracle license discounts or special terms – you either bring licenses or pay Oracle via OCI.
Oracle Cloud (OCI): Multitenant in Oracle’s Cloud
Oracle’s own cloud (OCI) naturally provides the most seamless options for Oracle Database, including Multitenant:
- BYOL on OCI: If you have existing Oracle Database and Multitenant licenses, you can apply them to OCI compute or Database services. In OCI, 1 OCPU is equivalent to 1 physical core, so one Oracle processor license covers one OCPU. BYOL on OCI is straightforward – it’s just like moving your workload to a new data center, with the same license counts needed.
- License-Included on OCI: Oracle offers database cloud instances in tiers. The Enterprise Edition High Performance (and Extreme Performance) service tiers include the Multitenant option (and many other add-ons like Partitioning, Active Data Guard, etc.) in the subscription price. If you choose those service levels, you can use Multitenant without separately purchasing licenses – it’s bundled into the hourly rate you pay to Oracle Cloud. If you opt for the base Enterprise Edition service on OCI (cheaper), which does not include Multitenant, you’d have to use BYOL for the Multitenant option or stick to the free PDB limit.
- Autonomous Database: Oracle’s Autonomous Transaction Processing and Autonomous Data Warehouse services use multitenant architecture under the hood (each customer’s “Autonomous” instance is effectively a PDB in an Oracle-managed CDB). However, you don’t need licenses for these – you simply pay for the cloud service consumption. All necessary Oracle licenses, including Multitenant, are handled by Oracle in the service fee.
OCI benefits flexibility: you can bring your licenses or let Oracle provide them as part of a cloud service. Cost-wise, it’s worth comparing – in some cases, paying Oracle per hour for a license-included service might be more cost-effective than buying perpetual licenses and paying support, especially for short-term or variable workloads.
Best Practices in Cloud and Hybrid Licensing
- Map & Monitor Your Assets: Create an inventory of all Oracle databases across on-prem and clouds, noting which use Multitenant and how they are licensed. Continuously monitor these deployments to catch any licensing overuse early.
- Leverage OCI for Multitenant: If you heavily use Multitenant (many PDBs) and have cloud flexibility, Oracle’s own OCI services (with Multitenant included) can simplify compliance and potentially save costs compared to juggling BYOL licenses on AWS/Azure.
- Use AWS/Azure BYOL Wisely: Rigorously calculate required licenses before deploying Oracle on AWS/Azure. Utilize tools (like AWS License Manager) to ensure you don’t launch more Multitenant-capable instances than you have licenses for. This includes properly accounting for the 2 vCPU = 1 license rule.
- Architect for Compliance: Take advantage of cloud features to avoid compliance risks. For example, using AWS RDS’s single-PDB limit ensures you can’t accidentally use extra PDBs. In OCI, choosing a service tier that includes Multitenant means Oracle handles compliance for that feature. Design your cloud architecture with these factors in mind.
- Allocate Licenses Carefully: In a hybrid environment, decide which licenses are assigned to on-prem and cloud. If you move a workload to the cloud under BYOL, update your records to show that those licenses now cover the cloud cores (and are not available on-premises unless you migrate them back). Avoid double-counting licenses across environments.
- Audit Cloud Deployments: Just as on-prem, periodically audit your cloud Oracle instances to ensure they remain within licensed boundaries (PDB counts, cores, etc.). Cloud resources can sprawl quickly, so set up a schedule to review Oracle usage in each cloud account.
- Stay Informed: Keep up with Oracle’s cloud licensing policy updates. Rules for counting licenses or allowed usage can change, so ensure your team stays current with Oracle’s announcements. For instance, if Oracle were to adjust the vCPU licensing formula or RDS lifted its PDB restriction, you’d want to know immediately and adapt.
- Optimize Costs: If you have extra on-prem licenses, consider using them in the cloud (where you might otherwise pay again for license-included). Conversely, if your cloud usage is bursty, consider license-included for short periods rather than perpetually assigning a BYOL license. Match the licensing approach to your cloud consumption pattern to avoid overspending.
FAQ
Q1: Is Oracle Multitenant free to use in Oracle Cloud (OCI)?
A1: Not exactly “free,” but Oracle Cloud offers database service tiers that include the Multitenant option at no extra charge. If you choose the Enterprise Edition High Performance (or higher) service on OCI, the cost of Multitenant is bundled into what you’re already paying. In that case, you aren’t buying a separate Multitenant license – the service fees cover it.
Q2: Do we need to buy new licenses if we move an Oracle database with multiple PDBs to AWS?
A2: You don’t need to buy new licenses; you can spare them if you have existing ones. You can bring your Oracle licenses to AWS using the BYOL model. However, you must have enough processor licenses to cover the AWS deployment. If on-prem you avoided buying Multitenant licenses by sticking to 3 PDBs or fewer, but in AWS you now intend to run 10 PDBs in one CDB, you will need to purchase the Multitenant licenses at that point (or reduce PDBs). Always true-up your license counts before a migration.
Q3: How does Oracle know what we’re running in the cloud?
A3: Oracle’s audit rights extend to any environment where you deploy their software. While AWS or Azure won’t report your usage to Oracle, Oracle can request an audit, and you would have to provide data from your cloud instances (just as you would from on-prem servers). In Oracle’s cloud (OCI), Oracle has insight into what you’re using (especially for license-included services), but they still expect you to manage compliance for BYOL resources.
Q4: What is the “2 vCPUs = 1 license” rule in cloud environments?
A4: This rule comes from Oracle’s cloud licensing policy for certain authorized cloud providers. In environments like AWS, Azure, and Google Cloud, Oracle has stipulated that for Enterprise Edition database licenses, you count two virtual CPUs as one processor license (if hyper-threading is enabled). This effectively acknowledges that two vCPUs correspond to one physical core with hyper-threading. If hyper-threading is disabled (one vCPU = one core), then one vCPU = 1 license. Always check Oracle’s current policy document, which has been the standard for several years.
Q5: Does AWS or Azure offer special pricing or deals for Oracle Multitenant?
A5: AWS and Azure do not sell Oracle licenses or include Oracle Database options in their pricing. They only provide the infrastructure. Any Oracle software licensing (including Multitenant) is either your responsibility under BYOL or, in Azure’s case, possibly handled via OCI if you use the integrated service. AWS’s only “included” Oracle offering is RDS for Oracle in Standard Edition (which doesn’t involve Multitenant). So, no special discounts on the Oracle side from AWS/Azure; you have to go through Oracle for any license negotiations.
Q6: Can I run more than 3 PDBs on AWS RDS for Oracle?
A6: Currently, no. Amazon RDS for Oracle (the fully managed service) restricts you to one user-created PDB per database instance on Enterprise Edition. You cannot use the Multitenant feature for multiple PDBs on a single RDS instance. If you need multiple PDBs on AWS, you would use RDS Custom or run Oracle on EC2, and then ensure you have the appropriate licenses.
Q7: In a disaster recovery scenario (on-prem primary, cloud DR, or vice versa), do we need to license Multitenant on both?
A7: Yes, in most cases. Suppose your DR database in the cloud is continuously running and kept in sync (e.g., using Data Guard). In that case, it will require the same licensing as the primary, including the Multitenant option if the primary uses it. Oracle’s 10-day rule for DR (allowing use of the software on an unlicensed standby for a limited time each year) might let you avoid licensing a completely idle passive DR instance. Still, it must be licensed if that DR instance is mounted and open for read-only (or used for tests beyond 10 days). It’s safest to license both primary and DR.
Q8: What if we use Oracle Autonomous Database – do we need a Multitenant license?
A8: No. If you use Oracle Autonomous Database (in OCI), you don’t need to bring any licenses or options for the database. It’s a fully managed service where you pay for database capacity (OCPUs per hour), and Oracle includes all necessary licensing in that price. Autonomous databases inherently use multitenant architecture, but that’s all behind the scenes and included.
Q9: Can we temporarily allocate an on-prem license to a cloud instance for a burst and then bring it back?
A9: Oracle licenses are generally not temporary-use tokens – they are tied to whichever environment you assign them to, until you reassign them (per contract terms). You can move licenses between on-prem and cloud, but it’s not practical for short “bursts” like a one-week cloud project, because Oracle’s contract may require a 30-day minimum before reuse on another server. If you have spare licenses, you could assign them to a cloud instance for a short time and then revoke, but you’d still be counting them during that time. For bursting scenarios, many companies find the license-included cloud model simpler (even if slightly higher cost) to avoid compliance risk during the burst.
Q10: Are there tools to help manage Oracle licenses in the hybrid cloud?
A10: Yes. Third-party IT asset management tools (from vendors like Flexera, ServiceNow, etc.) can track license allocations across environments. AWS has a License Manager service can help you keep tabs on BYOL deployments and ensure you don’t exceed your entitlements. Oracle also provides a cloud management pack (if you use Oracle Enterprise Manager) to track where Oracle software is deployed. Utilizing these tools can provide an early warning if, for example, someone in your company deploys a new Oracle EC2 instance with too many PDBs or too many vCPUs for your license pool.
Read more about our Oracle License Management Services.
