Why did your cloud bill increase? A practical guide

The email from finance is short. The latest cloud invoice is attached, with one question: why is this higher than last month?

Answering it often takes more than one person. Finance may only have the totals. Whoever manages the cloud account, whether an internal developer or an outside provider, knows what was added, resized or switched off. They need to put that information together before anyone can explain the difference.

Guessing has a cost either way. Accept an increase without understanding it and spending that serves no purpose can carry on for months. Cut something in response and you may weaken a service your customers rely on.

This guide sets out a five-step review that turns the question into a recorded decision. Parts of it repeat every month: preparing the same comparison and chasing the same follow-ups. Those parts can be automated. Working out why a cost changed, and deciding what to do about it, stays with people. The exact setup depends on the tools you use.

Before you start

You need two complete invoices for the periods you’re comparing and a breakdown of charges by service. If you can’t reach the billing console, ask whoever manages the cloud account to export the breakdown for both periods. You’ll also need some of that person’s time, because several questions below depend on what they know.

The example used in this guide

We’ll follow one hypothetical business, a small online retailer, through all five steps. Its cloud bill rose from 4,800 EUR in July to 5,450 EUR in August. The business, figures, findings and dates are illustrative. This is not a TardiTech client case.

Three roles matter in its review. The finance lead raised the question. The technical lead manages the cloud account and knows what was changed. The operations manager approves any change to a live service. In a smaller company, one person may cover more than one of these roles.

Two pieces of automation already support the review. A monthly report, configured by the technical lead, compares each bill with the previous month using the same filters. A task tool sends a reminder before each follow-up is due. Neither decides anything. They save the team from rebuilding the same comparison and chasing the same actions every month.

1. Establish a fair comparison

Two totals can only be compared when they measure the same thing. Before looking for causes, check four things:

Complete periods. A partial-period total or an estimate may differ from the final bill, so use complete finalised periods for both.
The same scope. Use the same accounts, projects and services for both periods. If something new was added in the later month, show its cost as a separate line.
The number of days. For a service charged at a steady daily rate, a 31-day month costs about 3.3% more than a 30-day one. Daily averages help with unequal months, though they can hide a few busy days or one large charge.
Credits, refunds and discounts. Keep these on their own lines. A credit that ends raises the amount you pay, even when nothing about how you use the services has changed.

Check currency, tax and upfront payments

Two further checks apply to some businesses. If you’re billed in one currency and report in another, exchange rates can move the total on their own, and tax should be treated the same way in both periods. If you’ve paid upfront for discounted capacity, your provider may show that cost in two ways: as billed in the month you paid, or spread across the period it covers, often called amortised cost. Microsoft’s guide to amortised costs shows the difference in Azure. Whichever view you choose, use the same one for both periods.

When the retailer’s August bill arrived, the monthly report had already lined up July and August: two complete 31-day months, billed cost in EUR, the same tax treatment, and no upfront payments. The technical lead still checked that the figures were final and that the report’s filters covered every account. One item needed its own line: a 400 EUR promotional credit had reduced July’s bill and expired on 31 July.

2. Locate the material changes

A material change is one large enough to matter to your review. Where you draw that line depends on the business: for some it’s 100 EUR, for others a percentage of the total.

Break the overall difference down by service or charge, and start with the largest increases and decreases. A service that cost less can offset one that cost more, so even a total that barely moved can hide changes worth understanding.

For the retailer, the breakdown looked like this:

Charge	July	August	Change
Compute for the order service	1,680 EUR	2,070 EUR	+ 390 EUR
Storage	860 EUR	720 EUR	− 140 EUR
Other services	2,660 EUR	2,660 EUR	0 EUR
Promotional credit	– 400 EUR	0 EUR	+ 400 EUR
Total billed	4,800 EUR	5,450 EUR	+ 650 EUR

Before credits, service charges rose from 5,200 EUR to 5,450 EUR, an increase of 250 EUR. The ended credit added 400 EUR to the amount payable, which brings the total increase to 650 EUR. That left three lines to explain: the credit, the order service and storage.

If a line is too broad to explain, ask the person managing the account to break it down further: by resource (an individual server, database or storage volume), by date, or by type of usage. A daily view often shows when an increase began, which narrows the search quickly.

Alerts can flag changes between reviews. Budget alerts warn when spending passes a threshold you set, and anomaly detection looks for unusual patterns. Check what yours covers. AWS Cost Anomaly Detection, for example, is built to catch unusual increases, so your monthly comparison still needs to show decreases.

3. Investigate the cause

For each material change, the next question is why it happened. Most explanations involve one or more of these:

