Warum ich neben AWS immer noch OVH und Contabo empfehle

Ein neues Kundenprojekt startet, und noch bevor irgendeine tatsächliche Infrastrukturentscheidung getroffen wird, ist AWS bereits völlig gesetzt. Manchmal liegt das daran, dass ein vorheriger Entwickler es so aufgesetzt hat. Manchmal liegt es schlichtweg daran, dass es der einzige Name ist, den jeder im Raum kennt.

Dann schaue ich mir an, was dort eigentlich läuft: eine Node-App, eine Postgres-Datenbank, Redis für Sessions und ein Nginx davor. Da ist absolut nichts, was Auto-Scaling-Groups benötigt. Da ist nichts, was wirklich zwingend zwölf Regionen braucht. Da ist nichts, das tatsächlich mehr als eine Handvoll von AWS' hunderten Managed Services nutzt. Und die monatliche Rechnung für diese Handvoll Services ist ein Vielfaches von dem, was exakt dieselben Rechenressourcen als reine VPS-Instanzen kosten würden.

Worin AWS tatsächlich extrem gut ist

Das hier ist absolut kein "AWS ist schlecht"-Rant. Ist es nicht. Wenn Sie wirklich von null auf einen plötzlichen, massiven Traffic-Spike hochskalieren und automatisch wieder runterskalieren müssen, ist es unübertroffen. Wenn Sie tief in Managed Services wie RDS Aurora, Lambda oder SQS stecken und die enge Integration dazwischen Ihnen echte Schwerstarbeit abnimmt, ist es fantastisch. Oder wenn die Compliance-Anforderungen eines Kunden spezifisch nach AWS verlangen, ist es absolut das richtige Werkzeug und den Premium-Aufschlag völlig wert.

Auto Scaling Groups, Multi-AZ RDS Failover und die schiere Bandbreite an Managed Services lösen sehr reale Probleme, die ansonsten komplett von Hand gebaut, gepatcht und aktiv gewartet werden müssten.

Der brutale Haken an der Sache ist jedoch, dass diese Features einen hohen Preis haben – völlig unabhängig davon, ob Sie sie aktiv nutzen oder nicht. Das Preismodell von AWS ist stark auf eine extrem granulare, metrische Abrechnung (Metered Billing) über dutzende verschiedene Dimensionen hinweg ausgelegt. Eine kleine EC2-Instanz mit EBS-Speicher, einem Datenübertragungs-Kontingent und einer kleinen RDS-Instanz summiert sich auf spürbar mehr, als die äquivalenten reinen Spezifikationen bei einem traditionellen VPS-Anbieter kosten würden. Oftmals um den Faktor zwei bis vier höher.

Was ein reiner VPS Ihnen liefert

Anbieter wie OVH, Contabo, Hetzner und Konsorten verkaufen Ihnen eine strikt festgelegte Menge an CPU, RAM und Festplattenspeicher für einen monatlichen Pauschalpreis (Flatrate). Punkt.

Es gibt null Überraschungen beim Daten-Traffic. Es gibt keine stundenbasierte Abrechnung für ein Dutzend verschiedene, mikroskopische Ressourcentypen. Es gibt absolut keine Rechnung, für deren volles Verständnis man eine Excel-Tabelle und eine AWS-Zertifizierung benötigt. Für einen Workload, der lediglich aus einer Handvoll Diensten besteht, die relativ gleichmäßig vor sich hin laufen, ist dieser Pauschalpreis sowohl drastisch günstiger als auch – was für ein kleines Unternehmen oft viel wichtiger ist – völlig vorhersehbar.

"Der Server kostet 40 € im Monat" ist ein konkreter Satz, um den ein Kunde sein Budget tatsächlich planen kann. "Es hängt vom Traffic, den Storage-IOPS, den API-Requests und davon ab, welche AZ der Traffic kreuzt" ist das absolut nicht.

Der explizite Trade-Off dabei ist, dass Sie aktiv mehr selbst verwalten müssen. Es gibt keine Managed-Database mit automatischem, nahtlosem Failover. Es gibt null Auto-Scaling. Es gibt keinen Managed Loadbalancer. Sie müssen diese Dinge manuell aufsetzen, wenn Sie sie tatsächlich brauchen.

Für einen gigantischen Prozentsatz der Projekte, an denen ich arbeite, ist dieser Trade-Off völlig in Ordnung. Der Workload benötigt schlichtweg kein automatisches Failover, weil er nicht in einer Größenordnung operiert, bei der das Risiko einer kurzen Downtime die massive zusätzliche Komplexität und die Kosten rechtfertigen würde. Und allein die eingesparte Zeit, weil man nicht ständig AWS-spezifische Tools konfigurieren muss, gleicht das initiale manuelle Server-Setup mehr als aus.

Wie ich mich tatsächlich entscheide

Die Frage ist so gut wie nie "AWS oder nicht AWS" im Sinne einer absoluten Philosophie. Die eigentliche Frage lautet: Benötigt dieser spezifische Workload wirklich zwingend etwas, das AWS bietet und ein normaler VPS schlichtweg nicht hat – und ist dieses spezifische Etwas seinen hohen Preis auch komplett wert?

Wenn die Antwort auf ein vages, hypothetisches "Wir könnten vielleicht mal schnell skalieren müssen" hinausläuft – anstatt auf ein strikt dokumentiertes Traffic-Muster –, dann deckt ein VPS, den man offline in fünf Minuten problemlos vergrößern (resizen) kann, dieses Risiko massiv ab, ohne dauerhaft die AWS-Premiumkosten zu zahlen.

Wenn die Antwort lautet: "Wir stecken bereits so tief in RDS und Lambda, dass es deutlich mehr an Engineering-Zeit kosten würde, das Setup zu verlassen, als es kostet, zu bleiben", dann ist das ein absolut valider Grund aus der echten Welt, dort zu bleiben.

Bei brandneuen Projekten, die diese Gravitationskraft noch nicht haben, greife ich strikt standardmäßig zu einem VPS. Ich überdenke diese Entscheidung nur dann, wenn und sobald die tatsächliche Form des Workloads – und nicht seine hypothetische Form in fünf Jahren – lautstark nach etwas verlangt, das AWS nachweislich besser kann. Zahlreiche hochprofitable, unglaublich zuverlässige Services laufen komplett auf ein paar gut konfigurierten VPS-Instanzen, und der Kunde muss absolut nie irgendjemandem eine furchteinflößende Überraschungsrechnung erklären.