MELLORCATalk to Mellorca
Impact›Cloud Infrastructure
Cloud Infrastructure · Impact

Cloud Costs Rising Every Month Without an Explanation

Cloud infrastructure is designed to expand quickly. Without equally strong cost visibility, that flexibility can turn normal operational change into a bill nobody can confidently explain.

Mellorca Impact·Cloud, Hosting, Servers & Infrastructure Spend·2 September 2026

The tolerated pain is a bill that grows faster than understanding

Cloud spending often starts with a clear story. A product needs hosting, a database needs capacity, a new environment is created for development. Months later the invoice contains dozens of services, accounts, regions, storage classes, reservations and usage charges. The total is visible; the business reason behind each line is not.

That is the point where cloud economics become a management problem rather than a hosting problem.

Take a software company in Pretoria with a team of twelve developers serving a few hundred business customers. Two years ago its cloud bill was easy to explain: one production environment and one test environment. Since then it has added a data warehouse for reporting, a second region for a large client, several short-lived environments for feature testing, and a document-processing service that calls an AI model. The bill has grown every month. The financial director asks why, and the lead developer needs most of a day to piece together an answer, which still ends with "some of it is probably old test environments".

Why unmanaged consumption survives

Cloud makes it easy to create resources and deliberately separates infrastructure consumption from traditional procurement cycles. That speed is valuable, but it means cost can change every day while ownership, budgets and review processes still operate monthly or quarterly.

The FinOps Foundation's State of FinOps 2026 report reflects how broad technology-cost management has become, and major cloud providers continue adding cost allocation and anomaly-detection capabilities. In June 2026 AWS added AI-assisted investigations to its Cost Anomaly Detection service, aimed at explaining whether a change came from usage or rate, which services, accounts and regions contributed, and, using CloudTrail data, which API calls and identities were involved. Microsoft Cost Management similarly provides anomaly detection and alerts for unexpected subscription-level changes; its documentation explains that anomalies are evaluated daily against a forecast based on the previous 60 days of usage, with detection running 36 hours after the end of each day.

That timing detail is worth noticing. Even good tooling reports on yesterday, not on this morning. A misconfigured resource can run for a day or two before any alert fires, and for weeks if nobody acts on the alert.

How the pain becomes money

  • Unnecessary consumption: workloads, storage and services continue running after the business need changes.
  • Margin erosion: cloud cost grows inside product or service delivery without being allocated to the customers or activities driving it.
  • Investigation labour: engineers and finance teams spend paid time reconstructing which change caused the bill movement.
  • Weak accountability: teams can increase spend without seeing a direct budget consequence.
  • Slow correction: unexpected usage can continue for days or weeks before month-end review reveals it.
The commercial signal. If finance can show that cloud spend increased but engineering cannot quickly identify which workload, team or business event caused the change, cost control is lagging behind consumption.

Start with attribution before optimisation

A business cannot optimise what it cannot allocate. The first question is not whether every workload is perfectly sized. It is whether meaningful spend can be tied to an owner, product, environment, customer or business unit.

Cost allocation tags, accounts, subscriptions and cost categories are practical mechanisms because they create a path from invoice to accountability. The specific mechanism varies by cloud provider, but the operating principle is the same: every material cost needs an explanation and an owner.

Microsoft's Cloud Adoption Framework suggests grouping tags by purpose: functional tags such as application and environment, accounting tags such as department or cost centre, and ownership tags naming the business unit and operations team. It also points out practical traps: tag values are case-sensitive, so "Production" and "production" appear as separate lines in cost reports, and not every resource type supports tags. A tagging standard that is enforced by policy rather than goodwill is far more likely to survive a busy quarter. Mellorca's article on cloud costs without business-owner allocation looks at the ownership side of this in more depth.

