Oracle new public Cloud licensing policy – good or bad?

Posted in: Cloud, Technical Track

A little while ago after a question from a customer about supporting Oracle products on the Google Cloud Platform (GCP) I decided to take a look for any updates to the Oracle public cloud support policies. The document can be easily found on the Oracle website. I quickly noticed some significant changes in the new version of the document. More specifically, I’m referring to the changes that came with the latest version of that document dated January 23, 2017.

In this blog I will attempt to summarize the findings and my thoughts about the matter. Before proceeding any further, let’s begin with a safe harbor notice (as Oracle does) and mention that I do not work for Oracle and I am not a licensing expert. Some of my observations may be incorrect and everyone reading this post is strongly encouraged to make a fully informed decision only after consultation with an Oracle sales representative. After reading the Oracle licensing policy, you should bear in mind that the document provides only guidelines and it is published for “education purposes only”.

So, what do we have in the new edition? The document shares details about the Oracle licensing policy on public cloud environments including AWS EC2, AWS RDS and Microsoft Azure platforms. Alas, still no mention of Google Cloud Platform (GCP). It leaves GCP out of charted territory and even though it doesn’t explicitly prohibit you from moving your Oracle products to GCP, it makes it difficult to estimate the impact and cost.

The first paragraph has a link to listing of all Oracle products where the policy applies. Notably, the document explicitly lists almost all Oracle Database Enterprise Edition options and packs except Oracle RAC and Multitenant. If the absence of Oracle RAC may have some technical justifications, then the exclusion of the Multitenant option doesn’t make too much sense for me.

The next paragraph reveals a lot of changes. The new version of the document officially recognizes AWS vCPU as a thread, not as a core. Prior to January 23 2017, we used to have an AWS published document showing vCores by instance type for licensing calculations, and it was widely-used even though it was never officially provided by Oracle. People used number of cores from the document and applied the Oracle multi-core factor table on top of the cores count. There was never a similar document for Azure consequently considered a vCPU as a vCore and the same calculation using the multi-core factor table. The new version of the Oracle document now states explicitly that the two vCPU on AWS have the same licensing cost as one vCPU on Azure.

It’s explicitly stated in the document that either two vCPU from AWS or one vCPU from Azure are equivalent to one Oracle CPU license. Another statement confirms that from now on, the Oracle multi-core factor no longer applies for the mentioned public cloud environments. This can be a serious impact to people migrating or planning to migrate to AWS or Azure using Bring Your Own License (BYOL) policy. They may now find themselves in a difficult position. Either you plan your migration to a smaller environment or increase your licensing cost. In this case, it’s important to keep in mind that the size of AWS EC2 instance may have direct impact not only to CPU power but to maximum available I/O on the storage layer.

Additionally, there is now a section containing formally defined rules for Oracle Database Standard Edition and Standard Edition 2. According to the paper, we count every four vCPUs on AWS or two vCPUs on Azure as one socket. This means that you cannot have more than 8 AWS vCPUs for a Standard Edition 2 (SE2) license. Standard Edition (SE) allows you to have a 16 vCPU machine, and hence still provides more opportunities when sizing EC2 or RDS . Unfortunately, the SE is only available up to version and support for that release is coming to an end. So what can still be used for an Oracle SE2 on AWS? We can get one of the *.2xlarge instances on EC2 or pick up a similarly sized RDS instance. Is that going to be big enough? That depends on your workload profile, but again, keep in mind IO limitations per instance type. It is going to be a maximum of 8000 IOPS per the instance. Not a small number, but you will need to measure and identify your IO requirements before going to the cloud.

On one hand, the new policies are way more clear and direct than they used to be and I believe that the clarification is good. It is always easier to plan your implementations and budget when you are confident of what to expect. On the other hand, it looks like we have to pay twice as much in licensing fees when moving to AWS or Azure when compared with any bare metal or OVM environment on premises. Will it make Oracle products more attractive for customers? I have some doubts that it will. Will it make the Oracle Cloud a more interesting target platform for cloud migrations? Possibly. That is likely the main goal of Oracle but we’ve yet to see if it works out for them as expected. I liked it when Oracle made Oracle Express Edition (XE) available for everyone for free and when Oracle Standard Edition came with the RAC option at no additional costs. While I don’t have any official numbers, I think that the Express Edition and RAC included with SE turned many customers onto Oracle products. However, I’m afraid that the new licensing policy for cloud may do the opposite and turn some people away from Oracle and consequently play out really badly for Oracle in the long term.



Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

Regarded by his peers as an Oracle guru, Gleb is known for being able to resolve any problem related to Oracle. He loves the satisfaction of troubleshooting, and his colleagues even say that seeking Gleb’s advice regarding an issue is more efficient than looking it up. Gleb enjoys the variety of challenges he faces while working at Pythian, rather than working on the same thing every day. His areas of speciality include Oracle RAC, Exadata, RMAN, SQL tuning, high availability, storage, performance tuning, and many more. When he’s not working, running, or cycling, Gleb can be found reading.

5 Comments. Leave new

Great post. Agreed that it is quite odd how Oracle has changed pricing models with AWS and appears to be dragging their feet on certifying GCP.

What I find more problematic is trying to figure out the end-game here. The changes to the Oracle development lifecycle places most on-prem customers in a near-continuous patch cycle (especially true with FMW products) and then you look at Oracle Cloud and find things like this ( that make you wonder is Oracle Cloud really ready for prime time.

It will be interesting to see how this plays out.


Yes, that is true and for some services and regions I have seen some interruptions and sometimes for prolonged period of time. I still have hope that it is temporary issues related to growth and relatively young age of the Oracle Cloud.


Thank you for this post.

Robin Chatterjee
March 15, 2017 11:50 pm

SInce Oracle cloud is not mentioned in the documetn does the core factor still apply to Oracles own cloud ?

Gleb Otochkin
March 20, 2017 8:34 am

Hi Robin,
I am not an Oracle representative and cannot speak on behalf of Oracle. You can potentially use BYOL policy on Oracle IaaS or Bare metal services as far as I know. An Oracle OCPU is defined as on physical core with two threads for a x86x64 platform and I don’t see any statement that the core factor is not working there. So, we can presume that it is still applied but I would ask Oracle representatives directly about it.



Leave a Reply

Your email address will not be published. Required fields are marked *