Across the smaller cloud-using firms we work with, UK businesses sitting between fifty and a few hundred employees, often with a single engineer or a small team carrying AWS, a recurring shape keeps appearing in finance reviews.

The AWS bill rises faster than the workloads it supports. A quarterly cost discussion triggers a brief reduction. A few months later, the same conversation lands on the same desk, and the same shape is back.

This is not a tooling problem. The tools to control cloud cost are well understood and widely available. It is a structural problem, and the structure tends to look the same across SMB-shaped businesses.

How AWS capability grows inside smaller firms

When AWS first arrives in a smaller business, it tends to do so quietly. An engineer needs more compute, or storage, or speed; AWS fits the bill, and the team starts using it. There is rarely a deliberate cloud strategy at this stage. There is rarely a budget line for cloud operations. The engineer who provisioned the original platform also becomes the AWS person.

Six months later, that engineer is also the security person, the cost person, the disaster recovery person, and often the on-call person. This is not a failure. It is how cloud capability grows organically inside firms of this size.

The trade-off comes later, and quietly.

The cost pattern that emerges

Three things tend to happen as the months pass.

First, optimisation drifts down the priority list. The engineer carrying AWS has many other things to carry. When release pressure lands, infrastructure tuning is the work that gets postponed. Idle resources accumulate. Reserved-capacity opportunities are missed. The default settings stay default.

Second, the security posture loosens. Permissions widen as the team grows. Service quotas drift from their original shape. Alerts pile up and stop being read. The gap between what was configured and what is actually running widens, and nobody quite has time to close it.

Third, the architecture outgrows itself. The pattern that worked for the early days does not necessarily work at the current scale. New services get bolted on rather than integrated. The system gets harder to reason about. Incident response slows because nobody has a complete picture.

By the time the cost surprise lands in front of the FD, the bill is reflecting all three of these dynamics, not just one.

Why quarterly reviews do not fix it

A common response is to schedule a quarterly cost review. The team picks through the bill, finds the obvious idle resources, switches off a few of them, applies some rightsizing, and the bill comes down for a month or two.

Then the same drift happens again, because the underlying structure has not changed. The same engineer is still carrying everything, the same priorities still apply, and the optimisation work is still secondary to whatever the team is shipping that quarter.

Quarterly reviews are useful, but they are a treatment, not a fix.

The structural shift that does work

The pattern we see across firms that have moved out of this loop is not a new tool, a more sophisticated dashboard, or a better tagging convention. It is operational ownership.

Cloud cost optimisation, security posture management, incident response, and architectural review are not technically hard. They are operationally hard at SMB scale because nobody owns them in full. The work has no fixed home. It lands on the engineer who can spell AWS, alongside everything else they are carrying.

When the work gets a clear home, internal hire, a partner running it as managed service, or a hybrid, the pattern breaks. Cost drift slows. Security posture firms up. Incident response improves because somebody is actually watching. The engineer originally carrying everything goes back to building things.

This is not about removing internal capability. It is about giving the steady continuous work a place to live, so the internal team can focus on the parts only they can do.

What this looks like in practice

A managed AWS engagement that fits an SMB-shaped business is not the enterprise product. It is not 24/7 SOC, layered support tiers, or a 200-page SLA. The shape that tends to work is smaller and more direct. Senior engineers, UK based, on the same call the customer joins. Continuous monitoring rather than periodic review. Cost optimisation as a monthly habit rather than a quarterly project. Security posture as a baseline, not a panic response.

Most of the firms we work with came in through a small scoped piece first, often a cost or security review, before any commitment to a longer engagement. AWS funds the assessment phase through the Optimisation and Licensing Assessment programme and the Well-Architected Framework Review, so the entry point usually carries no upfront cost.

The conversation after the bill

When the cost shape does shift, the conversation tends to move away from the bill itself, and onto what the team is now able to do that they were not doing before. This is the part nobody mentions in the cost-optimisation pitch, and it is the part that matters most.

Where does the cost drift currently sit in your business: at the engineer level, the FD level, or somewhere between?

Start with a conversation

D55 is an AWS Advanced Consulting Partner running managed AWS services for UK businesses across multiple sectors. We offer a complimentary cost or security review for SMB-shaped firms exploring whether their AWS work has the right home. No pitch, no obligation. Just an honest conversation about where you are and what is possible.

Book a discovery session