Wenn ein mittelständisches Unternehmen „in die Cloud" will, fällt erstaunlich oft im selben Satz das Wort „AWS". Manchmal „Azure", manchmal „Google". Selten fällt die Frage, die davor gehört: Was genau brauchen wir eigentlich?
Das ist der Auftakt einer kleinen Serie. Es geht um einen Stack, mit dem ein Mittelständler ohne eigenes Plattformteam moderne Software betreiben kann — mit voller Kostenkontrolle, klarer Datensouveränität und überschaubarer Komplexität. Teil 1: die Infrastruktur darunter. Teil 2 wird Terraform für kleine Teams, Teil 3 die Frage, wie man Serverless-Funktionen im eigenen Haus betreibt — in Dokploy auf der eigenen Infrastruktur statt bei einem US-Edge-Anbieter.
Anfangen will ich mit dem teuersten Reflex, den ich kenne.
„Cloud" ist nicht gleich „Hyperscaler"
In fast jedem Projekt erlebe ich dasselbe: „Cloud" wird mit AWS oder Google gleichgesetzt. Nicht, weil jemand die Anforderungen durchgerechnet hätte — sondern weil das die Namen sind, die man kennt.
Was die Rechnung dann nach oben treibt, sind selten die Server. Es sind die Dinge drumherum: Ausfallsicherheit über Redundanzen, die man vielleicht gar nicht braucht. Test- und Staging-Systeme, die nochmal kosten. Log-Zugriff, der extra berechnet wird. Managed-Datenbanken, deren Komfort man teuer bezahlt. Jede einzelne Position ist begründbar. In Summe zahlt der Mittelständler einen Enterprise-Preis für ein Mittelstands-Problem.
Wo Hetzner & Co. wirklich reichen
Bei den allermeisten Mittelständlern. Die typischen Workloads sind keine Raketenwissenschaft — Webseiten, CMS, PIM, E-Commerce-Shops, Backends für Apps. Das sind gut verstandene, planbare Lasten. Dafür reicht ein solider Anbieter wie Hetzner — und „reicht" ist hier nicht „billiger Kompromiss", sondern die richtige Wahl: deutscher Standort, EU-Datenhaltung, transparente Preise.
Ich habe das in vier Projekten gemacht. Was gut lief: die Integration in Terraform (dazu mehr in Teil 2), ein Support, der antwortet, und vor allem Kostentransparenz — man weiß am Monatsanfang, was am Monatsende auf der Rechnung steht.
Was Schmerz macht, will ich nicht verschweigen: Nicht jeder Komfortdienst eines Hyperscalers ist da. Eine private Container-Registry zum Beispiel betreibt man selbst. Das erhöht den initialen Aufwand — und senkt zugleich die laufenden Kosten, weil man fast alles selbst hosten kann, statt es pro Gigabyte zu mieten. Diesen Tausch muss man bewusst eingehen. Für ein Team ohne Plattform-Abteilung ist er oft trotzdem der bessere Deal.
Die Rechnung
Eine Größenordnung — kein konkreter Kundenfall, Listenpreise, gerundet. Preise ändern sich; entscheidend ist die Struktur, nicht die Nachkommastelle.
Ein typischer Mittelstands-Webstack: drei Anwendungs-Server, eine Datenbank mit Ausfallsicherheit, ein Load Balancer, etwas Block-Storage, rund 3 TB Traffic im Monat.
- Selbstbetrieben (Hetzner-Klasse): dedizierte vCPU-Server, selbst betriebene Datenbank, Load Balancer, Volume — grob 120 bis 150 Euro im Monat. Traffic: in den meist enthaltenen 20 TB komplett abgedeckt, also 0 Euro.
- Hyperscaler (Listenpreis, on demand): vergleichbare Instanzen, eine Managed-Datenbank mit Multi-AZ, Load Balancer — plus Egress. Allein die 3 TB Datenverkehr nach außen kosten rund 270 US-Dollar im Monat. In Summe landet man grob bei 750 bis 850 US-Dollar.
Das ist Faktor fünf bis sechs. Mit Reserved Instances oder Savings Plans drückt man den Hyperscaler-Preis spürbar — realistisch bleibt Faktor drei bis vier. Und der größte strukturelle Treiber ist nicht die CPU, es ist der Egress: Datenverkehr nach außen ist beim Hyperscaler einer der teuersten Posten überhaupt, bei Hetzner sind zweistellige Terabyte-Mengen schlicht inklusive. Diese eine Zeile überlebt jede Preisrunde.
Was der höhere Preis kauft, ist real und gehört dazu — dazu gleich.
Wann es ein Hyperscaler sein muss
Gegen den „Hetzner reicht immer"-Reflex: Es gibt klare Fälle, in denen ein Hyperscaler die richtige Wahl ist.
- Echte Multi-Region-Anforderungen. Daten müssen in mehreren Regionen liegen, Last entsteht weltweit — und zwar nicht nur als CDN-Last vorne, sondern im Hintergrund: Services, APIs, Admin-Oberflächen, die regional skalieren müssen.
- Wirklich nahe 100 Prozent Verfügbarkeit. Wenn ein SLA das Geschäft trägt, kann ein Hyperscaler ganz anders skalieren und Ressourcen bereitstellen, als man es selbst je bauen würde.
- Managed Services mit echtem Stabilitätsgewinn. Managed Kubernetes, Kafka und Co.: Ein gemanagter Dienst ist stabiler, als sich selbst mit Netzwerk, Updates und Nachtschichten herumzuschlagen. Diesen Vorteil zahlt man — und manchmal ist er das Geld wert.
Das ist kein Widerspruch zum Rest. Es ist die Bedingung dafür, dass die Empfehlung trägt.
Vier Fragen vor der Entscheidung
Bevor irgendein Anbietername fällt, beantworte ich mit dem Kunden diese vier Fragen. Sie entscheiden mehr als jedes Preisblatt:
- Wer nutzt die Systeme — und wo? Interne Nutzer an einem Standort sind etwas anderes als Endkunden über drei Kontinente.
- Welche Zertifizierungen verlangt die Systemlandschaft? Compliance-Anforderungen können einen Anbieter erzwingen — oder eben nicht.
- Wo dürfen die Daten liegen? Souveränität und Datenstandort sind im Mittelstand oft Pflicht, nicht Kür.
- Wer leistet Betrieb und Support? Das ist die eigentliche Managed-Services-Frage: Habe ich das Team, das selbst betreibt — oder kaufe ich mir das ein?
Wer diese vier Fragen sauber beantwortet, hat die Anbieterwahl meist schon getroffen — und merkt oft, dass „die Cloud" gar kein Hyperscaler sein musste.
Fazit
Hetzner statt Hyperscaler ist keine Sparmaßnahme aus Geiz. Es ist die passende Antwort, wenn die Anforderungen es hergeben — und das tun sie im Mittelstand häufiger, als der Reflex glauben macht. Der Hyperscaler ist nicht der Default. Er ist eine begründete Entscheidung, genau wie sein Gegenteil.
In Teil 2 geht es darum, wie man so eine Infrastruktur in den Griff bekommt, ohne ein Plattformteam zu haben: Terraform für kleine Teams — was sich lohnt, was Overhead ist.
Wenn Sie vor genau dieser Entscheidung stehen und eine Einschätzung statt einer Anbieter-Verkaufsfolie wollen: Das ist Teil meiner Arbeit im Technical Consulting.