A driving factor for companies to migrate to Amazon Web Services (AWS) from on-premises, commercial databases is to reduce infrastructure and software licenses costs. When assessing the viability of migrating Oracle databases to AWS, organizations consider many factors including business requirements, security posture, high availability, performance, disaster recovery, migration duration, cost optimization, and license optimization.

In this post, we will explore Oracle database licensing considerations before starting a migration to AWS. We’ll describe the licensing nuances and outline typical challenges with Oracle licensing when migrating Oracle databases to AWS.

House of Brick is an AWS Advanced Tier Services Partner and AWS Marketplace Seller with the Oracle Consulting Competency that helps customers optimize vendor license spend and ensure compliance.

In this post, We have illustrated multiple scenarios with examples. This post will help data center leaders, enterprise architects, and systems/database administrators understand their licensing options when migrating their Oracle databases to AWS.

Primer for Oracle Licensing on AWS

House of Brick has published information about licensing on AWS.  See the following post for detailed information.  This paper is not a treatise on Oracle licensing principles but rather an effort to explain the  intricacies with licensing Oracle core technologies in an authorized public cloud like AWS.

Bring Your Own License (BYOL)

You can bring your existing license entitlements with you on your journey to AWS.  The big difference between licensing Oracle in an on-premises environment versus in AWS is Oracle’s Cloud Licensing Policy.  This policy document outlines how to license AWS instances by the vCPU versus traditional core-based licensing. The general rules for Oracle licensing are governed by your master agreement and ordering documents when bringing your own entitlements into AWS, but the Cloud Policy provides an additional way of counting deployments in a public cloud.  The key points in Oracle’s cloud policy are:

• The core factor table does not apply with Oracle’s cloud licensing policy; The Oracle core factor table describes how many licenses you need for your on-premises hardware, for example the core factor for x86 is 0.5
• Two vCPUs are counted as one Oracle processor license with multi-threading enabled
• One vCPU is counted as one Oracle processor license with multi-threading disabled
• Oracle lists the programs that are available through the cloud policy
• For Standard Editions, four or fewer vCPUs are counted as one socket license
  • For instances with greater than four vCPUs, count one socket license in increments of four, rounding up to the nearest four
  • A maximum of 16 vCPUs are allowed for Standard Edition
  • A maximum of 8 VCPUs are allowed for Standard Editions 1 and 2
  • For Standard Edition 2 Named User Plus (NUP) licenses, 10 NUP minimums per 8 vCPUs are required when using Oracle cloud policy

As you can see, the Cloud Policy is restrictive and provides one physical core as two vCPUs in AWS which equates to two hyperthreads. Whereas the Oracle Core Factor Table requires one Oracle processor license for every two physical cores, or four hyperthreads when applying to X86-based processors.

Of course, you can still license your Oracle workloads using traditional core-based licensing constructs in AWS.  This would allow for the use of the Core Factor Table.  This would require the use of AWS Dedicated Hosts or Bare Metal Servers and then provisioning your AWS instances on these dedicated physical servers.  As long as you can name your AWS physical host, you can use traditional core-based licensing.

Amazon Relational Database Service (RDS) License Included

AWS has a fully managed Database As A Service (DBaaS) option Amazon RDS for Oracle that includes the licensing for the instance as part of the overall cost.  This database service provides many benefits beyond just including the license.

• Provision Oracle databases with a few clicks of a mouse or through the AWS CLI
• Built-in and automated disaster recovery capabilities with Amazon RDS Multi-AZ
• Automated patching
• Reduced overall operational support of your databases
• Automated scalability features
• Automated orchestration with Amazon CloudFormation
• All of the goodness of running on a hyperscaler platform

RDS Oracle License Included comes with many great features, but is only available for Standard Edition 2.

If you are running Oracle Enterprise Edition and cannot migrate to Standard Edition, then RDS for Oracle is still an option.  You will just need to provide your own licenses for RDS when running Oracle Enterprise Edition. 

House of Brick has helped many customers migrate from Enterprise Edition to Standard Edition.  If you want to get out of the business of managing your Oracle licenses and still need to run Oracle databases, Amazon RDS for Oracle License Included is a great option.

Figure 1 – Oracle licensing options on AWS. Contact your AWS representative about the Optimized License Assessment (OLA) to understand Oracle licensing on AWS. This complimentary program empowers both new and existing customers to assess and optimize their on-premises and cloud environments, reduce required instances, and enhance resource efficiency.

Amazon Multi-AZ and Cross-Region Replicas

Amazon RDS for Oracle has a feature called Multi-AZ that will keep your Oracle database in sync across multiple Availability Zones in an AWS Region.  Multi-AZ is an option when setting up an Amazon RDS for Oracle database.  If this option is selected, then a second database is kept in sync for availability/redundancy  purposes.  In the event of a failure, access to the database is automatically switched to the Multi-AZ copy of the database.  This provides seamless Disaster Recovery(DR) for the database.  Keep in mind that the Multi-AZ option has licensing implications.  Since there is a second copy of the database running and being replicated, this second copy requires an Oracle license.  If RDS is using BYOL licensing, then you need to account for the Multi-AZ database in your licensing calculations.  For every RDS Multi-AZ instance you would need to double the vCPUs when counting your licenses.

