The cloud doesn’t come with operators: What AWS and Azure don’t sell you.

Disclosure first: I’m CTO of vmXcloud®, Inc., which sells managed infrastructure. That’s a conflict and you should read this accordingly. I’m writing it anyway, because the mistake I’m describing costs organizations money whether they fix it by hiring, by outsourcing, or not at all.

AWS and Azure sell you resources. They don’t sell you the ability to operate them, and they’ve never claimed to. The confusion is ours, not theirs.

Here’s where it comes from. The console flattens the difficulty curve at exactly the wrong point. Standing up a VPC, a subnet, a security group and an instance takes an afternoon and a credit card. It looks like the hard part is done, because the visible part is done. Everything after that has no console button and no completion state.

What operating actually means, roughly in the order it bites:

– Someone owns the security posture continuously, not at launch. Rules get added during incidents and never removed. IAM grows. Nobody audits it because nobody’s job is to audit it.
– Someone owns cost. Not reviews the bill – owns it. Untagged resources, orphaned volumes, the dev environment nobody turned off.
– Someone tests restores. Backups configured is not backups working. You find out which one you have on the worst day of the year.
– Someone answers at 2am. Not gets paged – answers, diagnoses, and has the authority to change production.
– Someone keeps the architecture honest as requirements move, which is a design job, not a ticket job.

That last one stalls on the org chart more often than on the diagnosis. Plenty of teams can tell you what’s broken at 2am. Fewer have someone awake who can change production without first waking three people for approval.

Each of those is a different skill set. That’s the actual problem, and it’s a staffing problem before it’s a technology one.

None of it fails loudly, which is the part people get wrong. An un-operated environment usually doesn’t fall over – it drifts. Access that should have been revoked stays live. Spend creeps because nothing is tagged and nobody owns the bill. Controls that were accurate at launch stop matching the architecture, and you find out in an audit rather than in an outage. The 2am call is the failure people plan for. The quiet one is the one that costs more, because it compounds for months before anyone names it.

The math is unkind to small teams. Real 24/7 coverage of a single on-call seat needs five to six people once you account for a 40-hour week, holidays, vacation and turnover. That’s one seat. Now staff the security posture, the network, the storage, the virtualization layer, and someone who can read a SOC 2 report and tell you what it doesn’t cover. A 200-person company with three people in IT is not getting there, and shouldn’t try.

So teams do the reasonable thing and reach for automation. Infrastructure as code, policy as code, automated remediation. All good, all worth having, none of it closes this gap.

Automation executes decisions. It doesn’t make them. A policy engine will enforce the rule you wrote – it won’t tell you the rule is wrong, or that it stopped matching your architecture six months ago. The bad failures I’ve seen happened with tooling in place. The tooling was fine. The judgment behind it had stopped being maintained, because maintaining judgment is somebody’s job and nobody had it.

This gets worse in regulated environments, which is where I spend most of my time. The shared responsibility model is honest – the platforms document it clearly and repeatedly. It still gets misread constantly, because the certification list is long and impressive and the reader wants it to mean more than it does. Your provider being FedRAMP authorized doesn’t make your system authorized. Their SOC 2 covers their controls, not yours. You inherit the physical and environmental layer. You don’t inherit your own configuration, access management or documentation, and those are the ones assessors actually find problems in.

None of this is an argument for managed infrastructure. It’s an argument for knowing which thing you’re buying.

If you have the people, run it yourself. You’ll do it better than anyone else can, because you know your workloads. If you don’t have the people, the honest options are to hire them, to buy the capability from someone whose business is having it, or to accept the risk explicitly and write it down somewhere a director will read.

All three are defensible. The one that isn’t is the fourth option, which is the one most organizations actually take: assume the platform’s competence transfers to you, and find out on a Saturday that it didn’t.