The Line on Your Bill That Nobody Can Explain
Your cloud bill grows every quarter. Your revenue does not grow with it. Someone in the building knows why. They have not told you yet.
This article is not for your CTO.
Send it to them if you like. They will find it interesting. But it is written for the person in your organisation who looks at the cloud bill every month, notices the number going up, asks a question, receives an answer full of technical language, and walks away less certain than before they asked.
That person is usually you.
Here is what the technical language is obscuring. Your cloud bill has two components that are almost never separated in the conversation you are having about it.
The first is infrastructure — the raw compute your applications need to run. CPU, memory, storage, network. This is the foundational cost and it is largely proportional to your workload. More users, more transactions, more data — more infrastructure. This part of the bill is honest. It reflects something real.
The second component is a premium layered on top of that infrastructure. It is charged for the convenience of not managing the infrastructure yourself — for letting the cloud provider operate your databases, your caches, your message queues, your search indexes on your behalf. This premium is not proportional to your workload. It is not proportional to the value it delivers. It is proportional to how deeply embedded you are in the cloud provider’s ecosystem and how difficult leaving would appear to be.
This second component is what nobody has separated out and shown you as a line item. It does not appear that way on the bill. It is folded into service costs that look like infrastructure costs but are not.
What the number actually looks like
A gaming company running production workloads on AWS was paying thirty thousand dollars a month. The bill had grown steadily for three years. Each time it was questioned the answer involved capacity requirements, scaling events, managed service reliability, the cost of the alternative. The alternative, in this conversation, was always framed as risky, complex, and expensive.
The alternative turned out to be six thousand dollars a month.
Ten racks in a data centre. Unlimited bandwidth at one gigabit. Hardware that was already owned and fully depreciated, sitting idle in a room, doing nothing because the path of least resistance three years earlier had been to click the managed service button instead.
The migration did not require new hardware investment. It required engineering time and engineering courage — the willingness to run infrastructure that the team understood and controlled rather than infrastructure that a cloud provider operated behind an abstraction layer. The bill went from thirty thousand to under one thousand for the workloads that moved. The remaining AWS spend covers what genuinely belongs there.
The difference was not technology. The technology was equivalent. The difference was a decision to look at the second component of the bill honestly and ask whether it was delivering value proportional to its cost.
It was not. It rarely is.
Why this conversation has not happened in your organisation
Your CTO is not withholding this information maliciously. In most cases they are not withholding it at all — they genuinely believe the managed services premium is justified, because the people who trained them, the certifications they hold, the conferences they attend, and the vendors they speak to have all delivered a consistent message that managed services are the responsible, reliable, professional choice.
That message was designed by the people who sell managed services. It is not independent analysis.
There is also a political reality that is worth naming directly. The person who owns the current architecture has an interest in that architecture not being questioned too aggressively. Changing it means implicitly admitting that the current approach has been more expensive than necessary. That is a difficult admission for anyone to make about decisions they were responsible for.
This is not unique to technology. It happens in every function in every organisation. The current vendor always has an advocate inside the building.
What is unusual about cloud infrastructure is the scale of the premium and the duration over which it compounds. A modestly inefficient software licence is an annoyance. A managed services architecture running at three to five times the equivalent self-hosted cost, growing with every workload added, compounding over years — that is a structural problem with a number attached to it that gets larger every month you do not look at it directly.
What the arithmetic looks like
The exercise is straightforward and requires no technical knowledge to initiate.
Ask for the cloud bill broken down by service category. Not the total — the breakdown. Compute on one line. Each managed service on its own line. Database services. Caching services. Message queuing. Search. Data transfer between availability zones.
Then ask one question for each managed service line: what open-source software does this service run, and what would it cost to run that software ourselves on compute we are already paying for.
Your engineering team can answer this question. If they cannot, that is itself useful information about whether your organisation has the infrastructure skills it is paying to outsource.
The gap between the managed service cost and the self-hosted equivalent cost is the premium. Multiply it by twelve. That is what the convenience has cost you this year. Multiply by the number of years you have been running the current architecture.
That number has a name. It is the managed services tax. It does not appear as a line item. It has been there every month regardless.
What the decision actually involves
Moving workloads off managed services and onto self-hosted infrastructure running on Kubernetes — either in the cloud on compute you already control, or on hardware you own outright — is an engineering project with a defined scope, a defined timeline, and a defined outcome.
It is not a leap into the unknown. The open-source software that replaces managed services is mature, production-tested, and running at scale in organisations that made this decision before you. The engineering skills required exist in the market. In many cases they exist inside your organisation already, underutilised because the managed service made them seem unnecessary.
The risk is not that it cannot be done. The risk is the transition period — the window between starting the migration and completing it, during which both environments need to be maintained. This is a manageable risk with a managed timeline. It is the kind of risk your engineering team handles routinely.
What it requires from you is not technical judgment. It is the same judgment you apply to any vendor relationship that has become more expensive than the value it delivers — the willingness to ask whether the current arrangement is still the right one, and to expect a clear answer rather than a technical deflection.
The question worth asking in your next budget conversation
Not “is our cloud infrastructure efficient” — that question invites a technical answer you cannot evaluate.
This question: “Show me our managed services spend as a separate line from our raw compute spend, and show me what the equivalent self-hosted cost would be.”
If the answer is immediate and clear, you have an engineering team that understands its own infrastructure costs. If the answer is deflection, complexity, and reasons why the comparison is not straightforward — that response is itself the answer to your question.
The bill grows because nobody has asked the question that way before.
Ask it.
Sugau works with organisations that have decided to ask the question and want a clear answer. The engagement starts with an infrastructure cost audit — what you are spending, what the equivalent self-hosted architecture would cost, and what the migration path looks like. No commitment beyond the conversation. If the numbers are not interesting, we will tell you that too. sugau.com