AWS Management & Governance Blog

Use AWS License Manager API operations to manage your Oracle licenses based on Oracle cloud policy

The simplified Bring Your Own License (BYOL) experience in AWS License Manager allows you to effectively manage your own software licenses in AWS. These licenses can be used with Amazon Elastic Compute Cloud (Amazon EC2) shared tenancy, EC2 Dedicated Hosts, Amazon RDS, AWS Marketplace, or in an on-premises environment. License Manager helps you manage your software licenses, including Microsoft Windows Server and Microsoft SQL Server licenses. License administrators can automate license management by building custom dashboards and track licenses centrally using License Manager API operations.

In this blog post, I show you how to count Oracle Processor licenses based on Oracle cloud policy.

Prerequisites

  • AWS CLI configured to access the appropriate AWS account.
  • Oracle Enterprise Edition on Amazon RDS.
  • Oracle databases on Amazon EC2 instances that are managed by AWS Systems Manager.

Solution walkthrough

I walk you through the following scenarios:

  • Scenario 1: Using License Manager API operations to manage Oracle licenses for databases running on Amazon RDS for Oracle.
  • Scenario 2: Using License Manager API operations to manage BYOL Oracle licenses for databases running on Amazon EC2 or on-premises servers.
  • Scenario 3: Using the built-in integration of License Manager API operations with AWS CloudTrail to prepare for vendor audit.

Scenario 1: Using License Manager API operations to manage Oracle licenses for databases running on Amazon RDS for Oracle

Step 1: Create a license configuration

First, use the create-license-configuration API operation to create a license configuration to track the number of Oracle licenses you own for databases running on Amazon RDS for Oracle. For information about the supported product types for Oracle database running on Amazon RDS, check create-license-configuration in the AWS CLI Command Reference.

You can use the License Manager dashboard to manage Oracle licenses for databases running on Amazon RDS across AWS accounts. You create licensing rules in the management account, attach them to resources in member accounts, and track license usage across AWS accounts.

In this scenario, I will track licenses used by Oracle databases running Enterprise Edition (EE) on Amazon RDS. The following CLI command creates a license configuration.

$ aws license-manager create-license-configuration \
--name license-configuration-oracle-licenses \
--description 'This license configuration tracks the consumption of licenses by Oracle database running Enterprise Edition in Amazon RDS' \
--license-counting-type vCPU \
--license-count 100 \
--product-information-list file://product_information.json

Here are the contents of product_information.json:

[{
 "ResourceType": "RDS",
 "ProductInformationFilterList": [{
 "ProductInformationFilterName": "Engine Edition",
 "ProductInformationFilterValue": ["oracle-ee"],
 "ProductInformationFilterComparator": "EQUALS"}]
}]

Step 2: Set up Oracle Enterprise Edition

For this scenario, I created an Oracle DB instance and then connected to a database. I set up Oracle EE running on Amazon RDS on t3.2xlarge, which has 8 vCPUs and 32 GiB of RAM. This instance type is not included in the AWS Free Tier — if you use it you will incur charges.

On an ongoing basis, License Manager discovers the resources used in your environment. The discovery of these resources is not immediate. It might take few minutes. After this resource usage update, License Manager reports the licenses used.

The following CLI command lists all license usage records for a license configuration, displaying license consumption details by resource at a selected point in time. For more information, see list-usage-for-license-configuration in the AWS CLI Command Reference.

$ aws license-manager list-usage-for-license-configuration \
--license-configuration-arn arn:aws:license-manager:us-east-1: 90XXXXXXXX30:license-configuration:lic-fcbbeb595520252c0534588af763e511 

The list-usage-for-license-configuration command returns the ARN, resource type (RDS), resource status (unavailable), resource owner ID, association time, and consumed licenses (8).

Figure 1: AWS CLI command for license configuration

Step 3: Get the vCPU count

To determine the Oracle license usage, I need to know the vCPU count for Oracle databases running EE on Amazon RDS. I run the AWS CLI get-license-configuration command and filter the ConsumedLicenses value that translates to the vCPU count. For more information, see get-license-configuration in the AWS CLI Command Reference.

aws license-manager get-license-configuration \
--license-configuration-arn arn:aws:license-manager:us-east-1: 90XXXXXXXX30:license-configuration:lic-fcbbeb595520252c0534588af763e511 | jq '.ConsumedLicenses'

Typically, Processor Oracle license metric is used for production and Named User Plus (NUP) Oracle license metric is for non-production.

