How Oracle Collects Audit Data for AWS Deployments
When Oracle initiates a license audit, the process for your AWS-based Oracle deployments is similar to traditional environments—but it involves extra steps because Oracle can’t directly access AWS to scan your environment.
You must provide detailed documentation and evidence yourself.
Below is a practical guide on how Oracle gathers audit data from AWS and what to expect during the audit.
Step 1: Oracle Sends Audit Notification and Scope
Oracle (or a contracted auditor like Deloitte or KPMG) begins an audit with a clear, formal letter:
- Request disclosure of all Oracle software deployments.
- Explicitly ask about deployments on cloud environments such as AWS, Azure, or GCP.
- Best practice: Be transparent. Disclosing AWS deployments upfront avoids severe compliance issues later.
Example Audit Request:
- “Confirm if you run Oracle software on AWS or other public clouds. Provide detailed information including instance types, software versions, and options.”
Read Oracle on AWS Licensing FAQs 4 of 4.
Step 2: Data Collection and Evidence Required by Oracle
Oracle auditors provide clear instructions and questionnaires to collect data:
- Typically, you’ll run Oracle-provided scripts (e.g., Oracle LMS Collection Tool scripts) on all EC2 instances hosting Oracle software.
- Scripts identify:
- Number of CPU cores and threads.
- Oracle software installed (version, edition).
- Database options or packs are used (partitioning, diagnostics pack, etc.).
- You provide output data to Oracle, as they have no direct access to AWS.
Example Clearly Explained:
- Run LMS scripts on your Oracle EC2 instance.
- LMS output example:
"Oracle Database EE 19c, Partitioning: TRUE (used 5 times), 8 CPU cores, 16 threads (hyper-threaded)".
Step 3: Gathering AWS Infrastructure Information
Oracle expects you to map your AWS infrastructure details to your Oracle deployments:
- Provide exact EC2 instance IDs and types.
- Document instance specs: vCPU counts, launch dates, and software installed.
Practical Example Clearly Explained:
"EC2 instance ID: i-abc123, instance type: m5.4xlarge, 16 vCPUs, running Oracle Database EE 19c with Partitioning option since July 1, 2024."- Match Oracle license entitlements to instance specs:
- 16 vCPUs (with hyper-threading) = 8 Processor licenses required.
- Confirm clearly that you have at least 8 Processor licenses.
Step 4: Proof of License Entitlements
You must provide Oracle-documented evidence of your license entitlements (purchase records, license agreements, support contracts):
- Oracle auditors cross-reference your license documents with the data collected from your AWS deployments.
- Any discrepancies between entitlements and deployment data indicate license compliance issues.
Example License Documentation Provided:
"Purchased 8 Processor licenses for Oracle Database EE, including Partitioning option, Order #12345 dated March 2023."- Oracle checks if your AWS deployment (16 vCPUs, requiring 8 Processor licenses) matches your documented entitlements.
Read Oracle Licensing on AWS vs. Azure and Google Cloud.
Step 5: Historical Evidence via AWS CloudTrail and AWS Config Logs
Oracle may ask how long instances have been running to assess licensing timelines and potential backdated usage:
- AWS CloudTrail or Config logs clearly show instance start dates, shutdowns, and historical usage.
- If Oracle software was recently removed, you may still need to clearly prove that it was short-lived or used for non-production purposes.
Example Scenario Clearly Explained:
- You deleted a temporary Oracle DB after 20 days of testing:
- Provide CloudTrail logs clearly showing launch/deletion dates.
- Oracle may exclude transient use clearly under 30 days, but you must prove transient usage with logs or documentation.
Step 6: No Direct AWS-to-Oracle Reporting
AWS does not automatically report your Oracle usage to Oracle.
- AWS has no contractual obligation to assist Oracle in audits.
- You, the customer, are responsible for disclosing and documenting Oracle usage on AWS.
Important noted:
- Refusal to provide data breaches your Oracle agreement, potentially escalating compliance issues and penalties.
Step 7: Final Audit Findings and Compliance Assessment
Oracle auditors consolidate all collected evidence:
- Cross-check LMS script outputs against provided license entitlements and AWS infrastructure data.
- Identify gaps or discrepancies (e.g., unauthorized use of database options, insufficient licenses).
Example Audit Outcome Explained:
- If LMS scripts reveal Partitioning = TRUE but no corresponding licenses are documented, auditors flag this as non-compliant usage.
- Oracle calculates additional license purchases and backdated support fees based on these findings.
Practical Example: Clearly Illustrated Oracle Audit Data Collection on AWS
- Oracle audit notice received: disclose AWS use transparently.
- Run LMS scripts on Oracle Database EC2 instances clearly:
- The script shows eight cores and 16 vCPUs that are hyper-threaded using the EE and Partitioning options.
- Provide AWS instance details clearly:
- Instance type: r5.4xlarge, instance ID provided.
- Provide license entitlement documents:
- Purchased 8 Processor licenses for Oracle Database EE, clearly including Partitioning.
- Oracle verifies that your entitlement matches your AWS usage clearly:
- Confirmed compliant—no additional licenses required.
- You must remediate if you are non-compliant (e.g., missing Partitioning licenses).
Clearly Explained Best Practices for Audit Preparation
Follow these practical tips to prepare clearly for Oracle audits involving AWS:
- ✅ Maintain Accurate, Up-to-Date Documentation
Keep records of AWS instances, Oracle installations, license allocations, and instance launch dates. - ✅ Regularly Run Internal License Reviews Clearly
Proactively identify potential gaps to resolve them clearly before Oracle audits occur. - ✅ Clearly Label and Document Oracle Instances on AWS
Clear naming conventions for AWS EC2 instances and tags should simplify identification during audits. - ✅ Utilize AWS Tools Clearly for Historical Data
Use AWS CloudTrail or AWS Config to demonstrate instance usage history, launch times, and deletions. - ✅ Cooperate with Oracle Auditors
Transparency mitigates risks. Promptly respond to auditor questions and provide comprehensive documentation.
Common Misunderstandings Clarified
- Misconception: “Oracle can directly access my AWS account to audit.”
Clarification: Oracle has no direct AWS access. You must provide all audit evidence yourself. - Misconception: “If I quickly delete Oracle instances from AWS, Oracle won’t find out.”
Clarification: Oracle expects historical records. Documented CloudTrail logs are still required to verify transient or historical usage. - Misconception: “AWS automatically reports Oracle usage to Oracle.”
Clarification: AWS never provides Oracle audit information clearly unless you voluntarily submit details.
Conclusion: Clearly Understanding Oracle Audit Data Collection on AWS
Oracle audits of AWS deployments require you, the customer, to collect and submit detailed deployment, usage, and license entitlement data yourself. Oracle has no direct AWS access, relying instead on your documented evidence.
Proactive, clear record-keeping, accurate internal license reviews, and transparent cooperation during the audit ensure a smoother, less stressful Oracle audit experience, clearly reducing compliance risks and potential financial penalties.
