The usual way this conversation starts: someone looks at their monthly managed service invoice and asks whether they could just handle the infrastructure themselves for less money. It's a reasonable question. The AWS console shows the resource costs clearly. The managed service fee is a separate line item. On the surface it looks like an obvious comparison.

It isn't, though. The direct infrastructure cost is the visible part of a larger number. The question is whether the comparison is being made against the right total.

The cost that sits in your engineering payroll

The clearest omission in the self-managed-vs-managed calculation is engineering time. Managing cloud infrastructure isn't a task that someone does during spare moments. At any meaningful scale it involves: monitoring configuration and maintenance, security patch scheduling and testing, incident response, backup verification, capacity planning, provider-specific tooling knowledge, and on-call availability.

A rough estimation exercise: if a mid-level engineer earns £65,000 per year fully loaded (salary, NI, pension), that's roughly £31 per hour. If infrastructure management consumes five hours per week of their time — not an unusual number for an environment running a real production application — that's £155 per week. Over a year, that's around £8,000 in fully-loaded engineering cost, before accounting for on-call or incidents.

Five hours per week is a conservative estimate for an environment that's running reasonably well. An environment that's having active problems — the kind that prompted the original question — is consuming significantly more.

On-call isn't free

Infrastructure problems don't schedule themselves for business hours. At some point, someone is on call for production. That person either has a formal on-call arrangement (in which case there's usually a stipend and some degree of disruption cost) or an informal one where they're expected to respond to problems as they arise.

The informal version is worse, not better. A developer who doesn't have a formal on-call rota but knows they're expected to fix things that break in the evening is in a permanently alert state outside working hours. The cost of this shows up in burnout, attrition, and the slow degradation of focus during working hours — none of which appear in a monthly cloud bill comparison.

The infrastructure costs are visible. The human costs are real but distributed across HR metrics, sprint velocity, and the ambient anxiety of the person who knows what happens if the database server falls over at 11pm.

The knowledge concentration problem

In small teams that manage their own infrastructure, cloud knowledge tends to concentrate in one or two people. This is a specific, underweighted risk.

When that person leaves — or is sick, or goes on holiday, or moves to a different project — the operational knowledge leaves with them. Documentation helps but rarely captures everything relevant. The team discovers what the departing engineer knew when something goes wrong and nobody can fix it quickly.

Managed infrastructure providers have teams with shared knowledge and documented runbooks. When an engineer leaves, the replacement can be briefed from documentation. The institutional knowledge doesn't have a single point of failure.

What genuinely belongs in the comparison

A more complete comparison between self-managed and managed cloud infrastructure should include:

  • Direct cloud resource costs (visible in billing)
  • Engineering time at loaded cost, including context-switching overhead
  • On-call coverage cost, formal or informal
  • Tooling for monitoring, logging, and alerting
  • Training and certification to keep knowledge current as cloud services evolve
  • Incident response time — actual hours at actual cost when things break
  • The risk premium for key-person dependency on cloud knowledge

Against that total, the managed service invoice looks different than it does against the AWS bill alone.

When self-managing actually makes sense

This isn't an argument that managed services are always the right choice. There are situations where self-management is genuinely the better option.

If you have a dedicated infrastructure or platform team — not developers doing it on the side, but people whose job is specifically infrastructure — and your environment is stable and well-understood, the economics work differently. You're already paying for the expertise. The question becomes whether there's marginal value in external management.

Similarly, if your workload has unusual requirements — specific compliance constraints, proprietary hardware dependencies, or integration with internal systems that an external provider couldn't access — the managed model may not be practical regardless of cost.

But for companies where cloud infrastructure is managed by developers as a secondary responsibility, the true cost of self-management is usually higher than it appears. The question is whether it's being measured against the right number.