What You Need to Know: Amazon RDS for Oracle -Extended Memory Configurations

tim-van-der-kuip-CPs2X8JYmS8-unsplash (3)

Many House of Brick clients I work with are unaware of the additional memory configurations AWS has introduced for RDS compute instances using the BYOL model, and the huge impact that they can have on optimizing licensing. This is an enormously important piece of information to know, as it can greatly impact licensing Oracle Enterprise Edition in RDS for Oracle. Amazon did its Oracle customers a great favor by creating these additional instance sizes.

Note: To save myself the effort of qualifying each statement as “currently”, assume that all statements regarding AWS offerings and pricing are as of March 2023. AWS keeps adding to their offerings, including these new memory configurations, so that qualifying the statements is necessary! Also, I am referring to offerings and pricing in the US West (Oregon) region.

First, a note about Oracle licensing in The Cloud. The standard Oracle license agreement (which has gone under different names over the years: Software Licenses and Services Agreement (SLSA), Oracle License and Services Agreement (OLSA) and Oracle Master Agreement (OMA)) contains no contractual right to license Oracle core technology products on a vCPU basis, which is how customers usually license those products in either AWS or Azure. That’s worth saying again: the standard Oracle license agreement does not give you any contractual right to license Oracle products on a vCPU basis. Oracle has published an extra-contractual document, colloquially known as Oracle’s Cloud Compute Policy, that is excluded from the contract by the contract’s Entire Agreement clause, but does offer guidelines on how to license Oracle products in two approved cloud environments: AWS and Azure. House of Brick consultants are not lawyers, but outside legal firms have expressed their opinions that while Oracle cannot impose non-contractual restrictions on their customers, they can grant extra-contractual rights/privileges, such as counting vCPUs instead of physical cores. We’ve seen Oracle utilize their Cloud Policy during audits, so it seems safe to trust the document, at least at the present time.

Oracle’s Cloud Compute Policy document grants us the privilege of counting two vCPUs as equivalent to one Oracle Processor license if multi-threading of processor cores is enabled (it is by default in AWS), and one vCPU as equivalent to one Oracle Processor license if multi-threading of processor cores is not enabled.

With that brief intro to Oracle licensing in the cloud, let’s talk about AWS RDS for Oracle. When you configure an RDS instance you choose an instance type and an instance size. AWS RDS for Oracle currently offers 19 different instance types that you can run Oracle on, with each instance type having multiple sizes.

For anyone not fluent with the AWS vocabulary, this additional excerpt from the AWS documentation[1] is offered:

Amazon EC2 provides a wide selection of instance types optimized to fit different use cases. Instance types comprise varying combinations of CPU, memory, storage, and networking capacity and give you the flexibility to choose the appropriate mix of resources for your applications. Each instance type includes one or more instance sizes, allowing you to scale your resources to the requirements of your target workload.

Even though there are 19 different instance types available for RDS for Oracle, House of Brick has often recommended using the r5 family. The r5 instance type, which is part of the Memory Optimized instance family, offers an 8:1 ratio of memory (GiB) to vCPU. Some other instance types offer smaller memory provisioning per vCPU; the M5 instance type, which is part of the General Purpose family, only offers a 4:1 ratio of memory (GiB) to vCPU. Running Oracle databases on r5 instances allows you to provision large amounts of memory without the need to license as many vCPUs as on other instance types.

Let’s take a look at the traditional r5 instance sizes:

As you can see, there is a 8:1 ratio of RAM (GiB) to vCPU.

What if you’ve got a database requiring 12 vCPUs and 192 GiB of RAM? Your compute needs could be solved with a db.r5.4xlarge instance, but to get the necessary memory you’ll need to increase the instance size to db.r5.8xlarge. Because the 8xlarge has twice as many vCPUs as the 4xlarge, you’ve also just doubled your Oracle license liability.

Well, AWS listened to its customers and introduced additional sizes within the r5 instance family. It should be noted that these additional instance sizes are only available for the RDS for Oracle offerings; I didn’t see evidence of them for the other database engines that RDS supports. AWS is aware of Oracle’s apparent penchant for making it more expensive to license Oracle products in AWS than it is for either on-prem or Oracle’s own cloud. Here is a look at the additional extended memory instance sizes that AWS added:

Now it’s possible to obtain up to a 64:1 RAM (GiB) to vCPU ratio! Using these extended memory instances will increase your AWS spend (AWS is actually giving you a larger instance size and disabling the extra vCPUs behind the scenes), but the thing to note is that you can save $$$ by not having to increase your Oracle processor license liability just to get the memory that you require.

From an AWS TCO perspective there aren’t any AWS savings for you, but by having these additional memory configurations it can save customers $$$ by not incurring additional Oracle processor license liability. When you consider that the list price of a single processor license (equivalent to 2 vCPUs) of Oracle Database Enterprise Edition is $47,500, the increased price of your AWS RDS for Oracle instance is negligible.

Talk to an expert to get started. You don’t have to optimize your licenses alone!

[1] https://aws.amazon.com/ec2/instance-types/

Table of Contents

Related Posts