Oracle Licensing on AWS: Rules, vCPU Counting, and Cost Optimisation

Oracle's Authorised Cloud Environment Framework

Oracle designates certain public cloud providers as Authorised Cloud Environments (ACEs). AWS, Microsoft Azure, and Google Cloud Platform are all designated ACEs. The ACE designation matters because Oracle applies different and more favourable licence counting rules to ACE environments compared to non-authorised cloud deployments.

In an ACE, Oracle abandons the physical-core-based counting methodology that applies on-premises and instead uses a vCPU-to-Processor conversion. This change recognises that customers running Oracle on AWS do not have visibility into or control over the underlying physical hardware, making physical-core counting impractical. The ACE rules are documented in Oracle's Licensing Oracle Programs in the Cloud Computing Environment policy document.

Critically, the ACE status does not eliminate Oracle's BYOL requirements. Customers running Oracle on AWS must still hold perpetual Oracle licences with active Software Update Licence and Support. The ACE framework only changes how the licence count is calculated — it does not reduce the total licence requirement for a given workload to zero.

The EC2 vCPU Counting Rule

For Oracle Database and most Oracle products on Amazon EC2, the licence counting rule under the ACE policy is: 2 vCPUs on the EC2 instance equal 1 Oracle Processor licence. This rule assumes hyper-threading is enabled on the EC2 instance, which is the default for the vast majority of AWS instance types. If hyper-threading is disabled (1 vCPU per physical thread), then 1 vCPU equals 1 Oracle Processor licence.

The Oracle Core Factor Table does not apply. On-premises, an Intel x86 processor has a Core Factor of 0.5, meaning 8 cores require 4 Processor licences. On EC2, 8 vCPUs require 4 Processor licences under the 2:1 ratio — the same result mathematically, but the methodology is different. The important distinction comes for non-x86 instance types (such as AWS Graviton ARM-based instances), where the Core Factor table would have applied different multipliers on-premises but the flat 2:1 vCPU ratio applies in the ACE context.

The rule applies to the total vCPU count of the EC2 instance, not the vCPUs actively used by Oracle. Buying a larger EC2 instance than Oracle needs and running Oracle at low CPU utilisation does not reduce the licence requirement. Oracle's licence obligation is based on the instance's vCPU count at provisioning, not Oracle's actual CPU consumption.

Oracle Standard Edition 2 on EC2: Special Rules

Oracle Database Standard Edition 2 has its own counting rule in ACE environments that differs from the EE 2:1 vCPU ratio. SE2 is licensed per server with a two-socket maximum in the on-premises model. In the ACE framework, Oracle defines SE2 instances by socket equivalence based on vCPU count.

For SE2 on EC2: instances with 4 or fewer vCPUs are considered 1 socket. Instances with 5 to 8 vCPUs are considered 2 sockets. SE2 requires a licence for each socket, and since SE2 is limited to 2 sockets maximum, SE2 on EC2 is only compliant on instances with up to 8 vCPUs. Running SE2 on an EC2 instance with more than 8 vCPUs exceeds the SE2 maximum socket limit and is therefore non-compliant — even if only 8 vCPUs are used.

Organisations running Oracle SE2 on EC2 should confirm their instance types are within the SE2 socket limit before deployment, and should review instance sizes if the application team requests a resize to a larger instance type that may exceed the SE2 limit.

AWS Auto Scaling and Compliance Risk

One of the most underappreciated Oracle compliance risks on AWS is auto scaling. AWS Auto Scaling can dynamically provision additional EC2 instances when application load increases. If Oracle is deployed on auto-scaled EC2 instances — or on an instance that itself scales to a larger type under load — each additional vCPU added through scaling increases the Oracle Processor licence requirement.

Organisations that have deployed Oracle on auto-scaling EC2 configurations and have not accounted for the maximum scaled instance size in their licence planning are potentially non-compliant during periods of auto-scale activity. Oracle's audit programmes include review of cloud deployment history, and auto-scale events that resulted in unlicensed vCPU deployment can be captured in the audit scope.

The recommended approach: Oracle workloads on AWS should use fixed instance sizes rather than auto-scaling configurations. The Oracle licence model is not compatible with dynamic infrastructure that scales to unlicensed capacity under load. For applications that require elastic capacity, consider alternatives — using AWS Lambda for application tiers with a fixed Oracle database tier, or migrating to Oracle Autonomous Database on OCI where BYOL licensing rules are cleaner for elastic workloads.

Oracle and AWS EC2 Dedicated Hosts

AWS Dedicated Hosts provide a physical EC2 server dedicated to a single customer account. For Oracle licensing purposes, Dedicated Hosts raise a frequently misunderstood question: can you limit your Oracle licence scope to the vCPUs of the specific VMs running Oracle on the Dedicated Host?

Oracle's answer is no, subject to the ACE rules. In an ACE, the licence obligation is based on the vCPU count of the EC2 instance running Oracle, not the physical core count of the Dedicated Host. A Dedicated Host does not change the counting methodology — it changes the underlying hardware dedication, not the licence calculation. Oracle continues to count vCPUs on the instance running Oracle, applying the 2:1 ratio, regardless of whether the underlying hardware is shared or dedicated.

