Services / Cloud / Cost optimisation

The same systems, a smaller bill every month

Cloud bills grow by accident, a test environment nobody switched off, a database sized for a launch that never happened, three years of logs nobody has read. We find it, prove it is safe to remove, and leave controls behind so it does not quietly come back.

Start the conversation →See the technology

Why it matters

The cost is the wait

Nobody decides to overspend on cloud. It accumulates. Someone runs a bigger machine to get through a busy week and never scales it back. A project ends but its environment keeps running. A default setting retains every log for a year because changing it was never anyone's job. Each individual decision was reasonable. The invoice at the end of the year is not.

The reason it persists is that cloud bills are close to unreadable. A single line item can cover forty different things, the units are unfamiliar, and the person signing it off has no way to connect a charge to a system, a team or a customer. Finance cannot challenge what it cannot interpret, and engineering has no visibility of what anything costs, so the conversation simply never happens.

Our job is to make the bill legible first and smaller second. Every cost gets attributed to something a human recognises. Waste gets listed and ranked by saving and by risk, then removed with your approval. Then the guardrails go in (budgets, alerts, ownership, a short monthly review) because savings only stick when somebody keeps looking.

What you actually get

Built to be trusted

Cutting a cloud bill is mostly method rather than cleverness. This is the method.

A bill you can actually read

Every resource tagged and every cost attributed to a system, an environment, a team and, where it matters, a customer. Once spend has an owner's name against it, most of the argument about whether it is necessary answers itself.

Switching off what nobody uses

Idle machines, unattached disks, forgotten snapshots, load balancers with nothing behind them, environments left over from finished projects. The safest savings in cloud are the things that are running and doing nothing, and there are always more of them than anyone expects.

Right-sizing on evidence

We measure real usage over weeks before changing anything, rather than guessing from a graph on the day. Machines and databases end up sized for observed demand with genuine headroom, not for the reassurance of a number somebody picked once and nobody revisited.

Buying at the right price

Committed-use discounts, reserved capacity and spot instances cut compute costs substantially, but only for the portion of your usage that is genuinely steady. We commit the stable baseline and leave the variable part flexible, so a discount never turns into a bill for capacity you stopped needing.

Paying only when things run

Non-production environments switched off outside working hours, batch work moved onto cheaper interruptible capacity, occasional workloads moved to pay-per-use. For systems used a few hours a day this is usually the single largest saving on the table.

Guardrails so it stays down

Budgets with alerts that fire before the invoice, cost estimates attached to infrastructure changes while they are still under review, and a short monthly readout in plain language. Without this, a bill returns to roughly where it started within a year.

Where it earns its keep

Same pattern, different desks

Where the money goes depends on your business model, so the first useful question is always what you actually sell.

01 · Subscription software (SaaS)

Nobody knows what a customer costs to serve

The problem: Infrastructure arrives as one undifferentiated bill. The team cannot say what the largest account costs to run, whether the free tier is affordable, or which feature is quietly eating the margin, so pricing decisions get made on instinct and the board asks questions nobody can answer.
What we build: Resources are tagged and shared costs allocated by a method the finance team can defend, producing cost per customer, per tier and per feature. Idle and oversized components go first, then the steady baseline is bought on commitment while burst capacity stays flexible.
What changes: A gross margin figure finance trusts, a clear view of which accounts are unprofitable at their current price, and a bill that stops growing faster than revenue.

02 · Online retail & media

Provisioned for peak, all year round

The problem: The platform is sized for the busiest day of the year, so eleven months of capacity sits mostly idle. On top of that, images and video are served straight from origin storage, and the data-transfer line on the invoice has quietly become one of the largest.
What we build: Automatic scaling is introduced so capacity follows demand, with a realistic load test proving the peak is still covered. Media moves behind a CDN with aggressive caching and long-lived asset URLs, and storage lifecycle rules move older files to cheaper tiers instead of keeping everything on the fastest one.
What changes: Peak days stay comfortable, the quiet months cost a fraction of what they did, and data transfer stops being a line item nobody can explain.

03 · Data & analytics

A warehouse that scans everything, every time

The problem: Dashboards refresh on a schedule whether anyone opens them or not, queries scan whole tables because nothing is partitioned, and a processing cluster spun up for a one-off project has been running ever since. The data team is productive; the data bill is growing faster than the data.
What we build: Query patterns are reviewed and the expensive ones rewritten, tables partitioned and clustered so scans read a fraction of the data, results cached, refresh schedules matched to who genuinely looks at them, and clusters set to shut themselves down when idle.
What changes: The same analysis at a materially lower cost per query, with spend visible per dashboard so the team can see the price of a design decision while they are still making it.

The technology

The tools behind it, named

Cost work is mostly visibility and discipline, but a few specific tools do the heavy lifting.

6 layers · 31 technologies

Where the money is going

The bill lives in the provider's own tooling. The first job is turning it into something a finance team can interrogate without a translator.

