What BYOL Means in the AWS Context
Bring Your Own Licence (BYOL) on AWS means you supply existing Oracle Database licences that you have purchased directly from Oracle, rather than consuming licences embedded in the AWS service price. In exchange for bringing your own licences, AWS charges a reduced hourly rate for the underlying compute instance, because the licence component is excluded from the AWS billing.
For Oracle Database, BYOL is supported on Amazon RDS for Oracle and on Amazon EC2 instances. The two deployment models have different licensing mechanics, different compliance obligations, and different cost structures that must be understood before committing to either.
BYOL is not a workaround for Oracle licensing. It is a recognised Oracle policy that allows customers to deploy software they have already purchased in designated authorised cloud environments. AWS is an Oracle-authorised cloud environment, meaning you may deploy Oracle Database software under a valid licence without purchasing a separate cloud-specific licence from Oracle. However, Oracle's cloud licensing policy still dictates how licences are counted in that environment.
Oracle's Cloud Licensing Policy for AWS
Oracle publishes a document titled "Licensing Oracle Software in the Cloud Computing Environment" which defines the counting rules for authorised cloud environments including AWS. For AWS specifically, the governing rule is that each AWS vCPU is counted as half an Oracle Processor licence when hyper-threading is enabled, which is the default on all standard EC2 instance types. This means that two AWS vCPUs equal one Oracle Processor licence.
If hyper-threading is disabled, each vCPU counts as one full Oracle Processor licence. Since disabling hyper-threading on EC2 requires a specific instance launch configuration and results in reduced instance performance, the standard practice is to leave hyper-threading enabled and apply the two-to-one ratio.
Applying the Counting Rule in Practice
Consider an EC2 db.r6i.8xlarge instance with 32 vCPUs. Under Oracle's cloud licensing policy, this instance requires 16 Oracle Processor licences (32 vCPUs divided by 2). At Oracle's list price of $47,500 per processor for Enterprise Edition, the licence cost alone for a single large instance reaches $760,000 before annual support is added. This figure illustrates why right-sizing instances before deployment is a critical licence cost management strategy.
For Standard Edition 2, the same instance class would be unusual because SE2 is constrained to a maximum of eight vCPUs in cloud environments, broadly equivalent to its on-premises two-socket restriction. This limits SE2 licensing costs but also limits the instance sizes available to SE2 workloads.
BYOL on Amazon RDS for Oracle
Amazon RDS for Oracle supports BYOL for Enterprise Edition and Standard Edition 2. The licence-included model on RDS is only available for Standard Edition 2 on specific instance classes; Enterprise Edition on RDS always requires BYOL.
Under BYOL on RDS, Oracle's cloud licensing policy is the only permitted counting method. You cannot use Dedicated Host-based counting or any other alternative method on RDS because RDS is a managed service running on shared infrastructure that does not expose physical host topology to the customer.
What the RDS BYOL Agreement Covers
To use BYOL on RDS, you must have an active Oracle licence with current Software Update Licence and Support (SULS), meaning your Oracle support contract must be in good standing. Oracle requires active support for all cloud deployments. Lapsing on support and then reinstituting it carries a back-pay penalty of up to 8 percent per year compounded for each year of lapsed coverage, applied retroactively to the period of lapse.
Under BYOL on RDS, you continue to use your existing Oracle support account for Oracle Database-specific service requests. AWS does not provide Oracle Database support under the BYOL model; you retain your direct Oracle support relationship.
Client Outcome
In one engagement, a North American insurance group migrated 40 Oracle Database instances to AWS using BYOL and later received an Oracle audit claim of $4.7M — Oracle's position was that the customer's processor licence count was insufficient for the AWS vCPU configuration used. Redress Compliance reviewed the instance sizing history and demonstrated that the correct Hard Partitioning configurations were in place at the time of migration. The final settlement was $630,000. The engagement fee was under 2% of the original exposure.
Migrating Oracle to AWS? Get an independent licence assessment first.
We identify compliance gaps and cost reduction opportunities before you move.Multi-AZ Deployments and Licence Doubling
One of the most frequently overlooked BYOL cost implications on RDS is the Multi-AZ deployment model. When you deploy an RDS for Oracle instance in Multi-AZ mode, AWS automatically provisions a synchronous standby replica in a different Availability Zone for high availability. This standby instance runs Oracle Database software and therefore requires its own Oracle licence.
Under BYOL, you must hold licences for both the primary instance and the standby instance in a Multi-AZ deployment. If your primary instance requires 16 Oracle Processor licences, your Multi-AZ deployment requires 32 processor licences in total. This doubles the licence cost compared to a single-AZ deployment.
Many organisations discover this requirement only after deploying Multi-AZ workloads in production. Oracle's compliance team views the standby instance as an active Oracle Database deployment regardless of whether it is serving queries, because the software is running. The technical distinction between active and passive matters to your database team; it does not matter to Oracle's licence compliance framework.
BYOL on Amazon EC2
On EC2, BYOL gives you two counting options that are not available on RDS: Oracle's cloud licensing policy (two vCPUs per processor) or physical core counting using Dedicated Hosts.
Standard EC2 Instances
On standard EC2 instances running on shared tenancy infrastructure, Oracle's cloud licensing policy applies. You count two vCPUs per processor licence regardless of the physical hardware underneath the instance. Oracle does not permit you to count only the vCPUs assigned to your instance against the physical core count of the underlying host; you must use the vCPU-based counting rule.
EC2 Dedicated Hosts
EC2 Dedicated Hosts give you a physical server entirely allocated to your AWS account. Because you have visibility into the physical core count of the dedicated host, you can choose to count Oracle licences based on physical cores rather than vCPUs. This is important because on a dedicated host you can see that 64 vCPUs correspond to 32 physical cores with hyper-threading enabled, and with Oracle's core factor for Intel processors (0.5), 32 physical cores require 16 processor licences. The result is arithmetically the same as the standard vCPU rule, but Dedicated Hosts offer a different compliance basis that may matter in specific audit contexts.
Dedicated Hosts are more expensive than standard EC2 instances. The premium for a dedicated host over shared tenancy is typically 10 to 30 percent depending on instance family. Whether the compliance clarity justifies the cost premium depends on your organisation's audit risk profile and the value of having a defensible physical host boundary.
EC2 Bare Metal Instances
AWS bare metal instances are licensed by Oracle exactly like an on-premises physical server. All physical cores on the bare metal instance must be licensed, adjusted by Oracle's core factor for the specific processor type. Bare metal instances provide the strongest compliance basis for BYOL because they eliminate the vCPU abstraction entirely, but they are significantly more expensive than standard EC2 instances and provide no flexibility for instance resizing without a service interruption.
Editions Supported Under BYOL on AWS
Oracle supports BYOL for Enterprise Edition and Standard Edition 2 on AWS. Oracle Database Standard Edition (the predecessor to SE2, discontinued in 2015) and older editions are not supported in cloud environments under any model.
Enterprise Edition BYOL on RDS requires a supported Oracle Database version. Oracle maintains release support schedules that determine which versions can be deployed on RDS. Deploying an unsupported version requires an extended support agreement with Oracle, which carries additional fees on top of the standard 8 percent per year support cost.
Standard Edition 2 BYOL on RDS is limited to instance classes with up to eight vCPUs, equivalent to four processor licences under the two-to-one counting rule. This constraint enforces SE2's hardware limitation in the cloud equivalent of a two-socket server.
Oracle Options and Management Packs Under BYOL
BYOL for the Oracle Database base product does not automatically include licences for Oracle Database options and management packs. If you enable options such as Partitioning, Advanced Security, Diagnostics Pack, or Tuning Pack in your AWS deployment, you must hold separate licences for those options. Each option is licensed on the same vCPU-based counting rule as the database itself.
This is a common source of unintended licence exposure. A database administrator enabling Automatic Workload Repository (AWR) reports in a development environment may not realise that AWR access requires a separately licensed Diagnostics Pack. Oracle's LMS team regularly identifies unlicensed option usage through its collection scripts, and AWS deployments are not exempt from audit.
Annual Support Fees and Cost Projections
Oracle's annual support fees are set at 22 percent of the net licence fee. Oracle increases support fees by 8 percent per year, compounding annually. For a deployment that cost $1 million in licences at year zero, year five support fees will be approximately $320,000 per year, up from $220,000 in year one. Over a ten-year deployment lifecycle, cumulative support costs typically exceed the original licence purchase price.
BYOL deployments on AWS must maintain active Oracle support to remain compliant. Dropping Oracle support to reduce costs while continuing to run the software is a material compliance violation that Oracle treats as an unlicensed deployment, not merely a support lapse.
Five BYOL Compliance Traps to Avoid
Resizing instances without recounting licences: Moving from a 16-vCPU instance to a 32-vCPU instance doubles your licence requirement. Resizing must trigger a licence review before the resize is implemented.
Enabling read replicas without additional licences: RDS read replicas run Oracle Database software and require their own licences under BYOL. Read replicas are not exempt simply because they are read-only.
Forgetting Multi-AZ standby instances: As described above, each standby in a Multi-AZ deployment requires its own licences at the same count as the primary instance.
Deploying unlicensed options: Enabling any Oracle option or management pack that is not separately licenced creates an audit exposure that Oracle can identify through its standard LMS collection tooling.
Lapsing on Oracle support: If your Oracle support contract lapses for any period while the software runs in AWS, Oracle will demand back-payment with interest at reinstatement. The 8 percent annual compounding rate makes even a one-year lapse costly to correct.
Oracle AWS Licensing Assessment
Before migrating Oracle to AWS or at your next renewal, an independent BYOL licence count review can identify gaps, reduce over-licensing, and verify compliance before Oracle does.