Where Dedicated Hosts do have value in Oracle licence management is for Dedicated Host Licence Configurations — a feature that allows pinning specific Dedicated Host capacity to specific Oracle licence pools, useful for large-scale Oracle BYOL programmes where tracking which licences are applied to which infrastructure is otherwise complex.

BYOL Requirements and Support Obligations on AWS

Running Oracle on AWS under BYOL requires active Oracle Software Update Licence and Support (SULS) for all licences applied. Oracle SULS fees escalate at 8% per year. An organisation that moved Oracle from on-premises to AWS several years ago and is paying support on a large Oracle EE perpetual licence estate is continuing to pay 8% annual support escalation on the full licence base, whether the workloads are on-premises, on AWS, or on any other platform.

The platform move to AWS does not reset or reduce the Oracle support fee. The licence base remains, the support continues to escalate, and the only way to reduce the support obligation is to reduce the perpetual licence count — through certification at ULA termination, decommissioning of unused licences, or negotiated true-up as part of a commercial event.

For organisations with large on-premises Oracle estates that have migrated some workloads to AWS, the support cost management strategy should be part of the cloud migration plan. Moving workloads to AWS and maintaining the on-premises licence support fees without reducing the licence base at the migration event is a common source of Oracle cost overrun in cloud migrations.

Oracle on AWS vs Oracle on OCI: Licence Cost Comparison

Organisations deciding between AWS and Oracle Cloud Infrastructure (OCI) for Oracle workloads should include Oracle licence cost differences in their platform comparison. OCI's BYOL programme is designed specifically to be licence-cost-efficient for Oracle workloads, and OCI applies the same 2:1 vCPU ratio as AWS (expressed as 2 OCPUs per Processor licence).

The primary difference between AWS and OCI for Oracle licensing purposes is Oracle's commercial incentive structure. Oracle's sales team actively promotes OCI for Oracle workloads and may offer licence credits, ULA scope extensions, or BYOL migration incentives for customers who move Oracle from AWS to OCI. These incentives are not available for AWS migrations. Additionally, Oracle has been more proactive about auditing Oracle-on-AWS deployments than Oracle-on-OCI deployments — a practical reality of Oracle's commercial interest in promoting OCI over AWS.

From a pure licence compliance standpoint, both AWS and OCI apply the same 2:1 vCPU counting rule, and both require active SULS for BYOL deployments. The practical differences lie in Oracle's commercial behaviour, pricing incentives, and the managed service capabilities each platform provides for Oracle workloads.

Cost Optimisation Strategies for Oracle on AWS

Right-size EC2 instances to Oracle's actual compute requirements. Every unnecessary vCPU on an Oracle EC2 instance represents half an Oracle Processor licence cost — plus the AWS infrastructure cost of the oversized instance. Use AWS Compute Optimizer to identify Oracle EC2 instances where CPU utilisation is consistently low and the instance size can be reduced without performance impact.

Consolidate databases onto fewer, larger instances. Running Oracle Multitenant (Container Database) on a single licensed EC2 instance allows multiple Pluggable Databases to share the same Oracle licence footprint. Consolidation reduces the total EC2 instance count — and therefore the total vCPU count — while maintaining database isolation at the Pluggable Database level. This is one of the highest-return Oracle cost optimisation strategies available in AWS environments.

Use Reserved Instances for predictable Oracle workloads. AWS RDS and EC2 Reserved Instances at 1-year or 3-year terms provide significant discounts (40 to 60 percent) on the AWS infrastructure cost. For Oracle EE BYOL deployments where the Oracle licence cost is separate, the infrastructure saving from Reserved Instances directly reduces total cost of ownership. Fixed-size Oracle instances — rather than auto-scaling configurations — are the prerequisite for benefiting from Reserved Instance pricing.

Plan ULA deployments to include AWS. Organisations under an Oracle ULA should consider whether additional Oracle deployments on AWS during the ULA term should be included in their deployment plan. Each Oracle deployment on AWS EC2 during a ULA term, certified at the end, converts to perpetual licence value at no incremental licence cost. The AWS deployment costs are real — the Oracle licence cost is not, during the ULA term.

Common Oracle AWS Compliance Mistakes

Applying the on-premises Core Factor to EC2 vCPUs. The Core Factor Table does not apply in ACE environments. Some organisations divide their EC2 vCPU count by 2 (applying the 0.5 Core Factor as if it were a physical core count) and then halve again for the 2:1 vCPU-to-Processor ratio, arriving at one quarter of the correct licence count. The correct calculation is simply: vCPU count ÷ 2 = Processor licence count.

Ignoring auto-scaling licence implications. Auto-scaled EC2 instances that increase vCPU count under load create licence obligations for the duration of scaling. Static instance sizing is the only way to maintain a predictable Oracle licence position on AWS.

Failing to account for development and test environments. Oracle licences are required for every EC2 instance running Oracle Database, including development, test, UAT, and performance testing environments. Development licences (which allow development-only use) are separately restricted and do not permit production-equivalent usage. Every unlicensed environment is audit exposure.

Treating AWS as an audit-safe zone. Oracle audits AWS deployments. Oracle's LMS scripts and cloud audit tools can identify Oracle deployments in AWS environments, and AWS's own Oracle Optimisation and Licensing Assessment programme provides Oracle with visibility into BYOL deployment counts. AWS deployments are not shielded from Oracle's standard audit programme.