A Solutions Architecture Approach to Cost Optimisation
If your AWS or Azure bill has started arriving with a slight sense of dread, you’re not alone. It’s one of the most common conversations we have with growing tech-focused businesses: the cloud spend crept up gradually, nobody quite knows why, and the instinct is to assume you just need to “use less cloud” — which usually isn’t the actual answer.
Cloud cost problems are rarely about usage being too high. They’re almost always about architecture that was never designed with cost in mind — because early on, it didn’t need to be. The good news is that this is one of the more fixable problems a scaling business will face, provided you’re solving the right problem.
Why cloud costs spiral
Cloud pricing is built to reward planning and punish improvisation. That’s not a criticism of AWS, Azure, or GCP — it’s just the nature of pay-as-you-go infrastructure. A few patterns show up again and again in growing businesses:
- Over-provisioning “just in case.”
- Resources sized for a traffic spike that happens twice a year, running at that size the other 363 days.
- Orphaned resources.
- Test environments, old databases, and unused storage volumes that were spun up for a project that finished months ago and never got switched off.
- No visibility into what’s actually driving spend.
- Without proper tagging and cost allocation, nobody can say which feature, team, or customer is responsible for which part of the bill — so nobody can prioritise fixing it.
- Architecture that made sense at a smaller scale.
- A design decision that was cheap and simple at low volume can become the single biggest line item on the bill once usage grows 10x, without anyone noticing the shift happened.
- Default settings left untouched.
- Many services default to convenient, not cost-efficient. Nobody revisits those defaults once the system is live and working.
None of these are exotic problems. They’re the predictable result of infrastructure decisions made under time pressure, by a team focused — rightly, at the time — on shipping rather than on the invoice.
Why “just cut costs” isn’t the right frame
The instinctive response to a high cloud bill is to go looking for things to switch off. That can help at the margins, but it treats the symptom, not the cause — and it risks cutting something that turns out to matter, or missing the structural issue that will just regenerate the same costs in six months.
A Solutions Architecture approach starts from a different question:
Not “what can we cut?” but “does the architecture match how the system is actually being used?”
That reframing usually surfaces bigger, more durable savings than a line-by-line audit of what to switch off.
Where the real savings usually are
In our experience, the biggest wins tend to fall into a small number of categories:
- Right-sizing, properly done.
- Not just picking a smaller instance, but matching compute and storage tiers to real, observed usage patterns rather than the original guess made at launch.
- Committing to savings plans or reserved capacity — but only once usage is stable.
- These can offer meaningful discounts, but committing too early, before your architecture has settled, can lock in inefficiency rather than remove it.
- Re-architecting for elasticity.
- Systems that scale down as well as up — rather than running at peak capacity permanently — can be one of the largest single savings available, particularly for workloads with predictable quiet periods.
- Storage lifecycle management.
- Data that’s accessed constantly and data that’s accessed once a year shouldn’t be sitting in the same (expensive) storage tier. This is often one of the simplest fixes with an outsized impact.
- Visibility and ownership.
- Proper tagging and cost allocation so that spend is attributed to the team, product, or feature responsible. You can’t optimise what you can’t see, and you can’t hold anyone accountable for a bill nobody can attribute.
Cost optimisation as an ongoing discipline, not a one-off clean-up
The other trap is treating cost optimisation as a single project: do a big review, fix what’s obviously wasteful, move on. That works once. Then the same drift starts again, because the underlying architecture and habits that created the problem the first time are usually still there.
The more durable fix is building cost awareness into how architecture decisions get made going forward — so that “what will this cost at scale?” is part of the design conversation from the start, not a question asked eighteen months later when the bill has become impossible to ignore.
The commercial case for getting this right
For a tech-focused SMB, infrastructure cost isn’t a back-office line item — it’s a direct input into your margins, your runway, and how much room you have to reinvest in the product. A well-architected system doesn’t just perform better; it’s usually the cheaper one too, because most cost inefficiency and most technical fragility come from the same root cause: architecture that wasn’t given the chance to be deliberate.
Getting a proper architectural view of your cloud spend, before deciding what to cut, tends to save more money and cause far less disruption than starting with the axe.
Ashdown Systems helps UK tech-focused startups and SMBs get their cloud architecture — and their cloud bills — under control. If any of this sounds familiar, get in touch.