Oracle on AWS Licensing FAQs 4 of 4
31. Can I move my existing Oracle licenses to AWS (license mobility)?
Yes, you can use your existing Oracle licenses on AWS โ this is effectively the BYOL process, and Oracle permits it as an authorized cloud for AWS. There isnโt a formal โLicense Mobilityโ program (like Microsoft has) that you need to apply for; Oracle simply allows it under policy.
Key considerations:
- Verify your license agreement: Most Oracle perpetual licenses are based on the OMA/OLSA, which donโt explicitly forbid third-party cloud usage. Oracleโs policy document (noncontractual but guiding) explicitly authorizes AWS, Azure, and GCP to deploy your licenses. So generally, if you have X licenses on 31. Can I move my existing Oracle licenses to AWS (is there โlicense mobilityโ)?
Yes. Oracle allows you to use your existing licenses on AWS without a special mobility program โ essentially, BYOL covers this. You should: - Verify your contracts: Most standard Oracle licenses allow deployment on third-party infrastructure as long as you adhere to Oracleโs policies. AWS is explicitly an โAuthorized Cloud Environmentโ in Oracleโs policy. Thereโs typically no need to notify Oracle when you move a workload to AWS, but you must remain compliant (track where your licenses are used).
- Maintain support: Continue paying Oracle support for those licenses. Moving to AWS doesnโt pause support. If you have a support agreement, it stays in effect, and you can get help from Oracle for issues (as discussed in support-related questions).
- No extra fees: Oracle doesnโt charge a transfer fee for using licenses on AWS. You simply allocate some of your purchased licenses to cover the AWS deployment. For example, if you own 10 processor licenses on-prem and want to shift 4 to AWS, you can do so (just ensure you still license whatever remains on-prem properly). Some organizations document this internally or inform Oracle sales, but itโs not a formal requirement.
- Beware legacy clauses: In older Oracle agreements, there were sometimes restrictions labeled โASPโ or โoutsourcingโ clauses that required Oracle to consent to run the software on hardware not owned by the customer. If you have very old contracts, have them legally reviewed. However, Oracleโs current policy and practice treat AWS like any other customer-controlled deployment, and Oracle has publicly stated that customers may deploy in authorized clouds. If in doubt, seek clarification from Oracle or a licensing advisor, but moving licenses to AWS is generally straightforward.
- Document the allocation: Internally, keep a record (for audit purposes) that X licenses from contract #ABC are now being used for AWS EC2 instance XYZ (with Y vCPUs). This helps if Oracle audits you, so you can clearly show which licenses cover which deployments.
32. Can I run Oracle on AWS Outposts (on-premises AWS), and how is it licensed?
AWS Outposts is essentially AWS infrastructure installed in your data center. From Oracleโs perspective, Outpost is an extension of AWS EC2 to an on-prem location.
Licensing Oracle on Outposts follows the same rules as in AWS regions:
- Authorized Cloud Environment: AWS Outposts are provided by AWS and connected to an AWS region, so they are considered part of AWSโs cloud for licensing. The same vCPU counting (2 vCPUs = 1 license with hyper-threading) applies to instances on Outposts. You donโt get to treat Outposts as traditional on-prem hardware (so you cannot apply Oracle core factor or license a subset of cores outside the cloud formula). Count the vCPUs of your Outposts EC2 instances, such as those in the AWS cloud.
- BYOL on Outposts: All Oracle software on Outposts will be BYOL since Outposts doesnโt offer Oracle license-included RDS for Oracle. AWS Outposts initially only supported RDS for MySQL and PostgreSQL, and as of 2025, Oracle RDS isnโt available on Outposts. So if you want to run Oracle Database on Outposts, youโd likely install it on an Outposts EC2 instance using your licenses. The same goes for Oracle Middleware or EBS โ treat the Outpost server as just another EC2.
- Hybrid benefit: Outposts might be attractive for low-latency or data residency, but it doesnโt change Oracle licensing costs. You still need to license the full vCPUs of the Outpost instances. If anything, be careful: some might think, โOutpost is in my data center, so maybe my on-prem Oracle processor licenses with core factor apply.โ Oracleโs policy would say no โ Outposts is explicitly under the cloud licensing policy, not on-prem.
- Support & Certification: Oracle will support products on Outposts just as on AWS. From their view, itโs an AWS deployment. Ensure the OS and software versions are supported. If Oracle raises environment questions, treat Outposts like AWS in explaining it. Outposts is relatively new, but itโs essentially identical to AWS region from softwareโs point of view.
- Cost Consideration: One advantage: Outposts can allow you to use the existing network, possibly reduce some AWS data transfer costs, or provide consistency with on-prem apps. However, Oracle licensing doesnโt offer any cost break for Outposts specifically. So plan capacity and licenses as you would in AWS. If you move workloads from on-prem hardware (where you maybe used core factor) to Outposts, remember to adjust your license counts to the cloud model. For example, a 16-core on-prem server (Intel, factor 0.5) needed eight licenses on-prem. Still, the equivalent Outposts instance with 32 vCPUs (16 cores with HT) would also need eight licenses โ consistent, but ensure you recalc properly.
33. How is Oracle licensing handled on VMware Cloud on AWS?
VMware Cloud on AWS (VMC) lets you run a VMware vSphere cluster on AWS-managed hosts. Oracle licensing in this scenario follows Oracleโs standard rules for VMware virtualization, with some nuances:
- No change in Oracle policy: Oracle has not published a special policy for VMware Cloud on AWS; they treat it like any VMware environment. Oracleโs contract definition of โprocessor where the program is installed and/or runningโ is key. Oracle will require licensing all physical cores in any ESXi host where Oracle VMs reside or could potentially migrate to. On VMware Cloud, if you have a cluster of 3 ESXi hosts, you need to ensure Oracle workloads are contained if you want to limit licenses.
- Dedicated Cluster for Oracle: The best practice is to create a dedicated cluster (or SDDC) for Oracle workloads within VMC and enable VM-Host affinity rules to pin Oracle VMs to certain hosts. VMware Cloud on AWS now supports such affinity rules to keep a VM on a subset of hosts. By doing this, you can limit the number of hosts you must license. For example, if you have a 6-host VMC deployment but only want to license 2 hosts for Oracle, youโd create a cluster of 2 hosts for Oracle and pin those VMs there (and not allow them on the others). Then, license those two hostsโ cores (using the AWS vCPU count per host; in VMC, each host might have 36 cores / 72 vCPUs hyper-threaded, etc.).
- Counting licenses: Depending on the instance type, each VMC host has a certain core count (e.g., i3.metal has 36 cores with HT = 72 vCPUs). If you commit to licensing the whole host, the Oracle license count would be based on those physical cores. The Oracle cloud policy (2 vCPU = 1 license) doesnโt directly apply to VMware Cloud because that policy is for licensing on AWS EC2/RDS. In VMC, youโre essentially running on VMware virtualization โ Oracle might treat it under normal virtualization rules (license every physical core in each ESXi host, potentially using core factor if your contract allows it on that hardware). However, since VMware Cloud hosts are uniform and Oracleโs cloud policy doesnโt mention VMware, itโs safer to assume no core factor (Oracle could argue that VMware Cloud is an authorized cloud โ a gray area). To be conservative, many license experts recommend treating it like AWS: 2 vCPUs on those hosts = one license. But you could discuss with Oracle: sometimes theyโve accepted licensing just the pinned hosts with core factor 0.5 (like physical), because the hardware is known (e.g., 36 core Intel = 18 licenses per host if using factor 0.5). This is complex; get advice for your specific scenario.
- Oracle support on VMware Cloud: Oracleโs support stance is the same as any VMware โ they donโt certify VMware. Still, they will support issues (and VMware and Oracle have whitepapers to give customers confidence). Many companies run Oracle on VMware Cloud on AWS successfully. Just ensure you record how many hosts Oracle runs on and that youโve licensed those. If Oracle were to audit, they might ask for evidence of which hosts had Oracle VMs. VMwareโs tooling can show that via logs or the configured affinity rules.
- In summary,ย segmentation is key on VMware Cloud. If you scatter Oracle VMs across all hosts, Oracle could demand that all those hosts be fully licensed. If you contain them, you only license the contained hosts. The cloud aspect doesnโt change Oracleโs stance on VMwareโitโs about controlling and documenting VM mobility.
Read Oracle on AWS Licensing FAQs 3 of 4.
34. Can I use Oracle software provided on AWS Marketplace AMIs, and how are those licensed?
AWS Marketplace offers Amazon Machine Images (AMIs) with Oracle software (like Oracle Database or WebLogic pre-installed) for convenience. However, these do not include a license by default (unless explicitly stated).
Key points:
- BYOL AMIs: Most Oracle AMIs on AWS Marketplace are tagged as โBring Your Own License.โ This means that AWS provides the software bits, but itโs your responsibility to have a valid Oracle license to use it. For example, you can launch an โOracle Database 19c BYOLโ AMI,, which saves installation time. Still, as soon as itโs running, you must apply one of your Oracle licenses to that instance (counting vCPUs as usual). If you donโt have an Oracle license, that instance is not legally licensed โ the softwareโs there, but youโre unlicensed (think of it as installing Oracle without a key โ it will run, but you need a license to stay compliant).
- Developer AMIs: Some Oracle-provided AMIs are for development/test (for example, an Oracle Database image that includes a development license or trial license). Read the description: Oracle sometimes allows use of those for a limited time or non-production without a purchase, but with constraints. Typically, production use is not allowed without a proper license. These AMIs might be useful for a quick PoC or evaluation. Always check the โUsage termsโ on the marketplace listing. If itโs from Oracle and free, it usually references Oracleโs standard trial agreement.
- WebLogic on Marketplace: There are official Oracle WebLogic Server images for AWS. These also are BYOL. Oracle and AWS collaborated to certify WebLogic on AWS, but you still need to own WebLogic licenses (or a suite that includes it) to use them. The image might let you choose which edition (Standard vs Enterprise) on first boot, which then implies what license you must have.
- E-Business Suite on AWS: Oracle has provided some EBS Cloud Manager tooling, but EBS isnโt an AMI per se. However, some third parties have published Oracle EBS stack AMIs, which require you to have proper Oracle app licenses. Be cautious: running Oracle applications from someoneโs AMI doesnโt magically confer license rights.
- Support Implications: If you use an AWS-provided Oracle image and hit an issue, Oracle Support will treat it as if you installed the software normally, assuming you have a support contract. An AWS image doesnโt change anything except speeding up how quickly you get running. Make sure the versions align with what Oracle supports. The marketplace images are usually up-to-date and official (especially those provided by Oracle or AWS).
- Conclusion: AWS Marketplace Oracle images are a convenience, not a licensing shortcut. They are essentially pre-installed Oracle software and are waiting for your valid license to cover them. Read the fine print on any marketplace listing to ensure compliance.
35. How do I license Oracle if I run it on AWS in Docker/Kubernetes containers?
Running Oracle software in containers (e.g., Docker containers orchestrated by Kubernetes on AWS EKS or ECS) is becoming more common for microservices or for encapsulating the DB/App. Oracleโs licensing, however, does not have special container pricing โ it treats containers like any other deployment on a server:
- License the underlying nodes: If you run an Oracle Database container on a Kubernetes cluster in AWS, you must license the compute node (EC2 instance) on which that container runs. Oracle doesnโt license โper containerโ or โper pod.โ So if a Kubernetes worker node is eight vCPUs and can run the Oracle DB pod, you need 4 Oracle processor licenses for that node (assuming hyperthreading 2:1) โ even if the container only uses part of the node. If multiple Oracle containers run on one node, itโs still just that nodeโs capacity that matters (you donโt double-count).
- Contain the spread: In Kubernetes, pods can move across nodes. To avoid licensing every node in the cluster, you should taint or label nodes to dedicate specific nodes for Oracle workloads (affinity rules). For example, two nodes should be labeled for Oracle DB only, and Oracle pods should be scheduled there and nowhere else. Then, you only need to license those two nodes. If Oracle containers can roam to any of, say, 10 nodes, youโd have to license all 10 nodesโ vCPUs (regardless of whether the container is always running, the possibility means it is installed or running on those nodes).
- ECS/Fargate: If you use AWS ECS on EC2, same rule โ license the EC2 instances where the container might run. Using ECS or EKS on Fargate (serverless containers) is very tricky: Fargate doesnโt give you a dedicated machine assignment; tasks can run anywhere under the hood. Oracle hasnโt provided a clear way to license that. The safest interpretation is to license the entire Fargate pool or underlying hosts (which you canโt since theyโre multi-tenant). This effectively makes running Oracle in pure serverless container mode non-compliant in practice. To use Oracle in containers, stick to EC2-based nodes you control.
- Oracle-provided containers:ย Oracle provides Docker images for Oracle Database and WebLogic for ease of deployment (especially for development). However, using those in production requires the same licensing as installing them on a VM. The container images are just packaging. Do not confuse the ease of spinning up an Oracle container with โfreeโโitโs not.
- Auditing containers: Oracle may ask which physical/virtual servers Oracle software runs. If you use containers, you should be prepared to show a map of containers to nodes and prove that those nodes were fully licensed. Save Kubernetes deployment configs that show node selectors for Oracle pods as evidence that you constrained them.
- Bottom line: Containers do not reduce Oracle license requirements. Treat the environment underneath as the licensed entity. Use isolation techniques to limit where Oracle runs (to avoid needing to license an entire large cluster).
36. What is Oracle Database@AWS (Exadata on AWS), and how is it licensed?
Oracle Database@AWS is a service (announced in 2022 and previewed in 2024) where Oracle delivers its Exadata Database Service running in AWS data centers. Itโs essentially Oracle Cloudโs Exadata hardware and managed service, co-located in an AWS region and accessible through AWS.
Licensing for this works a bit differently, more like Oracleโs cloud:
- Service model: Oracle Database@AWS is sold through the AWS Marketplace, but itโs Oracle-managed. You have two options: BYOL or License-Included. If you BYOL, you bring your Oracle Database licenses to apply to the Exadata service (similar to how you would on OCI or RDS). If you choose license-included, the cost you pay (hourly/monthly) covers the Oracle licenses. This is akin to how RDS license-included works, but for Exadata (and handled by Oracle).
- Included Apps Support:ย Oracle specifically supports certain applications (E-Business Suite, PeopleSoft, JDE, etc.) on Database@AWS because, essentially, itโs like running on Exadata in Oracleโs cloud. This is a fully sanctioned environment for those apps.
- Why use it: It gives Oracle customers the performance of Exadata and Oracle-managed convenience while being in AWS for connectivity. From a licensing perspective, it can simplify things โ if you have a lot of Oracle licenses, you can use BYOL and just pay for infrastructure; if not, you can rent the licenses as part of the service.
- Support Rewards and Commitments: Using Database@AWS counts toward Oracle Support Rewards (you get credits against support costs) and also counts toward your AWS spend commitments, which is interesting. Itโs like a partnership benefit: AWS wins because you consume through them, and Oracle wins by providing the service.
- License specifics: If BYOL, the same per-core licensing applies, but Exadata uses Oracleโs OCPU concept. Oracle would likely tell you how many licenses you need for a given Exadata shape. Usually, 1 OCPU = 1 DB EE license (plus whatever options) in BYOL. If it is license-included, you just pay a rate. There is no need to count vCPUs; Oracle has done that internally.
- Keep compliance: If you BYOL to Database@AWS, those licenses are now being consumed there, so ensure youโre not also counting them elsewhere. Oracle will consider those licenses โin useโ on that service. The service by design should prevent you from using more than you bought (or you will be charged if you do license-included). Itโs slightly different from DIY on EC2 โ this is more controlled.
In summary, Database@AWS is Oracleโs answer to the hybrid cloud: it gives you Oracle-managed Exadata in AWS, with flexible licensing (BYOL or included). It doesnโt change Oracle licensing rules but simplifies execution since Oracle takes on the management. For customers, it can reduce compliance risk (Oracle is running it, so they ensure itโs properly licensed as long as you choose the correct BYOL or included option and have entitlements if BYOL).
37. How can we optimize Oracle licensing costs on AWS?
Optimizing Oracle license costs on AWS requires both technical and contractual strategies. Here are some effective approaches:
- Use the Rightsize and Use Standard Edition, if possible:ย Not every workload needs Enterprise Edition. Oracle SE2 on AWS (up to 8 vCPUs) can drastically cut license costs since itโs much cheaper per processor. Consider that architecture if your database is small enough or can be sharded into multiple SE2 instances. Similarly, donโt over-provision instance sizes โ an idle core on AWS still costs you an Oracle license (if BYOL, you paid for it and pay support yearly regardless of usage). Analyze CPU utilization and choose the smallest instance that meets performance needs. You can always scale up if needed, but oversizing means unnecessary licenses.
- Leverage License-Included for transient workloads: For dev/test environments that donโt run 24/7, using Amazon RDS license-included (for SE2) or even Database@AWS license-included can be cheaper than using your licenses. You pay only for hours used. For example, if the QA environment is up during office hours only, license-included hourly might save money vs. dedicating a purchased license (which incurs support 24/7). You can start/stop RDS instances as needed.
- Architect for high availability smartly: Active/passive setups can save licenses if the passive is truly idle. Oracleโs rules allow a passive failover (for disaster recovery) to be unlicensed if used <10 days/year for testing. On AWS, you can keep a stopped instance or an instance in recovery mode and only start it during failover or brief tests. If you adhere to the โ10-day ruleโ, you donโt need to license that standby database. But if you want instant failover with no downtime, consider using Data Guard without the Active Data Guard option (the standby is in mount mode, not open read-only โ that avoids needing an ADG license). If you can tolerate that, you save on the ADG option and possibly on licensing the standby if itโs idle except during a failover event.
- Consolidation (carefully): Oracleโs Multitenant option (if you license it) can let you run many PDBs in one container database, maximizing usage of one EC2 instanceโs capacity. Instead of 10 small DB instances, each on separate VMs (which might force you to license many vCPUs separately), you could run one bigger EC2 instance with 10 PDBs and license that one box fully. This requires the Multitenant option license and careful resource management, but it can be more license-efficient. Similarly, running multiple Oracle schemas in one database (if separation of concerns allows) can reduce the number of licenses if it leads to fewer total cores used. Just be mindful not to mix workloads in violation of any appโs restricted licenses (like donโt mix an EBS schema with non-EBS schema on the same DB without proper licensing).
- Take advantage of Oracle promotions or ULA wisely: If you have growing Oracle usage, sometimes a ULA can be cost-effective in the short term while you migrate to AWS (covering spikes in usage). But plan the ULA exit as discussed. Another angle: Oracle sometimes offers cloud-specific deals (like โbring a workload to OCI, get a discount on supportโ). AWS wonโt give you Oracle discounts, but Oracle might discount your licenses if you commit to some strategic partnership. Uncommon, but ask your Oracle rep if any programs exist for cloud migrations.
- Turn off unused services/features: Ensure youโre not accidentally incurring extra costs. Example: If you donโt need Oracle Partitioning, donโt create any partitioned tables, and you donโt have to license that option. If you donโt need Diagnostics Pack, disable the automatic collection of AWR/ASH so youโre not tempted to use it. This isnโt cost optimization in the sense of reducing base licenses, but it avoids needing to buy pricey add-ons. Cloud makes it easy to spin things up; be vigilant about what you use.
- Monitor and adjust: Continuously monitor usage. If a project using Oracle in AWS is retired, terminate those instances and potentially re-harvest the licenses elsewhere or consider dropping the support on them at the next renewal. Oracle support renewals are annual โ if you can identify unused licenses before the renewal, you could save costs by terminating those (though Oracle has rules around reinstatement if you drop support, so plan carefully). The dynamic nature of AWS can lead to orphaned resources (e.g., someone forgot to delete a test DB), which might mean you allocated a license for it. Regular audits of AWS accounts to find Oracle installations can help you reclaim and reuse licenses where needed.
Combining these tactics can significantly reduce the effective cost of running Oracle on AWS while staying compliant.
38. What happens if Iโm out of compliance with Oracle licenses on AWS (audit outcomes)?
Suppose Oracle audits you and finds youโre not properly licensed (short on licenses or using unlicensed options). In that case, the outcome on AWS is essentially the same as if it happened on-premises: you will be asked to resolve the compliance gap, typically by purchasing licenses and back-support fees to cover the period of unlicensed use.
Specifically:
- Purchasing required licenses:ย Oracle will quantify how many licenses you are short (e.g., you used 10 processors but owned 8, so two processors are unlicensed). It usually requires you to buy those two licenses at list price (or sometimes a negotiated rate if you handle it diplomatically). They may also require you to license any options or packs you used without entitlement. This can be expensive โ e.g., being caught using a diagnostics pack on 4 CPUs means buying four licenses of that pack.
- Backdated support costs: Oracle often asks for back support when those licenses were used without support. For instance, if the unlicensed usage went on for 2 years, they might charge 2 years of support plus reinstatement fees on those licenses in addition to the license purchase. However, in many audit settlements, Oracle might waive some back support if you agree to a larger purchase, a new ULA, etc. Itโs a negotiation at that point.
- Cease (in theory): Technically, if you donโt agree to remediation, Oracle could terminate your license agreement for breach, which would legally force you to stop using the software. In reality, Oracle doesnโt want to lose customers or prompt them to migrate away; they want the revenue. So it rarely gets to โstop using it nowโ โ instead, the pressure is on to buy whatโs needed. If you utterly refuse, you expose your company to legal liability for IP infringement. So, practically, you will need to either reduce usage to compliant levels or purchase licenses for the excess. Reducing usage on AWS could mean shutting down instances or migrating some Oracle workloads to alternative systems. Still, by the time of the audit, Oracle will insist on a purchase for past usage regardless of plans.
- Cloud nuance: One nuance on AWS โ if Oracle finds non-compliance, they might push you to consider moving to Oracle Cloud as part of the settlement (โWeโll give you a deal if you move X workload to OCIโ). Youโre not obligated; you can simply buy the licenses to fix AWS usage. But be prepared for that pitch.
- Audit fees: Oracle doesnโt typically charge the customer the audit cost (some vendors do if youโre found compliant; Oracleโs contracts usually allow audit at their expense). But the cost is in the license gap. Also, note that Oracleโs auditors (often LMS or a third-party firm like Deloitte) will want this resolved quickly so that it can strain procurement timelines.
- No penalty if fully compliant: If by chance Oracle audits you and youโre fully compliant (you had everything properly licensed), then nothing happens โ you get a report saying no issues (or minor observations). Oracle might be disappointed, but they move on. This underscores the value of internal audits; if you find a gap first, you can address it on your terms (maybe via reallocation or quietly buying a few licenses) rather than the high-pressure environment of an official audit.
In summary, the repercussions are financial. Thereโs no โfineโ legally, but the requirement to purchase enough licenses (often at less discount than you might normally get) can feel like a fine. The key is to avoid that by managing compliance proactively.
39. How does Oracle licensing on AWS compare to Azure and Google Cloud?
Oracleโs approach to licensing on the major public clouds (AWS, Microsoft Azure, and Google Cloud Platform) is very similar, with a few differences, mostly in service offerings rather than the core rules:
- vCPU Counting: All three (AWS, Azure, GCP) are recognized as โAuthorized Cloud Environments.โ Oracleโs policy says the same thing for each: if hyper-threading is enabled, two vCPUs = 1 Oracle Processor license; if not, one vCPU = 1 licenseใ1โ L53-L60ใ. Azure and GCP follow essentially the same rule as AWS. Historically, Azure VMs didnโt use hyper-threading, so a vCPU was a core, but newer Azure VM types do have hyper-threading. Oracleโs formula covers both scenarios. So, license calculations yield the same results on AWS, Azure, and GCP for equivalent CPU specs.
- No Core Factor on any: Just as AWS doesnโt get core factors, neither do Azure or GCPโOracleโs cloud policy explicitly includes all of them and says core factors donโt apply.
- License-Included Services: This is where thereโs a difference:
- AWS only offers licenses included for Oracle via RDS (and only for Standard Edition 1/2).
- Azure does not offer an Oracle database license-included service (until the new Oracle Database@Azure, which is an Exadata-like Database@AWS). Generally, you must BYOL on Azure for Oracle software; thereโs no RDS equivalent on Azure. So, everything on Azure is BYOL (database, middleware, etc.).
- GCP: Google Cloud similarly has no native Oracle-managed service. You can BYOL on VMs. Google hasย Bare Metal Solution, a dedicated physical server for Oracle, which you pay to rent, but you still pay BYOL for the Oracle software. GCPโs Bare Metal is akin to renting a hosted Oracle machine; Oracle counts those cores with the same rules.
- Oracle Cloud (OCI) differences: While not asked, for context โ OCI is Oracleโs cloud, where they do allow core factor indirectly and have different metrics (OCPUs), plus many license-included offerings. But between AWS/Azure/GCP, Oracle doesnโt favor one over the other in policy text. Theyโre all simply โthird-party cloudโ to Oracle.
- Support considerations: None of these clouds are โcertifiedโ by Oracle, but Oracle supports all similarly (as per earlier Q on support). There was some FUD that Oracle would not support Azure or AWS; thatโs largely dispelled now. Oracle even partnered with Microsoft to offer Oracle services integrated with Azure (similar to DB@AWS). So, practically, Oracle is cloud-agnostic in support as long as you pay.
- Compliance: same game: The compliance issue is identical if you deploy 10 Oracle EE instances without enough licenses on any of these clouds. Oracle will audit and pursue it the same way. Nothing about AWS makes Oracle any stricter or looser than if you were on Azure or GCP. The only difference might be anecdotal: Oracle sales reps might push OCI by highlighting AWS/Azure license costs, but thatโs sales strategy, not policy.
- Conclusion: The rules you follow for AWS (BYOL counting, no core factor, license metrics) you also follow for Azure and GCP. The cloud providers differ in what convenience they offer (Azure and GCP require full BYOL for DB, AWS has RDS for SE, which is an exception, OCI has many exceptions). So, if you understand Oracle on AWS, you also understand it for Azure/GCP.
40. How would an Oracle audit collect data for my AWS deployments?
In an Oracle audit, you are responsible for providing evidence of your Oracle deployments and usage, even on AWS. Oracle doesnโt have direct access to AWS to โscanโ your environment, so hereโs how it typically works:
- Audit letter and scope: Oracle (or its auditor firm) will send an audit notice asking for information about all Oracle deployments, including cloud environments. They may specifically ask, โDo you run Oracle on AWS/Azure/other clouds? Provide details.โ Itโs best to be transparent because hiding it can lead to worse findings later.
- Data gathering: Oracle will provide questionnaires and may request that you run Oracleโs LMS collection tools on each database or middleware instance. From the software perspective, these tools (scripts) gather details like the number of processors, options usage, etc. For AWS, youโll run these scripts on your EC2 instances or have the RDS team (via support) help gather equivalent data if RDS is BYOL. You might need to retrieve vCPU counts, instance types, and configurations from AWS. Oracle might ask for AWS account-level info showing the instances. They cannot directly get this from AWS โ you provide it.
- Evidence of licenses: Youโll also give Oracle your entitlement documents (proof of what licenses you own). Then itโs a mapping exercise: auditors map entitlements to deployments. On AWS, for example, you might provide a list: โEC2 instance i-abc123, type m5.4xlarge, 16 vCPUs, running Oracle Database EE 19c with Partitioning option, started on X date.โ Alongside, youโd say, โWe have 8 Processor licenses of EE and 8 of Partitioning covering this.โ Oracle may want to confirm the instanceโs vCPUs = 16, requiring eight licenses, etc.
- CloudTrail/Config logs: In some cases, Oracle might ask how long an instance has been running (to assess back-dated usage). AWS CloudTrail or AWS Config can show instance launch times. If you recently deleted an Oracle EC2 instance and think itโs gone, note that Oracle can request records or screenshots of past environments. Itโs on you to prove if something was short-lived or only used for test <30 days (Oracle might exclude short-term, transient usage if it truly was temporary and uninstalled โ but be ready to show it).
- No automatic โshelf auditโ from AWS: AWS will not report your Oracle usage to Oracle (AWS isnโt deputized for that). Oracle relies on the contractual right to audit you, and you must comply by providing information. Refusing to cooperate is a breach of contract, so itโs not advisable.
- Audit script output: Particularly for databases, the LMS script output will show if options were used (e.g., โPartitioning = TRUE, times used: 5โ). If you didnโt license that option, thatโs evidence against you. Those scripts also show the server’s CPU count. AWS will report something like โCPU cores: 8, threads: 16โ for an instance โ Oracle knows from that how many licenses should be there.
- Preparation: To smooth this, have your records (as we suggested in compliance best practices). During the audit, providing a clear, organized report of โhereโs every Oracle instance in AWS, with instance IDs, types, vCPUs, whatโs running, and the license covering itโ will make the process easier and show the auditors youโre on top of it. They will cross-verify with the script outputs. If something doesnโt match (e.g., the script finds an option use you didnโt account for), theyโll flag it.
- Finally,ย the auditors will compile a finding. You’re fine if you provided all the info and it aligns with entitlements. If not, they present the gaps. The fact that itโs AWS doesnโt change the outcome, except you might have additional details to gather (like mapping AWS instance IDs to Oracle installations). Itโs treated as any other environment in terms of compliance.
In short, Oracle audits AWS deployments by asking for dataโbe prepared to deliver precise information about every Oracle workload in the cloud, just as you would for on-prem servers. Being organized and truthful is the best way to get through it with minimal pain.
