Cloud bills rarely grow because of one bad decision. They grow through hundreds of small ones: a test environment nobody switched off, a virtual machine sized for a peak that never came, a snapshot kept just in case. Each is trivial on its own. Together they can add up to a substantial part of what an organisation pays.
The good news is that cloud waste follows familiar patterns, and most of it can be found with data you already have. The harder part is stopping it from coming back. That is a question of ownership and routine far more than of tooling.
Seven common sources of waste
- Idle resources: virtual machines, databases, load balancers and public IP addresses left running after a project ends or a migration completes. Often nobody knows whether they are safe to delete, so they stay.
- Oversized resources: instances sized on guesswork, or copied from on-premises specifications during a lift-and-shift. Utilisation data usually shows that smaller sizes or a different instance family would do the job.
- Missing commitments: steady, predictable workloads still on pay-as-you-go pricing. Reserved instances, savings plans and committed use discounts lower the unit price in exchange for a commitment, but buy them after right-sizing, or you lock in the waste.
- Storage and snapshot sprawl: disks left behind when virtual machines were deleted, snapshots and backups with no retention policy, and rarely used data sitting on premium storage tiers.
- Data egress: moving data out of a cloud region or between providers is charged. Chatty architectures, cross-region replication and large data exports can produce surprising lines on the bill.
- Non-production running around the clock: development, test and training environments that are used in office hours but run through nights and weekends.
- Licences paid twice: paying for Windows Server or SQL Server licences included in the cloud price while already owning eligible licences. Bring-your-own-licence options such as Azure Hybrid Benefit can address this, within the vendor’s licensing rules.
The underlying problem: nobody owns the cost
Behind most of these patterns is a lack of tagging and ownership. If a resource cannot be linked to a team, a product and an environment, nobody feels responsible for it, and nobody can safely remove it. Finance sees one large invoice. Engineers see the infrastructure, but not the price.
The fix starts with a consistent tagging standard covering owner, cost centre, application and environment, enforced through policy rather than written guidelines. Combine it with an account and subscription structure that mirrors how the organisation works. Once costs can be allocated, they can be discussed, and once they are discussed, they start to fall.
FinOps: making cost part of everyday operations
FinOps is an operating practice that brings engineering, finance and business owners together around shared cost data. The FinOps Foundation describes it as an iterative cycle with three phases:
- Inform: visibility and allocation. Everyone can see what they spend, broken down by team, product and environment, with budgets and forecasts.
- Optimise: acting on that data through right-sizing, scheduling, removing waste, buying commitments and choosing more cost-effective architectures.
- Operate: the roles, routines and policies that keep improvements in place, such as regular cost reviews, anomaly alerts and clear rules for trade-offs between cost, speed and quality.
The aim is not to minimise cloud spend at any price. Spend that supports growth is welcome. The aim is that every cost is known, owned and justified, and that decisions are made by people who understand both the technical and the business side.
Quick wins versus structural changes
It helps to separate two kinds of savings, because they need different people and different timelines.
Quick wins can usually be made within weeks and with little risk: deleting confirmed idle resources and orphaned disks, cleaning up old snapshots, right-sizing clearly oversized instances, scheduling non-production environments to shut down outside working hours, and applying licence benefits you are already entitled to. They build credibility and help fund the next steps.
Structural changes take longer and need engineering involvement. They include buying commitments against a stable baseline, redesigning data flows to reduce egress, moving to managed or serverless services where they fit, introducing autoscaling, setting storage lifecycle policies, and making cost a standard part of architecture reviews and deployment pipelines. This is where the larger and more lasting savings tend to sit, but it only works when product teams own their costs.
A common mistake is to treat the quick wins as a one-off clean-up and stop there. A few months later the waste is back, because the conditions that created it have not changed.
Questions to ask your team
- Can we show cloud spend per team, product and environment, and name an owner for each line?
- How many of our resources lack an owner or cost centre tag?
- Which steady workloads are still on pay-as-you-go pricing, and when do our current commitments expire?
- Do non-production environments shut down automatically outside working hours?
- Do we have retention policies for snapshots and backups, and are they enforced?
- Are we using licences we already own in the cloud, and do we have the records to prove our entitlement?
- Who is alerted when spend jumps unexpectedly, and what are they expected to do?
If several of these are hard to answer, the problem is less about individual resources and more about visibility and accountability. That is where to start.
How Altechy can help
Our FinOps Quick Scan is a fixed-scope, three-week review of your cloud spend and governance. You get spend broken down by service, team and environment, a prioritised list of savings with estimated impact and effort, a gap analysis covering tagging, policies and access, and a FinOps roadmap with roles and routines. Where licensing is a large part of the bill, our IT Asset & Licence Management specialists can establish what you own and where bring-your-own-licence options apply.
Want to discuss where your own cloud costs come from? Book a free 60-minute idea session.