The Managed Services Tax: What Your Cloud Bill Is Not Telling You
You moved to the cloud to cut costs and move faster. So why does the bill keep climbing?
There is a conversation happening in boardrooms right now that goes something like this. The CTO opens the cloud spend dashboard. Someone clears their throat. A number appears that is larger than last quarter, which was larger than the quarter before. Someone says “we need to optimise.” And then nothing changes, because nobody in the room can explain exactly where the money is going — only that the cloud provider’s margins are, by all accounts, excellent.
Here is what that conversation is missing.
Your cloud bill has two components. The first is compute and storage — the raw infrastructure you actually need: CPU cycles, RAM, disk, network. This is the part you signed up for. The second is something else entirely. It is a premium layered on top of that infrastructure for the privilege of not managing it yourself. A tax, collected quietly, on every database, every cache, every message queue, every search index you chose to let the cloud provider operate for you.
That tax is not small. And it was designed that way.
How the tax works
Take a PostgreSQL database. You can run it yourself on a virtual machine — your virtual machine, already paid for, already sitting in your cloud account. The engineering effort to deploy and operate it properly is real but finite. Or you can use Amazon RDS, which runs PostgreSQL on a virtual machine — a virtual machine very similar to yours — and charges you roughly three to five times the underlying compute cost for the operational wrapper around it.
The same logic applies across the stack. Amazon ElastiCache for Redis. Amazon MSK for Kafka. Amazon OpenSearch. Amazon MQ. Each one is an open-source project you could run yourself, wrapped in a managed interface, and priced at a multiple of what the raw compute would cost you. The open-source software is free. The tax is not.
This is not a criticism of cloud providers for being businesses. It is an observation that the economics were engineered deliberately. Managed services are the highest-margin products in the cloud portfolio. The more of them you consume, the better the quarterly results look — theirs, not yours.
The performance cost nobody talks about
The tax is not only financial. There is an operational cost embedded in managed services that rarely appears in the sales conversation.
Consider storage. Amazon EBS — the default persistent storage layer for most managed services — is a network-attached block device. It is reliable and flexible, and it sits somewhere between your compute and your data, connected by a wire that introduces latency you cannot eliminate. A well-configured NVMe SSD local to your compute node delivers input/output performance that EBS cannot match on its best day. The difference is not marginal. For a busy PostgreSQL instance handling hundreds of transactions per second, it is the difference between an application that feels immediate and one that does not.
The people who built software in the early 2000s remember what fast felt like. Monolithic applications running on physical servers with local disks, everything close to everything else, latency measured in microseconds rather than milliseconds. Then the industry moved to the cloud, distributed everything, put storage on the network, and called the resulting slowness an acceptable trade-off for flexibility. For many workloads it was. For many others it was not, and teams simply adapted their expectations downward without examining the choice.
Running your own database on your own compute with local NVMe storage — in the cloud, on the same instance type you are already paying for — gives you back performance you did not realise you had surrendered.
The high-availability theatre
Here is where the managed services argument usually gets made: automated failover, multi-AZ replication, point-in-time recovery, managed backups. The operational burden, the story goes, justifies the premium.
Examine the story carefully.
Multi-AZ replication means your data is synchronously written to two availability zones simultaneously. This protects against a failure that, in practice, occurs rarely — a full AZ outage. When it does occur, as AWS has demonstrated on several memorable occasions, the failure is often broad enough that the multi-AZ architecture provides limited practical benefit, because the dependent services, the shared control planes, and the applications built on top are affected regardless.
Meanwhile, cross-AZ network traffic is billed per gigabyte, in both directions. A busy database with continuous replication is generating that traffic constantly. The protection is theoretical and intermittent. The cost is real and monthly.
Automated failover, the centrepiece of the managed services reliability promise, is also more narrow than advertised. The database promotes a replica in thirty seconds. Your application connection strings need to follow it. Your caches are cold. Your background jobs were mid-execution. Your message queues are in an undefined state. The database recovered automatically. Your application recovers on whatever timeline your engineers can manage at the time of the failure — which, in practice, is measured in minutes, not seconds.
Failback, universally, is manual. It has always been manual, because automated failback has caused more outages than it prevented. The engineers who designed these systems know this. The marketing materials do not reflect it.
A Live and DR architecture — a primary environment optimised for performance, a recovery environment tested and ready, with honest RTO and RPO numbers documented and drilled — is not a step backwards from managed high-availability. It is a more honest version of the same thing, at a fraction of the cost, with performance characteristics that managed services cannot match.
What freedom actually looks like
Kubernetes was built to run workloads portably. The same manifest that deploys your PostgreSQL cluster — backed by CloudNativePG, with local NVMe storage, Patroni-managed failover, and PgBouncer connection pooling — runs in AWS, in GCP, in Azure, on Hetzner, or on bare metal in your own rack. You are not rewriting anything. You are not migrating. You are choosing where to run, and the choice is yours to make again next quarter if the economics shift.
This is what managed services quietly remove. Not capability — you can replicate every feature. What they remove is optionality. Every RDS instance is a thread in a web that makes leaving incrementally more expensive. Not because the data cannot move — it can — but because the muscle memory, the tooling assumptions, the runbooks, and the institutional knowledge all accumulate around a proprietary interface that exists only in one place.
The tax compounds.
The question worth asking
The cloud providers are not hiding any of this. The pricing is public. The architecture is documented. The trade-offs are knowable by anyone who looks.
The question is whether anyone in your organisation has looked recently — not at the architecture diagram, but at the bill, line by line, and asked what each managed service is actually delivering relative to what it costs, relative to what running it yourself on infrastructure you already own would require.
For most organisations that do this exercise honestly, the answer is surprising. Not because self-hosting is always the right answer. For some workloads, the managed service premium buys genuine value. But for many — the databases, the caches, the queues, the search indexes that form the backbone of the application — the premium is paying for a convenience that your engineering team could replace, with better performance, more portability, and a bill that stops growing on its own.
The cloud sold you compute. The managed services tax is what happens when you stopped there.
Sugau specialises in bare-metal Kubernetes, cloud repatriation, and private AI infrastructure — helping organisations reclaim control of their stack without sacrificing the agility that brought them to the cloud in the first place. If your cloud bill has become a conversation you dread, get in touch.