The unexpected cloud bill: what companies discover a year after migration
Why cloud costs end up higher than projected - and what you can do before it becomes a problem.
Cloud migration is sold as a savings story. No need to buy hardware, no need to run a data center, you pay only for what you use. All of this is true in theory. In practice, many companies find that a year or two after migration their IT costs went up, not down.
This is not a unique story. I observe similar dynamics across different companies. It is worth understanding why this happens and what to do about it.
Where the unexpected bill comes from
Several mechanisms I see most often.
Migration without optimization. The classic scenario: a virtual machine moves from a local server to the cloud with the same specs. On-premises it was bought three years ago when the load was different. In the cloud you pay for it every month, and actual consumption is measured. It turns out that half the capacity is unused - but still paid for.
Data transfer traffic. Cloud providers charge not only for compute and storage but for outbound traffic. Companies that actively move data between regions, or between cloud and on-premises systems, find that this line item is significant and was not included in forecasts.
Development and test environments. In local infrastructure a test environment is a one-time purchase of hardware. In the cloud every day a test environment exists costs money. Teams get used to spinning up environments and forget to tear them down.
Storage without inventory. Data is cheaper to keep in the cloud than to think about. The result is terabytes of logs, backups, and old snapshots accumulating - nobody knows if they are needed, but they cost money continuously.
Redundancy without a plan. High availability and redundancy in the cloud are set up in a few clicks. This is convenient and expensive. Companies often enable redundancy wherever it is technically possible, not because it is a business requirement, but because it seems "safer".
Why this is not obvious at the time of migration
During a migration the focus is on functionality: move it, start it, make sure it works. Operating cost is a second priority. Forecasts are built on resource prices, not on actual consumption patterns - which often differ from expectations.
Another factor: cloud costs are diffuse. There is no single invoice for a server - there are hundreds of small line items across dozens of services. Without dedicated tooling, understanding exactly what is being charged for is difficult.
What to do
Three things that deliver results.
First - regular resource inventory. Once a quarter, look at what is actually being used. Unused or underloaded resources are the first candidate for optimization.
Second - tags and cost attribution. Every resource should be tagged with the product, system, or team responsible for it. Without this, optimization has no address.
Third - someone responsible for cloud costs. This is not a general function of the IT director. It is a specific person who sees the costs, understands anomalies, and has the authority to act. In smaller companies this can be a part-time role, but it must be an explicit one.
The cloud is not cheaper on its own. It can be cheaper with proper cost management. That is a separate competence that needs to be built alongside the migration, not after the unexpected bill arrives.