How much can you actually save?

We will not put a number on it before reading the bill, because the honest answer depends entirely on how the account grew. An account nobody has audited in two years usually has obvious waste in it — idle load balancers, unattached volumes, development environments running through the night. An account that has already been through a cleanup has far less headroom, and we would rather tell you that in week one than bill you for finding nothing.

Will this make our systems slower or less reliable?

Not if it is done in the right order. Deleting genuinely unused resources costs nothing in performance. Right-sizing is done against measured utilisation with headroom left for peaks, not by shaving every instance to its average. Anything that reduces redundancy is flagged as a separate decision for you to make, because that is a risk trade rather than a saving.

What does the percentage-of-savings option involve?

A baseline month is agreed and documented before anything is changed, and the fee is a share of the measured reduction against it for an agreed period. It only works when the baseline is clean — if you are about to launch something that triples usage, or you have just finished a migration, a fixed fee is fairer to both sides and we will say so.

Do you need access to our production systems?

For the analysis we need billing and read access to the accounts, which is enough to produce the findings and the plan. Making the changes needs write access, but they can equally be handed to your own team as an ordered list with the exact resource identifiers. You can take the report and do the work yourself.

Is this the same as switching to a cheaper provider?

No. Moving providers is a migration with its own cost, its own risk and its own data-transfer charges, and it is a separate conversation. This work is about paying the right amount for what you are already running — which is usually where the largest, fastest reductions are anyway.

Will the saving still be there in six months?

Only if guardrails go in with it, which is why the last phase exists. Budget alerts, a maximum on every autoscaling group, tagging enforced on new resources and a short monthly review are what stop the bill drifting back. Without them, a cost cleanup is a one-off that quietly undoes itself.

Cloud, DevOps & Infrastructure

Getting your cloud bill back under control

The bill read line by line, attributed to real workloads, then cut in the order that carries least risk — waste first, sizing second, commitments last.

From: $1,000–$12,000 or % saved
Typical time: 2–6 weeks
Usually bought by: Cloud-heavy clients

What this actually solves

Cloud bills grow for a structural reason rather than a careless one. The people who create spending are engineers, working at speed, doing the sensible thing in the moment. The people who see the invoice are in finance, months later, looking at a document that lists services rather than projects. Nobody is being reckless. There is simply no point at which one person sees both the decision and its price.

So the bill goes up and the explanation goes missing. A staging environment stood up for a two-week test is still running a year later. A load balancer sits in front of a service that was decommissioned, charging its fixed hourly rate to route nothing. Volumes stay behind after the instances they belonged to were deleted. Snapshots accumulate monthly and are never expired. An autoscaling group with no upper limit meets a crawler and quietly runs the compute line up for a weekend. Each of these is small. Together they are usually the difference between the bill you have and the bill you should have.

The second kind is subtler and more expensive — paying full rate for capacity you have used steadily for two years, and paying for data movement nobody has ever looked at. Traffic leaving the provider's network is billed per gigabyte, and so is traffic crossing between availability zones inside it. That second one catches almost everyone, because it appears under transfer rather than under the service that caused it, and a chatty application split across two zones can spend more on talking to itself than on running.

How the work runs

Turn the invoice into something that can be argued with. Cost broken down by service, by environment and by owner, using whatever tagging already exists and noting what cannot be attributed at all. The untagged portion is itself a finding — you cannot manage what nobody owns. Two to four days.
Find the waste, before touching anything that is working. Unattached volumes, idle load balancers, orphaned public addresses, old snapshots and images, non-production environments running outside working hours, and log retention nobody chose. Every item is listed with its resource identifier and its monthly cost so you can approve or veto it individually. Three to five days.
Right-size against real utilisation, not against the shape of the bill. At least several weeks of CPU, memory and disk throughput data, peaks included, with headroom deliberately left. Storage tiers reviewed at the same time — cold data on hot storage is one of the quietest recurring charges there is. Three to five days.
Look at data movement. Egress out of the provider and cross-zone chatter mapped to the workloads that cause them, with the architectural fixes named — moving heavy static files to storage that does not bill for egress, co-locating services that talk constantly, putting a cache in front of an endpoint that is serving the same object thousands of times a day. Two to four days.
Commit last, once the baseline is real. Only after the waste is gone and the sizes are correct is it safe to buy savings plans or reserved capacity, because a commitment locks in whatever shape you are in when you sign it. Discounts for committing are substantial, and they are bought with a one or three year promise — which is exactly why the wrong commitment is expensive for years. Interruptible work is moved to spot capacity where it can genuinely tolerate being reclaimed at a couple of minutes' notice. Two to five days.
Put guardrails in so it stays fixed. Budget alerts, a maximum on every autoscaling group, tagging required on new resources, and a short monthly review with the numbers next to last month's. Two to three days.