How to diagnose where the money is going

  1. Export the last six months of billing data, grouped by account or subscription and by service.
  2. Mark what share of spend carries a usable owner or cost-centre tag.
  3. For the biggest untagged items, find the person who created or last changed them; activity logs and access permissions are usually the quickest route.
  4. Classify each item as production, non-production, or unknown.
  5. Look at month-on-month changes by category: new costs, removed costs and changed costs. Microsoft's guidance uses this same three-way split for investigating unexpected charges.

Build a transparent cost model

Monthly unexplained growth
current month cloud spend − prior comparable month spend − approved planned growth
Investigation cost
people involved × hours spent explaining or correcting cost changes × loaded hourly labour cost

Then separate waste from legitimate growth. A higher bill is not automatically bad. If transaction volume, customer demand or resilience requirements increased, the spend may be economically rational. The failure is not growth; it is growth the business cannot attribute or evaluate.

In the Pretoria example, splitting the bill this way might show that the second region is fully justified by the client contract, that the AI document service grows in step with customer usage and should be priced into that product, and that a cluster of forgotten test environments is pure leakage. Each answer leads to a different action: keep, reprice, or switch off. Mellorca covers that last category in the financial waste of unused cloud resources.

Anomaly detection is useful, not sufficient

A cost alert can identify unusual movement, but it cannot decide whether the spend creates value. Cloud providers increasingly make anomalies easier to detect and investigate, yet a business still needs owners who can explain whether the usage was intentional, necessary and appropriately sized.

This is why FinOps is ultimately a decision discipline rather than a dashboard exercise. The FinOps Foundation's principles say that teams need to collaborate, that business value should drive technology decisions, and that everyone takes ownership for their technology usage, with accountability pushed to the edge where engineering teams manage their own spend against budgets. Alerts that arrive in a shared mailbox nobody reads deliver none of that.

When this becomes commercially urgent

Priority is high when cloud cost grows faster than the revenue or workload it supports, invoices surprise finance, teams cannot allocate spend, new projects have no budgets, test systems remain active indefinitely, or engineering must perform forensic work every month to explain variance. Usage-based AI and data workloads make this especially important because consumption can change quickly. Mellorca's note on AI usage costs that are not allocated to business outcomes covers that newer source of variance.

Trade-offs to keep in view

  • Control versus speed. Approval gates on every new resource slow engineering; budgets and alerts with clear owners usually give enough control without blocking work.
  • Commitments versus flexibility. Reservations and savings plans can lower rates but lock in spend; they suit stable workloads, not experiments.
  • Tagging effort versus visibility. Retro-tagging an old estate is tedious, so start with new resources and the largest existing costs.

What good looks like

A controlled cloud environment has cost ownership, allocation standards, budgets, anomaly alerts, regular variance review and a process for shutting down resources that no longer create value. Engineering sees cost as an operating metric; finance understands enough of the architecture to distinguish planned growth from leakage.

Practical next actions

  1. Identify the top cloud accounts, subscriptions, services and workloads by monthly spend.
  2. Assign an accountable owner to each material cost area.
  3. Implement cost allocation using tags, accounts, subscriptions or cost categories.
  4. Set budgets and anomaly alerts at useful organisational boundaries.
  5. Review monthly variance by business cause, not only by technical service name.
  6. Track idle, test and orphaned resources separately from production growth.
  7. Measure unit economics where possible, such as infrastructure cost per transaction, customer or workload.

What to do first

Take the five largest cost lines on last month's bill and, for each, write down the owner, the business purpose and whether the growth was planned. If any line has no owner, fix that before attempting any optimisation. Higher cloud spend can be legitimate; measure unexplained variance, investigation labour and unit economics from your own billing and workload data rather than assuming a generic percentage of waste.

Bottom line

Cloud cost growth is not automatically waste. Unexplained cloud cost growth is a control failure. When every material increase has an owner, a business reason and a measurable unit of value, flexible infrastructure becomes manageable rather than mysterious.

Sources and further reading

Related Mellorca reading

Method noteHigher cloud spend can be legitimate. Measure unexplained variance, investigation labour and unit economics from your own billing and workload data rather than assuming a generic percentage of waste.