Consumption: more orders, data, requests or users.
Resources: something added, made larger, or left running after it was needed.
Pricing: a provider price change, or a service moved to a more expensive region.
Credits and discounts: a credit ending or a discount expiring.
Commitment coverage: if you’ve committed to a level of spending in return for a discount, less of your usage may now fall under it. Ask whoever manages the account whether coverage changed. AWS’s Savings Plans coverage report is one example of where to look.

Check what the evidence supports

Two kinds of evidence help you tell these apart. Billing evidence shows what you were charged for: which resources, how many hours or requests, and at what rate. Usage evidence shows how those resources were actually used, such as processing load, request volumes or data stored. A change log records what changed and when. Compare it with billing and monitoring records to check whether the changes are connected.

It helps to record each finding at the level the evidence supports. A cause is confirmed when records show it happened and how it affected the bill. It’s likely when the timing and the type of charge fit, but nobody has yet shown the link to cost. Anything else is still unverified.

Where the systems can be connected, a report can show billing data and change records side by side, so a charge that rose on the day a server was enlarged stands out. Timing alone does not establish the cause.

What the retailer could confirm

The retailer’s technical lead worked through the three lines. The credit was the simplest: the credit record showed it expired on 31 July, so that finding was confirmed, and future forecasts needed to exclude it.

Storage was confirmed too. Deletion records and the billed storage data showed less data stored at unchanged rates, and the company’s retention policy explained why that data had been deleted.

The order service was only partly explained. After customers reported slow checkout, its database had been moved to a larger server, and the change log confirmed the date. Completed orders had also risen over the same period. Both may have contributed, but nobody had yet shown what made up the full 390 EUR.

The question for the technical lead became specific: which charges account for the increase, and what links them to the server change, to order growth or to something else? More orders may have prompted the server change in the first place, so it was worth checking how the two related before splitting the cost between them.

4. Check the operational and business context

Knowing why a cost changed doesn’t tell you whether it’s worth paying. That depends on what the spending supports. Is it still needed? Does it serve more customers, faster performance, recovery after a failure or a planned project? Was it expected, and is it already in someone’s budget?

For the retailer’s larger database server, the technical lead checked whether checkout had become faster after the change and how much processing power and memory the server used, including at busy times. Those resource-use measurements are called utilisation.

The bill shows the server capacity paid for; monitoring shows how much was used. Together with order activity and checkout performance, this helps a team assess whether a larger server meets the business’s needs. More usage does not automatically mean more value. The retailer’s operations manager also asked what would happen to checkout if capacity were reduced again.

Before changing a live service

A few cautions apply before anyone changes a live service. Reducing capacity may not lower the bill straight away if that capacity is covered by an existing commitment. And the effect on customers and on recovery needs checking first. An alert about a cost nobody can explain yet is not, on its own, a reason to resize or shut something down.

Automation still has a role once people have agreed to the rule. If the team approves something like switching off test servers outside working hours, a tool can carry that out within agreed limits.

Falling costs deserve a check as well. The retailer’s lower storage bill was only good news if the copies needed to recover from data loss were still in place. The technical lead confirmed they were.

5. Record the decision

Most material changes end with one of three decisions. You keep the spending because it supports a known need. You investigate further because the cause or the benefit is still unclear. Or you evaluate a change, weighing its likely saving against its effect on the service and getting the required approval before acting.

Whichever you choose, write down the next action, who owns it, who approves it, where approval is needed, and when you’ll review it. The owner coordinates the follow-up. On a shared service, that person can bring the right people together without owning every charge or approving every change.

Assign the actions and review dates

The retailer documented its decisions on 4 September 2026.

The finance lead will update forecasts by 11 September to exclude the expired 400 EUR credit.

The technical lead will investigate the 390 EUR order-service increase and review the findings on 18 September. Current capacity stays in place while the team checks the charges and checkout performance. Any proposed resource change needs the operations manager’s approval after its effect on customers and recovery is assessed.

The operations manager will retain the approved storage policy and check the next complete bill on 5 October, with the technical lead confirming that required recovery copies remain available.

The team added these actions, owners and dates to its task tool and configured reminders to prompt each follow-up, including the investigation that remained open.

The bill difference was accounted for, but the cause of the order-service increase was still partly open, with an owner and a review date.

Your review record

Copy the table below for your own review. Above it, note what you compared: the two billing periods, the accounts and services included, the currency, the cost view, and how credits, refunds, discounts and taxes were treated. Then add one row for each material change.

Cost change	Evidence	Explanation/uncertainty	Decision	Owner	Review date

When questions stay open

Some reviews end with rows still marked “investigate further”. The evidence may sit across several services, or the person who could answer may have little time to look.

TardiTech can help you investigate costs that remain unclear and assess proposed changes before they’re made. Where the same preparation repeats every month, we can also help automate the comparison and the follow-up, so your team’s time goes on the questions that need people. If you’ve completed a review record and still have open questions, bring us the record and those questions, and we’ll start from what you’ve already found.