What moves the price

How many accounts there are. One account with forty resources is an afternoon of analysis. Six accounts across two providers, with shared services billed to one of them, is a genuinely different piece of work before a single saving is found.

Whether the architecture can change. If the engagement is limited to dials — sizes, tiers, schedules, commitments — it is quicker and the ceiling is lower. If the transfer and storage findings can actually be acted on, the saving is larger and the work is longer, because that is engineering rather than configuration.

The commercial model. A fixed fee is simpler and suits accounts where the outcome is uncertain. A share of measured savings suits accounts with obvious headroom, and needs a documented baseline month agreed in writing before anything is touched.

What usually goes wrong

Commitments are bought first because they are the easy win. Reserved capacity or a savings plan signed in week one locks in today's oversized instances for a year or three. Every later right-sizing then fights the commitment, and you end up paying a discounted rate for capacity you should not have been running at all. Waste and sizing come first for this exact reason.

The compute line gets all the attention while transfer quietly wins. Everyone looks at instances because they are the biggest single row and the easiest to understand. Data transfer is spread across the invoice, is not obviously anybody's fault, and on chatty multi-zone systems can be the largest genuinely removable cost in the account.

Something dormant turns out to be the recovery plan. The idle standby instance, the snapshot set older than the retention policy, the second-region bucket that nothing writes to — these look exactly like waste and are sometimes the only thing standing between a bad day and a lost business. Nothing is deleted from a report alone. Every candidate is confirmed with whoever built it, and anything that cannot be traced to an owner is stopped first and deleted only after it has been proven not to be missed.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

How much can you actually save?: We will not put a number on it before reading the bill, because the honest answer depends entirely on how the account grew. An account nobody has audited in two years usually has obvious waste in it — idle load balancers, unattached volumes, development environments running through the night. An account that has already been through a cleanup has far less headroom, and we would rather tell you that in week one than bill you for finding nothing.
Will this make our systems slower or less reliable?: Not if it is done in the right order. Deleting genuinely unused resources costs nothing in performance. Right-sizing is done against measured utilisation with headroom left for peaks, not by shaving every instance to its average. Anything that reduces redundancy is flagged as a separate decision for you to make, because that is a risk trade rather than a saving.
What does the percentage-of-savings option involve?: A baseline month is agreed and documented before anything is changed, and the fee is a share of the measured reduction against it for an agreed period. It only works when the baseline is clean — if you are about to launch something that triples usage, or you have just finished a migration, a fixed fee is fairer to both sides and we will say so.
Do you need access to our production systems?: For the analysis we need billing and read access to the accounts, which is enough to produce the findings and the plan. Making the changes needs write access, but they can equally be handed to your own team as an ordered list with the exact resource identifiers. You can take the report and do the work yourself.
Is this the same as switching to a cheaper provider?: No. Moving providers is a migration with its own cost, its own risk and its own data-transfer charges, and it is a separate conversation. This work is about paying the right amount for what you are already running — which is usually where the largest, fastest reductions are anyway.
Will the saving still be there in six months?: Only if guardrails go in with it, which is why the last phase exists. Budget alerts, a maximum on every autoscaling group, tagging enforced on new resources and a short monthly review are what stop the bill drifting back. Without them, a cost cleanup is a one-off that quietly undoes itself.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Cloud cost optimisation (FinOps) All Cloud, DevOps & Infrastructure services