Oracle on AWS: BYOL Licensing Rules and Pitfalls

Running Oracle on AWS under Bring Your Own Licence looks simple — until an audit reveals the instance type, the Multi-AZ standby or a stray bare-metal host has quietly doubled the licence count. This guide sets out the Oracle on AWS BYOL rules for EC2 and RDS, and the traps that turn a clean migration into a compliance claim.

By Oracle Practice Lead

The Authorized Cloud Environment Rule

Oracle on AWS BYOL licensing is governed by Oracle's Authorized Cloud Environment policy, which lists AWS and Microsoft Azure as approved third-party clouds for Bring Your Own Licence deployments. The single most important consequence is that the Oracle Processor Core Factor Table — the 0.5 multiplier that halves on-premises x86 counts — does not apply on AWS. In its place Oracle substitutes a flat vCPU rule, which is simpler but not always cheaper.

The critical caveat is that this policy is not a contract. It is a unilateral document Oracle publishes and can revise without your consent, and enterprises have been caught mid-migration when the rules shifted under them. Where the cloud counting maths underpins a multi-year business case, the protection is to secure the relevant terms in writing in your Oracle agreement rather than trusting the published policy to hold. This is one of the cloud-specific risks we examine across the advanced Oracle licensing guide, and it applies equally to Azure and to Oracle's own cloud.

Counting Licences on EC2 and RDS

The rule itself is straightforward once hyperthreading is accounted for. With multi-threading enabled — the AWS default on most instance families — two vCPUs equal one Oracle Processor licence. With multi-threading disabled, one vCPU equals one licence. A 16-vCPU instance therefore needs eight Processor licences with hyperthreading on, or 16 with it off. The same rule applies whether you run Oracle on raw EC2 or on managed Amazon RDS for Oracle under BYOL.

AWS configurationvCPUsHyperthreadingOracle Processor licences
EC2 single instance16On8
EC2 single instance16Off16
RDS db.r6g.4xlarge, single-AZ16On8
RDS db.r6g.4xlarge, Multi-AZ16 + 16 standbyOn16
EC2 bare metal / dedicated hostFull physical coresN/A — core factor appliesCores × 0.5

Reserved Instances do not change the licence count, but they materially change the hardware bill: one- and three-year RDS reservations reach up to 48% net savings versus on-demand, which is where the real cost optimisation lives once the BYOL count is fixed. For workloads that span multiple clouds, compare the AWS position against the OCI pricing comparison and the distinct Oracle Database@Google Cloud model before you commit — the same database can cost very different amounts depending on which provider's counting rule applies.

The Five Pitfalls That Double Your Count

Most AWS BYOL compliance gaps come from a short list of recurring errors. Multi-AZ doubling is the most common: an RDS Multi-AZ deployment runs a standby replica, so both the primary and the standby vCPUs must be licensed. Size for the primary alone and you are under-licensed by half the moment the deployment goes live.

The bare-metal and dedicated-host trap is the most expensive. The simplified vCPU rule applies only to standard shared instances; bare-metal and dedicated hosts fall back to the on-premises core factor and must be licensed for the full physical core count of the underlying server, regardless of how many vCPUs you actually use. Third, an accidental hyperthreading change — triggered by a reboot or an instance-type swap — can silently flip you from the two-for-one rule to one-for-one, doubling the requirement without any change in workload. Fourth, snapshot and AMI proliferation: test, development and staging copies count as deployed instances, and each running clone needs its own licences. Fifth, disaster-recovery drift, where a standby instance is opened for reporting and crosses from passive into fully licensable use — the same failover rules covered in our guide to Oracle DR licensing for standby and failover.

An AWS migration is a licence-position event, not just an infrastructure event. We have seen estates arrive in AWS believing they had halved their Oracle exposure, only for a dedicated-host design choice and a Multi-AZ standby to push the true requirement above the on-premises baseline they left behind.

