Cloud oder On-Prem-Hardware?

Die Illusion der Geschwindigkeit: Warum ein schneller Cloud-Start ein Unternehmen bremsen kann

In der IT-Branche hat sich eine weit verbreitete Annahme etabliert: Cloud bedeutet Geschwindigkeit. Aus Sicht der Time-to-Market mag das oft stimmen. Ein Kubernetes-Cluster über Managed Services (EKS, GKE und ähnliche Plattformen) bereitzustellen, dauert zwischen 5 und 15 Minuten, während die Beschaffung physischer Hardware, Logistik und Inbetriebnahme Wochen oder Monate beanspruchen kann.
Doch es gibt einen grundlegenden Unterschied zwischen Bereitstellungsgeschwindigkeit und Datenverarbeitungsgeschwindigkeit (Execution Speed und Latenz).

Ein typisches Szenario der „Skalierungsfalle“ sieht folgendermaßen aus: Ein Unternehmen startet seinen Service in der Cloud. Im MVP-Stadium sind die Workloads gering, die Kosten überschaubar und die Flexibilität maximal. Mit zunehmendem Datenvolumen und steigenden Transaktionen treten jedoch verborgene Probleme auf:

• Finanzielles Delta: Die Ressourcenkosten steigen nicht-linear. Komplexe Architekturen erzeugen Kosten für ausgehenden Datenverkehr (Egress Fees) und I/O-Operationen (IOPS), die zu Beginn nur schwer prognostizierbar sind.

• Technische Variabilität: Ingenieure begegnen dem sogenannten „Noisy-Neighbor“-Effekt. Trotz logischer Isolation teilen virtuelle Maschinen L3-CPU-Cache und Speicherkanäle. Dadurch kann eine Datenbankabfrage, die normalerweise lediglich 2 ms benötigt, zeitweise um 20–100 % langsamer werden und 4 bis 5 ms erreichen. Für stark ausgelastete Systeme wird dieses Jitter zu einem kritischen Engpass.

Experten-Insight: „Wenn die Cloud einen schnellen Start ermöglicht, warum zahlen wir dann für vCPUs, die physischen Kernen unterlegen sind, und verlieren dabei gleichzeitig die Vorhersagbarkeit der Reaktionszeiten unter konstanten Lasten?“

On-Prem-Server bieten direkten Zugriff auf die Hardware und erlauben den Einsatz von Kernel-Bypass-Technologien zur Minimierung der Latenz. Die Cloud hingegen verkauft Abstraktion, wobei Ausfallrisiken und Abschreibungen in den Preis einkalkuliert werden.

Vergleichstabelle

Launch und Skalierung – die Vorteile der Cloud

Für Projekte mit hoher Unsicherheit, saisonalen Schwankungen oder variabler Nachfrage bleibt die Cloud weiterhin das rationalste Modell, da sie kritische Flexibilität bietet.

In wettbewerbsintensiven Märkten hat die Geschwindigkeit bei der Validierung von Hypothesen oberste Priorität. Zugriff auf PaaS-Lösungen wie Managed Kubernetes oder DBaaS ermöglicht es Teams, direkt am Code zu arbeiten, ohne die langwierige physische Planung eines Rechenzentrums. Fehler in der Architektur sind in der Cloud zudem kostengünstig: Ressourcen können sofort gelöscht werden, während ein für den falschen Zweck gekaufter Server zu einem illiquiden Asset wird.

Dieser entscheidende technische Vorteil von IaaS wird durch Elastizität ergänzt, die On-Prem nur schwer nachzubilden ist. Ein Szenario: Eine Marketingkampagne erhöht die Service-Last für 48 Stunden um das Zehnfache. Automatisch konfigurierte Auto-Scaling-Gruppen fügen Instanzen hinzu, wenn die CPU-Auslastung steigt, und entfernen sie wieder bei sinkender Last. Die Reaktionszeit liegt zwischen 30 Sekunden und zwei Minuten. Ökonomisch gesehen wird nur für tatsächlich verbrauchte Ressourcen während des Peaks gezahlt. 

