Oracle on AWS Licensing FAQs 2 of 4
11. What are the minimum license requirements (per-core or per-user) for Oracle on AWS?
Oracle enforces similar minimums on AWS as on-prem for license metrics:
- Processor License Minimum: You cannot license less than a whole processor as defined by Oracle’s cloud policy. That means even if your instance is very small, the minimum “purchase” is one processor license (which on AWS could cover two vCPUs with hyper-threading). There’s no fractional license. So, for example, an EC2 instance with one vCPU (with hyper-threading off) would still require one full processor license (counted as one vCPU = 1 license in that rare case) – you can’t buy half a license for it. Essentially, the smallest unit is one Oracle processor license, which on AWS typically lets you use up to 2 vCPUs (if HT on).
- Named User Plus (NUP) Minimums: Oracle’s standard minimums for NUP apply on AWS. The rule for Oracle Database Enterprise Edition is 25 Named Users per processor, which holds in the cloud. So, if you have one processor license allocated (covering two vCPUs), you need at least 25 named users licensed. Suppose you had two processor licenses worth of AWS capacity (e.g., 4 vCPUs), a minimum of 50 named users, and so on. For Standard Edition 2, as noted, it’s 10 Named Users per 8 vCPUs (which effectively works out to 10 per SE2 processor since one SE2 license = up to 4 vCPUs, the eight vCPU comes from two licenses).
- Universal Cloud Credits / BYOL: If you use Oracle’s “BYOL” cloud programs (like on OCI), Oracle may have its internal tracking, but on AWS, you simply abide by these on-paper minimums. There’s no cloud-specific user minimum beyond what’s in the contract.
- Application Users: For Oracle applications (E-Business Suite, etc.), licensing can be user-based (named user or employee counts). Those metrics remain the same on AWS – for example, if EBS module X requires a license per employee, you must have sufficient licenses for your employees; the cloud doesn’t change that. The minimums concept mostly applies to technical products (databases, middleware) with 25 NUP per processor rules.
- Don’t forget User Minimums in Virtual Environments: If you attempt to use NUP licensing for a database on AWS, ensure you still meet the minimum per processor and count all human and non-human users that access the DB. NUP on AWS is less common (because it’s tricky to manage in dynamic cloud setups), but it can be useful for small user-count scenarios. Remember that, for example, if only five users use the database, but Oracle requires 25 per processor, you still need to buy 25 – that’s the floor.
12. How does Oracle licensing work on Amazon RDS for Oracle?
Amazon RDS for Oracle is a managed database service, and licensing can be handled in two ways on RDS:
- License Included on RDS: For Oracle Standard Edition One/Two, you can launch RDS in “License Included” mode. Here, AWS bundles the Oracle license in the hourly cost. You don’t need to provide a license. This is great for those who don’t own Oracle licenses or want a fully managed experience without worrying about compliance. AWS ensures that Oracle is licensed properly for that instance. However, this is limited to Standard Edition (specifically SE2 nowadays) and certain versions. Also, if you use License Included RDS, you can’t use Enterprise Edition features or options since that offering isn’t available.
- BYOL on RDS: For Oracle Enterprise Edition, or if you prefer to use your existing licenses for Standard Edition (perhaps you have a site license or discount), you can use the BYOL model on RDS. In this case, when creating the RDS instance, you indicate you’ll bring your license. AWS will not charge you Oracle license fees, but you are responsible for having sufficient Oracle licenses to cover that RDS instance’s configuration. The calculation is the same as that for vCPU-based counting (RDS internally uses EC2 instances under the hood). So, a BYOL RDS instance with eight vCPUs requires 4 Oracle EE licenses from your pool.
- Tracking and Compliance: AWS helps by clarifying how many vCPUs your RDS instance has. However, you must ensure you’ve allocated the appropriate number of licenses in your organization for BYOL. Oracle can audit BYOL usage on RDS just as they would on EC2. One thing to note: if Oracle audits you, any License Included instances do not count against your owned licenses (since those licenses belong to AWS). So you would only need to demonstrate licensing for the BYOL deployments. It’s wise to keep an inventory of which RDS instances are BYOL vs included.
- Feature Differences: RDS for Oracle has some restrictions (for example, access to certain system privileges or features might be limited for managed service reasons). But from a licensing perspective, if you need an optional Oracle pack (like the Advanced Security Option for TDE) on RDS, you must also license that option via BYOL. AWS doesn’t provide most Enterprise Options in license-included fashion. So on RDS, you can use things like multi-tenant or TDE if you’re BYOL and have those licenses – and you must indicate that. For instance, using more than three pluggable databases (PDBs) in an Oracle 19c RDS instance would require you to have the Oracle Multitenant option licensed in addition to Enterprise Edition. RDS won’t stop you from using it if BYOL you useyou are responsible for compliance.
Read Oracle on AWS Licensing FAQs 1 of 4.
13. Are all Oracle Database editions available on RDS?
Amazon RDS for Oracle supports Oracle Database with some caveats:
- Standard Edition 2 (SE2): Yes, RDS supports SE2. SE2 is the edition that can be used with the License Included model (making it unique on AWS as a fully managed Oracle with no owned licenses needed). You can also use SE2 in BYOL mode on RDS if you prefer. Consider SE2’s limitations (no RAC, 16 vCPU instance max in RDS, though RDS might restrict instance sizes for Sgly).
- Enterprise Edition (EE): RDS supports Enterprise Edition only in BYOL mode. You must bring your own EE licenses. Many customers run production Oracle EE on RDS BYOL to offload the management using their existing licenses. All the EE features you have licenses for can be utilized (except for a few that might not be supported in the RDS environment due to technical constraints).
- Standard Edition 1 or old Standard Edition: Oracle SE1 and SE (prior editions) are legacy (SE1 is no longer sold, and SE was replaced by SE2 in 2015). RDS historically supported SE1 in License Included for older versions. Today, practically everything has moved to SE2. If you have an SE1 legacy app, you coit on an old version RDS instance that AWS might eventually deprecate; for new deployments, consider SE2.
- Express Edition (XE): RDS does not offer Oracle XE. If you want Oracle XE (which is free), you’d run it manually on an EC2 instance. RDS is focused on fully supported Oracle editions.
- RDS Custom: AWS introduced RDS Custom for Oracle, which is a managed/hosted solution for cases where you need sys/system access or custom configurations not permitted in standard RDS (for example, if you need to apply a specific patch or run Oracle E-Business Suite’s database). RDS Custom supports Enterprise Edition (and maybe SE2) but always in BYOL – no license is included in RDS Custom. Essentially, RDS Custom gives you more control (with the responsibility of your license) and is meant to run Oracle in previously only possible scenarios on EC2. It’s still a single-tenant managed VM but with more flexibility.
- Edition switching: If you start with SE2 on RDS License Included and need Enterprise features, you must migrate to a new RDS instance with Enterprise BYOL (there’s no in-place “upgrade” from SE2 LI to EE BYOL). Also note that AWS Outposts does not yet support RDS for Oracle (as of the latest updates), so RDS is only in AWS Regions.
14. What is Amazon RDS Custom for Oracle, and how does licensing apply?
RDS Custom for Oracle is a variant of Amazon RDS that allows more customization and direct operating system access for the Oracle database instance. This is useful for applications like Oracle E-Business Suite or third-party apps that require special Oracle database configurations or specific patches thadard RDS. Licensing for RDS Custom works as follows:
- BYOL Only: RDS Custom does not include Oracle licenses. You must bring your own Oracle Database license (Enterprise Edition typically) to use RDS Custom. AWS provides the infrastructure and management interface, but you are responsible for licensing as if it were an EC2 instance. All the vCPU counting rules apply the same way. For example, an RDS Custom instance with eight vCPUs requires 4 Oracle EE licenses from you, identical to an EC2 or regular RDS BYOL setup.
- Use Cases: RDS Custom is often used for Oracle E-Business Suite databases, since EBS requires certain patches and schema access that a normal RDS doesn’t allow. It’s also used if you need to run Oracle versions that RDS doesn’t normally support or need to access OS-level features (like SAP on Oracle, etc.). From a licensing perspective, these are typically Enterprise Edition databases with perhaps additional options (like Diagnostics Pack, etc., if used – those options must also be licensed BYOL).
- Support and Compliance: Even though AWS automates some of RDS Custom’s management, Oracle support and licensing treat it as a customer-managed environment. You have root/administrator access in RDS Custom, so you can run Oracle’s LMS audit scripts if needed. Oracle will expect you to have the proper licenses for the cores in use, and since RDS Custom might allow things like RAC (technically, RDS Custom currently doesn’t support RAC, but it can support Data Guard setups), you’d license those as if on EC2.
- Comparison to EC2: Think of RDS Custom as a middle ground between full DIY on EC2 and fully managed RDS. Licensing-wise, it’s closer to EC2 (BYOL). The benefit is that AWS still handles some automation (backups, etc.), but you trade that for needing to maintain compliance with Oracle licenses. Always ensure your license inventory accounts for any RDS Custom instances.
15. How do I license Oracle Database options (like RAC, Multitenant, Partitioning) on AWS?
Oracle’s database options and management packs (e.g., Real Application Clusters, Multitenant, Partitioning, Advanced Security, Diagnostics Pack, etc.) must be licensed separately on AWS, just as they are on-prem.
There is no difference in how you account for them: if you use an option on a database, you must have licenses for that option for every database processor.
Key points:
- Real Application Clusters (RAC): RAC is an Oracle Database Enterprise Edition option. Suppose you set up RAC on AWS (which requires EC2 instances and a shared storage mechanism – doable via third-party clustering solutions). In that case, you must license the Oracle RAC option and the base database. RAC option is licensed per processor on each node. So, if you have two EC2 instances with eight vCPUs each in a RAC cluster, you need Enterprise Edition licenses for both nodes (as usual) and RAC option licenses for both nodes’ processors. Note that AWS RDS does not offer RAC. This would be a custom setup on EC2 or VMware Cloud on AWS.
- Oracle Multitenant (Pluggable Databases): Multitenant is an option that lets you consolidate multiple databases (PDBs) into one container database. Oracle’s rule (starting 19c) is that you can have up to 3 PDBs in an EE database without the Multitenant license; if you use more than 3, you must license the Multitenant option. On AWS, if you’re running an EE database (BYOL on EC2 or RDS) and you create 10 PDBs in it, you must have the Multitenant option licensed for that server’s processors. Same cost structure as on-prem. If using RDS, AWS currently limits one user-created PDB per instance (so you wouldn’t need the option on standard RDS unless that changes). However, on EC2, nothing stops you technically from using many PDBs – just ensure the option is accounted for.
- Partitioning, Advanced Security, etc.: Each optional feature that Oracle sells separately (Partitioning, OLAP, Advanced Compression, Active Data Guard, etc.) must be counted. The licensing is, for example, if you use Partitioning on a 4-processor EE deployment on AWS, you need four licenses of Partitioning option in addition to the 4 EE licenses. AWS doesn’t bundle any of these in license-included offerings (Standard Edition doesn’t have these features anyway). So BYOL is the only way, and you must own the rights. Auditors frequently check feature usage on cloud databases via
DBA_FEATURE_USAGE_STATISTICS, so if something like Partitioning shows as used, they’ll expect you to have bought it. - Management Packs (Diagnostics/Tuning Pack): These packs are tied to Oracle Enterprise Manager or certain DB features (like AWR, performance hub). Often, DBAs enable them inadvertently. On AWS, if you spin up an EE database on EC2, those packs are available, and if you use them (e.g., run an AWR report), you incur license needs. Each pack is licensed per database processor. In some cases, RDS restricts access to such features unless you declare a license. Always ensure that you disable unlicensed options or have them in your Oracle contract.
- No special pricing: There’s no special cloud pricing – the options cost the same license-wise whether on AWS or on-prem.
16. Can I run Oracle Real Application Clusters (RAC) on AWS, and what are the licensing implications?
Running Oracle RAC on AWS is possible but not straightforward. AWS does natively support RAC in any managed service, so you’d be doing it on EC2 (or VMware on AWS) using third-party or custom setups (e.g., FlashGrid or your cluster stack).
If you do implement RAC on AWS:
- License both nodes fully: Oracle RAC means multiple instances of Oracle Database running on different servers accessing the same database. You must license each server’s vCPUs for Oracle Database Enterprise Edition (no change from a single-instance case) and the Oracle RAC option for those servers. So, a two-node RAC cluster effectively doubles the number of licenses needed compared to a single instance (since you’re running Oracle on two machines). There is no reduction or sharing – each processor in the cluster needs a database license and an RAC option license.
- No Standard Edition RAC with SE2: If someone tries to use Oracle Standard Edition RAC (allowed on old SE up to 11g with certain limits), note that SE2 discontinued RAC support. On AWS, the only feasible RAC is with Enterprise Edition. Standard Edition 2 cannot be clustered in RAC form, and RDS doesn’t offer it either.
- Technical challenges: AWS EC2 doesn’t provide shared storage, which RAC needs for the database files. Solutions like third-party storage software (FlashGrid, SIOS, etc.) or AWS EFS (in some cases) are used. Ensure whatever solution you use is supported because Oracle Support for RAC on AWS might require you to show that any issues aren’t due to an unsupported storage configuration. Some companies have successfully run RAC on AWS for high availability, but Oracle might not officially certify it. They will, however, support it as long as you’re on a supported OS and Oracle version, treating AWS as just hardware (with the caveat that they might ask you to reproduce issues on a non-AWS environment if it’s complex).
- License implications of RAC vs other HA: Remember that RAC is an expensive option. Many AWS architectures avoid RAC and instead use alternatives (like using Data Guard or Active Data Guard or relying on AWS Multi-AZ RDS or replication). Active Data Guard (the ability to open a standby DB for read) is a licensed option, but a read-only standby might be cheaper in licenses than a full RAC if you don’t need active-active writes. If high availability is needed and you want to reduce licenses, consider one primary and one standby on AWS (with Data Guard). Oracle permits one standby to be running in recovery mode without additional DB license if it’s truly idle/passive until failover (with a 10-day-per-year grace for testing) – beyond that, or if open read-only, you need to license it. In contrast, RAC has no “grace”; both nodes are active and need full licensing.
Read Oracle on AWS Licensing FAQs 3 of 4.
17. What are some common pitfalls in Oracle licensing on AWS
Organizations frequently make several mistakes when moving Oracle to AWS.
Being aware of these pitfalls can help avoid compliance problems and unexpected costs:
- Miscounting vCPUs/Core Licensing: A top pitfall is misunderstanding how to count AWS vCPUs for Oracle. Some underestimate (e.g., thinking four vCPUs = 1 license instead of the correct two vCPUs = 1 license), leading to under-licensing, while others overestimate (buying too many licenses by mistakenly counting every vCPU). Always apply Oracle’s official formula exactly. Double-check instance vCPU counts and ensure you’ve allocated the right licenses. Miscounting can result in significant shortfalls discovered at audit time.
- Applying On-Prem Rules Incorrectly: Companies sometimes apply the Oracle core factor table on AWS (not applicable), or assume they can cap CPU usage to reduce licensing (not allowed, as discussed). These incorrect assumptions can leave you out of compliance if you license too few or overspend if you buy too many. Remember: no core factor on AWS, and count maximum allocated vCPUs.
- Ignoring Developer/Test Deployments: It’s easy to spin up Oracle on AWS for dev/test and forget that those require licensing too. Oracle doesn’t automatically exempt non-production environments in the cloud. Unless you’re using Oracle’s free versions or have a special license, any running Oracle software in AWS – dev, test, QA, or DR – must be licensed via BYOL or license-included. A common scenario: a dev team launches an Oracle EE instance on AWS for a project without telling procurement. At audit time, those instances are discovered and need licensing. Always track all environments. In some agreements, Oracle offers discounted non-production licenses, but you must still acquire them.
- Unlicensed Options/Features: Oracle database software does not prevent you from using extra-cost options – it’s an honor system. In the cloud, a DBA might turn on something like Transparent Data Encryption (requires Advanced Security option license), Partitioning, or even accidentally use Diagnostic Pack features via OEM. These uses get recorded, and auditors will flag them. The pitfall is thinking, “If it’s a small use in cloud, it’s okay.” It’s not – one use of an option without a license is technically non-compliant. The solution is to disable explicitly features you haven’t licensed (Oracle provides parameter settings to disable packs, etc., or don’t install certain components).
- Overlooking AWS Infrastructure Changes: AWS makes it easy to change instance types, add replicas, or auto-scale. Each added instance needs licensing if you have an auto-scaling group of Oracle DB servers. If someone changes an instance to a larger type with more vCPUs, your license requirement increases immediately. Not tracking these changes can lead to gaps. It’s a pitfall to assume your licensing is “one-and-done” after initial deployment – in the cloud, you must continually govern and adjust as the infrastructure changes.
- ULA and Cloud Usage Misconception: If you have an Oracle Unlimited License Agreement, a pitfall is assuming it covers cloud deployments fully. As we’ll cover, Oracle ULAs have nuances in cloud (usage is allowed, but counting that usage at ULA end may not be allowed), which can trip you up if you rely on a ULA to cover expanding AWS usage without planning the exit properly.
18. How can I ensure Oracle license compliance on AWS to avoid audit issues?
Staying compliant with Oracle on AWS requires proactive management.
Here are the best practices to help avoid audit findings:
- Inventory and Document Everything: Maintain a centralized inventory of all AWS instances (EC2, RDS, Outposts, etc.) running Oracle software. Document the instance type, number of vCPUs, Oracle edition, and any available options for each. Keep this up to date as instances are added or changed. Also, track which licenses (by license number or contract) you allocate to each deployment. During an audit, this documentation will be your evidence to show what is deployed and how you calculated license needs.
- Use AWS Tools for Visibility: AWS tagging can help – tag instances that have Oracle software. AWS Config or Systems Manager Inventory can detect where Oracle might be installed (searching for Oracle DB installation paths, etc.). Some organizations use AWS License Manager, but note that AWS License Manager doesn’t natively know Oracle’s rules; you can input your own rules, but it’s not foolproof. Nevertheless, using automation to flag untagged Oracle installations or to track when an instance size changes is helpful for compliance oversight.
- Monitor Feature Usage: As mentioned, regularly check your Oracle databases for usage of extra-cost features. Oracle provides views like
DBA_FEATURE_USAGE_STATISTICSandDBA_OPTIONto see what’s been used. Do this at least quarterly on all databases. If you find that someone used Partitioning or turned on Active Data Guard, you can address it (either procure licenses or disable the feature and document that it was accidental). There are third-party tools and Oracle’s own LMS scripts that can automate gathering this info across instances. - License all Environments or Use Alternatives: Ensure all dev/test/QA instances are licensed or use permitted alternatives. For example, for development, you could use Oracle Database Personal Edition (if on Windows) or Oracle XE to avoid license needs, but these have limitations. If you use full Oracle EE in dev on AWS, you must own licenses (or use license-included for short-term dev instances that can be turned off when not used). Some clients use License Included RDS for dev/test (pay as you go) and BYOL for production to optimize costs while staying compliant. That’s a valid strategy.
- Limit Access and Educate Teams: Only allow authorized personnel to spin up Oracle instances in AWS (perhaps through a service catalog or approval process). Educate cloud engineers and DBAs on Oracle licensing basics so they don’t unknowingly create compliance issues. For instance, they should know not to use an m5.4xlarge instead of an m5.2xlarge without checking license availability or not to clone an Oracle AMI for a quick test without awareness of licensing. A little training goes a long way to avoid mistakes.
- Regular Audits and Reconciliation: Perform your internal “audit” at least annually. Reconcile your Oracle license entitlements (what you’ve purchased) against the AWS deployments. House of Brick (a licensing advisory firm) notes that it’s critical to know what licenses you own vs what’s deployed and to assign each deployment to an entitlement bucket. If you find a shortfall, address it before Oracle comes knocking. If you find excess licenses, that’s good – you have headroom (but note that support costs on unused licenses are wasteful, so optimize if possible).
By implementing these practices, you build a defensible position for an audit. Oracle audits in the cloud are just as rigorous as on-prem, so never assume “they can’t see in my cloud, so I’m safe.” You will be asked to provide evidence, which needs to be accurate.
19. How do Oracle Unlimited License Agreements (ULAs) work with AWS deployments?
Oracle Unlimited License Agreements (ULAs) grant unlimited use of certain Oracle products for a period, after which you certify usage. Using a ULA in AWS has some specific considerations and gotchas:
- ULA usage on AWS – allowed during term: If you have a ULA for, say, Oracle Database EE, it generally allows you to deploy unlimited instances of that product on any environment, including AWS, during the ULA term. Oracle’s policy explicitly permits ULAs to be used in Authorized Cloud Environments like AWS. This means you can scale out Oracle usage on AWS without immediate additional license cost, which is one of the appeals of a ULA.
- Certification exclusion: However, Oracle does not allow you to count AWS (or other public cloud) deployments toward your usage at the end of the ULA in the standard policy. In other words, when the ULA period ends, and you need to declare how many licenses to convert to perpetual, Oracle expects you to exclude any AWS-based instances from that count. The rationale (from Oracle’s perspective) is that you do not own cloud hardware, so they treat it differently for certification. This can be a nasty surprise: if you deployed heavily on AWS under the ULA, you don’t get to keep those deployments as perpetual rights unless you negotiate an amendment.
- Negotiating cloud-inclusive ULAs: Some customers negotiate ULAs that explicitly allow cloud deployments to be included in the final certification. This is something you’d have to get in writing in your ULA contract. If you plan to run a lot on AWS and eventually exit the ULA, try to negotiate that upfront. Otherwise, you might finish the ULA term and find that you’re suddenly under-licensed in AWS because you can’t count those toward your perpetual allotment.
- Document AWS usage anyway: Even though Oracle says not to include them at certification, you should still track how much you use AWS during the ULA. It’s important for capacity planning and any true-up if you exit the ULA early or choose to extend it. Also, Oracle might want to see that you indeed had rights to deploy on AWS during the term (which you do, but keeping records is wise).
- Post-ULA compliance: If you cannot count AWS instances and end up with a certain number of on-prem licenses certified, you’ll need to allocate some of those to AWS or buy additional licenses to cover AWS usage going forward. A common pitfall is a company ends a ULA assuming everything is fine, then realizes their AWS databases aren’t licensed because they couldn’t certify them. So plan for the end-state: reduce the AWS footprint or buy licenses. Some companies convert the ULA into a perpetual set and immediately purchase a cloud ULA or a subscription to cover the cloud—various strategies exist. Just don’t ignore the issue.
In summary, ULA can be used on AWS temporarily, but plan for long-term licensing because the standard ULA terms do not give you perpetual rights for those cloud deployments.
20. Can I use my Oracle ULA on AWS, and what are the caveats?
Yes, you can use an Oracle ULA on AWS, but as noted, the major caveat is that it is time for ULA certification. To answer directly:
- During ULA: Deploying on AWS is fine. For example, if you have an Oracle Database ULA, you can launch 50 EC2 instances with Oracle Database – all covered by the unlimited use rights. Oracle will still expect you to stay on supported configurations (supported OS versions, etc.), but AWS is not prohibited.
- Caveat – End of ULA: When the ULA term ends (typically 3-5 years), you have to declare the number of licenses to keep. Oracle’s default policy forbids counting cloud instances in that declaration. So those 50 EC2 instances we mentioned wouldn’t be counted. If your on-prem usage were 20 processors, you’d get 20 licenses, not including the cloud ones. Those 50 instances on AWS would then be unlicensed unless you reduce them or purchase licenses. This is the biggest caveat – it can lead to a huge compliance gap if not addressed.
- Possible Solutions:
- Extend or renew ULA: If you plan to stay on a ULA and negotiate renewal, you could continue unlimited use (including AWS) and push the issue out further, but at some cost.
- Cloud-specific ULA or Subscription: Oracle has begun offering “Oracle Cloud at Customer” and other subscription models. In some cases, you might convert a ULA into a subscription metric that allows cloud use. Evaluate if switching metrics is beneficial.
- Buying licenses for AWS at exit: If you must exit the ULA and can’t count AWS, budget to purchase the needed licenses for AWS workloads. Perhaps dropping some AWS instances or consolidating can minimize that number.
- Negotiate at signing: Ideally, negotiate language in the ULA contract that “Oracle will allow counting of Authorized Cloud Environment deployments in the certification.” Oracle may resist, but some customers have succeeded, especially if the ULA covers all deployments globally. Having that clause would remove the caveat.
