Our cloud bill keeps growing, and nobody can explain why

The situation

The monthly invoice from your cloud provider has climbed steadily since the migration. Finance asks IT to explain it. IT points to growth, new projects and the provider’s pricing. Everyone agrees it should be lower, but each attempt to reduce it stalls because nobody is sure what can be switched off without breaking something.

You have been offered FinOps tooling and cost dashboards. You suspect the problem is not that you cannot see the bill. It is that the architecture behind the bill was never designed with cost in mind.

Why this is hard

• Cloud cost is an architecture outcome. Instance sizes, storage classes, data transfer paths, how environments are duplicated and how resources are tagged decide the bill long before anyone looks at a dashboard.
• Nobody owns the whole picture. Developers create resources, operations keep them running, procurement signs commitments, and finance sees only the total.
• Lift-and-shift migrations copy on-premises sizing into the cloud, where it is paid for every hour whether used or not.
• Reserved and committed-use discounts require decisions about the future that teams are reluctant to make, so everything stays on the most expensive on-demand rate.
• Some savings are risky. Turning off an unknown resource can break a dependency nobody documented.

What goes wrong when it is ignored

• Cloud is declared “too expensive” and the organization loses confidence in a platform that was never tuned.
• Budget intended for new capability is absorbed by waste.
• Teams respond to cost pressure by cutting the wrong things, such as backups, logging or redundancy.
• A tool is bought to watch the spend, and the spend keeps rising because the architecture did not change.

How I approach it

1. Read the bill as an architect, not as an accountant. I group spend by workload and environment and connect each large line to the design decision that created it: a size, a storage choice, a transfer path, a duplicated environment.
2. Inventory and tag what exists. Idle resources, orphaned storage, old snapshots, forgotten test environments and oversized databases are found and listed with an owner and a decision: keep, resize, schedule or remove.
3. Right-size with evidence. Using the utilization data the provider already collects, I propose instance, database and storage changes with the expected effect and the risk of each.
4. Decide on commitments deliberately. For the stable part of the estate I set out which reserved or committed-use options fit, for how long and with what flexibility, so you stop paying on-demand prices for workloads that never move.
5. Fix the structural causes. Non-production environments switched off outside working hours, storage lifecycle rules, data transfer paths redesigned, logging retention set with intent, and a tagging and ownership standard so the next bill is explainable.
6. Put a light governance routine in place. A monthly review with a short agenda and named owners, using the provider’s native cost tools. No new tooling purchase is assumed.

This works on AWS, Google Cloud and Oracle Cloud Infrastructure, and the same thinking applies to stc cloud and Zain Cloud estates and to hybrid environments.

What you receive

• A cost breakdown by workload and environment, tied to the architecture decisions behind it.
• A resource inventory with a keep, resize, schedule or remove decision for each item.
• A right-sizing and commitment plan with the expected effect and risk of each change.
• Structural recommendations: scheduling, storage lifecycle, transfer paths, logging retention, tagging.
• A simple monthly cost-governance routine your team can run without new tools.

Where to start

Export the last few months of billing data, or just bring the invoices, to a free 30-minute Architecture Decision Review at /free-architecture-review/. I will show you where the structural cost sits and whether a full review is worthwhile. The contact form is the alternative.