Oracle Database on AWS

How is Oracle Database on AWS licensed?

Oracle Database on AWS is licensed under Oracle's Authorized Cloud Environment policy, which designates Amazon Web Services as an approved venue and sets a two vCPU per processor counting rule where hyper threading is enabled. You bring your own Oracle licence to AWS, either on a self managed EC2 instance or on Amazon RDS for Oracle, and you count the licence requirement from the vCPU size of the instance rather than from the physical hardware Amazon operates. There is no License Included path for Oracle Database on raw EC2; the licence is always brought.

The crucial point, set out in the Oracle OCI licensing pillar, is that this favourable treatment rests on a policy document and not on the customer's contract. AWS is a perfectly viable home for Oracle Database, used by a very large number of enterprises, but the licence position depends on a counting rule Oracle can revise. The discipline is therefore the same as for any BYOL deployment: count precisely, document the basis, and govern scaling.

Licensing Oracle on EC2

On a self managed EC2 instance, you provision the virtual machine, install Oracle Database, and license it by counting the vCPUs of the instance type. Under the policy, where hyper threading is on, two vCPUs equal one Enterprise Edition processor licence. An r5.4xlarge with 16 vCPUs therefore requires 8 Enterprise Edition processor licences, plus licences for any options enabled. The arithmetic is the same across instance families; only the vCPU count changes.

Because EC2 is BYOL only for Oracle Database, you must already hold the processor licences and keep them supported, exactly as in the BYOL model. EC2 also lets you constrain vCPU count through instance sizing, which is the primary lever for controlling the licence requirement, since the policy counts the instance you provision regardless of utilisation.

Licensing Oracle on RDS

Amazon RDS for Oracle is a managed service, and it offers two licensing paths. Under License Included, AWS bundles the Oracle Standard Edition Two licence into the RDS rate, so no Oracle licence is brought; this path is limited to Standard Edition Two. Under BYOL, you bring your own Oracle licence, including Enterprise Edition, and count it against the RDS instance class vCPUs under the same two vCPU rule.

The common error on RDS is assuming the managed service handles all licensing. It handles the Standard Edition Two case under License Included, but any Enterprise Edition deployment is BYOL, with the full entitlement obligation on the customer. The boundary between the two is the same policy boundary described in the Authorized Cloud Environment article, and it is where managed service convenience masks a real licence obligation.

Counting cores on AWS

The counting rule on AWS is the two vCPU rule with no core factor, identical to Azure and distinct from both OCI's OCPU mapping and on premise core factor counting. The detailed arithmetic, including the Standard Edition vCPU threshold treatment, is worked in the OCPU versus vCPU article. The single most important consequence is that a processor that carried a favourable core factor on premise gets no such discount on AWS, so a lift and shift can increase the licence count even though the workload is unchanged.

This makes the on premise to AWS comparison non trivial. You cannot assume the same server needs the same licences after migration; you must recount under the cloud rule. For some processors the result is neutral because hyper threading halves the vCPU count; for others with a low on premise core factor it is worse. Running this comparison before migrating is what prevents a nasty surprise in the first AWS true up.

Options and editions on AWS

Edition and option choices drive AWS Oracle cost as much as instance size. Enterprise Edition on EC2 or RDS BYOL requires the full processor count plus any options; Standard Edition Two, available under RDS License Included or BYOL, is counted under a more favourable vCPU threshold and includes no extra cost options because most are not available on it. Choosing Standard Edition Two where the workload allows is frequently the largest single AWS Oracle saving.

The options trap is identical to on premise and OCI: enabling Partitioning, Advanced Security, or a management pack on an Enterprise Edition AWS deployment without owning the option creates a shortfall. The database options article covers the option set, and the discipline is to confirm exactly which options are active and owned before any audit asks.

Where AWS deployments create exposure

