When a mid-sized company wants to "move to the cloud", the word "AWS" falls remarkably often in the same sentence. Sometimes "Azure", sometimes "Google". Rarely does the question that belongs before it get asked: what exactly do we actually need?
This is the opener of a small series. It is about a stack a mid-sized company can run without its own platform team — with full cost control, clear data sovereignty and manageable complexity. Part 1: the infrastructure underneath. Part 2 will be Terraform for small teams, part 3 the question of how to run serverless functions in house — in Dokploy on your own infrastructure instead of with a US edge provider.
I want to start with the most expensive reflex I know.
"Cloud" is not the same as "hyperscaler"
In almost every project I see the same thing: "cloud" is equated with AWS or Google. Not because anyone has worked through the requirements — but because those are the names people know.
What then drives the bill up is rarely the servers. It is the things around them: failover through redundancy you may not even need. Test and staging systems that cost again. Log access billed separately. Managed databases whose comfort you pay dearly for. Every single line item is justifiable. In sum, the mid-sized company pays an enterprise price for a mid-market problem.
Where Hetzner and the like genuinely suffice
For the vast majority of mid-sized companies. The typical workloads are not rocket science — websites, CMS, PIM, e-commerce shops, backends for apps. These are well-understood, predictable loads. A solid provider like Hetzner is enough for that — and "enough" here is not "cheap compromise" but the right choice: a German location, EU data residency, transparent pricing.
I have done this in four projects. What went well: the integration into Terraform (more on that in part 2), support that answers, and above all cost transparency — at the start of the month you know what will be on the bill at the end of it.
What hurts I do not want to gloss over: not every convenience service of a hyperscaler is there. A private container registry, for example, you run yourself. That raises the initial effort — and at the same time lowers the running costs, because you can host almost everything yourself instead of renting it per gigabyte. You have to enter that trade deliberately. For a team without a platform department it is still often the better deal.
The math
An order of magnitude — no concrete client case, list prices, rounded. Prices change; what matters is the structure, not the decimal place.
A typical mid-market web stack: three application servers, a database with failover, a load balancer, some block storage, around 3 TB of traffic per month.
- Self-operated (Hetzner class): dedicated vCPU servers, a self-run database, a load balancer, a volume — roughly 120 to 150 euros per month. Traffic: fully covered within the usually included 20 TB, so 0 euros.
- Hyperscaler (list price, on demand): comparable instances, a managed database with Multi-AZ, a load balancer — plus egress. The 3 TB of outbound traffic alone cost around 270 US dollars per month. In total you land roughly at 750 to 850 US dollars.
That is a factor of five to six. With reserved instances or savings plans you push the hyperscaler price down noticeably — realistically a factor of three to four remains. And the biggest structural driver is not the CPU, it is egress: outbound traffic is one of the most expensive items at a hyperscaler, while at Hetzner double-digit terabyte volumes are simply included. That one line survives every pricing round.
What the higher price buys is real and belongs in the picture — more on that next.
When it has to be a hyperscaler
Against the "Hetzner is always enough" reflex: there are clear cases where a hyperscaler is the right choice.
- Genuine multi-region requirements. Data must sit in several regions, load arises worldwide — and not only as CDN load at the front, but in the background: services, APIs, admin interfaces that have to scale regionally.
- Truly near-100 percent availability. When an SLA carries the business, a hyperscaler can scale and provision resources in a way you would never build yourself.
- Managed services with a real stability gain. Managed Kubernetes, Kafka and the like: a managed service is more stable than wrestling with networking, updates and night shifts yourself. You pay for that advantage — and sometimes it is worth the money.
This is not a contradiction to the rest. It is the condition for the recommendation to hold up.
Four questions before the decision
Before any provider name comes up, I work through these four questions with the client. They decide more than any price sheet:
- Who uses the systems — and where? Internal users at one site are something other than end customers across three continents.
- Which certifications does the system landscape require? Compliance constraints can force a provider — or not.
- Where may the data reside? Sovereignty and data location are often mandatory in the Mittelstand, not optional.
- Who provides operations and support? That is the real managed-services question: do I have the team that operates it itself — or do I buy that in?
Anyone who works through these four questions has usually already made the provider choice — and often notices that "the cloud" did not have to be a hyperscaler at all.
Conclusion
Hetzner instead of a hyperscaler is not a stinginess-driven cost cut. It is the fitting answer when the requirements allow it — and in the Mittelstand they do more often than the reflex suggests. The hyperscaler is not the default. It is a justified decision, just like its opposite.
Part 2 is about how to get such an infrastructure under control without having a platform team: Terraform for small teams — what pays off, what is overhead.
If you are facing exactly this decision and want an assessment instead of a vendor sales slide: that is part of my work in Technical Consulting.