The same holds true for Cross-Region replicas in AWS.  In this scenario, all replicas must be licensed as there is an active database that is being kept up to date with data replication.

When using Cross-Region automated backups, the backup copy does not require licensing.  In this scenario a snapshot is replicated to a different Region.  Since these backups cannot be accessed, they do not require a license.  Only when the backup is activated do they require a license.

Multitenant Database

It is possible to configure pluggable databases on AWS.  There are two ways to do this:

• Configure multitenant databases on EC2
• Use the multitenant feature with Amazon RDS Custom for Oracle or standard RDS for Oracle. Amazon Relational Database Service (Amazon RDS) Custom is a managed database service for legacy, custom, and packaged applications that require access to the underlying OS and DB environment.

Customers can configure multitenant with RDS Oracle license included. If you are hosting more than three pluggable databases in a container database, then the Multitenant option must be licensed in addition to Database Enterprise Edition. This is the same for cloud instances as well as on-premises.

Oracle One-Year Term License

There are many ways to manage your licenses during a migration to maintain compliance.  By doing things like reducing your on-premises footprint and properly decommissioning workloads during a migration, you can manage your compliance posture as part of the migration effort.  However, if there is a need for additional licenses to fill a short-term gap during the migration, purchase of one-year term licenses is possible.  See the following blog by House of Brick for a detailed explanation.

Disaster Recovery to AWS

As part of your journey to the cloud, the topic of DR may come up.  Any DR environments that have Oracle software installed and/or running must be fully licensed as per your agreements with Oracle.  There are situations where your DR environments do not need to be licenses.

The Oracle contract contains a backup testing clause.  The clause specifies that offsite backups can be tested four times per year with a maximum of  calendar days per test.  The clause also states that the Oracle binaries cannot be replicated from the source as part of the test.  With this in mind, a comprehensive DR strategy needs to be in place that takes into consideration all license compliance concerns. GoldenGate is another data replication tool that is used for Extract ,Transform and load(ETL), database migrations, and DR. GoldenGate is a separately licensed feature for Oracle, which means it must be licensed for each database where it is in use.  GoldenGate must be licensed on the source and target databases using the same metrics as the databases.  For database migrations, GoldenGate licenses can be purchased as a 1-year term license if GoldenGate will not be used beyond the migration period. 1-year term licenses are 20% of a perpetual license cost and terminate one year from the date of purchase, You must still pay for support at the normal rate, but the cost of the license is much cheaper.

Traditional Data Guard implementations must be fully licensed for Database Enterprise Edition on both the source and target sides.  Since there is Oracle software installed on all Data Guard nodes, all nodes must be licenses.

Oracle Licensing and Containerization

The topic of containers comes up occasionally when discussing licensing.  Whether or not containers make sense for Oracle database is a topic for a different discussion.  However, if you are using containers with Oracle databases then you must pay attention to licensing. For example, if you have an EC2 instance with containerization and there is a container that has Oracle software installed, then the EC2 instance will need to be licensed.  The standard licensing rules hold true for containers, if Oracle software is installed then a license is required.

Oracle to AWS Migrations

Customers frequently have inquiries regarding particular components of a migration, such as Oracle licensing in the cloud, which come up during preliminary conversations about the migration.

Let’s review the different licensing options for a customer in AWS.

Comparative License Model Between On-Premises, EC2, and RDS

Let’s look at what happens when a customer asks for a comparative chart of on-premises Oracle licenses vs. Amazon EC2 and Amazon RDS for Oracle licenses, which can assist them in fast-tracking license inventory maintenance while they are migrating to AWS.

As stated earlier, there are two ways to count license deployments on AWS—using Oracle’s public cloud policy and by using traditional core-based licensing with Oracle’s core factor. Beyond that, there are different ways to deploy Oracle on AWS that have licensing implications.

For example, Amazon RDS for Oracle Bring Your Own License (BYOL) vs. Amazon EC2 in a shared tenancy model. Customers can use a bare metal instance to run their applications directly on a physical server, as opposed to in a virtual machine (VM). As a result, the customer has more leeway and freedom to tailor their environment to specific requirements with direct access to the physical layer.

A dedicated host, on the other hand, is a physical server that’s exclusively used to host one particular customer’s virtual machines. This gives the customer the freedom to define their own VMs(EC2) based on their requirements and scale as necessary.

House of Brick illustrates these differences with the following examples:

Current On-Premises Deployment

For on-premises workloads, we count physical cores and apply the Oracle core factor to arrive at the number of licenses required. In this example, we’re using Oracle Enterprise Edition Processor licenses not Named User Plus. This method uses traditional core-based licensing for Oracle that is outlined in your contract.

