Moving to the cloud is sold as a way to spend less. For a good number of the teams we walk into, the opposite happened: the migration finished on time, the hardware is gone, and the monthly invoice is bigger than the one it replaced. Nobody lied to them. The savings were real on paper and they evaporated in operation.
The pattern is consistent enough that it is worth writing down.
Where the money actually goes
In almost every environment we review, four things account for most of the surprise.
- Resources nobody resized. Compute instances, managed databases and block storage provisioned for the peak of a workload that never arrived, running twenty four hours a day because nothing turns them off.
- Configuration chosen on the first day and never revisited. A storage class, a database tier or a redundancy option selected during the cutover, when the priority was finishing, and never looked at again.
- Data moving between regions and availability zones. The line item nobody models before the migration and everybody discovers afterward, because it is invisible in an on-premise world where the network was already paid for.
- Managed and premium services bought for convenience. They genuinely remove operational load, and they carry a premium that has to be a decision instead of a default.
None of these are mistakes of competence. They are the residue of a project that was measured on finishing, not on operating.
The first fix is a change of posture
The habit that costs the most money is running a cloud account the way a data center was run: provision once, size for the worst case, and leave it alone because change is risky. In a data center that was prudent, because the capital was already spent. In the cloud that same prudence bills by the hour.
A migration is not the finish line. It is the first day of an operating discipline that did not exist before.
Which means the migration plan and the cost plan cannot be the same document, and they cannot end on the same day.
FinOps is a standing practice, not a project
Cloud financial management works when finance and the technical team look at the same numbers on the same cadence. Not a quarterly report that arrives too late to change anything: a running cycle of plan, measure, adjust, where an engineer can see what a decision costs before making it and finance can see what it bought after the fact.
That requires two unglamorous things first. Tag everything that costs money, because there is no attribution without tagging and no conversation with finance without attribution. And publish the spend by area, per business unit or per environment, because a single aggregate number is exactly what makes cloud spend impossible to govern.
From paying for what you use to paying for what you need
The entry level of cost control is paying only for what runs. Non production environments are the cheapest place to start: development, test and staging rarely need to exist at three in the morning on a Sunday, and shutting them outside working hours removes roughly three quarters of their hours from the bill. It is arithmetic, not a promise.
The next level is commitment. Reserved capacity and savings plans discount the baseline you know you will run, and on the providers' own published rates that reaches up to seventy two percent against on demand. The condition is that you have to know your baseline, which is why this step comes second and not first.
Catch the anomaly before the invoice
By the time a cost surprise reaches an invoice it is a month old. The tooling to avoid that already exists in both clouds and most teams have never turned it on: cost explorers and dashboards for granular visibility, and anomaly detection that flags an unusual spend pattern in days rather than at the close of the month.
On AWS that is Cost Explorer, the Cloud Intelligence Dashboards and Cost Anomaly Detection. On Azure it is Cost Management and Billing together with Advisor and reservation recommendations. The names differ, the discipline does not.
What this looks like when it is working
A team that has this in place can answer three questions without preparing: what did we spend last month and on what, which of it was waste and which was structure, and what will we spend next month if nothing changes. Most teams cannot answer the second one, and that is the whole gap.
At Farus we start with a review that ends in a list of findings ordered by what each one is costing, separate the waste you can remove this week from the structural work that needs architecture, and then operate the discipline month over month. On replication and standby alone we usually find between ten and twenty five percent of that spend.