Oracle Enterprise Manager Licensing in Cloud and Hybrid Environments
As enterprises migrate databases to the cloud or split workloads between on-premises and cloud, Oracle Enterprise Manager (OEM) licensing becomes more complex.
This article offers CIOs and CTOs a roadmap for OEM licensing in cloud and hybrid scenarios. We explain how Oracle’s Bring Your License (BYOL) policy works for OEM management packs, what’s included when using Oracle’s cloud services, and how to maintain compliance and cost-efficiency across hybrid environments.
You’ll learn to ensure your use of OEM features remains within license bounds, whether on-prem, in Oracle Cloud, or on AWS/Azure.
Read Oracle Enterprise Manager Licensing Best Practices for Compliance.
BYOL vs. Cloud-Included Licensing
When moving Oracle workloads to the cloud, you have two models:
- Bring Your Own License (BYOL): Use the licenses you purchased on new cloud instances. For OEM packs, BYOL means that if you have four processor licenses of Diagnostics Pack on-prem, you can assign those to an Oracle database running in the cloud (Oracle or third-party), covering up to 4 cloud-processor equivalents.
- License-Included Services: Some cloud services include necessary licenses in the price. In Oracle Cloud Infrastructure (OCI), for example, if you use an Autonomous Database service, the Diagnostics and Tuning Pack features are built into the service – you don’t separately license those packs. However, if you install Oracle on a standard cloud VM (OCI Compute, AWS EC2, etc.), the cloud provider does not include OEM packs; you must use BYOL for any pack features.
In short, Oracle’s managed cloud services may bundle OEM functionality, whereas self-managed Oracle on VMs in any cloud requires you to bring or buy the licenses as if on-prem.
Oracle OEM in Oracle’s Cloud (OCI)
Oracle Cloud provides some unique advantages for OEM licensing:
- Autonomous Database Includes Packs: Oracle Autonomous Database (and similar Oracle-managed database services) include performance diagnostics and tuning features by default. You get the benefit of Diagnostics Pack and Tuning Pack capabilities without needing separate licenses – it’s part of the service you pay for.
- BYOL on OCI Compute: If you run your own Oracle databases on OCI Compute instances (virtual machines or bare metal), you simply allocate your existing licenses. OCI’s interface lets you declare which packs you’re using under BYOL. The rules are the same as those for on-prem: if you enable a pack’s features on an OCI instance, you must have enough licenses to cover it.
- Oracle Cloud Tooling: OCI offers tools like Oracle Cloud Management Pack for Database (confusingly named but essentially cloud-based OEM), which can help oversee both cloud and on-prem databases. If you use these in OCI, note that Oracle treats them like any OEM deployment—packs used require licenses unless Oracle explicitly says otherwise. The benefit is that OCI’s monitoring might alert you to pack usage, helping you stay compliant.
- No Hardware Constraints: In OCI, you can spin up and shut down instances. Oracle licenses in OCI are more flexible with reallocation (Oracle doesn’t force a 30-day transfer wait in their cloud). This means you can use a pack license for a server this week, terminate it, and use the same license for another server next week, as long as at any point in time you’re not using more licenses than you own.
Using Oracle’s cloud can simplify some aspects of OEM licensing and reduce the chances of accidental misuse, especially with Autonomous services.
Read Cost Optimization Strategies for Oracle Enterprise Manager Licensing.
OEM Licensing on AWS and Azure
For Oracle on AWS, Azure, or other third-party clouds, treat it like on-prem in terms of licensing:
- Counting Cores (vCPUs): Oracle has specific rules for counting cloud cores. For Enterprise Edition, Oracle typically counts two vCPUs as one processor license on most third-party clouds (because they assume hyperthreading). So, if you have an AWS EC2 with eight vCPUs, you need four processor licenses for any OEM pack you use there. Always confirm the current policy – Oracle publishes cloud licensing guidelines (e.g., as of now, AWS/Azure 2 vCPU = 1 license for EE).
- No Free Use on AWS/Azure: Unlike OCI Autonomous services, if you deploy Oracle on AWS or Azure VMs, those providers don’t include Oracle packs. OEM packs are not included even if the Oracle database license is covered (say, via AWS’s license-included offerings for the base DB). In fact, on AWS’s license-included RDS service for Oracle, you can’t use most pack features because they’re not part of the offering.
- Amazon RDS and Packs: If you use Amazon RDS for Oracle in BYOL mode, you would theoretically cover packs with your licenses, but practically, RDS restricts access to certain features (like you can’t run the OEM GUI or certain PL/SQL packages needed for packs). Essentially, RDS is not intended for use with OEM packs—those advanced features are outside of its scope.
- Azure Oracle Scenarios: Azure hosts Oracle workloads similarly under BYOL. There’s also an Oracle-Azure interconnect where you can run Oracle Database on OCI. In contrast, your app runs in Azure – in such cases, the database is on OCI, so Oracle’s cloud rules apply (which could include packs in the service if using Autonomous, or BYOL if using a regular database on OCI).
The key is that moving to AWS/Azure doesn’t reduce your Oracle licensing requirements—you must manage them just like before, with the added step of translating VM specs into license counts.
Hybrid Environment Considerations
In a hybrid environment, you might have Oracle databases on-prem and in one or more clouds:
- Unified Policies: Maintain a single set of policies for Oracle license use. For example, if your policy is to disable unlicensed packs, ensure that is done on every new database, whether on a physical server or a cloud VM.
- Central License Tracking: Keep a central record of all Oracle databases, which packs (if any) are enabled, and how they are licensed. This inventory should span on-premises and cloud. It helps avoid a scenario where a dev team enables a pack on a cloud database without anyone realizing there’s no license for it.
- License Mobility and Overlap: Plan your license allocations during migrations. If you’re transitioning a workload to the cloud, be careful about running it in both places concurrently. Either purchase temporary licenses for the overlap period or schedule a quick cutover. Oracle’s standard agreements don’t allow the same license to cover two active deployments simultaneously (even for a few migration days) without extra arrangements.
- Cloud Monitoring & Audit: Ensure you can audit your cloud instances for Oracle usage. This might mean installing Oracle’s LMS scripts on an AWS VM or reviewing usage logs in OCI. During an official audit, you must provide data from all environments. Ideally, internally audit your cloud Oracle instances just as you do on-prem.
Hybrid setups offer flexibility but require diligence to ensure your Oracle usage remains compliant.
Recommendations
- Map licenses to deployments: Maintain an up-to-date mapping of which OEM pack licenses cover which servers/instances, regardless of location.
- Use included services when possible: If feasible, leverage Oracle Autonomous Database or other cloud services that include management features – this can reduce the need for separate pack licenses.
- BYOL wisely: When using BYOL on cloud VMs, ensure you have enough licenses for the peak usage. Remember to account for DR or test instances if they are running simultaneously.
- Consistent configuration: Standardize your Oracle configurations so that any unlicensed packs are disabled by default on new instances, whether on-prem or in the cloud.
- Educate cloud teams: Make sure your cloud architects and DevOps engineers understand Oracle’s licensing (e.g., not to turn on certain Oracle options/packs without approval).
- Monitor cloud usage: Implement tagging or monitoring in your cloud environment to quickly identify when a new Oracle database is launched, so you can verify it’s licensed properly.
- Leverage Oracle’s tools: In OCI, use Oracle’s built-in license tracking tools; for AWS/Azure, consider third-party SAM tools that can track cloud deployments.
- Review contracts: If you have enterprise agreements or ULAs and you’re moving to the cloud, review and update them to reflect new usage patterns (e.g., including cloud vCPUs, etc.).
FAQ
Q1: Are Diagnostics and Tuning Packs free on Oracle Autonomous Database?
A: Yes. When you use Oracle’s Autonomous Database (a fully managed cloud service), the diagnostics pack and tuning pack capabilities are included in the service. You don’t need to own those pack licenses separately for an Autonomous Database – Oracle provides performance monitoring and tuning as part of what you’re paying for in the cloud.
Q2: If we move an Oracle database to AWS, do we need to buy new OEM pack licenses?
A: Not if you already have them. Under Bring Your Own License, you can allocate your existing OEM pack licenses to cover an AWS deployment. Just ensure you have enough licenses to cover the AWS instance’s vCPUs. Suppose you don’t have licenses yet and are starting a new deployment on AWS. In that case, you’d need to purchase the appropriate licenses (Oracle will happily sell them to you – there’s no special cloud-only license, but they are the same licenses).
Q3: How do I count licenses for OEM packs on AWS or Azure VMs?
A: Oracle’s cloud licensing policy states that for Enterprise Edition, every two vCPUs count as 1 Oracle processor license (because most cloud vCPUs are hyperthreads). So, for an Azure VM with eight vCPUs, you’d need four processor licenses of any pack you use. Always check the latest policy, but generally, divide the total vCPUs by 2 (and round up) to get the number of licenses required for that instance.
Q4: Does Oracle ever audit cloud environments for license compliance?
A: Yes. Being in the cloud doesn’t exempt you from Oracle audits. Oracle can request audit data for any environment. The difference is that Oracle can’t access AWS/Azure environments directly, so they’ll rely on you to run their scripts and provide output. Suppose you’re using OCI, especially license-included services. In that case, audits might be less of a focus (since Oracle already controls those environments), but if you BYOL to OCI, they can still audit that you have sufficient licenses. Treat your cloud usage with the same compliance rigor – keep records and evidence just in case of an audit.
Q5: Are there special licenses or lower costs for using OEM packs in non-production (dev/test)?
A: No. Oracle does not offer separate “non-production” licenses for OEM packs. If you use the packs in a dev or test environment, they must be licensed just like production. The cost and rules are the same (though you could choose Named User Plus licensing if user counts are small). The alternative is to avoid using those features in non-production to save on licenses.
Q6: Can one OEM Cloud Control instance monitor on-prem and cloud databases?
A: Absolutely. For example, OEM Cloud Control (13c) is designed to manage multiple environments. You can set up a centralized OEM server (either on-prem or in the cloud) that connects to all your databases. Just remember: if Cloud Control uses pack features on any of those databases, those databases need to be licensed for the packs. The location of OEM doesn’t change the licensing requirement for the targets it manages.
Q7: Will Oracle’s licensing rules change if we use a cloud provider’s managed Oracle service (like Amazon RDS)?
A: The rules don’t change, but the scenario does. You can’t use OEM packs in Amazon RDS (License Included) because AWS doesn’t provide access to those features. In RDS BYOL, you theoretically could if you have licenses, but RDS limits what you can do (no direct SYS access, etc.), so packs are largely unusable in practice. Oracle on Azure (if using Azure’s Oracle images) is BYOL for the database and packs. So, the licensing rules are the same, but the cloud provider’s service might restrict usage of features that require those licenses.
Q8: If we have an Oracle ULA for databases, are OEM packs included?
A: Not automatically. It depends on what’s negotiated. Some Oracle ULAs include specific management packs, but many ULAs cover only the database licenses. If your ULA doesn’t explicitly list OEM packs (like Diagnostics, Tuning), then those packs are not covered, and you must license them separately, even under the ULA. Always verify the exact terms of your ULA.
Q9: What’s a smart way to handle OEM licensing when migrating to the cloud to avoid issues?
A: Do a pre-migration license assessment. Know what packs you’re using on-prem and ensure you have licenses to cover the equivalent in cloud (factoring in the vCPU conversion). During migration, avoid running duplicates – e.g., don’t leave the old system using packs while the new cloud system also starts using them unless you have licenses for both. Perhaps temporarily double-license during transition or time the cutover tightly. After migration, update your records to mark licenses for cloud deployments. Plan it out so you’re never inadvertently overusing licenses in the chaos of migration.
Q10: Does using Oracle Cloud (OCI) make license compliance easier?
A: Generally, yes. Oracle’s cloud services, like Autonomous DB, remove the need for you to license packs separately – Oracle gives you the functionality as part of the service. This eliminates many compliance concerns for those particular databases. Additionally, Oracle Cloud has tools to help track BYOL usage if you go that route. Oracle also has a vested interest in cloud customers being successful, so you might experience fewer aggressive audits while you’re heavily in OCI. But remember, if you use BYOL on OCI or mix environments, you still need to manage compliance – OCI just provides more built-in help and, in some cases, bundles that simplify licensing.
Read about our Oracle License Management Service.
