1. Why Oracle Licensing on AWS Costs Enterprises 2x More Than They Expect
Oracle licensing on AWS is the single biggest hidden cost in most cloud migration business cases. Enterprises routinely budget for AWS infrastructure costs — EC2 instances, storage, network — while dramatically underestimating the Oracle licensing obligations that come with running Oracle Database, Middleware, or applications on Amazon's cloud.
The reason is structural. Oracle's cloud licensing policy eliminates the Core Factor Table on AWS. On-premises, an Intel or AMD core carries a 0.5 core factor — meaning one processor licence covers two physical cores. On AWS, that factor disappears. One processor licence covers one physical core equivalent (two vCPUs). For the same workload, you need twice as many Oracle licences on AWS as you do on-premises.
At Oracle Database Enterprise Edition's list price of approximately $47,500 per processor licence — plus 22% annual support ($10,450/year) — doubling your licence count on AWS doesn't just increase costs incrementally. It can add $500K to $2M+ to a migration's true cost, depending on the size of your Oracle estate.
And unlike OCI, where Oracle's Support Rewards programme gives you 25 cents back for every dollar spent, AWS offers no Oracle-specific cost offsets. There are no Support Rewards, no bundled management packs, and no Oracle compliance monitoring. AWS doesn't police your Oracle usage. AWS doesn't report your Oracle deployments to Oracle. That sounds like freedom — until Oracle's audit team decides to exercise their contractual right to a full licence review.
I've advised enterprises that budgeted $800K for an AWS migration and discovered $1.4M in Oracle licensing costs they hadn't modelled. The infrastructure savings were real. The Oracle licensing bill wiped them out. This article exists so that doesn't happen to you.
A global manufacturer with 8,000 employees migrated Oracle Database workloads to AWS EC2 instances. They assumed their existing 16 on-premises processor licences (covering 32 cores at 0.5 core factor) would cover the same capacity on AWS. They were wrong — the 32 vCPUs on AWS required 16 licences, but Oracle's cloud policy meant those 16 licences only covered 16 vCPUs (32 cores × 0.5 = 16 on-prem, but 32 vCPUs ÷ 2 = 16 on AWS — same in this case, but their actual deployment used larger instances). After our assessment, we identified the gap and explored migrating to OCI where BYOL plus Support Rewards cut total costs by approximately 50%. See more case studies →
✓ ~50% total cost reduction by moving Oracle workloads to OCI🔍 Not sure how your Oracle licences map to AWS vCPUs? We'll audit your position for free.
Oracle Advisory Services →2. The vCPU Counting Rule — How Oracle Calculates Processor Licences on AWS
Every Oracle licensing conversation on AWS starts with the same question: how do vCPUs translate to processor licences? Oracle's licensing models were designed for physical hardware. AWS runs on virtualised infrastructure. The translation rules determine your entire cost structure.
The Core Rule: 2 vCPUs = 1 Processor Licence
On standard AWS EC2 instances with hyperthreading enabled (the default for virtually all instance types), every 2 vCPUs = 1 Oracle processor licence. Each vCPU represents a single hardware thread. Two threads = one physical core = one processor licence.
If hyperthreading is disabled (available on some instance types), each vCPU becomes a full physical core — and 1 vCPU = 1 processor licence. Disabling hyperthreading doesn't reduce your licence requirement; it changes the counting arithmetic but the cost per physical core remains the same.
The Conversion Table
| AWS Instance | vCPUs | Hyperthreading | Physical Cores | Oracle EE Licences Required |
|---|---|---|---|---|
| m5.xlarge | 4 | Enabled | 2 | 2 |
| m5.2xlarge | 8 | Enabled | 4 | 4 |
| m5.4xlarge | 16 | Enabled | 8 | 8 |
| m5.8xlarge | 32 | Enabled | 16 | 16 |
| r5.2xlarge (HT off) | 4* | Disabled | 4 | 4 |
* With hyperthreading disabled, the vCPU count reflects actual physical cores.
This is not optional. You cannot license a subset of an instance's vCPUs. If you deploy Oracle on a 16-vCPU EC2 instance, you need 8 processor licences — regardless of whether Oracle actually uses all 16 vCPUs. Oracle counts allocated capacity, not consumed capacity.
The most expensive mistake I see repeatedly: an enterprise assumes 1 vCPU = 1 licence. It's an easy error when you're used to on-premises core-factor counting. On AWS, an m5.4xlarge with 16 vCPUs needs 8 processor licences, not 16. But an m5.8xlarge with 32 vCPUs needs 16 — and at $47,500 list per licence, that's $760,000 in Oracle software before you've paid a cent to AWS. Get the counting right before you deploy. Remediation after the fact is exponentially more expensive.
For the definitive mapping across all major cloud platforms — OCI, AWS, Azure, and GCP — see our Oracle Cloud Licensing comparison guide. For the broader licensing framework, our Oracle Database Licensing Guide covers every metric and edition.
3. Oracle BYOL on AWS vs License Included — What Each Model Really Costs
AWS offers two distinct approaches to Oracle licensing, and the choice between them determines your cost structure, compliance obligations, and operational flexibility.
BYOL (Bring Your Own License) on AWS
Oracle BYOL on AWS means deploying Oracle software on EC2 instances using your existing perpetual licences. This is the only option for Oracle Database Enterprise Edition on AWS — Amazon RDS does not offer EE under a License Included model.
With BYOL, you pay AWS only for infrastructure (compute, storage, network) and continue paying Oracle's 22% annual support fee on the underlying licences. You're responsible for every aspect of Oracle cloud licensing compliance — counting vCPUs, tracking feature usage, ensuring option licences are in place, and documenting everything for a potential audit.
BYOL is also required if you want to self-manage Oracle on EC2 with custom configurations, RAC clusters, or specific patching schedules. It's the default choice for organisations with existing Oracle investments migrating to AWS.
License Included on Amazon RDS
License Included is available through Amazon RDS for Oracle — but only for Standard Edition One (SE1) and Standard Edition Two (SE2). Oracle Enterprise Edition is not available as License Included on RDS. The licence cost is bundled into the RDS hourly rate. You don't buy Oracle licences separately, AWS handles compliance, and you pay only for the hours the instance runs.
This model is ideal for development environments, testing, variable workloads that don't run 24/7, and applications that don't require Enterprise Edition features. If your database runs 40 hours per week instead of 168, License Included costs a fraction of perpetual licensing.
BYOL on AWS EC2
RDS License Included (SE2)
* Perpetual licence is a one-time purchase. Shown for total cost context. BYOL annual recurring cost is infrastructure + support.
Oracle Enterprise Edition is NOT available as License Included on AWS. If you need EE features — Partitioning, Advanced Compression, RAC, Data Guard, Multitenant, Diagnostics/Tuning Packs — you must bring your own licences. There is no pay-as-you-go option for Enterprise Edition on AWS. This is the single most important constraint in Oracle AWS licensing strategy.
For a complete Oracle BYOL guide across all cloud platforms, including the mechanics of transferring on-premises entitlements to cloud, see our linked resource. For the CIO-level strategic playbook on BYOL, our CIO Playbook for OCI and BYOL Strategy covers the governance and decision frameworks.
📊 Running Oracle on AWS and Unsure If BYOL Is Costing You More Than It Should?
Our Oracle licensing specialists model your AWS deployment costs against OCI BYOL and License Included alternatives — giving you a clear picture of where your money is going and where it could be saved.
CIO Playbook: Structuring Your Oracle Commercial Relationship for Maximum Leverage
Governance frameworks, negotiation sequencing, and vendor relationship management strategies for CIOs managing complex Oracle estates across on-premises and cloud.
Download White Paper →4. The Core Factor Trap — Why You Need Double the Licences on AWS
This is the section that saves — or costs — enterprises the most money. Oracle's pricing and licensing framework includes a Core Factor Table that reduces licence requirements on certain processor types. On-premises, Intel and AMD processors carry a 0.5 core factor. One licence covers two physical cores. For an 8-core Intel server, you need 4 Oracle Database EE processor licences.
On AWS, the Core Factor Table does not apply.
Oracle's Authorised Cloud Environment policy for AWS specifies a flat vCPU-to-licence mapping: 2 vCPUs = 1 licence. No core factor reduction. No exceptions. This effectively doubles your licence requirement compared to on-premises for the same physical compute capacity.
| Environment | Physical Cores | Core Factor | Oracle EE Licences | Licence Cost (List) |
|---|---|---|---|---|
| On-Premises (Intel Server) | 8 | 0.5 | 4 | $190,000 |
| AWS EC2 (16 vCPUs = 8 cores) | 8 | N/A — not applied | 8 | $380,000 |
| OCI (8 OCPUs = 8 cores) | 8 | N/A — 1:1 mapping | 8 | $380,000* |
* OCI licence count is the same, but BYOL infrastructure costs are lower and Support Rewards offset 25% of OCI spend.
The maths is painful. An enterprise with 32 physical cores on-premises needs 16 Oracle EE processor licences (32 × 0.5 = 16). Moving those workloads to AWS EC2 instances with equivalent 64 vCPUs still needs 32 licences (64 ÷ 2 = 32). That's an additional 16 licences at $47,500 each = $760,000 in unbudgeted Oracle licensing costs, plus $167,200 per year in incremental support.
This is the number-one budget surprise in every AWS migration I review. The cloud infrastructure business case looks great — AWS compute is cheaper than data centre hardware. Then the Oracle licensing reality lands: you need twice the licences, and Oracle doesn't offer a cloud discount on perpetual software. The infrastructure savings evaporate. Always model Oracle licence requirements at cloud counting rules before committing to a migration target.
For the complete picture of how Oracle licensing differs across cloud environments, including the specific policies for each authorised cloud, see our guide to Oracle licensing in cloud computing environments.
📊 Core Factor elimination could double your Oracle costs on AWS. We model the real numbers.
Oracle License Management →5. EC2 vs RDS vs Dedicated Hosts — AWS Deployment Models and Their Licensing Impact
How you deploy Oracle on AWS determines not only your operational model but your licensing obligations. Each AWS deployment pattern has distinct compliance implications that most enterprises don't fully understand until they're in an audit.
Self-Managed Oracle on EC2
Running Oracle on standard EC2 instances gives you complete control: any Oracle edition, any configuration, any version. You manage the OS, Oracle installation, patching, backup, and everything else. Licensing follows the standard vCPU rule — 2 vCPUs = 1 processor licence with hyperthreading enabled.
On shared EC2 instances (the default), you license the vCPUs allocated to your instance, not the underlying physical host. This is Oracle's concession for multi-tenant cloud environments — you don't need to license the entire AWS server, just your virtual machine's capacity.
Amazon RDS for Oracle
Amazon RDS is a managed database service. AWS handles provisioning, patching, backups, and failover. For Oracle, RDS supports two models: BYOL (any edition, including EE) and License Included (SE1/SE2 only). The licensing rules are the same — 2 vCPUs = 1 licence for BYOL. For License Included, the licence cost is in the hourly rate and AWS manages compliance.
The critical RDS limitation for Oracle: no RAC. Amazon RDS doesn't support Oracle Real Application Clusters. If you need RAC, you must self-manage on EC2 (or consider OCI). This alone drives many Enterprise Edition deployments to EC2 rather than RDS.
AWS Dedicated Hosts and Bare Metal
This is where licensing gets expensive. If you use AWS Dedicated Hosts or bare-metal instances (where you have exclusive access to an entire physical server), Oracle treats it like on-premises hardware. You must license every physical core on the host, even cores not running Oracle. The upside: Oracle's Core Factor Table does apply on Dedicated Hosts, since you're licensing physical hardware.
Some organisations use Dedicated Hosts to consolidate multiple Oracle VMs on a single fully-licensed host. This can be cost-effective if you maximise utilisation — but the upfront licence requirement (every core on a 48-core or 96-core host) is substantial.
| Deployment Model | Licence Counting | Core Factor? | Editions Available | Key Constraint |
|---|---|---|---|---|
| EC2 (Shared) | 2 vCPUs = 1 licence | No | All (BYOL) | Full self-management |
| RDS — BYOL | 2 vCPUs = 1 licence | No | All (BYOL) | No RAC, managed service limits |
| RDS — License Included | Bundled in hourly rate | N/A | SE1/SE2 only | No EE, no RAC |
| Dedicated Host | All physical cores on host | Yes (0.5 for Intel/AMD) | All (BYOL) | Must license entire host |
| Bare Metal (i3.metal etc.) | All physical cores | Yes | All (BYOL) | Full physical server licensing |
An APAC technology company was running Oracle on AWS EC2 instances with BYOL but hadn't accounted for the vCPU-to-licence mapping correctly. Our assessment found they were under-licensed by 12 processors — over $600K in compliance exposure at list price. We remediated the position before Oracle's audit notice arrived, restructured their deployment to right-size instances, and explored a partial migration to OCI for the most licence-intensive workloads. Read more case studies →
✓ $600K+ compliance exposure remediated pre-auditFor virtualisation-specific licensing guidance, including VMware Cloud on AWS scenarios, see our guides on Oracle licensing VMware audit strategies and Oracle audits in virtualised environments.
☁️ Running Oracle on AWS EC2? The Deployment Model You Chose Has Locked In Your Licensing Costs.
We've helped enterprises restructure their AWS Oracle deployments to reduce licence counts, right-size instances, and avoid compliance gaps — saving millions in the process.
Oracle Enterprise Negotiation Guide: Strategies, Tactics & Benchmarks for Every Agreement Type
Covers Oracle's sales structure, deal approval mechanics, quarter-end dynamics, and the specific tactics that shift leverage — with benchmarking data for ULAs, cloud transitions, and support renewals.
Download White Paper →6. Soft Partitioning, Hard Partitioning, and Why Neither Saves You on AWS
One of the most persistent misconceptions in Oracle licensing for virtualised environments is that you can limit your Oracle licence exposure by restricting CPU resources. On-premises, Oracle recognises a short list of approved hard partitioning technologies (Oracle VM, Solaris Zones, IBM LPAR) that allow you to license only the cores assigned to Oracle. Everything else — VMware, Hyper-V, Docker, Kubernetes, and all cloud instance partitioning — Oracle considers soft partitioning and refuses to recognise for licence reduction.
AWS is classified as a soft-partitioned environment by Oracle.
This has three specific consequences for Oracle licensing on AWS:
On shared EC2 instances: You must license all vCPUs allocated to the instance. You cannot run Oracle on a 16-vCPU instance and claim you only use 8 vCPUs. CPU cgroups, processor affinity settings, and AWS CPU credit limits don't count. Oracle requires licensing the full instance capacity.
On Dedicated Hosts: You must license every physical core on the entire host — even cores not running Oracle. If you provision a c5.metal Dedicated Host with 96 vCPUs (48 physical cores) and only run Oracle on a VM using 16 vCPUs, Oracle's position is that you must license all 48 physical cores. The Core Factor applies (0.5 for Intel), so you'd need 24 processor licences. This makes Dedicated Hosts economically viable only when you fully utilise the host with Oracle workloads.
No third-party capping tools count: Software that limits CPU utilisation (cgroups, CPU governors, AWS throttling) is not recognised by Oracle. Capping CPU at 50% in software does not halve your licence requirement.
Enterprises sometimes deploy Oracle on large EC2 instances and then use OS-level CPU affinity or container limits to restrict Oracle to a subset of cores, believing this reduces licence requirements. It does not. Oracle's auditors will count every vCPU allocated to the instance. In an audit, Oracle's LMS team will request your EC2 instance configurations and license the full vCPU count — regardless of any software-based restrictions you've applied.
The practical implication: right-size your EC2 instances to match your licence entitlements. If you own 8 processor licences, deploy Oracle on instances totalling 16 vCPUs — no more. Use multiple smaller instances rather than one oversized instance if it gives you better alignment between licensed capacity and actual consumption.
For a deeper dive into partitioning strategies and their audit implications, see our Oracle on VMware best practices guide.
💡 Think partitioning will reduce your Oracle licence count on AWS? It won't. We'll show you what will.
Oracle Contract Negotiation →7. Auto-Scaling, DR, and Read Replicas — The Hidden Oracle Licensing Traps on AWS
AWS's greatest strengths — elasticity, high availability, and managed failover — create some of Oracle licensing's most dangerous compliance traps. Every AWS feature that spins up compute capacity has a licence obligation attached.
Auto-Scaling and Oracle Licensing
Auto-scaling is a core AWS capability. When traffic spikes, new instances launch automatically. When it subsides, they terminate. For most workloads, this is efficient and cost-effective. For Oracle, it's a compliance minefield.
Every EC2 instance that starts with Oracle software requires a processor licence for the duration it runs. If your auto-scaling group scales from 5 to 10 Oracle instances, those 5 additional instances each need their own licences. If your Oracle licence pool covers 5 instances and auto-scaling doubles to 10, you're immediately out of compliance — and Oracle doesn't care that it was automated.
The same applies to CI/CD pipelines that bake Oracle into AMIs (Amazon Machine Images) and spin up instances for testing or deployment. Each instance requires licences.
Disaster Recovery and Multi-AZ Failover
Oracle's standard licensing policy requires licensing any standby database that is running. Multi-AZ deployments on RDS, Data Guard replicas, and cross-region failover instances are all "running" for licensing purposes. Oracle's limited exception — the 10-day rule — allows a completely idle backup to run up to 10 cumulative days per year for testing without licensing. But an always-on standby (which is the entire point of DR) requires full licensing.
For an enterprise running Oracle EE with 8 processor licences on a primary instance, adding a DR instance doubles the requirement to 16 licences. That's $380,000 in additional licence costs — plus $83,600/year in support — just for the standby.
Read Replicas
Amazon RDS supports Oracle read replicas. Each replica is a running Oracle instance and requires its own processor licences (for BYOL) or is covered by the RDS hourly rate (for License Included). If you create 3 read replicas of a 4-licence primary, you need 12 additional licences (3 × 4). This scales costs rapidly.
Here's what I tell every enterprise running Oracle on AWS: treat your Oracle licence pool as a hard capacity cap and enforce it in your cloud governance. Use AWS Systems Manager or custom Lambda functions to prevent auto-scaling events from exceeding your licensed capacity. Tag every Oracle instance. Monitor total vCPU allocation daily. If your infrastructure team can spin up Oracle instances without procurement knowing, you've already lost control of compliance. And Oracle's audit team will find the gap.
For audit defence strategies specific to cloud deployments, see our Oracle License Audits: Strategic Guide for CIOs.
💰 Hidden Licensing Costs in Your AWS Architecture? We Find the Gaps Oracle's Auditors Will.
We audit your AWS Oracle estate — EC2 instances, RDS deployments, auto-scaling groups, DR instances, and read replicas — to identify compliance gaps and cost optimisation opportunities before Oracle does.
Oracle Licence Audit Defence Playbook: A Complete Response Framework for LMS Engagements
When Oracle's LMS initiates contact, every response matters. This playbook equips IT, legal, and procurement teams with defence methodology, document management protocols, and settlement benchmarks.
Download White Paper →8. Oracle Standard Edition 2 on AWS — The Budget Option That Comes with Hard Limits
Oracle Database Standard Edition 2 (SE2) is dramatically cheaper than Enterprise Edition — a single SE2 licence costs approximately $17,500 versus $47,500 for EE. But on AWS, SE2 comes with hard constraints that can trip you up.
The 8-vCPU Ceiling
Oracle limits SE2 on AWS to instances with a maximum of 8 vCPUs (equivalent to 4 physical cores). This maps to Oracle's on-premises rule that SE2 is limited to 2 sockets. If you deploy SE2 on a 16-vCPU instance, you're out of compliance — Oracle considers this an Enterprise Edition deployment and will demand EE licences at $47,500 each.
This means SE2 is viable for smaller workloads — db.m5.xlarge (4 vCPUs, needing 1 SE2 licence) or db.m5.2xlarge (8 vCPUs, needing 2 SE2 licences) on RDS, or equivalent EC2 instances. The moment your workload outgrows 8 vCPUs, you need Enterprise Edition.
Feature Limitations
SE2 lacks the features that most enterprise Oracle workloads depend on: no Partitioning, no Advanced Compression, no RAC (though SE2 does include basic HA via Oracle Restart), no Data Guard (manual log shipping only), and a 3-PDB limit for Multitenant. If your application uses any EE-only feature, SE2 is not an option.
That said, for applications that genuinely fit within SE2's bounds, the cost advantage on AWS is massive. A 4-vCPU SE2 deployment on RDS with License Included costs a fraction of an equivalent EE BYOL setup.
DBAs sometimes enable EE-only features (like Partitioning or Diagnostics Pack) on SE2 databases without realising the licensing implication. Oracle's audit scripts detect feature usage regardless of edition. If your SE2 database shows usage of an EE feature, Oracle will claim EE licences are required — retroactively. Governance is essential: restrict DBA access to EE features on SE2 instances and run Oracle's feature usage report quarterly.
For the full breakdown of SE2 vs EE capabilities and costs, see our Oracle Database Licensing Guide.
📝 Not sure whether SE2 or EE is right for your AWS workloads? We'll map it out. Free consultation.
Book a Meeting →9. Oracle on AWS vs OCI — The Licensing Cost Comparison Oracle Wants You to See
Oracle has every incentive for you to run Oracle on OCI instead of AWS. And honestly? From a pure licensing economics perspective, they have a point. The cost differential is real — and it's significant.
| Factor | AWS | OCI |
|---|---|---|
| Core Factor Applies? | No — doubles licence count vs on-prem | No — but 1 OCPU = 1 licence is straightforward |
| Support Rewards | None | 25% back (33% for ULA) |
| Autonomous Database | Not available | Native — BYOL or License Included |
| Oracle Compliance Visibility | None — your responsibility | Oracle monitors BYOL declarations |
| Audit Risk Level | High | Lower |
| EE License Included Option | Not available | Available on ADB and DB Cloud Services |
| Managed Oracle Services | RDS (limited) | Full Autonomous DB, Exadata Cloud |
| RAC Support | Self-managed on EC2 only | Native on Autonomous DB and Exadata |
The total cost difference is stark. Consider a workload using 8 processor licences (16 vCPUs on AWS, 8 OCPUs on OCI):
On AWS (BYOL): ~$9,500 AWS infrastructure + $83,600 Oracle support = ~$93,100/year. No Support Rewards. No managed database. Full compliance burden on you.
On OCI (BYOL + Autonomous DB): ~$22,560 OCI infrastructure + $83,600 Oracle support − $5,640 Support Rewards = ~$100,520/year. But you get a fully managed Autonomous Database, included database options (Partitioning, Advanced Security, RAC up to 16 OCPUs), and reduced audit risk.
The OCI infrastructure cost is higher, but the total value — managed service, included options, Support Rewards, compliance monitoring — makes OCI significantly more cost-effective for Oracle-intensive workloads. The complete OCI vs AWS vs Azure vs GCP comparison covers every dimension.
That said, AWS makes sense when Oracle is a minority workload alongside a larger AWS-native estate, when you're running short-term Oracle deployments on RDS License Included, or when your organisation's strategic cloud platform is AWS and the operational cost of managing a second cloud provider (OCI) outweighs the Oracle licensing savings.
The honest answer: if Oracle is a significant part of your IT estate, OCI will almost always be cheaper to license. But if you have 500 workloads on AWS and 3 Oracle databases, the operational complexity of adding OCI may not justify the savings. The decision isn't binary — many of my clients run a hybrid model: Oracle on OCI for the licensing benefits, everything else on AWS. The key is making that decision with full cost visibility, not discovering the licensing gap after migration.
For the strategic playbook on cloud platform selection, see our guide to Oracle Licensing on Azure for the Azure alternative.
🛡️ AWS vs OCI for Oracle — We Model Both So You Can Decide with Real Numbers.
Whether you're committed to AWS or open to OCI, our independent cost analysis shows you the true total cost of ownership — including the licensing costs that cloud pricing calculators ignore.
Oracle Third-Party Support Decision Framework: Business Case, Vendor Selection & Transition Toolkit
Third-party support can deliver 50–70% annual savings. This framework provides a complete business case methodology, vendor assessment scorecard, and Oracle response playbook for organisations ready to cut support costs.
Download White Paper →10. Oracle Audit Risk on AWS — Why Cloud Doesn't Hide You
The most dangerous assumption in Oracle AWS licensing: "Oracle can't see what we're running on AWS, so audit risk is lower." The opposite is true. Oracle audit risk is higher on AWS because you carry 100% of the compliance burden with 0% of Oracle's monitoring assistance.
Oracle's contractual audit rights apply regardless of where the software runs. Oracle can — and routinely does — request full licence compliance data from organisations running Oracle on AWS. They don't need access to your AWS account. They request it from you, via the audit clause in your Oracle licence agreement.
Why AWS Deployments Get Audited
Oracle's audit triggers include cloud migration activity (moving workloads off on-premises to AWS), support renewal negotiations (Oracle checks whether your deployment matches your licence declarations), ULA certification events, and any reduction in Oracle spending. AWS migrations hit multiple triggers simultaneously: you're moving workloads, potentially reducing on-premises support, and Oracle's sales team has visibility into your reduced on-premises footprint.
In our Oracle audit defence engagements, cloud deployments are now the number one source of compliance gaps. The most common issues we remediate:
vCPU miscounting: Wrong licence-to-vCPU mapping (the 2:1 rule errors described in Section 2). Unlicensed options: Database features (Diagnostics Pack, Tuning Pack, Partitioning) enabled by default or by DBAs without licence procurement. Auto-scaling overshoot: Instances that temporarily exceeded the licensed pool. DR instances unlicensed: Standby databases running continuously without separate licences. SE2 breaches: Standard Edition 2 running on instances larger than 8 vCPUs.
A Fortune 500 financial services company received an Oracle LMS audit notification six months after migrating significant database workloads to AWS. Our pre-audit assessment found multiple compliance gaps: 3 instances running with more vCPUs than licences covered, Diagnostics Pack enabled on 7 databases without licences, and an always-on Data Guard replica requiring 8 additional processor licences. Total exposure: $1.8M at list. We negotiated a remediation plan that reduced the settlement to under $400K and restructured their AWS deployment to prevent recurrence. More case studies →
✓ $1.4M+ saved through pre-audit remediation and negotiationFor the top 10 Oracle audit triggers, our linked article explains exactly what draws Oracle's attention.
🔍 Oracle audit exposure on AWS? We've defended enterprises from both sides of the table.
Oracle Audit Defense →11. Cost Optimisation Strategies — 12 Ways to Reduce Oracle Licensing Costs on AWS
Oracle licensing on AWS is expensive by design. But there are legitimate strategies to optimise costs without compromising compliance.
- Right-size every Oracle instance. Match EC2 instance vCPUs exactly to your licence pool. Over-provisioning by even one instance size costs thousands in unnecessary licences. Use AWS Compute Optimizer data to identify right-sizing opportunities.
- Use RDS License Included for SE2 workloads. Any database that doesn't need Enterprise Edition should run on RDS with License Included. You pay by the hour, stop paying when the instance stops, and AWS handles compliance.
- Consolidate Oracle onto fewer, right-sized instances. Four 4-vCPU instances need the same 8 licences as one 16-vCPU instance. But if some of those databases can share an instance via Multitenant (EE only), you reduce total vCPU count.
- Evaluate SE2 for every workload. At $17,500 vs $47,500 per licence, SE2 saves nearly $30,000 per licence. If a workload fits within SE2's 8-vCPU limit and doesn't need EE features, the savings are immediate.
- Shut down non-production Oracle instances outside business hours. BYOL licences are perpetual and cover 24/7 use. But if non-production databases only run during business hours, consider License Included on RDS — paying for 40 hours instead of 168.
- Enforce Oracle licensing governance in your cloud landing zone. Use AWS Service Control Policies, IAM restrictions, and tagging requirements to prevent ungoverned Oracle deployments. If engineers can spin up Oracle AMIs without approval, your compliance exposure is unbounded.
- Consider OCI for Oracle-heavy workloads. The Support Rewards programme alone can justify moving Oracle to OCI while keeping everything else on AWS. A hybrid cloud strategy isn't ideal operationally, but the licensing savings can be substantial.
- Negotiate Oracle's cloud policy into your contract. Some enterprises successfully negotiate explicit AWS authorisation into their Oracle contracts, including specific vCPU counting rules and feature authorisations. This requires leverage — a renewal, a large purchase, or a ULA — but it provides contractual clarity that Oracle's generic policy doesn't.
- Migrate non-Oracle workloads off Oracle. The cheapest Oracle licence is the one you don't need. If peripheral databases can run on PostgreSQL, Aurora, or another open-source alternative, every Oracle instance you retire reduces your licence footprint.
- Use AWS Reserved Instances for long-running Oracle VMs. Your Oracle licence cost is fixed — squeeze savings from the AWS infrastructure side. Reserved Instances or Savings Plans reduce EC2 costs by 30-60%.
- Track and disable unused database options. Oracle's audit scripts detect feature usage. If Diagnostics Pack, Tuning Pack, or Advanced Compression is enabled but not actively used, disable it and document the remediation. Oracle licence management is a continuous process, not a one-time exercise.
- Get independent advice before major changes. Oracle's sales team will always model the scenario that favours Oracle. An independent Oracle licensing advisor models the scenarios Oracle won't — including the ones where Oracle earns less.
For specific UCC and OCI cost optimisation tactics, see our Top 10 UCC Optimisation Tips and OCI Cost Optimization FAQ. For the broader Oracle licence optimisation playbook, our linked guide covers strategies across all environments.
📈 Want Us to Model Your Oracle AWS Licensing Costs Against Alternatives? We Run the Numbers Oracle Won't.
Independent cost analysis across AWS BYOL, RDS License Included, OCI BYOL, and hybrid scenarios — with benchmarking data from hundreds of enterprise engagements.
12. ULA and Cloud: What Happens When Your Unlimited Agreement Meets AWS
If your organisation is under an Oracle Unlimited License Agreement (ULA), running Oracle on AWS adds complexity that can either maximise or destroy the ULA's value.
Can You Deploy on AWS During a ULA?
Most modern ULAs include authorised cloud environments — AWS, Azure, GCP — in the deployment scope. During the ULA term, you can deploy Oracle on AWS without worrying about individual licence counts (that's the "unlimited" part). But older ULAs may not include cloud authorisation. Check your ULA contract language before assuming AWS is covered.
The Certification Trap
The real risk is at ULA certification — when the ULA expires and you count your deployments to convert to perpetual licences. Every Oracle instance running on AWS at certification time gets counted. The vCPU-to-licence mapping applies (2 vCPUs = 1 processor licence). If you've proliferated Oracle across dozens of AWS instances during the ULA period, certification can lock in a very large (and permanent) licence count.
Some enterprises deliberately expand Oracle on AWS during the ULA to maximise their certified licence count. This is legitimate — but only if you plan to actually use those licences post-ULA. Certifying 200 licences you don't need means $440,000/year in perpetual support for software you're not using.
The ULA-AWS playbook depends on your post-ULA strategy. If you plan to continue running Oracle on AWS, maximise deployments before certification to lock in the largest possible perpetual licence pool. If you plan to reduce Oracle or migrate to alternatives, right-size your AWS deployments before certification to minimise the perpetual licence count (and its permanent support obligation). Get your ULA certification strategy right — it's a one-time decision with permanent cost implications.
For the comprehensive ULA playbook, including certification tactics, renewal negotiation, and exit strategies, see our Oracle ULA Complete Guide. For Oracle negotiation strategies that apply to ULA renewals and cloud transitions, our linked guide covers the tactical approaches.
A US healthcare organisation with 10,000 users completed their cloud migration (including significant AWS Oracle deployments) and then moved Oracle support to a third-party support provider. Annual support costs dropped from $1.8M to $780K — saving $1.02M per year while maintaining full database coverage. See support reduction case studies →
✓ $1.02M/year saved on Oracle support post-migration📞 Want to Talk to a Former Oracle Licensing Expert About Your AWS Strategy?
Whether you're migrating to AWS, already running Oracle on EC2, or trying to decide between AWS and OCI — we can help. No obligation. No Oracle bias. Just honest, independent advice.