The snapshot pitfall deserves particular attention because it is invisible in normal cost reporting. Every Amazon Machine Image, RDS snapshot and cloned environment that runs Oracle is, in Oracle's view, a deployment requiring licences — and DevOps automation spins these up routinely for testing, staging and blue-green releases. An estate with disciplined production sizing can still be materially under-licensed because its non-production sprawl was never counted. Tag Oracle-bearing images explicitly, cap how long clones persist, and reconcile the running inventory against entitlement on a schedule rather than waiting for an audit to do the counting for you.

BYOL vs License Included: The Cost Decision

Amazon RDS for Oracle offers two commercial models. License Included bundles the Oracle licence into the hourly instance price, but it is available only for Standard Edition 2 — there is no License Included path for Enterprise Edition or its options. It suits variable and non-production workloads: an instance running only business hours (roughly 30% of the week) can cut effective licensing cost sharply because you pay by the hour rather than for a perpetual entitlement. BYOL reuses licences you already own and supports both SE2 and Enterprise Edition, and it is the lower-cost option whenever you hold active, supported licences you can redeploy.

AWS has also been narrowing the gap on hardware cost: in September 2025 Amazon introduced RDS for Oracle bare-metal instances priced around 25% below equivalent virtualised instances. That is attractive for raw performance, but it is a licensing trap in disguise — bare metal drops you out of the simplified vCPU rule and back onto the core factor calculation, so the hardware saving can be swamped by a larger Oracle bill. Always evaluate instance choices on fully-loaded cost, hardware plus licence, never hardware alone.

The decision is rarely AWS-only. It interacts with your support position, your remaining on-premises entitlement and any unused rights you can redeploy rather than re-buy — which is why we always pair an AWS migration with a licence harvesting review and the broader optimisation-after-migration analysis. For the full methodology, the Oracle Negotiation Playbook and the Oracle vendor intelligence hub track the policy changes that move these numbers. If you are planning or defending an AWS deployment, request a confidential briefing before you finalise the architecture — the instance and topology choices made on day one set your licence cost for years.

Common Questions

Oracle on AWS BYOL: FAQ

How many Oracle licences does a 16-vCPU AWS instance need?
Under Oracle's Authorized Cloud Environment policy a 16-vCPU EC2 or RDS instance with hyperthreading enabled needs eight Oracle Processor licences, because two vCPUs count as one Processor. With hyperthreading disabled the same instance needs 16 licences, since one vCPU then counts as one Processor. The core factor table does not apply on AWS.
Does RDS Multi-AZ double my Oracle licence count?
Yes, under BYOL. An RDS Multi-AZ deployment runs a standby replica, so you must count the vCPUs of both the primary and the standby. A db.r6g.4xlarge Multi-AZ pair (16 vCPUs each) requires 16 Oracle Processor licences in total, not eight. Teams that size for the primary alone are routinely under-licensed by half.
Can I use the vCPU counting rule on AWS bare metal or dedicated hosts?
No. The simplified two-vCPU rule applies only to standard EC2 and RDS instances. Bare-metal and dedicated-host deployments fall back to the on-premises core factor calculation and must be licensed for the full physical core count of the underlying server — which frequently doubles the licence requirement versus a comparable virtualised instance.
Is Oracle's Authorized Cloud Environment policy contractually binding?
No — it is a unilateral Oracle policy document, not a contract term, and Oracle can change it at any time. Several enterprises have been caught mid-migration when the policy shifted. Where the cloud counting rules matter to a business case, the protection is to secure the relevant terms in writing in your Oracle agreement rather than relying on the published policy.

Don't Migrate Oracle to AWS Blind

The instance type, topology and licensing model you choose on day one set your Oracle cost for years. We model the position before you commit — and defend it if Oracle audits.

Request a Confidential Briefing See Our Oracle Case Study

Oracle Licensing Intelligence

Monthly briefings on Oracle policy changes, audit tactics, ULA strategy and cloud licensing — from advisors who have been on both sides of the table.