The cloud bill that arrived after the fast migration
Companies that rushed to the cloud under pandemic pressure are now receiving bills nobody planned for. Why this happens and what to do about it.
From March through May 2020, many companies did something they had been putting off for years - they moved infrastructure and teams to the cloud. The pressure was understandable: remote access had to happen fast, and there was no time to plan.
A few months later, the bills arrived. And they were often a surprise.
I am not talking about fraud or provider errors. I am talking about the fact that fast migration under pressure almost always creates a specific set of spending patterns that nobody anticipated.
Why a fast migration ends up expensive
When you move quickly, you provision generously. Servers that were on-premise get replicated one-to-one - or larger, just in case. In the cloud, that model is different: you pay for every hour an instance runs, regardless of whether there is any load on it.
The second pattern is forgotten resources. Test environments launched "for a couple of days", dev instances that nobody switches off at night or on weekends. In the cloud every one of those has a running meter.
The third is traffic. Outbound data transfer is billed by most cloud providers. Companies that previously had everything inside one data centre now pay for every gigabyte that goes out.
What a cost audit usually finds
I have run cloud cost audits after several of these crisis migrations. The findings are almost always the same:
- instances sized for a workload that no longer exists - it was moved or optimised, but the instances stayed;
- storage being written to but never read;
- managed-service licences that duplicate something already in use;
- two or three parallel VPN solutions launched by different teams independently.
In total this often amounts to 20-40% of the bill. These are not unusual numbers - they are the typical result of a fast migration with no subsequent review.
How optimisation works
Cloud cost optimisation is not a one-time exercise. It is a process that needs an owner.
First step: resource tagging. Every instance, every disk, every service should be labelled: who owns it, which project, which environment. Without this you cannot know what to switch off.
Second step: utilisation review. Resources running below 20% of their allocation are candidates for right-sizing or decommissioning.
Third step: automatic shutdown policies. Dev and test environments should not run 24/7. This is straightforward to configure and produces fast results.
A question before the next decision
Cloud has become the default. But "cloud as default" does not mean "cloud without governance". The fast move was justified by the situation - now is the time to understand exactly what is running, what it costs, and whether it is still needed.
Three questions to start with:
- Does anyone in your company know which cloud resources are currently running and who is responsible for each one?
- Do you have a policy for switching off non-production environments outside working hours?
- Who receives the cloud provider invoice and breaks it down line by line?
If the answer to the first two is "not sure" - that is a good place to start.