I’ve been working with cloud infrastructure for about fourteen years. It does some things very well, and some things poorly. So when someone asks me whether moving something to the cloud will save money, I tend to give the stereotypical architect’s answer:
It depends.
But that isn’t a dodge. What it depends on is the interesting part.
A recent conversation started with someone describing an experience with Azure. Around 2018 or 2019, he tried to set up a VPN for four computers that would be used for roughly half the month. It was complicated to configure and ended up costing somewhere around $200. He replaced it with a €4 Hetzner server. Years later, the VPN is still running, supports as many machines as he needs, runs continuously, and costs a fraction of what the cloud solution did.
It would be easy to respond to that story with a defense of cloud pricing or an explanation of all the things the Azure solution might have provided. But sometimes a €4 server really is the right answer.
Cloud has been oversold. Managed services in particular have sometimes been sold on a warped version of reality: install PostgreSQL, RabbitMQ, IIS, or some other service yourself and you will supposedly need an army of engineers constantly nursing it back to health.
That simply isn’t true.
Sometimes PostgreSQL is just PostgreSQL. Sometimes a small server, some sensible backups, and someone who knows what they are doing are entirely adequate.
And sometimes they aren’t.
That is where things get interesting.
The Same Database Can Be Two Very Different Problems
The question I was asked next was essentially: at what size does cloud make sense? How many requests per second?
I don’t think requests per second is the right metric.
Imagine two PostgreSQL servers, each handling 50 requests per second. The first supports an application where a few hours of downtime would be inconvenient but not disastrous. Losing the most recent few hours of data might be unpleasant but survivable, and someone knows how to restore it from backup.
The second supports a business-critical application. It needs high availability, automatic failover, replication across failure domains, point-in-time recovery, security patching, monitoring, alerting, encryption, audited access, tested backups, and somebody who knows what to do when replication quietly stops working at three in the morning.
They are both doing 50 requests per second. They are not remotely the same operational problem.
That distinction matters far more than the request rate. The same thing happens with load balancers, proxies, caching, queues, certificates, operating systems, WAFs, monitoring, and everything else that accumulates around a production system. The software itself may be inexpensive. Responsibility isn’t.
Sometimes You Are Paying to Stop Worrying About It
I know a business owner with very limited technical experience. He needs several Internet-facing services to be reliable, but he doesn’t want to become a systems administrator. He doesn’t want to learn how to configure VPNs, maintain operating systems, or spend his evenings figuring out why a server stopped responding.
For him, AWS Lightsail is almost exactly the right product.
Could I probably run what he needs on cheaper infrastructure? Yes. That isn’t the point.
The cheapest server is not necessarily the cheapest solution.
His time has value. His attention has value. The knowledge he would have to acquire has a cost, as does the risk of something failing when he doesn’t know how to fix it. He is paying more for infrastructure in exchange for carrying less operational responsibility.
That’s a perfectly reasonable trade.
Managed Services Are Valuable When You Need What Is Being Managed
That doesn’t mean every managed service makes sense.
Consider RDS versus running a small MySQL database on Lightsail. RDS can give you automated backups, point-in-time recovery, managed patching, monitoring, replication, failover options, and a considerable amount of operational machinery you don’t have to build yourself.
Those things have value, but only if you need them.
If I have a small application with modest traffic, straightforward backup requirements, tolerable downtime, and a database that fits comfortably on a small server, MySQL on Lightsail may be entirely adequate. RDS could be technically “better,” but it could also simply be more than the business needs.
Managed services are valuable when you need what is being managed. Otherwise, you may simply be paying a premium for capabilities you aren’t using.
The word I keep coming back to here is appropriate. Not biggest. Not most sophisticated. Not most cloud-native. Appropriate.
Sometimes the Best Server Is No Server
There is another version of the same problem that happens even earlier. I’ve seen dynamic web applications used for things that could have been statically served.
Once you’ve decided something is a dynamic application, you’ve inherited a collection of problems. You may need application servers, a runtime, databases, patching, scaling, monitoring, caching, deployment infrastructure, security updates, perhaps containers, and perhaps orchestration for those containers. Eventually someone starts asking how much all of that costs.
But there was an earlier question:
Did this need to be a dynamic application in the first place?
If the content can be generated ahead of time and served as static files, many of those operational problems simply disappear. A static file does not need a database failover strategy. It does not care whether your application runtime has a critical vulnerability. It does not need an autoscaling group.
There is a tendency, especially when infrastructure is easy to provision, to solve the question of how to operate something before asking whether we needed the thing at all.
The cheapest infrastructure is often the infrastructure you discover you don’t need.
Moving to the Cloud Doesn’t Change Your Architecture for You
At the other end of the spectrum, I’ve seen organizations move substantial systems from on-premises infrastructure into the cloud and discover that their costs increased dramatically, sometimes badly.
A common contributor is lift-and-shift: taking an application designed around one infrastructure and economic model and moving it largely unchanged into another. There is a much larger discussion to be had about lift-and-shift, and I won’t wander into all of it here, but sizing alone can hurt.
Hardware sitting in your own data center has a very different cost model from rented compute billed continuously. An oversized machine you bought several years ago may have little incremental cost today. Recreating that oversized machine in the cloud means paying for that unused capacity every hour of every day.
The abstraction changes. The economics change with it.
Cloud doesn’t automatically make an architecture efficient. Sometimes it simply sends you a very precise monthly bill for your inefficiency.
Engineering Time Is Part of the Infrastructure Bill
This is the part that gets lost when people compare a €4 VPS with a $100 or $500 managed service. The cloud bill is visible. Engineering time often isn’t.
Someone has to patch the operating system, verify the backups, know how to restore them, notice when replication breaks, maintain the proxy, renew certificates, configure the firewall, investigate disk space, respond to security vulnerabilities, and understand what happens when the machine disappears.
None of this necessarily requires a large operations team. That claim is part of the oversell.
But none of it is free either.
For a small software company with six developers and no database specialist, spending several engineer-weeks building and maintaining highly available database infrastructure may cost considerably more than paying a managed-service premium. And there is another cost hiding there: those are engineer-weeks not spent building the product.
Sometimes paying Amazon, Microsoft, Google, or somebody else to carry an operational responsibility is cheaper than carrying it yourself.
Sometimes it isn’t.
Scale Changes the Equation Again
As organizations get larger, another transition can occur. Eventually you may already employ database engineers, networking specialists, platform engineers, security engineers, SREs, and operations staff. The knowledge is already inside the organization. The tooling already exists. The fixed costs can be spread across hundreds or thousands of systems.
At that point, the premium charged by a managed service can start looking very different. At sufficient scale, taking responsibility for more of the infrastructure yourself may once again become economically attractive.
But even this isn’t a simple progression from small to self-hosted, medium to cloud, and large back to self-hosted. A large organization might sensibly run its own compute while continuing to use a managed database. A tiny organization might happen to have exceptional operations expertise. Regulatory requirements might dominate the decision. A workload might be extremely bursty. An application might have unusual hardware requirements. The cost of downtime might dwarf the cost of everything else.
Which brings us back to the annoying answer.
It depends.
So, Is Cloud Cheaper?
Wrong question.
Cheaper than what? And what are we counting?
Hardware? Engineering time? Expertise? Downtime? Opportunity cost? Risk? The cost of carrying knowledge inside the organization? The cost of discovering at three in the morning that the person who understood the database left six months ago?
There is no number of requests per second where cloud suddenly starts making economic sense.
Instead, I would ask: What happens when this fails? How quickly does it need to recover? How much data can we afford to lose? Who patches it? Who monitors it? Who understands it? What security guarantees do we need? What capabilities are we paying for that we actually use? What expertise do we have? What expertise do we want to have? And what else could those engineers be doing?
Sometimes the right answer is RDS.
Sometimes it is MySQL on a small Lightsail instance.
Sometimes it is a €4 Hetzner server.
Sometimes it is a static file.
Cloud is not inherently cheap. Self-hosting is not inherently cheap. Managed services are not inherently wasteful. Running your own infrastructure is not inherently more efficient.
The mistake is comparing the price of a server with the price of an operating model.
Architecture matters. The organization matters. The requirements matter. Context matters.
It depends.
No responses yet