Cloud cost optimization: where the bill nobody expected comes from

Cloud cost optimization becomes a priority in exactly the same way every time: someone on the leadership team looks at this month's bill, compares it with last year's, sees it has doubled without anyone approving anything, and asks for an explanation. That's when you find out nobody in the company can say how much of that amount belongs to the dashboard, how much to the assistant that was trialled in March, and how much to a machine a vendor spun up fourteen months ago for a test.

The cloud doesn't raise its prices: your consumption rises. And it rises because switching resources on takes one click, while switching them off is nobody's job. On your own server, spend was an annual decision with a signature behind it; in the cloud it's the sum of thousands of small decisions nobody recorded. That's the gap you have to manage, and changing provider doesn't close it.

This guide walks through where spend actually comes from in data and AI projects, what you can switch off this week without breaking anything, which levers genuinely lower the bill, and how to budget so next month holds no surprises.

Why does the cloud bill grow on its own?

It doesn't grow on its own. It grows for five reasons that repeat in almost every company:

• Nobody switches anything off. The test environment for a closed project is still running. The machine from last year's demo is still billing. Creating has an owner; destroying doesn't.
• Everything is sized out of fear. When nobody knows how much machine is needed, they ask for double. It works, nobody complains, and that double stays forever because turning it down feels risky.
• Storage is never reviewed. Data goes in and never comes out. Copies of copies, intermediate dumps from processes that no longer exist, history nobody has queried since 2019.
• You pay for movement, not just volume. Pulling data out of the cloud, moving it between regions, or querying it a thousand times a day costs money on top of what it costs to store. It's the line item that surprises people most.
• The invoice arrives without a usable breakdown. One total and two hundred lines of technical services. Nobody can answer "how much does the demand forecasting project cost us?" because the invoice is organised by service, not by project.

The underlying pattern: cloud cost is variable and the organisation treats it as fixed. Nobody reviews the office rent monthly because it doesn't change. The cloud changes daily and still goes unreviewed.

Where does the spend in a data and AI project really come from?

It helps to separate the line items, because the levers for each are different. This is what a typical data platform bill with some AI on top is made of:

| Line item | What it is | What drives it up | Main lever | |---|---|---|---| | Compute | Machines and processes that run something | Idle environments, oversizing | Switch off out of hours, right-size | | Storage | Data at rest | History with no policy, duplicate copies | Tiering by age, deletion with criteria | | Queries / processing | What it costs to read and transform | Dashboards refreshing every 5 min, unfiltered queries | Caching, partitioning, lower frequency | | Egress traffic | Moving data out or across regions | Integrations dumping everything nightly | Move only what changed, single region | | Platform licences | Tools priced per user or per capacity | Accounts that never log in | Quarterly review of accounts | | AI inference | Calls to models | Volume, long context, oversized model | Smaller model, less context |

The first common surprise is that compute isn't usually the biggest line in mature data projects — query processing is, because you pay per read and dashboards read far more than anyone imagines. A panel refreshing every five minutes through the working day fires well over a hundred daily executions of the same heavy queries. If the source data updates once a day, a hundred-odd of those executions are paying to return exactly the same thing.

The second surprise is egress. Storing data is cheap; getting it out isn't. An integration that dumps an entire table to an external system every night — when it could move only the rows that changed — can cost more than the database feeding it.

What can you switch off this week without breaking anything?

Before any redesign, there's a clean-up round that needs no project and no architecture approval. In order of return on effort:

1. Orphaned resources. Disks not attached to any machine, reserved IP addresses nobody uses, backups of systems that no longer exist. You can identify them in an afternoon and delete them without consequence. 2. Non-production environments out of hours. Development and test running 24/7 when they're used 8am to 7pm, Monday to Friday. Switching them off nights and weekends removes roughly two thirds of their hours. 3. Finished projects. Anything spun up "just to try" more than six months ago that nobody has touched since. If deleting feels scary, switch it off and wait thirty days: if nobody complains, it wasn't needed. 4. Licence seats. People who left the company or who never logged in. It's the easiest line to cut and the least examined. 5. Old snapshots and backups. Backup policies keeping a daily copy for three years because nobody ever defined a retention period.

If the first clean-up round cuts nothing, someone is already doing this work. The normal outcome is a meaningful cut, and that says more about spend governance than about technology.

One caveat: this round is hygiene, not strategy. It lowers the bill once. If you don't change who watches the spend, in twelve months it's back where it started.

How do you optimize cloud costs without slowing the project down?

