A cloud cost review should explain why spending changed before anyone deletes resources. Compare usage, rates and commitments, then check each resource’s business owner and dependencies.
Before cutting spend, explain the change
- Compare the same billing period, currency and tax treatment.
- Separate increased usage from changed rates or expired discounts.
- Find the owner and dependencies of each candidate resource.
- Agree a tested change, data-retention decision and rollback route.
Compare like-for-like billing periods
A longer month, a new workload or an expired discount can change the total without a fault. Separate usage changes from rate changes. Check tax, currency, credits and marketplace purchases before comparing two headline figures.
Break the bill down by service, account or subscription and environment. Azure, AWS and Google Cloud each provide billing tools, but access rights and reporting delays matter. Have finance and technical staff look at the same period and figures.
Find an owner before calling something unused
An idle-looking virtual machine may support an occasional reporting job. A storage account can contain recovery data. Ask who owns the resource, what depends on it and when it was last needed.
Use tags and inventory to connect spend with business purpose. Missing tags are a reason to investigate, not permission to delete. For genuinely unused resources, agree a removal plan with a rollback path and any required data retention.
An idle resource is a question, not a deletion order
Fictional example: a virtual machine with little daytime activity. Its purpose matters more than one utilisation screenshot.
What the dashboard shows
- Low average CPU use during office hours.
- A recurring monthly charge.
- No reliable owner tag.
What to establish next
- Does it run an overnight or month-end job?
- Do other services or recovery procedures depend on it?
- Who approves resizing or removal, and how would the change be reversed?
Review sizing and commitments separately
Check whether capacity matches observed demand, including peaks and maintenance windows. Reducing a server too far can shift cost into downtime or engineering time. Test changes to important workloads rather than relying on an average utilisation number. For Azure, Microsoft’s Cost Management best practices explain how to analyse and allocate spending.
Reserved capacity and savings commitments can reduce particular charges, but introduce obligations and eligibility rules. Do not buy a long commitment for a workload that may move next quarter. Check existing commitments before changing the architecture.
Which costs are easy to miss?
Data transfer, logs, snapshots, public addresses and marketplace subscriptions can remain after the main workload changes. Check them individually. Keep security and recovery requirements visible so that a saving does not accidentally remove evidence or protection.
Should every workload move to the cloud?
No. Cost is one factor alongside availability, data access, support and existing investment. Some businesses benefit from on-premises or hybrid arrangements. Compare the whole operating cost rather than a cloud line item with hardware purchase price alone.
Make the cloud cost review an engineering decision
ICT Shift’s Cloud & Infrastructure management reviews resources and dependencies. Strategic ICT Consulting connects technical choices with your roadmap and budget.
Talk to an engineer about your cloud costs with two recent bills, an inventory and your upcoming business changes. The aim is justified spending, not the smallest bill at any cost.