AWS Oracle estates create exposure in predictable ways. Auto scaling groups and elastic instance resizing can push the deployment beyond the carried entitlement. A lift and shift counted on the old core factor rather than the cloud rule can be under licensed from day one. Enterprise Edition options can be enabled on RDS BYOL without the matching licence. And the whole position rests on a policy Oracle can dispute. Each is avoidable with counting discipline and documentation.

The defensive posture is to baseline the entitlement before migrating, count every instance under the current policy, cap elastic scaling at the licensed vCPU count, and document the policy version relied upon. If Oracle opens a review of an AWS estate, the audit defence practice handles it, and the argument frequently turns on whether the policy was incorporated into the agreement, exactly as the Authorized Cloud Environment article describes.

AWS versus OCI for Oracle

Oracle prices OCI to make it the cheaper home for its own software, and OCI offers a License Included path for Enterprise Edition that AWS does not. For a customer with no spare Enterprise Edition licences, OCI License Included can therefore beat AWS BYOL on total cost. For a customer with idle, supported Enterprise Edition licences, AWS BYOL keeps the workload on the preferred cloud at the infrastructure rate. The choice is a genuine multi cloud decision, and preserving the ability to run on either preserves negotiating leverage, as the Oracle OCI licensing pillar argues. Azure offers a similar BYOL position, covered in the Oracle Database on Azure article, and the first party Oracle Database@Azure service changes the picture again.

The buyer side view

Oracle Database runs perfectly well on AWS, but always as a brought licence counted under a policy Oracle can revise. The discipline is to count every EC2 and RDS BYOL instance at two vCPUs per processor, choose Standard Edition Two wherever the workload allows, confirm options are owned, cap elastic scaling at the licensed count, and document the policy version relied upon. Run the on premise to AWS recount before migrating, and keep OCI and Azure in the comparison so Oracle cannot price you into a corner. To assess an AWS Oracle position, request a consultation.

Reserved instances and the licence question

AWS reserved instances and savings plans reduce the infrastructure cost of running Oracle on EC2, but they have no effect whatsoever on the Oracle licence requirement. A three year reserved instance still consumes the same vCPUs and therefore the same Oracle processor licences as the equivalent on demand instance. This is an easy and expensive confusion: teams optimising AWS spend through reservations sometimes assume they have also optimised the Oracle position, when the two are entirely independent. The infrastructure commitment is to Amazon; the licence obligation is to Oracle, and only resizing or re editioning the database changes the latter.

The practical implication is that Oracle licence optimisation on AWS happens at the instance sizing and edition layer, not the purchasing layer. Right sizing a database to fewer vCPUs reduces both the AWS bill and the Oracle licence count; buying a reservation reduces only the AWS bill. The two exercises should run together but be costed separately, because conflating them hides the real Oracle exposure.

Migrating from on premise to AWS

A migration to AWS is the moment to recount the Oracle position under the cloud rule rather than assume it carries over. The correct sequence is to baseline the on premise entitlement, recount the target instances under the two vCPU rule, confirm whether the result is higher or lower than the on premise core factor count, and only then size the EC2 or RDS instances to match the licences being carried. The frequent mistake is to lift and shift first and discover the recount afterward, by which point the deployment may already exceed the carried entitlement.

The migration also surfaces option usage that was dormant on premise. An option that was installed but unused on the source database becomes a live obligation if it is enabled on the AWS target. Auditing the option set during migration, and disabling what is not owned, is part of the same recount. Done in advance, the migration cleans up the position; done carelessly, it creates a new shortfall on a policy basis Oracle can later dispute, as the Oracle OCI licensing pillar warns.

One further AWS specific point deserves emphasis: the licence count is fixed to the instance you provision, not to the workload's actual CPU usage, so an oversized instance running a light database is pure waste in Oracle licences as well as AWS dollars. Because Oracle counts what you provision, the single most effective ongoing optimisation is a standing review of instance right sizing, treating every idle core as a licence you are paying for twice, once to Amazon and once to Oracle in retained support. Estates that review EC2 sizing quarterly routinely surface Enterprise Edition cores that can be reclaimed simply by matching the instance to the real workload.