Per Licensing Oracle Software in the Cloud Computing Environment official Oracle documentation, every two consumed licenses equals to one Oracle Processor license, if hyper-threading is enabled. One consumed license is one Oracle Processor license, if hyper-threading is not enabled. Although License Manager does not count NUP rules, NUP licensing still applies, including counting the minimums where applicable.

NUP usage is calculated by [(Number of Oracle Processor licenses, depending on if hyper-threading is enabled)] x 25, where 25 is the minimum NUP per Processor for Oracle EE. Oracle EE and Standard Edition 2 (SE2) are the only two databases that can be licensed using the NUP metric or the Processor metric. For information about hyper-threading support, see Introducing Optimize CPUs for Amazon RDS for Oracle.

For example, consider the get-license-configuration CLI command yields a ConsumedLicenses value of 8. Because hyper-threading is enabled by default on Amazon RDS for Oracle instance types, I infer four Oracle Processor licenses are in use and a minimum of 100 NUP. If hyper-threading is not enabled on the Amazon RDS for Oracle instance type, it is equivalent to 8 Oracle Processor licenses in use and a minimum of 200 NUP.

The following table shows Oracle license metrics based on consumed vCPUs and with hyper-threading enabled on an Oracle database running EE on Amazon RDS.

Setup 1 (Oracle database running EE on Amazon RDS with hyper-threading enabled)
ConsumedLicenses 8
Hyper-threading Enabled
Oracle Processor license 4 ← Because hyper-threading is enabled, every two consumed licenses = 1 Oracle Processor license
NUP minimum of 100 ← NUP usage = 4 x 25

The following table shows Oracle license metrics based on consumed vCPUs and with hyper-threading not enabled on an Oracle database running EE on Amazon RDS.

Setup 2 (Oracle database running EE on Amazon RDS with hyper-threading disabled)
ConsumedLicenses 8
Hyper-threading Not enabled
Oracle Processor license 8 ← Because hyper-threading is not enabled, every one consumed license = 1 Oracle Processor license
NUP minimum of 200 ← NUP usage = 8 x 25

Because Oracle database Standard Editions (SE) are based on the number of occupied sockets, the approach to counting usage is somewhat different. Oracle has defined maximum instance sizes permitted to run on SE editions. SE can have a maximum of 16 vCPUs. SE 1 and SE 2 can have maximum of 8 vCPU. An Oracle Processor license is counted as 4 vCPUs or fewer. Each 4 vCPU or fewer = 1 Oracle Processor license, up to the maximum number of vCPUs permitted. If you are licensing SE 2 by the NUP metric, the minimums are 10 NUP licenses per 8 Amazon vCPUs.

The following table shows Oracle license metrics based on consumed vCPUs for an Oracle database running SE 2 on Amazon RDS.

Setup 3 (Oracle database running SE 2 on Amazon RDS)
ConsumedLicenses 8
Hyper-threading Not applicable
Oracle Processor license 2 ← Each 4 vCPU or fewer = 1 Oracle Processor license, up to the maximum number of vCPUs permitted
NUP minimum of 10 ← If licensing SE 2 by the NUP metric, the minimums are 10 NUP licenses per 8 Amazon vCPUs

Let’s assume the get-license-configuration CLI snippet yields a ConsumedLicenses value of 6 for Oracle databases running one of the SE editions on Amazon RDS. In that case, there would be two Oracle Processor licenses in use. If the ConsumedLicenses value had been more than 8 and less than or equal to 12, then there would be 3 Oracle Processor licenses in use.

Scenario 2: Using License Manager API operations to manage BYOL Oracle licenses for databases running on Amazon EC2 or on-premises servers

For this scenario, I have BYOL Oracle licenses for databases running on Amazon EC2 instances that are managed by AWS Systems Manager.

To use AWS Systems Manager to track BYOL Oracle licenses running on your EC2 instances or on-premises VMs, see Setting up AWS Systems Manager, Setting up Systems Manager for hybrid environments, and Installing SSM Agent on an instance. After all the instances are managed by Systems Manager, associate the previously defined license configuration to the discovered instances so License Manager can track the license usage.

Use the update-license-specifications-for-resource API operation to associate the license configuration to the EC2 instance. Replace the resource name in --resource-arn with the ARN of the EC2 instance. For more information, see update-license-specifications-for-resource in the AWS CLI Command Reference.

