Cost Control
Part of Cloud resource optimisation
Right-sizing compute after measuring workload
Measure busy workload demand, screen compute sizes and check application results before treating a resize as a saving.
Right-size existing compute after observing a representative workload cycle. Choose a configuration that completes required work during busy periods while preserving appropriate headroom. Low average CPU is a reason to investigate, not evidence that a smaller instance will work.
Measure the work and its limits
Name the application or job, its owner, normal hours, busy periods and infrequent events that affect demand. Include relevant batch jobs and known peaks, such as an annual peak, when setting the observation window.
Use a window that covers the full relevant demand cycle, and record its start and end dates and which events occurred. If an important peak was not observed, treat that requirement as unassessed rather than assuming recent usage represents it.
Collect request or job counts, completed actions, latency, errors and queue length. Measure CPU, memory, disk I/O and network use wherever each could constrain the work; record the current instance size and count and any scaling settings.
Separate observed demand from forecasts. Ordinary recent usage cannot establish the effect of a coming launch or annual peak. A quiet recovery standby may also be intentionally underused.
Provider recommendation windows are useful checks, but do not by themselves prove that the workload's relevant cycle was covered. AWS Compute Optimizer analyses specifications and CloudWatch metrics from the last 14 days; enhanced infrastructure metrics can extend analysis to up to 93 days.
For EC2 recommendations, AWS Compute Optimizer uses the maximum utilisation point in each five-minute interval. Its analysis can take up to 24 hours, and its preferences let you adjust CPU headroom and threshold and memory headroom for EC2.
Azure Advisor's VM resize recommendations use CPU, memory and outbound network utilisation. It analyses the last 7 days by default; available lookback periods are 7, 14, 21, 30, 60 and 90 days. After a lookback change, recommendations can take up to 48 hours to update.
Google Compute Engine recommendations use Cloud Monitoring system metrics from the previous 8 days. Google says the algorithm suits workloads with weekly patterns, workloads that grow or shrink over weeks, and workloads that persistently underutilise or are throttled by insufficient resources. These tools do not check the complete business action.
Key Metrics to Monitor During Workload Measurement
- Memory Usage
- Peak consumption across observation window
- Disk I/O
- Read/write operations per second during peak demand
- Network Outbound Traffic
- Utilisation by VM (Azure) or instance (GCP)
Screen a candidate size
| Check | Question |
|---|---|
| Capacity | Can it handle observed busy work and a stated growth allowance? |
| Compatibility | Does it support required disks, network features, software and architecture? |
| Scaling | Will the change affect instance count, limits or deployment overlap? |
| Recovery | Can the team return to the earlier configuration if required? |
| Cost | What changes at actual account rates and with existing commitments? |
Use provider recommendations to shortlist candidates, then check each against the measured workload and application limits. A smaller candidate is viable only if busy-period demand still completes required work within response-time, error and queue limits, and relevant CPU, memory, disk or network constraints fit.
Set headroom against observed busy demand, known workload events and application requirements, and record the rationale. AWS Compute Optimizer exposes headroom preferences, but a low average or a tool recommendation alone does not establish that the candidate is safe.
A resize may require a restart or replacement, depending on the service and method; account for that in the change plan. A lower unit price need not lower the total bill if instance count, storage or commitment use changes.
Check the action and charge
Before the change, record the existing configuration and define the application-level pass conditions and the point at which you would return to the earlier configuration. Plan for any required restart or replacement, and include background jobs where they affect the result.
After the change, check completed work, response time, errors, queueing and the resources the resize was intended to address at relevant normal and busy demand. Record the result only after performing the check; if an important peak was not covered, leave that requirement unassessed.
Compare costs over a comparable billing period. AWS guidance names Cost Explorer for reviewing before-and-after costs; Azure Advisor bases resize recommendations on retail rates, so treat its estimate as an input rather than the account's financial result.
Keep the decision, measurement window, tested configuration and remaining uncertainty together. Review them when traffic, software or dependencies change.