Amazon RDS for Oracle BYOL

With RDS BYOL, the only option for counting Oracle licenses is using Oracle’s Cloud Licensing Policy. This states that for Amazon RDS, two AWS vCPUs are equal to one Oracle license. If we determine that we need the same number of physical cores in AWS as we have on-premises, then the licensing breakout is as follows.

Amazon EC2

Amazon EC2 differs from Amazon RDS for Oracle when it comes to Oracle licenses in that you can use either Oracle’s Cloud Licensing Policy or traditional core-based licensing with dedicated hardware.

* r7iz dedicated hosts contain 64 cores, so assuming at least 160 cores are needed we have to deploy 3 r7iz dedicated hosts with a total of 192 licenses.

This table exemplifies the advantage of using traditional core-based licensing with the core factor from your Oracle contract vs. using Oracle’s Cloud Licensing Policy.

Amazon RDS for Oracle License Included

Amazon RDS for Oracle License Included is an attractive option for customers because it removes the licensing complication from their Oracle workloads. The Oracle licensing is included in the price of the Amazon RDS for Oracle instance, but there are two restrictions with the RDS License Included that need to be followed:

• Amazon RDS for Oracle License Included is restricted to Standard Editions 2.
• AWS Service Terms do not allow for hosting services to third-party businesses with Amazon RDS for Oracle License Included, see section 10.3.1.

If these conditions can be met, Amazon RDS for Oracle License Included should be considered. Even if all your databases don’t meet the criteria, any databases that can be migrated to RDS License Included will reduce the overall Oracle licensing liability.

The following table illustrates the above scenario, assuming 50% of the databases are moved to Amazon RDS License Included and the other 50% run on RDS BYOL.

Oracle Compliance Monitoring

It’s critical to understand what Oracle licenses are owned (entitlements) and which Oracle licenses are deployed in your environment. This sounds easy and straightforward, but in reality, is a lot more complicated than expected. Some examples of this complexity are:

• Separately licensable Oracle features like Partitioning, Diagnostics, and Tuning Packs, etc.
• Different use restrictions on different licenses, full use vs. limited use, application specific full use, and proprietary hosting agreements.
• Different licensing rules for AWS deployments vs. on-premises deployments.
• Unlimited/Perpetual/Enterprise agreements and the subsequent exit of such agreements.
• Active Data Guard requires a license whereas Data Guard comes with Enterprise Edition
• Use of the Multi-Tenant option to stack pluggable databases on AWS instances.

All of the deployments associated with these licenses need to be kept track of in their respective licensing bucket. In other words, the deployments need to be assigned to the correct type of license in use. This all gets very complicated when a client is governed by different licensing restrictions. Additionally, all Oracle features are unlocked and available for use without any additional action. If these options are turned on then a licensing liability is incurred.  For example, if a DBA decides to perform a Data Pump extract with COMPRESS=ALL, this triggers the use of the Advanced Compression Option (ACO).  This will happen with no indication that a license is needed for ACO.  This is true for most Oracle features and packs.  This is the place where our clients get into the biggest licensing trouble.  It is paramount to monitor feature use for all of your databases to ensure that only licensed options and packs are used.

Oracle keeps track of feature use in metadata in each database. Each time a feature is used, that use is stored in the database and can be accessed via the “DBA_FEATURE_USAGE_STATISTICS” view. To collect licensing information about your deployments, this feature use data must be collected from each database.

Data gathering for license deployments:

Database

• Enterprise Edition (EE) or Standard Edition (SE)
• Version of the database
• Database features in use
  • From/to dates of the features in use
  • Number of times the features were used
• Database entitlements
  • Products and quantities
  • Edition of the licenses, SE or EE
  • License metric, Processor or NUP
  • Use restrictions, full use vs. limited use.

Infrastructure

Since traditional Oracle licensing is governed by the number of processors where the licenses are installed and/or running, it’s essential to understand the number of physical cores where the programs are installed. Also, if the programs are installed in AWS, it’s important to know the cloud infrastructure details.

• Physical host
  • Populated sockets
  • Processor model
  • Core count
• Cloud deployments
  • Amazon EC2 or RDS
  • If RDS, only BYOL is counted, License Included is not counted towards client owned licenses
  • AWS instance type
  • Is hyperthreading enabled?
  • Optimize CPU settings

According to Oracle’s Licensing Policy, customers can’t use Optimize CPU to reduce licensing liability, but it’s important to keep track of that information. To count the licenses in use in AWS, customers need to sum the total number of vCPUs deployed based on the maximum size of the AWS instance.

Conclusion

AWS supports several deployment methods for Oracle database workloads such as Amazon RDS for Oracle, Amazon RDS Custom for Oracle and Amazon EC2.

In this post, we demonstrated techniques to evaluate licenses without exceeding your entitlement. We also covered the licensing-specific discovery mechanism needed before beginning a migration.

If you still have questions, reach out to House of Brick, we can help.