Nick Walter, Principal Architect

Recently I wrote a blog about AWS’ newly unveiled Optimize CPUs for Amazon EC2 Instances feature. While a very welcome feature, it was disappointing that the feature was only initially available for EC2 but not RDS. Considering that RDS is the preferred platform for many shops wanting to leverage the simplified administration and provisioning features of Oracle on RDS, not seeing the Optimize CPUs feature supported for RDS felt like a very conspicuous absence.

However, today AWS proved that they are listening to customers with a feature announcement that addresses almost every drawback I pointed out in my initial article. This announcement brings the Optimize CPUs feature to any Bring Your Own License (BYOL) customers of RDS using Oracle Enterprise Edition, Standard Edition, Standard Edition One, or Standard Edition 2.

In addition to bringing the Optimize CPU feature to RDS, AWS also addressed one of the hurdles to adoption for the initial release: the necessity of using API access to configure the feature. The RDS version of the Optimize CPUs feature is fully configurable through the RDS console GUI.

In terms of the actual details of the feature, nothing has changed since the original announcement. The Optimize CPUs feature for RDS, just as with EC2, allows the reduction of the number of vCPUs assigned to a RDS instance during instance creation. It also allows setting threads per core to 1, effectively disabling hyperthreading. Just as with EC2, this reduction in vCPU power available to a RDS instance can greatly reduce the per-vCPU licensing costs associated with a particular RDS instance, while maximizing the RAM and networking available.

Configure Optimize CPUs for RDS

As the above screenshot demonstrates, configuring Optimize CPUs is very easy when provisioning a RDS Oracle instance through the RDS console GUI. In addition to all the traditional options presented, there are now places to specify the CPU cores available and the threads per core. The former option can be set to any number between 1 and the normal maximum cores available to the instance class being provisioned. The latter option can be set to 1 to disable hyperthreading or to 2 to enable hyperthreading.

Optimze CPUs and Licensing History

Any shop relying on Oracle’s Licensing Oracle Software in the Cloud Computing Environment document should also keep in mind that there is still the possibility of needing to provide proof of usage history in a future Oracle license audit. Traditionally AWS CloudTrail has provided a reliable mechanism to prove usage to Oracle in a later audit, as it provides instance creation/deletion times and instance class information. Prior to the release of the Optimize CPUs feature, that was all the information required to have a history of how many vCPUs were associated with an Oracle workload. The Optimize CPUs feature documentation from AWS does not mention CloudTrail as a method of recording vCPUs allocated however, so it may be necessary for shops using CloudTrail to also leverage AWS Config service to record past system states for licensing compliance purposes. House of Brick always strongly recommends that any shop utilizing Oracle products ensure that they have a documented retention policy that covers all the information sources required to prove usage in the event of an Oracle audit. Therefore, users of the Optimize CPUs feature may need to extend their documented retention policy to cover AWS Config information if it does not already do so.

Conclusion

AWS has demonstrated again how serious they are about making RDS a compelling and customer-friendly platform for any shop that wants to run Oracle databases in a public cloud environment. The Optimize CPUs for Amazon RDS Instances feature is a good step towards providing Oracle shops the maximum flexibility to apply their precious and expensive Oracle licenses in the most efficient way possible. House of Brick has many years of experience in assisting shops with minimizing their Oracle license spend, and one of the strongest tactics is to migrate workloads to the smallest possible CPU count that will support those workloads without performance degradation. Thanks to AWS, this is now a much easier tactic to apply to RDS environments as well.