AWS bills have a way of growing faster than the work they support. The quarterly cost review brings them back down for a month. Three months later, the same conversation lands on the same desk, and the bill has drifted back up.

This isn't a software problem. The tools to control AWS spend are well understood and widely available. It's a structural problem, and the structure tends to look the same across mid-market businesses.

How AWS capability arrives, quietly

AWS shows up in a smaller business the same way most useful infrastructure does. An engineer needs more compute, or storage, or speed. AWS fits the bill. The team starts using it. There's rarely a deliberate cloud strategy at this point. There's rarely a budget line called "cloud operations". The engineer who provisioned the platform also becomes the AWS person.

Six months later, that engineer is also the security person, the cost person, the disaster recovery person, and most weekends, the on-call person. None of this is a failure. It's how cloud capability tends to grow inside businesses of this size: organically, around whoever happened to be in the room when AWS first turned up.

The trade-off comes later, and quietly.

The cost pattern that emerges

Three things tend to happen as the months pass.

First, the work of cutting the bill slides down the priority list. The engineer carrying AWS is also carrying many other things. When release pressure lands, infrastructure tuning 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's actually running widens, and nobody quite has time to close it.

Third, the architecture outgrows itself. The pattern that worked for the early days doesn't 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 don't fix it

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

Then the same drift happens again, because the underlying structure hasn't changed. The same engineer is still carrying everything. The same priorities still apply. The cost work is still secondary to whatever the team is shipping that quarter.

Quarterly reviews help. But they're a treatment, not a fix.

The shift that actually works

The teams that move out of this loop aren't the ones that buy a new tool, build a more sophisticated dashboard, or adopt a better tagging convention. They're the ones where the AWS work gets a home.

Cloud cost work, security posture, incident response, architectural review: none of these are technically hard. They're operationally hard at this scale because nobody owns them in full. The work has no fixed home. It lands on whoever can spell AWS, alongside everything else they're already doing.

When the work gets a clear home (an internal hire, a partner running it as a 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 isn't about removing internal capability. It's 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 a mid-market business isn't the enterprise product. It isn't 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 work as a monthly habit rather than a quarterly project. Security posture as a baseline, not a panic response.

Most of the businesses 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 weren't doing before. That's the part nobody mentions in the cost pitch, and it's the part that matters most.

Where does the cost drift currently sit in your business: at the engineer level, the FD level, or somewhere in 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 mid-market businesses exploring whether their AWS work has the right home. No pitch, no obligation. An honest conversation about where you are and what's possible.

Book a discovery session