Oracle on AWS Licensing FAQs 1 of 4
1. What licensing models exist for running Oracle software on AWS?
AWS supports two primary models for Oracle licensing: Bring Your Own License (BYOL) and License Included. Under BYOL, you use your existing Oracle licenses on AWS resources (EC2 instances or RDS instances), abiding by Oracle’s cloud licensing policies. Under the License Included model, offered in certain cases on Amazon RDS, the Oracle license cost is bundled into vice pricing.
In practice:
- BYOL – You purchase or own Oracle licenses (with active support) and deploy Oracle software on AWS. You remain responsible for compliance (counting CPUs/users) but have the flexibility to reuse investments. This applies to all Oracle products on EC2 and RDS for editions where AWS doesn’t offer built-in licenses (e.g., Oracle Database Enterprise Edition must be BYOL on RDS).
- License Included—AWS provides the Oracle license as part of the service (for an uplifted cost). This is available only for certain services/editions (for example, Amazon RDS offers license-included instances for Oracle Standard Edition One and Two). AWS handles the Oracle licensing fees in this case, and you pay as you go. This model simplifies compliance for the customer but is limited in availability (Enterprise Edition is not offered license-included on AWS).
2. What is Bring Your Own License (BYOL) for Oracle on AWS?
BYOL means you deploy Oracle software on AWS using licenses you’ve purchased from Oracle (or obtained via enterprise agreements). AWS is just another data center where you can use your Oracle entitlements.
Key points for BYOL on AWS:
- To ensure you have enough licenses, you must license AWS compute resources according to Oracle’s policies (vCPU-based counting, explained in other FAQs). For example, running Oracle Database on an EC2 instance with eight vCPUs would “consume” 4 of your processor licenses if hyper-threading is enabled (since two vCPUs count as 1 Oracle processor).
- Applicable to all Oracle software: BYOL is the primary method for Oracle Database Enterprise Edition, Oracle Middleware (WebLogic, etc.), and Oracle applications on AWS. AWS does not include licenses for these by default, so you must BYOL for any Oracle software not covered under a special AWS offering.
- Support requirements: You must maintain Oracle support contracts for your BYOL licenses. Oracle requires that licenses used in the cloud have active support (for updates and compliance). Beyond your stand license, no special “cloud license” is needed, but check your Oracle contract for any clauses about third-party cloud use (most modern contracts allow it, treating AWS as an “Authorized Cloud Environment”).
- No automatic portability: Unlike some vendors, Oracle doesn’t require a separate “license mobility” program—if you own a valid license, you can use it on AWS as long as you adhere to the rules. However, you should document the move. It’s wise to notify Oracle or get written confirmation if your contract has older “outsourcing” provisions. Oracle’s policy document authorizes AWS usage, so BYOL is a well-established practice.
Read Oracle on AWS Licensing FAQs 2 of 4.
3. What is the “License Included” model for Oracle on AWS?
The License Included model means the AWS service usage fee already covers the Oracle software license. In this scenario, you do not need to bring or own an Oracle license separately.
Key points:
- Where it’s available: Amazon RDS for Oracle offers a license-included option for Oracle Database Standard Edition (One and Two). This allows you to launch an RDS Oracle SE2 instance and pay AWS hourly (or via reserved instance) for the database, with Oracle licensing handled by AWS. Enterprise Edition on RDS has no license-included option (you must use BYOL for EE). There are no license-included options on plain EC2 – if you install Oracle on EC2 yourself, you must BYOL.
- What’s included: The hourly RDS rate in the License Included covers the Oracle database license, software updates, and patches (since AWS has an agreement with Oracle for this). You must still follow Oracle’s usage policies (e.g., not using features beyond what’s allowed for that edition). Still, you don’t have to report usage to Oracle – AWS takes care of the licensing reporting.
- Scaling and cost benefits: License Included is often used for convenience or short-term needs. It can be cost-efficient for development/test environments that run only during business hours or intermittently. Since you pay per use, you avoid purchasing perpetual licenses for transient workloads. For steady, long-term production, BYOL might be cheaper if you already own licenses.
- Limitations: With License Included, you’re limited to the editions/features that AWS offers. For instance, Standard Edition 2 via RDS license-included cannot be modified to Enterprise features. Also, you cannot take an AWS-provided Oracle license outside of AWS. If you later move that workload on-premises, you will need to purchase Oracle licenses.
4. Can I use Oracle software on AWS if I don’t already own Oracle licenses?
Yes – even if you don’t own Oraclay, you can still run Oracle products on AWS, but you must do so under proper licensing:
- Use AWS’s License Included services: The simplest path is to use Amazon RDS for Oracle with the License Included option (available for Standard Edition databases). This requires no prior Oracle license purchase – you pay Amazon’s rates, including the Oracle fees. This is ideal for trying out Oracle or for smaller workloads that fit within Standard Edition limits. Remember this license, not things like Oracle WebLogic or applications (which have no license-included). Chase new licenses from Oracle:** If you need Oracle products not offered as license-included, you should acquire the licenses from Oracle (or an authorized reseller). Oracle licenses are generally platform-agnostic, so a license you buy can be deployed on AWS. For example, suppose you need Oracle Database Enterprise Edition on EC2 or Oracle WebLogic Server on an EC2 VM. In that case, you’d buy the appropriate number of processor or user licenses from Oracle and then deploy them on AWS under BYOL. Be sure to size the purchase correctly (see core counting rules in these FAQs) to remain compliant.
- Trial and free usage: Oracle provides certain products under trial or free developer licenses (for example, Oracle Database Developer Edition or XE and certain free tiers on OCI but not on AWS). However, there isn’t an “Oracle free tier” on AWS beyond using Oracle’s free editions. Running Oracle’s free Express Edition (XE) on AWS is allowed without a license (XE is free to use) but has limited capability. It cannot be used for paid production deployments in place of a licensed edition. Always double-check the specific Oracle product’s licensing terms if you think it might be free.
- No “unlicensed” usage: It’s important to note that simply launching an Oracle AMI or installing Oracle software on AWS without a license is not compliant (except for tXE). Oracle’s audit rights extend to cloud deployments, so you should never run Oracle programs in AWS (or anywhere) without proper licensing arrangements. If in doubt, engage Oracle or a licensing expert before deployment.
5. How do I count Oracle processor licenses when using AWS EC2 instances?
Oracle uses a specific formula to count processors on AWS. Unlike on-premises hardware (where Oracle counts physical cores multiplied by a core factor), the counting is based on virtual CPU in AWS.
The official policy for Authorized Cloud Environments (which includes AWS) is: “Count two vCPUs as one Oracle Processor license if hyper-threading is enabled; count one vCPU as one license if hyper-threading is not enabled.”
In practical terms:
- Most AWS instance types have hyper-threading enabled, meaning each vCPU is one hardware thread. Thus, two vCPUs are generally equal to one Oracle processor license on AWS. For example, an EC2 instance with eight vCPUs would require four Oracle processor licenses (assuming hyper-threading on】.
- If an instance type does not use hyper-threading (or if you explicitly disable it), then each vCPU is a full core, and each vCPU counts as an Oracle processor license. For instance, an older AWS instance where one vCPU = 1 physical core would need eight licenses for eight vCPUs. (Azure used to fall in this category since Azure vCPUs were core-based; now, AWS and Azure largely follow the 2-for-1 rule due to hyper-threading).
- Oracle’s Core Factor table is not applied on AWS. Oracle’s on-prem licensing often uses a factor (e.g., 0.5 for Intel cores) explicitly waived in cloud policy. The vCPU mapping (2 vCPUs per license) is the only factor, so ignore any core factor multipliers for AWS deployments.
- License per instance, not per VM guest: If you run multiple Oracle databases, you still count the instance’s vCPUs overall (not per database). Conversely, if you run a single Oracle database across multiple EC2 instances, license each instance’s vCPUs on which Oracle software runs.
6. Why is hyper-threading relevant to Oracle licensing on AWS?
Hyper-threading affects how many vCPUs an instance reports, affecting Oracle licensing counts. AWS instance types with hyper-threading (the most instance families on modern AWS) will show two vCPUs for each physical core. Oracle’s policy effectively acknowledges this by allowing two vCPUs = 1 license in those cases.
Here’s why it matters:
- Double-counting risk: You might over-license if you mistakenly treat AWS vCPUs as physical cores. For example, an EC2 instance with eight vCPUs corresponds to 4 cores with hyper-threading. In that scenario, Oracle only requires four licenses, not 8. Understanding hyper-threading prevents over-spending on licenses.
- When hyper-threading is off: Some AWS offerings (like certain bare-metal instances or explicitly disabling multithreading via CPU options) mean each vCPU is a full core. In those cases, Oracle sees each vCPU as one core license. If you turn off hyper-threading, this can double your license requirement for the same instance size. For example, an EC2 Metal instance with eight physical cores (and you choose to have eight vCPUs with one thread each) would need 8 Oracle licenses, whereas if hyper-threading were on (16 vCPUs) it would still only need eight licenses (since 16 threads = 8 cores). Turning off hyper-threading doesn’t reduce licenses – it just reduces performance in many cases.
- Best practice: Generally, leave hyper-threading enabled on AWS instances running Oracle unless you have a specific performance reason to disable it. It doesn’t hurt Oracle licensing to have it on (in fact, it makes each license cover two threads). Oracle counts “per thread” either way, so you gain compute capacity with no extra license cost by using hyper-threading.
- AWS default: By default, AWS will have hyper-threading on for instance families that support it (e.g., Intel and AMD-based instances). You would only encounter a non-hyper-threaded scenario if you intentionally modify CPU settings or use instance types like AWS Graviton (ARM), which doesn’t hyper-thread. Oracle’s two vCPU = 1 license policy applies to multithreaded Intel/AMD CPUs. For AWS Graviton (not explicitly called out in Oracle’s policy), one could assume each vCPU = one core since there’s no hyper-threading. However, Oracle hasn’t formally published guidance on Graviton. When in doubt, consult Oracle or assume worst-case (1 vCPU = 1 license for Graviton).
7. Can I reduce Oracle licensing costs by disabling cores or using AWS “CPU options” to limit vCPUs?
Not effectively – Oracle’s policy counts the maximum available vCPUs of an instance type, regardless of how you configure it at runtime. You cannot partially license an EC2 instance by throttling or limiting its vCPUs.
Key considerations:
- AWS offers “Optimize CPU” options that let you customize the number of cores or threads an instance uses (for example, you could launch an 8 vCPU instance type but restrict it to 4 vCPUs). Oracle, however, will still count the instance type’s full potential vCPUs in most cases. Oracle’s cloud licensing document explicitly says to count the maximum vCPUs of the instance type. So even if you turn off some vCPUs, Oracle expects you to license as if they were all on.
- Example: Suppose you use an AWS c5.4xlarge (which normally has 16 vCPUs), but you pin it to 8 vCPUs via CPU options. Oracle’s policy would still consider it a 16 vCPU instance because that’s its defined size. You would need eight processor licenses (with hyper-threading) even though you only actively use half the vCPUs. In other words, you don’t save money by under-utilizing the instance’s capacity from Oracle’s perspective.
- The only way to legitimately reduce Oracle licensing on AWS is to choose a smaller instance type. For example, use a c5.2xlarge (8 vCPUs) instead of a c5.4xlarge rather than trying to cap a bigger instance. Licensing is tied to instance size.
- Disabling hyper-threading is not a cost-saving method (as discussed, it can increase the count per vCPU). Oracle has clarified that customers should not use tricks like CPU pinning or custom core counts to “optimize” licenses beyond the approved counting method. Always follow the official vCPU count rules to avoid compliance issues.
8. Does Oracle’s Processor Core Factor table apply to AWS instances?
No. Oracle’s Processor Core Factor table (which gives a reduction factor for certain CPU types on-premises) does not apply in AWS or other authorized public clouds. Oracle uses the simplified vCPU-based counting in the cloud with no further core type adjustment.
This means:
- Whether the underlying AWS hardware is Intel or AMD, two vCPUs = 1 Oracle license (if hyper-threaded) across the board; you do not multiply by any 0.5 or 0.25 factor that you might in an on-prem environment. For example, on-prem an Intel core often has factor 0.5, but on AWS an Intel vCPU counts as 0.5 license inherently via the 2-for-1 rule – no additional factor is applied on top of that.
- Oracle introduced this change in 2017. Previously, some customers hoped to apply core factors in the cloud, but Oracle’s policy update explicitly removed that possibility. So, the licensing math in the cloud is more straightforward but sometimes less forgiving for processors that would have had a discount on-prem.
- All instance types are treated equally in terms of license per vCPU. There’s no difference if the AWS instance has newer or older CPU models – just count vCPUs. This simplifies compliance: You must know how many vCPUs your Oracle workloads run on.
- Keep in mind that Oracle’s core factor table still applies on-premises. So, if comparing costs between AWS vs on-prem, a physical core might cost less license on-prem (with factor) than the equivalent vCPUs on AWS. This is one reason Oracle on its own Oracle Cloud (OCI) uses a different metric (Oracle’s “OCPU” equals a full core, effectively similar net effect). In AWS, however, Oracle treats it as full-cost cores.
9. Hard Edition (SE) licenses counted on AWS?
Oracle Database Standard Edition (including SE1, SE2, and old SE) has special licensing rules on-prem and in the cloud.
In AWS’s context:
- Socket-based licensing: Standard Edition products are usually licensed per “socket” (processor socket) instead of per core. Oracle’s cloud policy translates the concept of a socket to vCPUs. Specifically, Oracle states that an instance with up to 4 vCPUs is equivalent to a single socket (and thus one Standard Edition license. If the instance has more than four vCPUs, it counts as an additional socket (rounding up). For example, an AWS instance with six vCPUs would count as two sockets (since six vCPUs round up to 8, i.e., two groups of 4), requiring two SE licenses.
- vCPU limits for SE on AWS: Oracle imposes an upper limit on instance size for Standard Edition in the cloud. Standard Edition 2 (SE2) (and the older SE1) may only be licensed on instances with up to 8 vCPUs in AWS. The older Standard Edition (SE – pre-SE2, allowed until 12c version) is limited to instances with up to 16 vCPUs. This means you cannot legally run SE2 on a 32 vCPU instance; Oracle would require you to use Enterprise Edition (or run multiple smaller SE2 instances).
- Minimum NUP for SE2: If you license Standard Edition 2 by Named User Plus (NUP) instead of processors, the policy sets a minimum of 10 Named Users per 8 vCPUs on AWS. This mirrors the on-prem minimum of 10 NUP per server for SE2 in a cloud context. So if you run any SE2 instance (since it can be a maximum of eight vCPUs), you need at least 10 named user licenses, even if fewer people use it.
- No core factor, and hyperthreading doesn’t change count: The four vCPU = 1 socket rule already accounts for hyperthreading indirectly (it’s just counting vCPUs). So you don’t do an additional 2-for-1 split as with Enterprise. Instead, simply apply: count vCPUs, divide by 4 (round up) to get several SE sockets to license. For example, 8 vCPUs = 2 sockets = 2 SE2 licenses. 4 vCPUs or less = 1 SE2 license. This is straightforward, but remember the vCPU limits above.
- No multi-tenancy or RAC on SE2: Standard Edition 2 does not allow Oracle RAC except in certain clustering scenarios on-prem (and on AWS, RAC is unavailable for SE2). Also, SE2 can’t use Oracle’s multi-tenant option (EE-only). So, while this doesn’t directly change “how to count licenses,” it affects how you architect an SE2 solution on AWS. You’ll deploy one SE2 instance per database (or use logical schemas) rather than RAC or multiple PDBs.
10. Can I run Oracle Database Standard Edition on AWS, and what are the limitations?
Yes, you can run Oracle Standard Edition (SE) or SE2 on AWS, but observe these licensing and technical limitations:
- Instance Size Limit: As mentioned, Oracle SE2 is limited to 8 vCPUs max on any single instance in Authorized Cloud Environments. That corresponds roughly to the on-prem limit of 2 sockets (since many modern CPUs have up to 4 cores per socket, two sockets × 4 cores each = 8 cores, aligning with eight vCPUs). If your workload needs more than eight vCPUs of power, you cannot scale up an SE2 instance beyond that – you’d have to either use multiple separate databases or move to Enterprise Edition.
- Counting Licenses: For a single processor license” per 4 vCPUs (or fraction thereof) on the instance. But practically, Oracle sold SE and SE2 licenses per socket (not core). So you simply ensure you have one SE2 license for an instance up to 4 vCPUs and two licenses for >4 to 8 vCPUs. Oracle SE licenses are relatively cheaper than EE, which can be cost-effective for smaller workloads.
- No Oracle RAC on AWS for SE: Oracle RAC (Real Application Clusters) for high availability is allowed on Standard Edition (the older SE (pre-2015) allowed RAC with up to 4 nodes, SE2 does not allow RAC at all). In AWS, RAC is not supported for SE because SE2 forbids it and SE1/SE are superseded. So you cannot use a multi-instance cluster for SE2 on AWS; you would use AWS’s high availability (like Multi-AZ RDS or EC2 failover mechanisms) rather than Oracle RAC.
- Feature Set: Standard Edition (SE2) is a limited-feature edition. Some features, like partitioning, data guard broker, parallel query, etc., are unavailable in SE2 or require EE. If you need those, SE2 on AWS might not meet the requirements. From a licensing standpoint, SE2 is all-inclusive (no separate options to license – options exist only for Enterprise). So it’s simpler: you either have the feature in SE2, or you don’t. This can avoid certain licensing headaches (no worry about accidentally using an option without a license since options aren’t even present in SE2 binaries).
- Use cases: SE2 on AWS is great for small-to-medium databases where eight vCPUs (and the memory that comes with an instance that size, say ~32–64 GB RAM) is sufficient. Many departmental or legacy apps can run on SE2 with significant cost savings. Plan the instance size accordingly and ensure your usage (users) fits the SE licensing metric you choose (NUP or processor).