Amazon Web Services
Microsoft Azure
Google Cloud
Cloudflare
Vercel
DigitalOcean

Making cost visible

Spend broken out by system, team and environment, in the same dashboards your engineers already have open, so cost stops being a monthly surprise delivered by finance.

Grafana
Prometheus
Datadog
Metabase
Native cost explorers

Costing a change before you make it

An infrastructure change that increases the bill should say so during review, while it is still cheap to change your mind about it.

Infracost
Terraform
OpenTofu
GitHub Actions
GitLab

Cutting the compute bill

Right-sized, scaled to demand, and running on the cheapest class of capacity the workload can genuinely tolerate.

Kubernetes
Docker
Cloudflare Workers
Spot & preemptible capacity
Serverless functions

Cutting storage and transfer

Usually the least-examined part of a bill, and often the easiest to halve, through caching, lifecycle rules, and not paying premium prices to store data nobody reads.

Cloudflare
Backblaze B2
PostgreSQL
Redis
Elastic
Storage lifecycle rules

Keeping it honest

Budgets, alerts and a monthly report written for a director rather than an engineer, because the person who can stop the spend is rarely the person who started it.

Slack
Grafana
Provider budget alerts
Monthly written review

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

A first pass takes a few weeks and is deliberately low-risk. Nothing is deleted without your approval, and the reversible savings come first.

Read-only access, and a complete picture

We start with billing data and read-only access to the environments. Nothing changes. What comes out is a full inventory of what exists, what it costs, and what, if anything, is actually using it.

Everything gets an owner

Tagging is applied consistently so every pound maps to a system, an environment and a team. Untagged spend gets chased down item by item, because that is reliably where the worst of the waste has been hiding.

The waste list

You get a ranked list: what each item saves, what it takes to do, and how risky it is, with every entry marked reversible or not. Anything we cannot prove is unused is flagged for your confirmation rather than deleted on our judgement.

Quick wins first

Reversible savings that need no architectural change go first: unused resources removed, non-production scheduled off out of hours, lifecycle rules applied, log retention set to something deliberate. This part normally pays for the exercise before anything harder begins.

Right-sizing and commitments

Only once there are weeks of real usage data do we resize workloads or buy committed discounts, and only against a baseline you are confident will still exist. You see the modelling behind every commitment before anything is signed.

Guardrails and a monthly rhythm

Budgets and alerts go in, cost estimates are added to your change process, and we review spend with you every month: what moved, why, and what to do about it. Short meeting, plain language, specific actions.

Before you commit

The questions worth asking

Is the cloud actually cheaper than owning servers?

Not automatically, and it is worth being blunt about it. If you take the servers you own and rent equivalent machines that run twenty-four hours a day at list prices, the cloud will usually cost more rather than less. It wins when you use what it is genuinely good at: paying only for what runs, scaling down as well as up, and handing maintenance to managed services so you stop paying people to patch things. Where a workload is steady, predictable and already bought and paid for, we will tell you it is fine where it is.

Will cutting costs make things slower or less reliable?

It can, which is why every recommendation carries a risk rating rather than just a number. Removing something genuinely unused carries no risk. Right-sizing carries a little. Dropping a redundant standby to save money carries real risk, and there are savings we will actively advise you not to take. You make the call with the trade-off written down in front of you.

Should we sign up for one- or three-year discounts?

For the portion of your usage that will certainly still be there, yes. The discounts are substantial and leaving them on the table is expensive. But a commitment is a bet on your own future, and companies do change platform, rewrite systems or lose a large customer. We commit conservatively against a measured baseline and keep the variable portion at flexible rates, so a change of plan costs you some flexibility rather than money you have already spent.

How quickly do the savings show up?

Removing unused resources shows on the next invoice. Right-sizing and commitments take a billing cycle or two to read properly, because usage varies week to week and one quiet fortnight proves nothing. Architectural changes (moving to pay-per-use, restructuring how data is stored) take longer and are only worth doing where the modelling justifies the effort.

Do you need access to production?

We start read-only, and for a great deal of this work that is all we ever need. Changes go through your normal change process, in agreed windows, with you approving the list. If you would rather your own team makes every change while we produce the analysis and the pull requests, that works perfectly well too.

What stops the bill creeping back up?

Ownership and visibility, mostly, which is not really a technology problem. If nobody can see what a system costs and nobody is accountable for it, spend will drift again. The guardrails we leave behind are budgets that alert before the invoice, cost estimates attached to infrastructure changes, and a monthly review that takes twenty minutes. It is unglamorous, and it is the part that decides whether the savings last.

Think you're overpaying?

Send us a recent cloud invoice and a rough description of what you run. We'll tell you where the obvious waste is likely to be, and whether it's worth a proper look at all.

Start the conversation →

Explore more

The rest of Cloud & Infrastructure

Migration Security & compliance Reliability ← All of Cloud