Es macht heute kaum noch Sinn, sich privat ein AWS EC2 zu holen, wenn man nur ein paar Instanzen in einem einzigen VPC betreiben will. Wer mit monolithischen Gebilden zu den US-Hyperscalern geht, zahlt oft ordentlich drauf.

Das Problem mit dem Hype

Viele Firmen denken, sie sparen massiv Geld, weil sie die Hardware und die Hypervisor Orchestrierung nicht mehr selbst bezahlen müssen. Das stimmt zwar theoretisch, aber wer nur einem Trend hinterherrennt, ohne seine Software zu prüfen, erlebt eine böse Überraschung. Die krasse Skalierungstechnologie der US-Anbieter bringt dir nämlich gar nichts, wenn deine eigene Lösung nur vertikal wachsen kann.

Das Beispiel SAP

Wer versucht, SAP ERP oder die SAP Business Suite eins zu eins in die Cloud zu migrieren, merkt schnell, dass AWS einfach zu teuer ist. In Europa ist die Performance für vergleichbare Preise oft viel besser. Klar spart man sich die Admins für die eigene Hardware und muss keine Oracle DB oder SAP DB mehr mühsam selbst einrichten. Aber die Kosten auf der anderen Seite wachsen ins Immense. Der Grund ist simpel: Man kann diese Software nicht einfach auf Micro Services verteilen oder OnDemand Dienste nutzen. Das Ergebnis sind riesige Rechnungen für EC2, RDS, EBS sowie S3 Speicher. Da hilft auch kein EKS, das macht die Sache nur komplizierter.

Das gleiche Problem hat man bei anderen populären Lösungen:

• Microsoft SharePoint (On-Premises): Die alten Versionen sind so tief mit dem lokalen System verzahnt, dass sie in der Cloud Unmengen an Speicher und SQL-Power fressen.
• Oracle E-Business Suite: Hier zahlt man nicht nur für die Rechenleistung, sondern wird bei den Datenbank-Lizenzen auf AWS richtig zur Kasse gebeten.
• Microsoft Dynamics AX oder NAV: Diese individuell angepassten Alt-Systeme lassen sich kaum sinnvoll skalieren und treiben die Windows-Lizenzkosten in die Höhe.
• HCL Domino (Lotus Notes): Diese Architektur ist meilenweit von Cloud-Native entfernt und schaufelt im Hintergrund so ineffizient Daten, dass die S3- und EBS-Rechnungen explodieren.
• Selbstgebaute .NET oder Java-Monolithen: Das sind oft die „Herzstücke“ einer Firma – über 10 bis 20 Jahre gewachsene Software, bei der keiner mehr so richtig weiss, wie alles zusammenhängt. Diese Programme erwarten oft eine ganz bestimmte Hardware-Umgebung oder lokale Dateipfade.

Weitere Beispiele monolithischer Software:

• SAP ERP 6.0 / SAP Business Suite
• Oracle E-Business Suite (EBS)
• Microsoft SharePoint (On-Premises)
• Microsoft Dynamics AX / NAV (Legacy)
• Sage 100 / Sage X3
• IBM DB2 (auf Mainframe-Basis)
• HCL Domino (ehemals Lotus Notes)
• Infor CloudSuite (ehemals Baan)
• Abacus Business Software
• Oracle NetSuite (trotz Cloud-Nativität oft monolithisch strukturiert)
• JD Edwards EnterpriseOne
• Finastra Essence (Core Banking)
• UNIT4 ERP (ehemals Agresso)
• DATEV (On-Premises Lösungen)
• Autodesk Vault (für PDM-Daten)

Preisvergleich: AWS vs. Hetzner

Ich habe dazu mal einen direkten Vergleich zwischen den Preisen bei AWS für EC2 und Hetzner gemacht. Dabei habe ich festgestellt, dass Hetzner definitiv günstiger ist als AWS, wenn man eine vergleichbare Performance möchte.

Will man bei AWS ähnliche Preise wie bei Hetzner erzielen, muss man erhebliche Performance Einbussen in Kauf nehmen. Man bekommt dann einfach weniger CPU, weniger RAM und meistens gar keinen inklusiven Speicher.

Keine Frage: Zu dem Preis ist das „Hetzner-EC2“ unschlagbar

Die allgemeine Überlegung zur Lösung

