Why your cloud bill grows after migration

A cloud bill that rises after migration is so common it should be planned for rather than treated as a surprise. The causes are usually mundane, they compound quietly, and almost all of them are visible in the billing data if you know what to look for.

Here are the five that account for most of it.

1. Everything was sized for hardware you bought years ago

On-premises capacity was bought in advance, for peak load, with headroom, on a procurement cycle measured in months. That produced servers specified generously because under-specifying was expensive to fix.

When those specifications are carried across during a rehost, you rent the generosity by the hour. A server sized for a peak that occurs twice a year now costs you for that peak every hour of every day.

What to do: measure real utilisation for two to four weeks after the move, under normal load, then resize. Do this as a deliberate step with an owner and a date, not as something to get to eventually. It is the single largest saving available on most estates, and it is available within the first quarter.

2. Nothing is ever switched off

On-premises, an idle development server cost nothing incremental. It was already bought. In the cloud it costs the same per hour as a busy one.

Development, test, staging and training environments typically run continuously because that is how they behaved before, and because nobody owns the decision to stop them. An environment used during working hours that runs all week costs roughly three times what it needs to.

What to do: schedule non-production environments to stop outside working hours. Make starting them easy and self-service so the schedule does not become an obstacle people route around.

3. Storage accumulates because deleting it is nobody's job

Storage grows in ways that are individually reasonable and collectively expensive.

Snapshots are taken before every change and rarely removed. Backups are retained on the assumption that more is safer. Disks are detached when an instance is deleted but the disk itself remains, still charged, attached to nothing. Log data is written to the fastest and most expensive storage class and left there indefinitely.

None of this is visible unless somebody looks, because storage does not fail or alert. It just quietly grows.

What to do: apply lifecycle rules that move older data to cheaper storage classes automatically, set snapshot retention deliberately, and run a monthly check for unattached disks and orphaned snapshots. This is unglamorous and it is reliably worth doing.

4. Data transfer, which nobody modelled

Moving data into a cloud platform is usually free. Moving it out costs money. Moving it between availability zones or regions costs money. Traffic through managed gateways is charged per gigabyte processed as well as per hour.

This matters most for architectures that were designed when the network was free. A chatty application split across zones for resilience, a backup job pulling a full copy out to another location every night, a reporting system reading across regions. Each is defensible in isolation and each shows up on the bill.

Data transfer charges also tend to appear in line items that are hard to attribute, which is why they are often noticed late.

What to do: look at the transfer lines specifically rather than accepting them as overhead. Where the cost is significant, the fix is usually architectural: co-locate chatty components, cache at the edge, or reconsider whether the cross-region copy is needed as often as it runs.

5. Nobody owns the total

The most expensive cause is organisational rather than technical. When several teams can create resources and no one is accountable for the aggregate, spend rises by accumulation. Each individual decision is small and justifiable. The sum is neither.

This is made worse when the bill arrives as a single number with no breakdown by team or workload, because then nobody can act on it even if they want to.

What to do: tag resources so that cost can be attributed to a team or a service, and show each team their own number regularly. Attribution changes behaviour more reliably than policy does. It does not need to be perfect: two or three mandatory tags applied consistently is enough to make the bill legible.

What good looks like after six months

You should be able to answer, without a research project:

• Which five workloads cost the most, and whether that is proportionate to their value.
• What proportion of spend is non-production, and whether it is scheduled.
• How much is storage, and how much of that storage was last read more than ninety days ago.
• What data transfer costs and which architectural choice causes it.
• Who owns each of the above.

If those answers require a week of digging, the visibility problem is the first thing to fix. Everything else is easier once the bill is readable.

A note on commitments

Reserved capacity and savings plans genuinely reduce cost, sometimes substantially. They are also a commitment, and committing to a footprint you have not yet right-sized locks in the oversizing.

Right-size first. Run at the corrected size long enough to be confident it is stable. Then commit to the baseline you actually need, and leave the variable portion on demand. Doing it in the other order is a common and expensive mistake.