The cost review lands on the same desk three quarters in a row. The numbers move, the slide gets a fresh date, the same conversation happens. A bit of tidying gets agreed. Three months later, the bill has drifted back up.

The platforms for keeping AWS costs in check are well understood and widely available. What keeps the bill drifting is the structure around them, and that structure looks roughly the same across mid-market businesses.

How AWS shows up in the first place

AWS arrives in a smaller business the way most useful infrastructure does. An engineer needs more compute, or more storage, or somewhere to put a dataset that's outgrown the office NAS. AWS fits. The team starts using it. Nobody calls it a cloud strategy. Nobody adds a budget line called cloud operations. The engineer who provisioned the first account becomes the AWS person by default.

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 that is anyone's failure. It's how cloud capability grows 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.

What the bill is actually reflecting

Three things happen as the months pass.

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 is what gets postponed. Idle resources accumulate. Reserved capacity opportunities pass. The default settings stay default.

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

The architecture outgrows itself. The pattern that worked for the early days doesn't fit the current scale. New services get bolted on rather than integrated. The system gets harder to reason about, and 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 at once, not just one.

Why the quarterly review doesn't break the loop

The natural 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 number comes down for a month or two.

Then the same drift starts 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. They're a treatment, not a fix.

What actually breaks the cycle

The businesses that move out of this loop aren't the ones that buy a new platform, 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 it's technically hard. It's operationally hard at this scale because nobody owns it in full. The work has no fixed home. It lands on whoever can spell AWS, alongside everything else they're already doing. When somebody owns it, the bill stops drifting on its own.

When the work gets a clear home, whether that's an internal hire, a partner running it as a service, or some combination, the pattern breaks. Cost drift slows. Security posture firms up. Incident response improves because somebody's actually watching. The engineer who was originally carrying everything goes back to building things, which is what you hired them for in the first place.

The shift gives the steady continuous work a place to live. Internal capability stays where it is; the engineer who was carrying everything gets to focus on the parts only they can do, which is what they were hired for in the first place.

What it looks like in practice

A managed AWS engagement that fits a mid-market business isn't the enterprise product. No 24/7 SOC, no layered support tiers, no 200-page SLA. The shape that works is smaller and more direct. Senior engineers, UK based, on the same call you join. 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 run AWS for came in through a small scoped piece first, usually 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. For most teams, the cost of finding out what's actually wrong is zero.

The conversation that comes next

When the cost shape does shift, the conversation moves off the bill. It moves on to 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 the cost drift sits in your business says something about the gap. At the engineer level it's an ownership question. At the FD level it's a structure question. Somewhere between the two is the most common.

Start with a conversation

D55 is an AWS Advanced Consulting Partner running managed AWS services for UK businesses across multiple sectors. The complimentary review on offer is a working conversation about where your AWS work actually sits and what would change if it had a home. No pitch, no obligation.

Book a discovery session