Migrating to AWS is has become the norm for many Oracle clients and bringing your own licensing (BYOL) has a great appeal. While the appeal is there, clients need to be aware that there is no silver bullet for Oracle Licensing!
To try to ease the minds of their potential clients, Amazon now provides an “easy to use” Software Asset Management (SAM) tool for monitoring your deployment to the cloud. As great as software asset management tools are, they can only do what they are told to by the business logic embedded in that tool. If you are not aware of the limitations of this (or any other) SAM tool, then there is still some risk as you manage or report your license usage. Oracle is very clear about who owns the responsibility of making sure licensing is correct and if your licenses are out of compliance, it is YOUR responsibility to pay for it no matter what the tool says. Ever heard the term “garbage in – garbage out”?
The real issue is that AWS wants your business and they do not provide the expertise to help you understand your licensing and all the rules surrounding an Oracle license deployment – and they don’t want to. They want you to know what your licensing is and manage it yourself by simply assigning licenses to the number of vCPU’s assigned based on your total licenses owned. Do not take this to trust that your licensing is correct during your use or that you are ok not to review your license entitlements reviewed periodically. Amazon has a caveat in their documentation that squarely puts the ownership on the client!
Example from AWS’ documentation:
If a client moved a portion of their footprint to AWS and the non-production environment was built to match production exactly, which did not consider the number of licenses that were actually owned there could present a compliance issue. In addition, when the non-production instance was created from a copy of production, it contained all the users and options used in production – which could create a perspective that you need those licenses or to count those users! Database options that are not in use in non-production can be turned off or removed if necessary, to complete compliance remediation. With this particular client use case, there was evidence of use on non-production because it was a copy of production! If that wasn’t enough, when they ran the data pump export, they did not explicitly say NO COMPRESSION which Oracle LMS declares as Advanced Compression use. Even though the client thought everything was ok, they ended up with an audit finding.
Cloud Migrations present opportunities for clients to make proactive changes in their licensing in order to save themselves thousands (or millions, even)! How would AWS’s tooling know the ins and outs of Oracle licensing? For many clients the tool only knows what you tell it so how would the tool know what your user minimums are or if you have special language in your agreements such as the original ordering document? What if you have different metrics for the same product depending on how it is being used? Hopefully, you can see the dilemma and mess this creates! Oracle licensing is complex, and they know it!
Before you rely on the AWS tool to determine your compliance, have your environment and licensing reviewed with a deep dive. This way you avoid the unpleasantness of a surprise during an audit or misuse that is frequently based on false assumptions.
-Evan Boyd, Vice President of Business Development