Bevor man also blind migriert, sollte man unbedingt eine Vorstudie machen. Man muss klären, wohin die Reise gehen soll und welches Modell am Ende ökonomisch am meisten Sinn für das eigene Unternehmen ergibt, wenn man die eingesetzten Lösungen und Dienste betrachtet.

Man kann diese Software eben nicht einfach auf Micro Services verteilen oder OnDemand Dienste nutzen. Das Ergebnis sind riesige Rechnungen für EC2, RDS, EBS sowie S3 Speicher. Da hilft auch kein EKS, das macht die Sache nur komplizierter. Bevor man also blind migriert, sollte man unbedingt eine Vorstudie machen. Man muss klären, wohin die Reise gehen soll und welches Modell am Ende ökonomisch am meisten Sinn für das eigene Unternehmen ergibt, wenn man die eingesetzten Lösungen und Dienste betrachtet.

________ANHANG___________________________________

Wem es interessiert, hier noch ein direkter Vergleich

1. Das „Alles oder Nichts“ Skalierungs-Problem

Bei einem Monolithen kannst du nicht nur den Teil skalieren, der gerade brennt (z. B. die Belegverarbeitung). Wenn das System mehr Power braucht, musst du die gesamte Instanz vergrössern.

• Der Fakt: In der Cloud zahlst du für „T-Shirt-Grössen“ (M, L, XL). Brauchst du nur 10 % mehr RAM, musst du oft auf die nächste Instanzgrösse springen, was die Kosten sofort verdoppelt.
• Zahlenbeispiel: Eine High-Memory-Instanz bei AWS für SAP HANA (z. B. r6i.8xlarge mit 256 GB RAM) kostet etwa 2.000 bis 3.000 USD im Monat (On-Demand). Wenn du merkst, dass 256 GB nicht reichen, landest du bei der 12xlarge oder 16xlarge und bist sofort bei 4.000 bis 6.000 USD. Bei einem Anbieter wie Hetzner kriegst du dedizierte Server mit massiv RAM für einen Bruchteil davon, ohne diese starren Sprünge.

2. Die „IOPS“ Steuer (Speicher-Performance)

SAP und Oracle Datenbanken sind extrem hungrig nach Schreib- und Lesegeschwindigkeit (IOPS). In der Cloud ist Speicherplatz günstig, aber Geschwindigkeit kostet extra.

• Die Falle: Standard-Cloud-Speicher (wie AWS EBS gp3) reicht für grosse Datenbanken oft nicht aus. Du musst „Provisioned IOPS“ (io2) dazu kaufen.
• Zahlen: Während du bei einem dedizierten Server bei Hetzner die volle NVMe-Power der eingebauten SSDs inklusive hast (oft über 1 Million IOPS), zahlst du bei AWS für garantierte 50.000 IOPS auf einem 1 TB Volume locker über 2.000 USD zusätzlich pro Monat nur für die Geschwindigkeit des Speichers!

3. Lizenzierung in der Cloud (Der „Core-Faktor“)

Oracle und SAP haben sehr eigene Regeln, wie ihre Software lizenziert wird, wenn sie auf fremder Hardware läuft.

• Das Problem: Oracle rechnet in der Cloud oft mit einem „Core Factor“. Auf AWS zählt eine vCPU (ein Thread) oft als ein voller Kern für die Lizenzierung, obwohl du in deinem eigenen Rechenzentrum oder auf einem dedizierten Server für die gleiche Lizenz doppelt so viel echte CPU-Power nutzen dürftest.
• Die Folge: Du zahlst für die gleiche Software-Performance in der Cloud effektiv die doppelten Lizenzgebühren, weil die Cloud-Hardware „virtuell“ ist und Oracle die Regeln dort zu seinen Gunsten auslegt.

4. Die versteckten „Exit“ Kosten (Egress Fees)

Monolithen wie SAP ERP sind Kommunikationsmonster. Sie reden ständig mit anderen Systemen, schaufeln Backups raus und tauschen Daten mit dem Lager oder dem Shop aus.

• Der Fakt: Während Hetzner oder andere lokale Anbieter oft 20 TB oder sogar unbegrenzten Traffic inklusive haben, lässt sich AWS je nach Modell jedes Gigabyte, das das Rechenzentrum verlässt, bezahlen.
• Zahlen: Wenn dein SAP-System monatlich 10 TB Daten bewegt (Schnittstellen, Backups, Exporte), kommen am Ende des Monats allein dafür ca. 500 bis 800 USD oben drauf, die du vorher gar nicht auf dem Schirm hattest.