ยท 5 min read
Your cloud bill doubled and nobody can say why.
A cloud bill that doubles is almost always a record of decisions nobody costed, not a pricing change. You can usually find which decision in an afternoon, with three questions and no new tooling.
Why did my cloud bill double?
Because a specific thing changed, and the invoice was the last system to hear about it. Pricing on AWS, GCP and Azure moves slowly and mostly downward, so a bill that jumps 80 to 120 percent in a quarter is tracking a decision inside your own company, not a rate card. The usual causes are dull: a new environment that was meant to be temporary, a logging or retention default left on, a data volume that grew with a customer you onboarded, or an architecture that now copies the same data several times. None of them announce themselves. All of them bill every month until someone looks.
Read the bill as a list of decisions
The mistake is to read the bill as a list of services. Read it as a list of choices instead. Sort the top ten line items by how much they grew, not by how large they are, and next to each one write the decision that would explain the growth. Most lines will have an obvious owner and reason. One or two will not, and those are where the doubling lives. This takes an afternoon and a read-only billing role, no platform required. The deeper version of the same problem is about who owns the architecture, which I cover in reducing AWS costs.
The three questions that find it
Before any tool, ask these three. They are what I ask in the first hour of a cost engagement, and they usually reach the cause before a dashboard has finished loading.
- What changed the month the curve bent? Line the billing graph up against your deploy log, your customer list, and your infrastructure changes. The increase has a start date, and something shipped near it.
- Which lines grow with customers, and which grow with nothing? Spend that tracks revenue is the cost of the business. Spend that climbs while revenue is flat is either technical debt or waste, and it is the whole game.
- Who would notice if this line went to zero? If you can name the person and the feature, keep it. If nobody owns it, you have found the waste. Unowned cost does not shrink on its own; it compounds.
Across more than one engagement, a doubled bill traced back to a single unglamorous change: a non-production environment cloned for a load test and never destroyed, or a retention setting that quietly kept every log and snapshot forever. In one case the split showed most of the increase was paying for things nobody owned, and the largest fix cost a decision rather than an engineer-month. The line that scales with nothing is usually the one to reverse, and it maps cleanly onto what technical debt costs per month.
What not to do
Do not start by calling your account manager. A savings plan on a bill you have not cleaned locks the waste in for three years at a discount. Do not buy a FinOps tool and treat the graph as the fix; a dashboard of unowned cost is just a tidier version of not looking. And do not re-platform to escape the number. Moving an architecture you do not yet understand to new infrastructure keeps the increase and adds a migration. Find the decision first. Then negotiate, tool, or rebuild if you still need to, which is the order the cloud-cost work follows.
Frequently asked
Why did my cloud bill double?
Because a specific decision inside your company changed, and the invoice was the last system to hear about it. Cloud pricing moves slowly and mostly downward, so a bill that jumps 80 to 120 percent in a quarter is tracking a choice you made, not a rate card. The usual causes are dull: a temporary environment that was never destroyed, a logging or retention default left on, a data volume that grew with a new customer, or an architecture that now copies the same data several times.
How do I find why my cloud bill went up?
Read the bill as a list of decisions, not a list of services. Sort the top ten line items by how much they grew, line the billing graph up against your deploy log and customer list to find the month the curve bent, and ask who would notice if each line went to zero. Lines nobody can name are where the increase lives. This takes an afternoon and a read-only billing role, with no FinOps tool required.
Should I buy a FinOps tool to fix a rising cloud bill?
Not first. A dashboard shows you the same numbers sooner, but it does not tell you which decision to reverse and it will not switch anything off. Find the decision behind the increase and give each large line an owner before you buy tooling or negotiate a savings plan, or you will lock the waste in at a discount.
Written from patterns I've seen across engagements. If any of it sounds too specific to be general, that's why.