This post is the second in our content series on exploring the risks of non-compliance with security, financial, architectural, or vendor requirements when deploying mission/business-critical systems and data to the cloud. In the first post, we explored the risk of data exposure from misconfigured cloud instances and/or data stores. Now, we will turn our attention to a different, but still potentially costly risk scenario – uncontrolled use of licensed Oracle technology in a public cloud environment.
There are a few fundamental threats related to Oracle compliance and the public cloud that we will address in this post. Other threats will be addressed in subsequent posts.
- Oracle add-on features which require additional licensing, e.g. Partitioning
- Ease of deployment, instances can be added with just a few clicks
- Using Oracle Enterprise Edition features in Standard Edition
Deploying Oracle Database and Middleware to Public Cloud Environments
Adopting an effective cloud strategy has been at the top of CIO’s plans for many years now. Moving Oracle or other business-critical workloads into a public cloud environment has been slower to move along the adoption curve, but there is definite value and potential cost savings by implementing such a strategy. As with most things in life, there are tradeoffs and risks that must be considered.
Licensing Oracle database and/or middleware software in a cloud environment can be accomplished in a number of ways depending on which cloud is being deployed to. Oracle Real Application Clusters (RAC) is only supported by Oracle on OCI, so the following license options assume no RAC usage:
For the Physical Core and vCPU license options, the customer must calculate the usage, and bring your own license (BYOL) to cover that usage. The base metric for Oracle licenses is called “Processor” and each Processor of Database Enterprise Edition license costs $47,500 at published list price.
The Potential Risk
While Oracle provides excellent enterprise-class data and application management solutions, they do not provide adequate safeguards to protect users against unintended usage. Coupled with Oracle’s aggressive, and often overreaching audit practices, this risk definitely rises to the level of existential. The ease of accidental usage and the bullying of an audit make one wonder if those two are not intentional vectors in Oracle’s dubious revenue generation strategy.
As a citation of a real-world threat, House of Brick defended a customer from Oracle where the auditors were claiming a license deficiency of the unbelievable amount of $300 million. If the customer had to actually pay that penalty, it would have quickly put them out of business. We engaged with the customer to calm their fears, and then analyzed the situation using the OpsCompass product.
We determined that the customer did not owe the staggering claim but were actually in compliance. We resolved the audit with the customer paying $0.
There are several ways that Oracle users can go out of compliance with their license parameters. In this post, we will explore two cost traps. Other risk scenarios will be explored in future posts.
AWS RDS Usage without BYOL
A popular service from AWS is the managed Relational Database Service or RDS. For Oracle databases, AWS offers RDS in either a bring your own license (BYOL) configuration, or in a License Included (LI) configuration (for Oracle SE 2 users). But how can you keep track of your AWS RDS instances to ensure that appropriate licenses are allocated?
OpsCompass looks for cloud instances of all types and flags them according to standard and customer-specific criteria. In the example illustrated below, OpsCompass has identified a high-severity alert of an RDS Oracle instance that is configured as BYOL. The problem is that we do not have this in our inventory of databases that are being monitored for license compliance.
Using Enterprise Features in Standard Edition Databases
As outlined in his excellent blog post, House of Brick’s David Woodard identifies the license trap that Oracle sets for users of Standard Edition 2 database. The problem is that Oracle leaves certain Enterprise Edition features enabled on installation of SE 2. Users can unintentionally invoke these EE features without warning, thus creating the risk of a massive cost of license deficiency.
Consider the following small, medium, and large SE 2 deployment environments. SE 2 is a bargain at a list price of $17,500 per socket (regardless of the number of cores per socket). The example shows that the database license cost ranges from $35k for the small, up to just over $1M for the large.
Oracle’s Enterprise Edition database is licensed differently from SE 2. The list price for EE is $47,500 per Processor, which for the x86 servers in public cloud environments translates into either 1 or 2 vCPUs depending on hyperthreading, or 2 physical cores in a dedicated host environment. Where SE 2 would use a maximum of 2 licenses per two-socket server, EE licenses are capped only by the core count. In the example above, while each server has 2 sockets, the number of cores per host ramps up from 12 for small, to 16 for medium, to 32 for large.
Unintended usage of the enterprise Diagnostics Pack and/or Tuning Pack in a SE 2 database would require the user to not only pay for those feature licenses but would cause a license change from Socket to Processor to cover Enterprise Edition. Consider the dramatic cost penalty of this unintended usage:
As you can see, a small Oracle SE 2 user would have potential audit fees of more than 10x the original license purchase. For the large environment the penalty would be more than 28x. And this does not even consider the burden that the 22% support fees would cost.
How Would OpsCompass Prevent this Existential Threat?
OpsCompass monitors every Oracle database for several threat vectors, but in this case, we are focusing on enterprise feature usage. OpsCompass monitors the feature metadata in every database and alerts users if there is unlicensed option or pack usage.
As you can see below in the alert view of OpsCompass, we are identifying everything that is triggering enterprise feature usage that is accessible in a SE 2 database. Not only are we identifying the problem, but also providing instructions on how to mitigate the issue to prevent it from happening again.
Summary
Oracle licensing is a high-cost risk that must be actively monitored and maintained in public cloud deployments. Failure to monitor for even unintended usage can result in potential license penalties that could dramatically harm your organization. OpsCompass actively monitors the compliance of our customers’ Oracle and Microsoft deployments to watch for license compliance problems as well as potential security vulnerabilities from misconfigurations.
As you can see in the license dashboard from OpsCompass, we are consistently and automatically performing a compliance audit on your Oracle environment and identifying the potential cost of unlicensed software usage.
OpsCompass can help you avoid these, and many more compliance risks. We would love to help evaluate your current risk profile and set up OpsCompass to keep an eye on your public and private cloud environment. Reach out if you would like to chat with us about how we can help you.
