Every Oracle cloud finding starts as an assumption about your maximum footprint. The auditor takes the instance shapes they can see, applies the counting rule in the way most favourable to Oracle, and treats the largest configuration as the licensed configuration. That preliminary number is an opening position, not a measurement, and the only thing that moves it is evidence. The cloud has a quiet advantage here that on premises estates rarely enjoy: the provider logs almost everything, independently of Oracle, in records you control. A disciplined cloud evidence file turns those logs into the most powerful argument you have, because it replaces Oracle's assumption with the provider's own account of what actually ran.
What is a cloud evidence file?
A cloud evidence file is the organised, dated record from your cloud provider that establishes exactly which Oracle programs ran, on which instance shapes, with what processor configuration, and over what periods. It is not a single screenshot or a spreadsheet someone typed up from memory. It is a structured collection of provider generated artefacts, each one traceable to the console or log it came from, assembled so that any line in the audit count can be tested against a corresponding line of evidence. The point of the file is to make the count auditable in the other direction. Where Oracle says you owe licenses for a configuration, the file shows whether that configuration ever existed, for how long, and under what CPU settings, so the conversation moves from assertion to record.
Why does cloud evidence reduce an audit finding?
Cloud evidence reduces a finding because the preliminary number is almost always built on the wrong footprint. Auditors reach for the maximum visible configuration, count autoscaling peaks as if they were permanent, treat short lived test instances as production, and frequently assume hyperthreading is off when it is on, doubling the license count under the authorized cloud environment rule. Each of those assumptions is a place where provider evidence can prove a smaller, accurate reality. Independent line by line review of findings typically cuts the claim 60 to 80 percent, and in cloud cases the provider logs are what make that reduction defensible rather than merely asserted. The reduction is not negotiation theatre. It is the difference between the footprint Oracle assumed and the footprint the provider recorded.
| Auditor assumption | Reality the evidence can show | Provider source |
|---|---|---|
| Peak autoscaling is permanent | Brief, intermittent scaling events | Scaling and activity logs |
| Hyperthreading is off | Hyperthreading enabled, 2 vCPUs per license | Instance shape configuration |
| Test instances are production | Non production, limited running hours | Tagging and cost reports |
| Instances ran the whole term | Decommissioned partway through | Resource lifecycle logs |
Where does cloud evidence come from?
Cloud evidence comes from the provider's own console and logging services, which record your activity independently of any Oracle script. On AWS the core sources are CloudTrail for the history of what was launched and changed, Cost Explorer and the cost and usage report for what ran and for how long, and the EC2 console for instance shapes and configuration. On Azure the equivalents are the activity log, cost management and billing exports, and the resource configuration for each virtual machine. These records matter precisely because they are not Oracle's. Running Oracle's collection scripts at all is a decision rather than an obligation, and Oracle's scripts can overcount across virtualization and cloud layers, so a buyer is far better served by provider evidence that the auditor cannot characterise as self serving Oracle output.
What should the file contain?
The file should contain enough to reconstruct the licensed footprint for every Oracle program in scope, with each fact tied to its source. That means an inventory of the instances that ran Oracle software, the shape and vCPU count of each, the hyperthreading or processor configuration that determines the counting rule, the running periods including start and decommission dates, the environment classification separating production from test and disaster recovery, and the provider artefacts that evidence each of those. It should also capture the disaster recovery picture, because the 10 day rule that allows limited testing of a failover environment each year can change whether a standby instance needs full licensing. A file that records all of this lets you answer any line of the finding with a corresponding line of proof.
- Instance inventory: every shape that ran an Oracle program, with vCPU count.
- Processor configuration: hyperthreading state, since it sets the vCPUs per license ratio.
- Running periods: launch and decommission dates from the lifecycle logs.
- Environment tags: production, non production, and disaster recovery separated.
- Disaster recovery detail: failover use against the 10 day rule.
- Source links: the console export or log that evidences each entry.
How do you handle disaster recovery in the cloud?
Disaster recovery in the cloud is one of the most common places a finding inflates, because a standby instance that sits idle still looks licensable to an auditor counting shapes. The 10 day rule allows a limited number of days of testing on a failover environment each year without separate licensing, and a cold standby that is genuinely not running Oracle does not carry the same liability as an active one. The evidence file should make the disaster recovery posture explicit: whether the standby is cold, warm or active, how many days it actually ran Oracle, and what the provider logs show about its lifecycle. This is a contract dependent area, so the precise treatment turns on your agreement, and the file exists to support whatever position the contract allows rather than to concede the auditor's assumption that every standby is a full production node.
A financial services firm received a cloud finding that counted every instance in an autoscaling group at peak, assumed hyperthreading was off, and treated a warm disaster recovery node as production. The buyer side team assembled the evidence file from AWS CloudTrail, the cost and usage report, and the EC2 configuration. The logs showed the scaling peaks lasted minutes rather than being permanent, confirmed hyperthreading was enabled so the 2 vCPUs per license rule applied, and demonstrated the disaster recovery node ran Oracle for only a handful of test days within the 10 day allowance. Reconstructed from evidence, the defensible count fell well into the 60 to 80 percent reduction band, and the remaining position was settled commercially.
What triggers the scrutiny in the first place?
Cloud migration is itself a recognised audit trigger, sitting alongside virtualization, Java downloads without a subscription, mergers and acquisitions, declining support spend, and rejected sales proposals. When a workload leaves Oracle's infrastructure for a competitor's cloud, the account team has both a revenue gap and a complex new estate to examine, and the audit is also the channel through which Oracle steers the resolution toward an OCI commitment. Knowing the trigger lets you prepare the evidence file before the letter arrives rather than after, so that the moment scrutiny begins you are reconstructing from contemporaneous logs rather than trying to recover a history that the provider may only retain for a limited window.
What is the buyer move?
The buyer move is to build the evidence file early, from the provider's own records, and to let it carry the count rather than conceding Oracle's assumed footprint. Capture instance shapes, processor configuration, running periods and environment classification while the logs still exist, classify disaster recovery against the 10 day rule, and tie every entry to a source the auditor cannot dismiss as Oracle output. With that file in hand, each line of the finding can be tested against a line of evidence, which is how a preliminary cloud number gets reduced to a defensible one and the remaining gap moves into a commercial conversation you control.
For the rule the count is built on, see the authorized cloud environment policy. For the commercial wrapper Oracle proposes, see OCI licensing and universal credits. The full method sits in the Oracle virtualization licensing guide.