Cloud spend is climbing and nobody can explain it
The hard part is making a change you can defend afterwards, and knowing which team owns the line it came from. A list of savings nobody dares apply is not a result.
Usually raised by: Engineering director, platform owner, or a finance partner working with them.
What normally triggers it: A budget conversation, a finance partner asking for attribution, or a bill that grew faster than usage.
- AWS
- Datadog
- Grafana
- Terraform
You probably recognise some of these.
Not all of them, and not in this order. If three or four land, this is the page you want.
- Cost cannot be attributed to a team, a product or an environment.
- Non-production is a significant share and nobody is sure what is still needed.
- Commitments were bought before anyone analysed the workload.
- There is a worry that cutting cost will quietly cut reliability.
What is different afterwards.
A baseline you can attribute, a short list of changes that were validated before being made, and budgets and controls handed to the people who own the spend.
The work itself
- Establish a cost baseline and get allocation working — tags, accounts, or whatever the estate can actually support.
- Identify avoidable consumption, separating the obvious from the load-bearing.
- Hand over budgets, alerts and the operating controls to the owning teams.
Who does it: an InfraEdge engineer, who walks your team through what was found and answers your reviewer on each change.
From a bill nobody owns to a line somebody does.
Every line of spend mapped to a team, a product or an environment.
Candidate changes checked against observed utilisation first.
A reviewed, reversible pull request — the normal approval path.
Budgets and alerts handed to the team that owns the line.
Baseline, allocation, and a validated first set of changes
One account or one environment, with the changes limited to those you approve individually.
Done when
Spend is attributable for the scope, each approved change is applied through the normal review path with its reasoning recorded, and before-and-after usage is reported where the data exists to support it.
What you receive
- A cost baseline and allocation model
- A change list with the evidence behind each, including the ones we advised against
- Budgets and alerts handed to the owning teams
- Measured before-and-after usage where it is genuinely available
What we need from you
- Billing and usage data access, and a named owner for cost decisions
- A reviewer for each change, since these are production changes like any other
What makes it larger or smaller for you.
The variables that drive the size, judged against your own estate.
Larger if
- Allocation has to be built before anything can be attributed — tagging, account boundaries, or both
- Commitments already purchased, which constrain what any change can do
- Spend concentrated in data transfer and managed services, where a change needs deeper validation before it is safe
Smaller if
- One account or one environment in scope
- Tagging or account boundaries that already support attribution
- Non-production consumption that is plainly unneeded once it is listed
For a sense of elapsed time on work of this shape, the phased timeline on a comparable engagement is published with it. We do not quote a duration for your estate before seeing it, and the scope you receive after the call names the package rather than an hourly rate.
What this does not include.
Stated here rather than discovered later.
- We do not guarantee a percentage saving. Observed savings, estimates and hypotheses are labelled as what they are.
- We do not recommend commitment purchases before the workload has been analysed.
How do we know a cost change will not cause an outage?
Because each one goes through the same review and approval path as any other production change, and is chosen to be reversible. Where a change cannot be made safely reversible, it is flagged as such and you decide. We would rather hand back a shorter list than a riskier one.
What we can point at.
Anonymised prior delivery, described by technical shape. No client names, no logos, and no figures we did not measure.
Problems that tend to arrive together.
A good baseline is quietly drifting back
Remediation nobody re-checks drifts back. Keeping it from doing so means being precise about three different things: what is detected automatically, what an engineer reviews, and what is actually changed.
Accounts, identity and networking no longer fit the organisation
Usually the structure was right for the company that built it, and that company no longer exists.
Describe the project
Twenty minutes, no charge, with the engineer who would do the work. We work out whether this is the work you need and whether we are the right people — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.