Your cloud bill, decoded – and cut down
In practice, your cloud bill breaks down into four cost types: compute (servers running your code), storage (databases and files), data transfer out of the cloud, and managed services. It rarely grows because of one bad decision, but because of forgotten environments and oversized capacity. A quarterly review with the right questions keeps it in check.
A growing cloud bill with no clear cause is one of the most common sources of discomfort for buyers. Hundreds of lines with cryptic service names, a total that keeps creeping upward, and no one who can quite explain why. But behind the line items there are really just a handful of categories. Once you understand them, you can both budget for operations and question them.
The four things you’re actually paying for
Almost everything on the bill sorts into four categories.
- Compute. Servers, containers, and functions that run your code. Almost always the biggest line item. The price is driven by how much capacity you reserve and how many hours it runs – not by how much it’s actually used.
- Storage. Databases, files, and backups. Cheap per gigabyte but grows steadily, since data is rarely deleted. Frequently read data costs more than untouched archive data.
- Data transfer. Traffic into the cloud is generally free, traffic out is priced per gigabyte. This is the line item that most often confuses people, especially for products that deliver files, video, or large API responses.
- Managed services. Managed databases, queues, email delivery, AI calls, monitoring. Convenient building blocks you skip operating yourself – but each has its own price tag, and they add up.
Most of what feels incomprehensible on the bill is really just one of these four, expressed in the vendor’s own product names.
A concrete example
Say you’re running a web application: a couple of containers behind a load balancer, a managed database, file storage, and monitoring. Compute is your heaviest line item. The database comes next, as a managed service you pay for to avoid running it yourself. Storage is small but steady. Then you launch an export feature that lets customers download large reports – and suddenly data transfer stands out clearly, a line item that was barely noticeable before. No one did anything wrong. A new feature just shifted the weight between categories, and without monitoring it only shows up on the bill.
Where the waste almost always hides
Cloud costs rarely rise because someone made a bad decision, but because no one made any decision at all. The most common leaks look the same everywhere:
- Oversized capacity. Capacity ordered for a spike that never came and was never scaled back down.
- Forgotten environments. Test setups, old disks, and copies no one shut down. They keep billing every month, quietly.
- Everything running around the clock. Development and test environments running nights and weekends even though no one’s using them.
- Surprise traffic. A new feature that sends a lot of data out, without anyone calculating what it costs.
The good news is that none of this requires a rebuild to fix. It’s about oversight, not architecture.
The questions to ask at the quarterly review
Do a review with your vendor every quarter and bring these questions along. They move the conversation from an incomprehensible total to concrete decisions.
- What are our three biggest line items this month, and why?
- Which resources are running but effectively unused – can they be shut down or scaled back?
- Are all environments running around the clock, or can test and development be shut down outside working hours?
- Do we have predictable baseline load that would pay off to reserve instead of paying hourly?
- What drove the latest increase, and was it expected?
- Are there forgotten disks, snapshots, or old copies we can clear out?
A vendor who cares about the relationship answers these directly. If you just get a shrug and a “the cloud is expensive,” that’s itself an answer worth noting.
Separate operational cleanup from architecture
A quarterly review cleans up and trims what already exists. It doesn’t fix a setup that’s misconfigured from the ground up – that’s bigger work that belongs in architecture, not in monthly housekeeping. Mix the two up and you often expect a review to halve a bill that’s actually high for structural reasons. If you don’t know which case is yours, that’s exactly the question a review should answer.
At Weapp we work with cloud architecture as part of our services and are happy to help read a bill that’s gotten out of hand. Get in touch and we’ll take a look at it together.
Frequently asked questions
Why is data transfer a cost category on its own?
Data going into the cloud is nearly always free, but data going out is priced per gigabyte. It's called egress and often catches people off guard, since it doesn't show up in the code. A new feature that exports large files or streams video can therefore show up more on the bill than in the development work.
What does oversized capacity in the cloud mean?
That you're paying for more capacity than you use. A server ordered for a traffic spike that never came, and then never scaled back down, costs full price around the clock. The cloud bills reserved capacity, not actual usage, so unused power is pure loss until someone actively scales it down.
How often should we review cloud costs?
Quarterly is a reasonable pace for most. Often enough to catch forgotten environments and runaway traffic before they've cost much, but not so often it becomes a burden. During rapid growth or major product changes, monthly reviews can pay off.
What's a reasonable cloud cost for a smaller product?
An early product with moderate traffic often gets by on a few thousand kronor a month, sometimes less with serverless. What matters isn't an exact figure but that cost grows proportionally with usage. A bill that spikes without traffic doing the same is a warning sign worth digging into.
Can we cut the bill without rebuilding the product?
Usually, yes. Shrinking oversized servers, shutting down test environments at night, cleaning up forgotten resources, and reserving capacity for predictable load require no re-architecture. That kind of action can typically remove a significant share of the cost without users noticing anything at all.