Auf On-Prem-Hardware würde teure Peak-Kapazität hingegen rund 95 % der Zeit ungenutzt bleiben.

Dieser Vorteil schwindet jedoch, sobald die Workloads konstant sind. Eine TCO-Analyse zeigt, dass bei 24/7-Betrieb die Mietkosten für eine VM bereits nach 8–12 Monaten mit den Anschaffungskosten eines physischen Servers vergleichbar sind. Bei einer typischen Hardware-Lebensdauer von fünf Jahren kann das Cloud-Modell langfristig zwei- bis dreimal teurer werden, da Anbieter R&D, Stromkosten und Reservekapazitäten einkalkulieren müssen.

On-Prem-Hardware – Kontrolle, Stabilität und Kosteneffizienz

Die Migration zu eigener Infrastruktur oder Bare-Metal-Servern bei Hosting-Anbietern markiert oft eine Reifephase der Infrastruktur, bekannt als „Cloud Repatriation“, getrieben von Leistungs- und Wirtschaftlichkeitsanforderungen.

Die Leistung ist On-Prem höher, da keine Virtualisierungsschicht existiert und Systeme feingetunt werden können. Studien zeigen, dass Hypervisoren 5–15 % der CPU-Ressourcen verbrauchen, während dedizierte Hardware die volle Kapazität den Anwendungen zur Verfügung stellt. Kernel-Tuning und Kernel-Bypass-Technologien (wie DPDK oder io_uring) können die I/O-Latenz um 50–80 % reduzieren, indem Kontextwechsel eliminiert werden.
Die Latenzanforderungen variieren jedoch je nach Anwendungsfall. Für Web-Anwendungen ist der Unterschied zwischen 20 ms und 25 ms vernachlässigbar. 

In real-Time-Bidding-Systemen (RTB) sind Latenzen bis zu 80–100 ms akzeptabel, was hybride Ansätze ermöglicht. Im Hochfrequenzhandel (HFT) sind jedoch Reaktionszeiten unter 100 µs zwingend, wodurch öffentliche Clouds aufgrund von Netzwerk-Jitter technisch ungeeignet sind; nur optimierte On-Prem-Hardware ist praktikabel. Gleiches gilt für industrielle Automatisierung und Hard-Real-Time-Systeme, wo garantierte Paketlaufzeiten schwer in der Cloud zu realisieren sind

Neben technischen Aspekten verändert On-Prem auch die Kostenstruktur. Colocation-Kosten, darunter Rackspace, Connectivity und Strom, sind fix und planbar, wodurch die „Egress Fee-Falle“ entfällt. Cloud-Anbieter berechnen oft hohe Gebühren für ausgehenden Traffic. Bei Web-Anwendungen macht dies 5–10 % der Kosten aus, bei datenintensiven Systemen (Streaming, AI-Datasets, Analytik) sogar bis zu 30 %. In privaten Rechenzentren erfolgt die Internetanbindung daher meist zu einem festen Preis pro Bandbreiteneinheit, wodurch das Wachstum des Datenverkehrs wirtschaftlich sicher ist.

On-Prem erfordert zudem ein qualifiziertes Team für Wartung von Servern, Netzwerken und Speicher. Das erhöht zwar die Personalkosten, ermöglicht aber volle SLA-Kontrolle: Das Unternehmen ist dadurch nicht mehr abhängig von globalen Cloud-Ausfällen oder Support-Prioritäten des Anbieters.

Experten-Insight: On-Prem-Hardware ist kein „Legacy-Ansatz“ mehr, sondern ein strategisches Wettbewerbsinstrument für reife Organisationen. Über einen Zeitraum von drei Jahren und mehr können OPEX-Einsparungen 60–70 % im Vergleich zur Cloud erreichen, insbesondere für stateful Workloads. Die Kontrolle auf physischer Ebene ermöglicht darüber hinaus ein vorhersehbares Systemverhalten, das in Multi-Tenant-Cloud-Plattformen nicht erreichbar ist. Im Endeffekt wird Flexibilität, die bei konstanten Lasten nicht mehr erforderlich ist, gegen höhere Margen eingetauscht.