After the clean-up, there are four structural levers, from least to most effort:

Size by measurement, not intuition. Look at real CPU and memory usage over the last four weeks. It's common to find machines running at 5-10% sustained. Dropping one size down and watching for a week is reversible and usually goes unnoticed. Do it one machine at a time so you know what changed if something goes wrong.

Commit capacity for what's stable. Providers discount appreciably in exchange for a one- or three-year commitment. The rule is simple: commit only the baseline you know you'll consume whatever happens, and leave the variable peak at list price. Over-committing swaps a high bill for a high, immovable bill.

Tier your storage. Not all data needs millisecond response. History older than two years that only gets queried during audits can live in cold storage at a fraction of the cost. This takes a business decision — how long can we wait to retrieve it? — more than a technical one.

Reduce what gets read. This is the highest-impact lever on data platforms and the most ignored. Three concrete moves: drop dashboard refresh frequency to the real update frequency of the data; partition large tables by date so a query about this month doesn't scan five years; and store precomputed aggregates instead of recalculating them on every visit. If you're building the platform right now, this gets decided up front in the design: it's much of what separates expensive data engineering from cheap data engineering.

A note on architecture: the ETL or ELT decision has direct consequences on the bill, because it moves transformation work to places that are billed differently. It isn't just a team preference.

How much does the AI part cost, and how do you control it?

Inference — each call to a model — has its own cost mechanics, worth understanding before you roll anything out company-wide:

• You pay for text processed, in and out. The context you send on every call counts. An assistant that attaches ten full documents to every question pays for ten documents on every question, even if the answer is two lines.
• The large model isn't always necessary. Classifying an email into four categories doesn't need the most powerful model in the catalogue. Trying a small one and measuring whether quality holds is the highest-return optimization in AI.
• Volume scales with adoption, and that's good. If cost rises because people are using it, cost isn't the problem: the problem is that nobody measured the saving on the other side. That's what measuring ROI against a baseline is for.
• Document retrieval has its own cost. In a RAG system, on top of the model you pay to index and to query the index. Re-indexing the whole repository nightly when forty documents changed is the modern version of the unnecessary nightly dump.

The practical rule: before opening an assistant to 200 people, calculate the cost per conversation on a real sample and multiply by expected usage. You get a number. If that number is alarming, now is the moment to know, not two invoices from now.

How do you budget the cloud without surprises?

Controlling spend isn't a savings project: it's a habit with three parts.

Tag everything you create. Every resource carries at least three tags: project, owner, environment. Without this there's no way to answer what each thing costs, and without that answer there's no conversation to have with leadership. It's dull work and it's what holds everything else up.

Show the cost back to whoever generates it. Having each area lead see monthly what their projects consume changes behaviour more than any policy. You don't need internal chargeback; it's enough that the number is visible with a name next to it.

Alert on drift, not on totals. An alert at month end once the budget is blown arrives too late. The useful one fires when the daily burn rate deviates from expected — while you can still switch off whatever got spun up by mistake.

On top of that, a thirty-minute monthly review with three questions: what went up versus last month and why, which new resources were created and who asked for them, and what can be switched off. It's little time and it's the only thing that stops you sliding back to the starting point. If you're mid-cloud migration, this review should start in month one, not when the project ends.

Frequently asked questions

Is going back to our own servers cheaper?

It depends on the consumption profile. For very stable, large, predictable workloads, on-premise can work out if you count everything: hardware, room, power, staff and a refresh every five years. For variable workloads or projects that grow and shrink, the cloud still wins because you only pay for the peak when it happens.

How much can a first review cut?

There's no honest percentage to apply blind, because it depends on how much drift has accumulated. What is constant is where the cut sits: idle non-production environments, storage with no retention policy, and queries repeating with no need.

Who should own cloud cost?

Someone with a name, and it can't be the technical team alone. What works is a technical owner watching consumption and a business owner approving the budget per project. If cost has no owner on the business side, it ends up with no real control.

Can cost optimization leave the system slow or unstable?

It can, if done blind. That's why changes go one at a time, with a week of observation and the option to undo them. Deleting orphaned resources and clearing old backups is safe; resizing production without measuring first is not.

---

The cloud bill isn't a technical problem: it's a spend governance problem that shows up as a bill. If you can't say what each project costs, the first step isn't switching off machines — it's tagging and looking. In the audit we review where your data platform's spend comes from and which part is cuttable without touching what works; if you'd rather talk it through first, let's talk.