Insights / Guide / Cloud migration and infrastructure evaluation
GuideHow to control cloud costs after migration
Cloud bills grow quietly. A few disciplined habits, from tagging to right-sizing to early alerts, keep spending visible and predictable.
Many organisations move to the cloud expecting lower costs, and in the first months the numbers often look good. Then the bill starts to creep. A test environment is left running over a holiday. A database sized for a launch peak is never scaled back. A team experiments with a new service and forgets to delete it. None of these is large on its own, but together they can push spending well beyond the business case.
Cloud bills grow quietly because the cloud makes it easy to create resources and gives nobody a natural reason to remove them. The good news is that a few habits keep spending visible and predictable. This guide sets out those habits and how to embed them.
Why cloud costs drift
In a traditional data centre, capacity is bought in large, visible chunks. Adding a server needs a purchase order, which creates a natural checkpoint. In the cloud, anyone with the right permissions can create resources in minutes, and costs accrue by the hour or second. Spending becomes a by-product of thousands of small technical decisions.
- Resources are provisioned generously to be safe, then never reviewed.
- Development and test environments run around the clock, though they are used only in working hours.
- Storage accumulates: old backups, snapshots, logs and unused volumes.
- Data transfer charges between regions or out of the cloud are overlooked in planning.
- Nobody can see which team or project is responsible for which costs.
The last point is the root of most of the others. When costs cannot be attributed, nobody feels responsible for them, and the bill becomes an IT overhead rather than a business decision.
Consider a typical mid-sized retailer six months after moving its e-commerce platform and back-office systems to public cloud. The monthly bill has risen steadily, but nobody can say whether the rise reflects more online orders, a new analytics project or simply resources left behind after the migration. Finance asks IT, IT asks the application teams and each team assumes the growth belongs to someone else. Every habit in this guide is designed to break that loop.
Habit one: tag everything
Label resources by owner, project and environment so costs can be attributed. Tags are simple labels attached to each resource. All major cloud providers support them, and their cost reporting tools can group spending by tag.
Setting up a tagging standard
- Agree a short list of mandatory tags: owner, cost centre or project, environment (production, test, development) and application.
- Define allowed values for each, so reports are not fragmented by spelling variations.
- Use the provider’s policy tools to block or flag resources created without the mandatory tags.
- Tag existing resources in a one-off clean-up, starting with the largest spend.
- Report untagged spend monthly and assign it to be resolved.
Once tagging is in place, cost reports change character. Instead of one large bill, leaders see what each application, team and environment costs. That visibility alone often prompts owners to clean up resources they had forgotten about.
Habit two: right-size regularly
Reduce oversized resources and switch off idle ones. Right-sizing means matching the capacity of each resource to what it actually uses. Cloud providers offer recommendations based on usage data, and many third-party tools do the same.
- Review compute and database utilisation monthly; resources running consistently well below capacity are candidates for a smaller size.
- Schedule non-production environments to shut down outside working hours and at weekends.
- Delete unattached storage volumes, old snapshots and obsolete backups according to retention rules.
- Move infrequently accessed data to cheaper storage tiers.
- Use auto-scaling for workloads with variable demand, so capacity follows usage.
Scheduling alone can make a noticeable difference. A test environment that runs only during working hours is switched off for most of the week. For organisations with many such environments, the saving is significant and requires no change to how applications work.
Be careful with production systems. Right-sizing a live database or application server should follow the same change control as any other production change, with a test of performance at peak load and a quick way back if response times suffer. Saving a modest sum is not worth a slow checkout page on the busiest day of the month.
Habit three: commit where demand is steady
Pay-as-you-go pricing is flexible but expensive for workloads that run constantly. Providers offer discounts in exchange for committing to a level of usage for one or three years, through reserved instances, savings plans or similar arrangements. For stable production workloads, these can reduce costs substantially.
The discipline is to commit only after right-sizing. Committing to oversized resources locks in waste. Review commitments as they approach renewal, and match them to current, not historical, usage.
Habit four: set budgets and alerts
Warn owners before overspend, not after. Most providers let you set budgets at account, project or tag level, with alerts when spending reaches a percentage of the budget or is forecast to exceed it.
- Set a monthly budget for each major application or team, based on its expected spend.
- Send alerts to the resource owner, not only to IT or finance.
- Use forecast alerts, which warn when spending is on track to exceed the budget, as well as threshold alerts.
- Set anomaly detection where available, to catch sudden spikes from errors or misconfigurations.
Alerts need owners
An alert sent to a shared inbox is often ignored. Route each alert to a named person who can act, and agree what they are expected to do when it fires.
Treat a fired alert as a prompt for a short conversation, not an automatic shutdown. Sometimes higher spend is entirely justified: a successful campaign drove more traffic, or month-end processing ran heavier than usual. The aim is that someone knows why the number moved and has decided it is acceptable.
Make cost a shared responsibility
The habits above work best when finance, IT and the business teams consuming cloud services share responsibility for cost. This approach, often called FinOps, does not need a large team. It needs a regular rhythm and clear roles.
- A short monthly review of spend by application and team, with trends and anomalies highlighted.
- Owners explain significant changes and agree actions.
- IT or a cloud specialist proposes right-sizing, scheduling and commitment opportunities.
- Finance tracks spend against budget and forecasts, and reflects cloud costs in team or product reporting.
- Architects consider cost alongside performance and resilience when designing new services.
A ninety-day starting plan
- Weeks one to two: agree the tagging standard and switch on cost reporting by tag.
- Weeks three to six: tag existing resources, starting with the largest spend, and schedule non-production environments.
- Weeks seven to ten: review right-sizing recommendations and act on the clear cases.
- Weeks eleven to thirteen: set budgets and alerts by application, hold the first monthly review and assess commitment discounts for stable workloads.
Start this month with two actions: agree a mandatory tagging standard and set budgets with alerts for your five largest applications. Within a quarter, the monthly review will have a clear picture to work from, and the quiet growth of the bill will become visible and manageable.
Source: Intelliversal analysis.