Hybride Strategie als Industriestandard

In der modernen Praxis werden hybride Cloud-Modelle gegenüber binären Entscheidungen bevorzugt, da sie die Stärken beider Ansätze kombinieren und so ein Gleichgewicht zwischen Geschwindigkeit, Kosten und Sicherheit herstellen.

Kernservices und primäre Datenbanken werden zunehmend auf privater Infrastruktur oder Bare-Metal-Servern betrieben, um Transaktionskosten zu minimieren und die Datensicherheit zu gewährleisten. Sobald die lokale Kapazität erschöpft ist, übernimmt Cloud Bursting: Ein Teil des Traffics oder der Berechnungen wird dabei automatisch in die Public Cloud ausgelagert, sodass eine Überprovisionierung seltener Spitzen entfällt.

Dieser Ansatz passt zum wachsenden Trend der Datenrepatriierung. Öffentliche Fälle wie 37signals (Basecamp), das durch Cloud-Abzug Millionen einsparte, und Umfragen, dass bis zu 83 % der CIOs an teilweiser Workload-Repatriierung interessiert sind, bestätigen: Cold Data oder intensive Disk-Operationen sind oft auf eigenen NVMe-Arrays günstiger als in Managed-Cloud-Diensten. Gleichzeitig verbleiben Frontend, CDN und DDoS-Schutz in der Regel in der Cloud, um eine globale Reichweite zu gewährleisten.

Die verbindende Schicht bildet standardisiertes Management über Kubernetes und Infrastructure-as-Code-Tools wie Terraform und Ansible. Diese Abstraktionen entkoppeln Anwendungen von der physischen Infrastruktur, machen die Platzierung transparent – egal ob auf Private Data Center-Servern oder Cloud-VMs – und reduzieren Vendor-Lock-In-Risiken.

Experten-Insight: „Die Ära des blindlings verfolgten ‚Cloud First‘ ist vorbei. Wir bewegen uns hin zu einer ‚Workload-Smart‘-Strategie. CTOs erkennen, dass die Cloud ein hochmargiger Mietservice ist, kein Gemeinwesen. Der wahre Infrastruktur-Insight 2025 lautet: Unternehmen bauen eigene Plattformen auf Bare-Metal-Servern mit derselben Kubernetes-Stack wie in der Cloud, wodurch sie Hardware-Level-Performance zu den Kosten von Strom und Abschreibung erreichen. Die Cloud bleibt bestehen, jedoch als Erweiterung für Gäste und Experimente, nicht als Fundament.“

Fazit

Die Wahl der Infrastruktur ist sowohl eine finanzielle als auch eine technische Entscheidung, die Berechnung statt Modedenken erfordert.

Sie sollte anhand der Workload-Eigenschaften und des Planungshorizonts getroffen werden. Die Cloud ist geeignet in frühen Projektphasen, bei unvorhersehbarer Nachfrage, wenn schnelle Bereitstellung notwendig ist oder interne Hardware-Expertise fehlt. On-Prem-Hardware ist vorzuziehen bei stabilen, hohen Workloads, sub-100-µs-Latenzanforderungen (wie im HFT), hohem ausgehendem Datenvolumen oder Planungshorizonten über drei Jahre.

Eine effektive Strategie erfordert detaillierte TCO-Modelle einschließlich Egress Fees und Support-Kosten, da Traffic bei Media- und AI-Workloads dominant werden kann. Workloads sollten segmentiert werden: stateless Services wie Microservices und Web-Frontends in die Cloud, stateful Komponenten wie Datenbanken und Speicher auf dedizierter Hardware.

Latenzanforderungen müssen zudem klar definiert sein – Mikrosekunden für Standard-CRM lohnen sich nicht, während physische Isolation im Börsenhandel unverzichtbar ist. Schließlich sollte strategische Flexibilität durch offene Standards erhalten bleiben, sodass die Migration zwischen Cloud und Hardware möglich ist, ohne Anwendungen neu programmieren zu müssen.