A useful cloud cost review starts with the difference between this month's bill and the last one. Find the services behind the increase and the people who own them. “Compute is up” is too broad to act on; an old test environment or a growing log archive is specific enough.
Separate increased demand from a price change, a configuration change, and resources left running. Each needs a different response.
Find resources with no current purpose
Look for unattached disks, old snapshots, abandoned development environments, duplicate monitoring services, and reserved addresses. Ask an owner to confirm what each resource does before removing it. A disk that is not attached today may still be part of a recovery procedure.
Give temporary environments an owner and an expiry date. For development systems that can be stopped safely, compare a working-hours schedule with running them continuously. Check scheduled jobs, integrations, and startup time before applying it.
Storage deserves its own review. Work out which retention periods are deliberate, which are defaults, and which have simply never been revisited. Price retrieval and restore work as well as the monthly storage charge before moving data to a cheaper tier.
Size against the busiest useful period
Low average CPU usage is a reason to investigate, not enough evidence to shrink a machine. A database may need its memory for cache; a batch job may do most of its work during a short overnight window. Some applications are constrained by disk latency or network throughput while CPU remains low.
Use a period that includes the relevant peaks, such as billing runs or month-end processing. Change one resource limit at a time and compare application response times, queue length, errors, and memory pressure. Keep a way to undo the change.
If the environment has failover capacity, test the proposed sizing with a host unavailable. Capacity held for a failure can look unused during normal operation. The recovery guide covers that distinction.
Buy commitments after the cleanup
A usage commitment can lower the price of a predictable workload. It can also leave you paying for an application that moved or was retired. Check what the commitment applies to, how usage is matched against it, and which changes would leave part of it unused.
Base the decision on the demand that remains after resizing and retirement work. Compare the total committed spend with the likely on-demand spend over the same period. A large percentage discount is of little use if it applies to more capacity than you need.
Include the cost of running the alternative
When comparing public and private cloud, include staff time, support, licences, backups, spare capacity, network traffic, and hardware replacement. Put migration and parallel-running costs in the same calculation.
Dedicated infrastructure can suit steady workloads that use a meaningful share of the capacity. It still has limits and ongoing costs. Extra workloads consume power, storage, support time, and room for growth, even if the monthly server charge stays the same.
Public cloud can be a better fit when demand is short-lived or difficult to predict, or when a managed service removes work your team would otherwise have to do. Compare deployment models using the workload you measured.
Keep a short record of each change: owner, expected saving, service checks, and the bill after the change. That gives the next review something firmer than a target percentage.