Cloud costs can change as workloads, teams and usage patterns change. A resource created for a project may remain after the project ends. Storage may grow quietly, a development environment may run outside working hours, or a design may use more capacity than the workload needs. These are possible sources of cost drift, not proof that a particular bill is wasteful. Start with usage and ownership data, then assess each change against performance, resilience and business requirements.
Make spend visible to the people who can act
A total bill tells an organisation how much it spent, but not necessarily which team, service or business activity drove the cost. Where practical, allocate usage to accounts, subscriptions, projects, environments, products or cost centres. Apply tags or labels with an agreed set of values and an owner for each resource.
Allocation is a management practice, not just a billing exercise. Engineering teams can make design choices, finance can forecast and compare spend, and business owners can explain whether a workload still creates value. The FinOps Foundation describes FinOps as a collaborative operating practice for financial accountability and technology value, not simply a cost-cutting exercise.^1
Unallocated spend should be visible as a separate problem to resolve. Do not invent a team assignment from a resource name if the owner is unclear. Investigate, assign an accountable owner and improve the process that allowed resources to be created without one.
Compare usage with the workload
Review utilisation and capacity over a representative period. Look for resources that are idle, consistently underused, overprovisioned or left running when they are not needed. Check compute, storage, network transfer, managed services and software licences separately because each has different cost drivers and operational trade-offs.
FinOps Foundation guidance describes usage optimisation as matching provisioned resources to business needs. It recommends looking at historical usage and spend, then validating potential actions against current conditions.^2 A short snapshot can be misleading if the service has seasonal peaks, month-end workloads or recovery requirements.
Before reducing capacity, identify the service’s normal and peak demand, performance expectations, availability design and recovery requirements. A lower bill is not a successful optimisation if a change creates unacceptable risk or prevents the workload from meeting its purpose.
Remove resources only after checking dependencies
Unattached volumes, old snapshots, temporary test environments, unused public addresses and abandoned load balancers can be candidates for review. Confirm whether each resource is still referenced, whether the data is subject to retention requirements and whether another system relies on it. Use an owner and a controlled change process before decommissioning.
Scheduling can reduce unnecessary runtime for non-production resources, but confirm that teams know how to restart them and that the schedule does not interrupt tests, backups or maintenance. Lifecycle rules can help manage data and snapshots, but retention and recovery needs should be part of the decision.
Use automation to apply agreed policies consistently. Keep exceptions visible and time-bound. A shutdown policy that silently breaks a critical job can create more cost and disruption than it saves.
Review rates and commitments separately
Usage and pricing are different questions. After checking resource demand, review whether a rate commitment, reserved capacity or service plan is appropriate. Compare the term, utilisation assumptions, flexibility and financial risk. A commitment can reduce rates for steady demand but may be unsuitable when workloads change or the organisation needs the option to scale down.
Include software licences, support plans, data transfer and managed-service charges in the review. A cloud bill may contain costs that are not changed by resizing a virtual machine. The FinOps Foundation’s Optimize Usage & Cost domain covers resource usage, rate optimisation, commitments and software or SaaS licensing as related but distinct activities.^3
Measure value, not only savings
For each proposed change, record the expected benefit, implementation effort, risk, owner and validation method. Track whether the action was completed, deferred or rejected, and why. Compare actual usage, performance and spend after the change with the baseline.
Use a small set of useful measures, such as unallocated spend, forecast variance, idle resource cost or the proportion of recommendations reviewed. The right measures depend on the organisation and its workloads. Avoid presenting a saving estimate as realised value until the change has been implemented and its effect checked.
Make cost review a regular operating practice
Cost drift is easier to address when teams review usage, ownership and decisions regularly. Establish who examines the data, who can approve changes and how exceptions are handled. Revisit the process after major deployments, acquisitions or changes to workload demand.
Read what cloud providers do not cover and what platform management should cover. For AltTab’s current cloud and workplace assessment, planning and support scope, see Cloud and Microsoft services.