aws license-manager update-license-specifications-for-resource \
--resource-arn arn:aws:ec2:us-east-1:90XXXXXXXX30:instance/i-07XXXXXXXXXXXXXc1 \
--add-license-specifications LicenseConfigurationArn=arn:aws:license-manager:us-east-1:90XXXXXXXX30:license-configuration:lic-fcbbeb595520252c0534588af763e511

Follow the instructions in Step 3 of scenario 1 to track the Oracle database licenses used on EC2 instances or on-premises servers.

Scenario 3: Use the built-in integration of AWS License Manager API operations with AWS CloudTrail to prepare for a vendor audit

In this scenario, I’ll show you how to prepare for Oracle license audits with the License Manager API and its integration with CloudTrail.

You can use the CloudTrail console to view the last 90 days of recorded API activity (management events) in an AWS Region. For information on creating a trail so that you have a record of events that extends past 90 days, see Creating a trail and Getting and Viewing Your CloudTrail Log Files.

Step 1: Get and store events for a license configuration

If you have a vendor audit of the license usage, search for the GetLicenseConfiguration event in CloudTrail for the requested timestamp. Locate the license configuration in the available events, select the event of the requested timestamp, and store the output to a file. The lookup-events AWS CLI command looks up CloudTrail management events for the specified attributes and lists the license configuration of interest.

aws cloudtrail lookup-events --lookup-attributes --output text  AttributeKey=EventName,AttributeValue=GetLicenseConfiguration --start-time "04/06/2021, 19:41" --end-time "04/06/2021, 19:44" --query 'Events[*].CloudTrailEvent' | jq 'select(.requestParameters.licenseConfigurationArn=="arn:aws:license-manager:us-east-1:90XXXXXXXX30:license-configuration:lic-fcbbeb595520252c0534588af763e511")'

Output for lookup-events includes licenseConfigurationArn, resourceType (rds), consumedLicenses (8), productInformationList, and more.

Figure 2: AWS CLI command for a 3-minute window

Step 2: Search for ConsumedLicenses keys

Search for ConsumedLicenses keys in the file and sum their values. Depending on the Oracle database edition, use the information in Step 3 of scenario 1 to compute Oracle Processor (and maybe NUP) license usage for the requested timestamp. The managedResourceSummaryList in the response of step 1 provides the summary of the managed resources at the time.

Cleanup

To avoid incurring charges in your AWS account for the resources provisioned in these scenarios, complete the following steps from the AWS CLI:

  1. Delete the Amazon RDS database instance used in scenario 1. For information, see delete-db-instance in the AWS CLI Command Reference.
aws rds delete-db-instance --db-instance-identifier <value> --region <value>
  1. Delete the EC2 instance launched in scenario 2. For information, see terminate-instances in the AWS CLI Command Reference.
aws ec2 terminate-instances --instance-ids <value> --region <value>
  1. Delete the AWS License Manager configuration rules. Use the delete-license-configuration command to delete the license configuration. You must disassociate all resources from the license configuration before you can delete it. For information, see delete-license-configuration in the AWS CLI Command Reference.
aws license-manager delete-license-configuration --license-configuration-arn "arn:aws:license-manager:us-east-1:90XXXXXXXX30:license-configuration:lic-fcbbeb595520252c0534588af763e511"

There is no additional charge for AWS License Manager. You pay for AWS resources (for example, EC2 instances) that you create to run your application. For more information, see AWS License Manager Pricing.

Conclusion

In this post, I showed how you can easily manage Oracle licenses on Amazon RDS, EC2 instances and on-premises servers with License Manager API operations. I also showed you how to prepare for vendor audits using the built-in integration between License Manager and CloudTrail.

You can use AWS License Manager to manage software licenses from other software vendors such as Microsoft, SAP, and IBM across AWS and on-premises environments.

Although I shared instructions for a single account, you can track software usage across multiple AWS accounts using AWS License Manager. I encourage you to use what you have learned here to reduce the effort of managing licenses across your organization. You might start by using AWS License Manager in a small part of the organization to demonstrate a proof of concept to your peers.

For more information, see the AWS License Manager AWS CLI Reference. If you have questions about other Oracle deployment options on AWS, contact our AWS Partner, House of Brick Technologies, for assistance.

About the author

Shree Chinnasamy

Shree Chinnasamy

Shree Chinnasamy is a Technical Account Manager who is focused on driving operational excellence for his customers. An avid reader and a marathon finisher, Shree is based in Washington state in the Pacific Northwest.