How it is assessed
Projects every timestamp to the candidate, then calculates SQL P95/P99 and total CPU P99.
Candidate passes whenSQL P95 ≤ 70%; SQL P99 ≤ 90%; total CPU P99 ≤ 90%.
Methodology
CPU identifies the opportunity. Every required resource must support the target.
The assessment evaluates exact AWS-orderable candidates against collected workload evidence. It does not approve a smaller configuration from average CPU alone.
How it is assessed
Uses P95 less-elastic SQL and non-SQL OS memory with 20% headroom; installed RAM alone is not workload demand.
Candidate passes whenCandidate RAM meets the floor and applicable pressure/coupling checks.
How it is assessed
Derives per-interval file operations from cumulative counters and aggregates files before percentiles.
Candidate passes whenP95 ≤ 70% sustained capacity and P99 ≤ 90% maximum capacity.
How it is assessed
Derives MiB/s from file-byte deltas and evaluates it independently from IOPS.
Candidate passes whenP95 ≤ 70% sustained capacity and P99 ≤ 90% maximum capacity.
How it is assessed
Remaps tempdb demand when storage placement changes and checks unchanged storage compatibility.
Candidate passes whenCapacity and placement remain compatible with the target.
How it is assessed
Checks Region, edition, SQL version, Multi-AZ, processor configuration, and a separate verification oracle.
Candidate passes whenThe exact target is orderable and independent verification passes.
Decision policy
One primary answer, with uncertainty kept visible.
- The smallest action-ready candidate becomes the primary optimized target.
- A smaller validation-required candidate is shown separately as an additional opportunity.
- If measured capacity rejects every reduction, the workload stays as is.
- If data, catalog, or verification prevents a reliable conclusion, the report names that issue rather than presenting it as measured capacity.
See how the result is presented
Review the Layer 1 report structure and technical evidence hierarchy.