Nick Walter, Principal Architect
Licensing Oracle software products in a public cloud environment has always been an awkward sticking point for enterprises looking to move towards hybrid cloud or public cloud solutions. Oracle software products have traditionally been licensed by metrics tied to physical sockets or processor cores. These are unreasonable metrics to apply to usage in a public cloud such as AWS where only the virtual machine details are visible, and the underlying hardware details are typically not publicized.
To address this issue for some of their customers, Oracle has published a policy called Licensing Oracle Software in the Cloud Computing Environment. This document is subject to change at any time (as was the case most recently on January 23, 2018), but it provides customers with the ability to license their workloads by virtual CPU (vCPU) rather than by the underlying processor cores in the physical server (as defined in Oracle’s license agreements). While licensing by vCPU helps alleviate the incompatible licensing metrics, it can still be a thorny process to optimize instances to the required Oracle licenses. This is largely because public cloud providers, such as AWS, have traditionally not offered instances with the right mix of virtual CPUs and RAM to be attractive for deploying most Oracle workloads. In addition, Oracle’s cloud policy can be confusing to apply because the number of licenses required is different depending on whether Hyper-Threading is enabled or disabled.
Licensing on a Per-vCPU Basis in AWS
House of Brick was delighted by AWS’ recent announcement of the Optimize CPUs for Amazon EC2 Instances feature. This newly unveiled feature is aimed squarely at allowing EC2 users to optimize their software licensing for products such as Oracle, which can be licensed on a per-vCPU basis. With Optimize CPUs, an EC2 user is no longer restricted to only the pre-set mix of vCPU/RAM combinations available in the menu of EC2 instances that AWS typically makes available. With the Optimize CPUs feature, the number of vCPUs and the number of threads per core can be specified at the time of instance creation. Any number, up to the normal amount of vCPUs in an instance, is supported. The change is persistent across instance reboots as well, so it is not something that needs extra monitoring to ensure licensing compliance.
Some Drawbacks Involved
This new feature does have a few drawbacks that users of Oracle on EC2 should be aware of, however. The GUI tools for instance creation in the AWS console do not yet support this feature, so it is only available when creating instances with tools, such as the AWS CLI, which interact directly with the AWS API. For shops with mature Continuous Delivery practices that rely heavily on tools such as Terraform or CloudFormation, this is a minor concern as those tools already interact directly with the AWS API. Shops just getting started with AWS tend to rely more heavily on the GUI console for creating and managing EC2 resources, and as a result may struggle with trying to utilize the Optimize CPUs feature. The Optimize CPUs settings are also reset to default if an instance is migrated to another instance type, so Optimize CPUs settings will need to be specified again during the migration process. However, that is less of a concern since instance migration has always been an event with potential licensing implications, requiring a reevaluation of required licenses for the target instance.
The Optimize CPUs feature does not reduce the cost of the instance in any fashion, so it makes the feature puzzling at first glance to those who are not familiar with the heavy burdens of licensing Oracle (or other enterprise software products) on a per-core basis. While paying AWS the same amount of money for an instance with fewer vCPUs may seem counterintuitive, it makes perfect sense when considering that Oracle Database Enterprise Edition can cost anywhere from $5k – $50k per vCPU annually. The net result is that customers will have a lower total cost of deploying Oracle to the cloud by only licensing the smallest number of vCPU needed for that workload.
The other big drawback to the Optimize CPUs feature is that it is not currently available for Bring-Your-Own-License (BYOL) users of Amazon’s Relational Database Service (RDS). The RDS platform greatly simplifies the administration and operation of databases, and as such is a compelling option for running Oracle workloads in the AWS cloud. While the RDS option does offer a good mix of different instance types, with different vCPU/RAM combinations available, it still does not allow an AWS customer to optimize their Oracle license usage to the same degree that the Optimize CPUs feature does on EC2.
Leverage the Optimize CPUs Feature Today
Given that most Oracle workloads tend to be constrained more by disk I/O or RAM metrics, House of Brick recommends that all shops currently running Oracle on EC2 immediately evaluate leveraging the Optimize CPUs feature. A quick peek at CloudWatch to determine the CPU usage histories of the EC2 instances running Oracle workloads will, in all probability, immediately identify good candidates for vCPU reduction.
House of Brick is keenly aware of the challenges of optimizing the very high costs of licensing and support for Oracle products, and celebrates a feature like Optimize CPUs for Amazon EC2 Instances that allows us to help our clients minimize their Oracle license costs in the cloud.
UPDATE: Amazon expanded their Optimize CPUs feature to RDS on 6/18/18. Read our blog, AWS’ Optimize CPUs Feature Expands to RDS, for details.
