Autoscaling makes a cloud Oracle footprint move minute by minute, which turns a single certified number into a moving target. The defensible count is the one your contract's basis supports and your cloud telemetry can prove, not the highest figure the platform briefly touched.
On premises, an Oracle processor count is mostly static. The cores in a server are the cores in a server, and they do not change between Tuesday and Friday. In the cloud, autoscaling breaks that stability. A deployment might run on eight virtual processors overnight, scale to forty at midday, and settle back by evening. When you go to certify that deployment, you face a question that has no on premises equivalent: which number is the count? This article works through how autoscaling interacts with the counting rules in a ULA, and how to land on a figure that is both fair and defensible.
Certification converts a deployed quantity into a permanent entitlement. The whole model assumes a deployment has a quantity you can point to. Autoscaling removes that assumption. The deployed quantity is now a distribution over time, with a baseline that always runs, a peak it sometimes reaches, and a long middle ground in between. None of those is obviously the right basis for a permanent license, and the contract does not always say which one applies.
Two consequences follow. The first is risk of overstatement: certifying the peak as if it ran constantly inflates the number beyond what the evidence supports, which an auditor can unwind. The second is risk of understatement: certifying only the baseline ignores capacity that genuinely ran for long periods and could legitimately count. The goal is neither the highest nor the lowest figure but the one that matches the contract's counting basis and survives inspection.
It depends on the contract, and the relevant language usually sits in two places: the cloud counting basis and any continuous run rule. The counting basis tells you whether the agreement measures a peak processor figure, a sustained figure, or the figure present on a defined measurement date. The continuous run rule, where it exists, tells you whether capacity has to persist for a period, commonly 365 days, to be eligible at all. Read together, these clauses decide how much of an autoscaling footprint enters the number.
Where the contract is silent on autoscaling specifically, which is common, you fall back on the general cloud counting method and on what you can evidence. Silence does not grant you the peak, and it does not force you to the baseline. It puts the burden on a defensible, evidenced interpretation, which is exactly where independent analysis earns its place.
Most counting bases reduce to one of three measures, and understanding each helps you read your own clause.
The baseline is the capacity that runs continuously, the floor the autoscaler never drops below. Baseline capacity is the most defensible part of an autoscaling count because it satisfies almost any continuous run requirement and is trivial to evidence. If your contract has a strict 365 day rule, the baseline is usually what clears it.
Sustained capacity is the level the deployment holds for meaningful, recurring periods, above the baseline but below the rare peak. A nightly batch window that runs at thirty processors for several hours every day is sustained capacity. Whether it counts depends on how the contract treats periodic running against any continuous requirement, and it is the area where careful evidence makes the difference between inclusion and exclusion.
The peak is the highest level the autoscaler ever reached, perhaps for an hour during an annual event. Certifying the peak as a permanent entitlement is the most aggressive reading and the easiest to challenge, because the evidence shows the capacity existed only briefly. The peak rarely belongs in a count unless the contract explicitly measures it.
Consider an indicative ecommerce platform running Oracle on an autoscaling cloud tier. Telemetry over the final year shows a baseline of 12 processors running continuously, a sustained nightly level of 28 processors for several hours most days, and a single peak of 96 processors during one seasonal event. Under a strict 365 day continuous rule, the defensible count centres on the 12 processor baseline. Under a sustained or average basis, a figure between baseline and the nightly level is arguable with strong evidence. The 96 processor peak almost never certifies as permanent. The figures are indicative and the basis is set by the clause.
Often only partly. Capacity that appears for minutes or hours and then disappears typically fails a continuous run requirement, so it does not certify as permanent entitlement. The portion that runs throughout the relevant period usually does. The practical answer is that an autoscaling deployment rarely counts as a single clean number. It counts as a baseline you can defend easily plus whatever additional sustained capacity your evidence and your contract together support. Pretending the transient peaks are permanent is how a cloud count becomes an audit finding.
Because the number is contestable, the evidence has to be unusually good. Cloud platforms record capacity telemetry, and that telemetry is the spine of the file. You want time series data showing virtual processor counts across the measurement period, the autoscaling configuration that defines the minimum and maximum, and a clear mapping from cloud capacity to countable Oracle processors under the contract's method. A written methodology explaining how you moved from raw telemetry to the certified figure is essential, because an autoscaling number that arrives without a method looks arbitrary. The broader principles are covered in evidence for cloud deployment counts.
The strength of this evidence cuts both ways. It protects a fair count from challenge, and it disciplines you against an unfair one, because the same telemetry that proves a sustained level also proves a peak was transient. Building the file honestly is what lets you certify the most you can legitimately claim and no more.
If autoscaling capacity matters to your number, the time to shape it is before the measurement period, not during it. Where a 365 day rule applies, capacity you want counted as baseline needs to be running as baseline for the full period, which means adjusting autoscaling floors well ahead of the exit. This is a planning decision that belongs in the same early window as the rest of the cloud strategy, and it interacts directly with whether your provider counts at all, which we cover in does Azure count toward your certification.
Autoscaling is one of the harder corners of cloud counting, and it rewards early, specific analysis. For the full exit framework it sits inside, start with our ULA exit strategy guide. To confirm whether your provider counts before you worry about how, read does Azure count toward your certification, and to build the file that holds the number up, read evidence for cloud deployment counts. Because the counting basis lives in your clause and the proof lives in your telemetry, an autoscaling estate is a clear case for an early review.
It depends on the contract. Some agreements count a peak processor figure, others a sustained or measurement date figure, and a 365 day continuous run rule may exclude capacity that does not persist. The counting basis has to be read from the clause and evidenced from cloud metrics.
Often only partly. Capacity that scales up briefly and falls away may not meet a continuous run requirement, while the baseline that runs throughout usually does. The defensible number is the one you can evidence from cloud telemetry against the contract's counting basis.
We turn autoscaling telemetry into a certified cloud count that matches your contract and holds up later.