Cloud costs: what only becomes visible after migration

When a company finishes its cloud migration, the first reaction is usually positive. Infrastructure is running, the old data centre is cleared out, the team breathes a collective sigh of relief. A few months later the first unexpected bill arrives.

This is a predictable pattern, not a surprise. Cloud spending is structured fundamentally differently from on-premise hardware costs. Capital expenditure becomes operating expenditure, and controlling it requires different discipline.

I have seen this situation often enough to describe its regularities.

Why costs grow invisibly

On your own hardware, the IT budget looks like a list of line items: servers, storage, licences, support. Each purchase is a separate decision. In the cloud, every developer, every team, every test environment can spin up resources at any moment.

Typical sources of unexpected spending:

• test environments that someone forgot to stop;
• over-provisioned resources "just in case";
• data transfer between regions and out of the cloud - traffic that is rarely counted separately;
• logs and snapshots stored indefinitely without a deletion policy;
• unused reserved instances that were prepaid.

Each of these items is small on its own. Together they add 30-60% on top of the expected budget.

What most companies lack after migration

Technical migration and financial control are different tasks, usually addressed at different times. The team that migrated the infrastructure was thinking about availability and performance, not about tagging resources by business unit and cost centre.

The result, six months after migration, looks like this:

• there is a bill, but no breakdown by product or team;
• which department pays for which resources is unclear;
• switching anything off feels risky because nobody knows who uses it;
• engineers do not see the cost of their architectural decisions in real time.

This is not a tooling problem - every major cloud provider offers detailed cost analytics. It is a process and ownership problem.

What actually works

Cloud cost control is not a one-time task - it is a continuous discipline. It has several components.

Resource tagging. Every cloud resource must carry metadata: team, product, environment (prod/staging/dev). Without this, cost analytics is meaningless. Tagging needs to be a mandatory rule, not something people do when they feel like it.

Budgets and alerts. Each team or product gets a budget with notifications when thresholds are crossed - say, 80% and 100% of the monthly limit. This makes costs visible to the people who create them.

Regular FinOps reviews. Once a month, someone looks at the largest cost items and asks a simple question: is this justified? This role does not have to sit with finance - assigning a responsible engineer or architect is enough.

Automatic stop policies. Test and staging environments should not run overnight or on weekends. An automatic schedule saves 40-60% of the cost of those environments with no inconvenience.

Three questions to check yourself

If you are already in the cloud or planning a move, ask yourself:

1. Can you say right now how much each team or product is spending - without manual work from an analyst?
2. Do you have budgets and alerts that will fire before the end of the billing period, not after?
3. Does the engineering team know the cost of their decisions at design time, not when the bill arrives?

If the answer to even one of these is "no" - it is worth spending a few days on basic FinOps discipline. That is cheaper than dealing with the next unexpected bill.