5-Jahres-TCO-Vergleich: RZ-Eigenbetrieb vs. Hyperscaler ab 100 Servern

Über ein volles Jahrzehnt hinweg folgte die europäische IT-Strategie einem beinahe unantastbaren Konsens. Eigene Rechenzentrumsflächen galten in Aufsichtsräten als schwerfälliges Relikt vergangener Tage, während die Public Cloud als alternativlose Leitwährung moderner Unternehmensführung propagiert wurde. Analystenhäuser versprachen die vollständige Ablösung hoher Investitionsausgaben (CAPEX) durch flexible operative Betriebsausgaben (OPEX).

In den Bilanzen des Jahres 2026 weicht diese Euphorie einer nüchternen kaufmännischen Bestandsaufnahme. Sobald eine Organisation ein Reifestadium erreicht hat, in dem die digitale Grundlast über Quartale hinweg stabil und planbar läuft, kehren sich die vermeintlichen Skaleneffekte der Hyperscaler um. Öffentliche Cloud-Plattformen wie AWS, Microsoft Azure und Google Cloud operieren in ihren Infrastruktursparten mit operativen Bruttomargen von über 35 Prozent.

Wer 100 oder mehr dauerhaft laufende Anwendungs-, Datenbank- und Middleware-Instanzen über einen Betrachtungszeitraum von 60 Monaten in der Public Cloud mietet, bezahlt die darunterliegende Server-Hardware nicht nur ein einziges Mal. Er finanziert dem Plattformbetreiber selbst unter Berücksichtigung dreijähriger Reserved Instances alle 15 bis 18 Monate einen kompletten Hardware-Erneuerungszyklus.

Die Ökonomie der Grundlast: Warum Reserved Instances ab 100 Servern gegen Bare-Metal verlieren

Das wirtschaftliche Grundversprechen der Public Cloud beruht auf Elastizität: Unternehmen bezahlen nur für jene Rechenkapazitäten, die sie in der jeweiligen Sekunde tatsächlich abrufen. In der betrieblichen Praxis europäischer Industrie-, Handels- und Finanzunternehmen zeigt die Auswertung der realen Telemetriedaten jedoch ein völlig anderes Lastprofil.

Zwischen 75 und 85 Prozent aller produktiven Unternehmens-Workloads bestehen aus durchgehend aktiven 24/7-Systemen wie ERP-Kernen, relationalen Datenbanken, Integrations-Pipelines und Container-Plattformen. Um die hohen On-Demand-Stundensätze dieser Dauerläufer zu senken, greifen Einkaufsabteilungen regelmäßig zu dreijährigen Verpflichtungsverträgen (Reserved Instances oder Compute Savings Plans).

Mit einem dreijährigen Commit gibt das Unternehmen jedoch genau jenen Vorteil preis, für den es ursprünglich in die Cloud gewechselt ist: die kaufmännische Flexibilität. Es entsteht ein synthetischer Fixkostenblock, der wirtschaftlich einem Leasingvertrag gleicht, jedoch das Drei- bis Vierfache der realen Bare-Metal-Abschreibung kostet und nach 60 Monaten mit null Euro Restwert endet.

Hinzu kommt die technische Diskrepanz bei der Definition einer Recheneinheit. Was Hyperscaler als virtuelle CPU (vCPU) abrechnen, entspricht keinem dedizierten physischen Prozessorkern, sondern lediglich einem einzelnen Hyperthreading-Thread (SMT). Im Eigenbetrieb mit aktuellen AMD-EPYC-9004-Prozessoren steht hinter jedem geplanten Kern hingegen ungeteilte physische Rechenleistung mit garantiertem L3-Cache.

Wie gravierend diese Nebenkosten ausfallen, belegt die öffentlich dokumentierte Cloud-Repatriierung des Softwareunternehmens 37signals (Basecamp und HEY) unter CTO David Heinemeier Hansson. Durch den Umzug von AWS auf eigene Dual-Socket-Server im Colocation-Betrieb senkte das Unternehmen seine Infrastrukturausgaben von 3,2 Millionen US-Dollar pro Jahr auf unter 850.000 US-Dollar und spart über fünf Jahre mehr als sieben Millionen US-Dollar.

Ähnliche Muster zeigen sich in zahlreichen europäischen Sanierungsprojekten, bei denen ein unreflektierter Lift-and-Shift-Umzug in öffentliche Clouds zu explodierenden Monatsrechnungen geführt hat. Eine detaillierte Aufarbeitung dieser Fehlkalkulationen finden Sie in unserer Analyse zum Post-Mortem einer gescheiterten Cloud-Migration.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud-Exit-Strategie im Enterprise-Einsatz, zu Community Cloud im Enterprise-Einsatz sowie zu Cloud Computing Beispiele im Enterprise-Einsatz.

Technischer Deep-Dive: Der 4-Schichten-Stack für moderne Colocation-Autarkie

Ein wirtschaftlicher Eigenbetrieb bedeutet ausdrücklich nicht, im eigenen Keller einen Serverraum mit Klimagerät und Notstromaggregat zu errichten. Moderne Infrastruktur-Autarkie nutzt Carrier-neutrale Tier-III-Colocation-Rechenzentren (wie Equinix, NTT oder maincubes), die redundante Stromversorgung, Biometrie-Zutrittsschutz und hocheffiziente Kühlung mit PUE-Werten unter 1,25 als standardisierte Immobilienleistung bereitstellen.

Ebene 1 & 2: High-Density AMD-EPYC-Compute und Ceph-NVMe-Storage

Auf der Hardware-Ebene hat die enorme Packungsdichte aktueller Server-Prozessoren den Flächenbedarf radikal reduziert. Um ein Portfolio von 100 produktiven Instanzen mit jeweils 16 vCPUs und 64 Gigabyte RAM (1.600 vCPUs und 6,4 Terabyte RAM) bereitzustellen, genügen heute acht kompakte Dual-Socket-Server mit AMD-EPYC-9554-Prozessoren (64 Kerne pro Sockel) und jeweils 1,5 Terabyte DDR5-ECC-RAM auf lediglich 16 Höheneinheiten in einem einzigen Rack.

Noch deutlicher fällt der Vorsprung beim Massenspeicher aus. Bei AWS (EBS gp3/io2) oder Azure (Managed Disks) sind Kapazität, IOPS und Durchsatz künstlich entkoppelt, sodass hohe Datenbank-IOPS jeden Monat vierstellige Zusatzbeträge verschlingen. Im Colocation-Cluster werden die acht Knoten hingegen mit jeweils acht Enterprise-U.3-NVMe-Laufwerken bestückt, die über Ceph zu einem dreifach replizierten, selbstheilenden Speicherpool verschmelzen.

„Die Public Cloud ist ein hervorragendes Mietmodell für unvorhersehbare Lastspitzen und kurzlebige Experimente. Wer jedoch berechenbare 24/7-Grundlasten über fünf Jahre bei Hyperscalern mietet, zahlt eine dauerhafte Bequemlichkeitsprämie, die den Gegenwert der eigenen Hardware mehrfach übersteigt.“

Ein einzelnes Enterprise-NVMe-Laufwerk liefert bereits über 750.000 Lese-IOPS bei Latenzen unter 100 Mikrosekunden. Das gesamte Cluster stellt Millionen IOPS ohne einen einzigen Euro laufender Nutzungsgebühr bereit. Die genauen Designregeln für solche Speichernetze beschreiben wir im Leitfaden zur Rechenzentrums-Autarkie mit Ceph und NVMe-over-Fabrics.

Ebene 3 & 4: 100-GbE-Spine-Leaf-Fabric, Carrier-Peering und GitOps-Steuerung

Damit der verteilte Speicher und die Live-Migration blockierungsfrei arbeiten, verbindet eine redundante Spine-Leaf-Architektur (Clos-Topologie) mit 25-GbE-Serverports und 100-GbE-Switch-Uplinks alle Knoten im Rack. Über BGP EVPN und VXLAN fließt der gesamte interne Ost-West-Verkehr kostenlos mit Drahtgeschwindigkeit, während in der Public Cloud bereits der Datentransfer zwischen zwei Availability Zones derselben Region mit bis zu zwei Cent pro Gigabyte tarifiert wird.

Für den externen Verkehr ins Internet nutzt das Unternehmen die Carrier-Neutralität des Standorts: Ein redundanter 10-Gbit/s-Glasfaser-Uplink mit direktem Peering am DE-CIX ist als Flatrate bereits für rund 400 Euro monatlich verfügbar. Auf der obersten Ebene (Ebene 4) sorgt KVM-Virtualisierung via Proxmox VE oder Sovereign Cloud Stack samt OpenTofu und Ansible für vollautomatisierte Bereitstellung per Git-Pull-Request.

Vollkostenrechnung über 60 Monate: Bloomberg-Radar-TCO-Matrix (100 Instanzen)

Für eine revisionssichere Vorlage im Investitionsausschuss betrachten wir ein exakt definiertes Referenzszenario über 60 Monate: 100 produktive Instanzen (je 16 vCPUs, 64 GB RAM), 50 Terabyte NVMe-Primärspeicher mit 150.000 garantierten IOPS, 100 Terabyte Backup-Speicher sowie 50 Terabyte monatlichen ausgehenden Datenverkehr (Egress).

Auf der Hyperscaler-Seite (AWS Frankfurt bzw. Azure Germany West Central) sind bereits durchgängige 3-Jahres-Reserved-Instances eingerechnet. Auf der Colocation-Seite kalkulieren wir den Kauf von acht Dual-Socket-Servern inklusive 5-Jahres-24/7-Herstellersupport (4 Stunden Vor-Ort-Reaktionszeit), redundanten 100-GbE-Switches, zwei Racks inklusive Grünstrom sowie das anteilige Plattform-Engineering:

Die Matrix verdeutlicht, dass selbst nach Einrechnung großzügiger Strombudgets, zweier Racks im Tier-III-Rechenzentrum und signifikanter Personalkosten für das Plattform-Engineering nach 60 Monaten ein struktureller Kostenvorteil von 840.000 Euro (44,3 Prozent) verbleibt. Zudem erfordert auch eine Cloud-Umgebung ab 100 Instanzen hochbezahlte Cloud-Architekten und FinOps-Spezialisten sowie prozentuale Enterprise-Support-Aufschläge von bis zu zehn Prozent des Rechnungsvolumens.

Im Eigenbetrieb hingegen vermeiden Unternehmen nicht nur diese Umsatzbeteiligung, sondern umgehen durch den Einsatz von Debian/KVM, Proxmox VE und Ceph gleichzeitig die Broadcom-Kostenfalle bei der Server-Virtualisierung. Der gesamte Software-Stack wird über transparente Pauschalen pro physischem CPU-Sockel abgesichert, wodurch die 64-Core-Dichte moderner Prozessoren ihren vollen Hebel entfaltet.

Die Make-or-Buy Sourcing-Weiche und regulatorische Souveränität unter DORA, NIS-2 und EU Data Act

Die Erkenntnis, dass statische Grundlasten in der Public Cloud überteuert sind, muss nicht in einen dogmatischen Komplettausstieg münden. Entscheidend für CIO und Einkauf ist eine differenzierte Sourcing-Weiche entlang der eigenen Betriebsreife.

Erstens (Carrier-neutrale Colocation mit eigenem Hardware-Eigentum): Für Organisationen ab 80 bis 100 dauerhaft laufenden Serverinstanzen und einem etablierten Linux-/DevOps-Team bietet das Anmieten eigener Racks bei Equinix, maincubes oder NTT in Verbindung mit gekauften oder geleasten Marken-Servern (Dell, HPE, Lenovo) die höchste Gesamtrendite. Der Break-even gegenüber dreijährigen Cloud-Reserved-Instances wird bereits nach 14 bis 16 Monaten überschritten.

Zweitens (Europäische Bare-Metal-Miete ohne CAPEX-Bindung): Unternehmen, die den Kostenvorteil dedizierter Hardware und großzügiger Traffic-Inklusivpakete nutzen wollen, aber bilanzielle Investitionsausgaben (CAPEX) ausschließen möchten, mieten dedizierte Enterprise-Server bei europäischen Anbietern wie Hetzner, OVHcloud oder Scaleway. Darauf betreiben sie ihren eigenen Proxmox-KVM- und Ceph-Cluster und sparen rund 35 bis 40 Prozent gegenüber US-Hyperscalern.

Drittens (Hybride Baseload-Repatriierung mit Cloud-Bursting): Für saisonale Geschäftsmodelle wie den E-Commerce oder für Unternehmen mit temporären KI-Trainingsläufen empfiehlt sich die Trennung zwischen Grundlast (Baseload) und Spitzenlast (Burst-Load). Die berechenbaren 80 Prozent der Dauerlast laufen hochwirtschaftlich in der eigenen Colocation, während kurzfristige Lastspitzen über einen verschlüsselten WireGuard- oder Direct-Connect-Tunnel dynamisch in der Public Cloud abgefangen werden.

Flankiert wird diese wirtschaftliche Rechnung durch verschärfte europäische Regulierungsrahmen. Unter DORA (Verordnung EU 2022/2554, Artikel 28) sowie der NIS-2-Richtlinie müssen kritische Einrichtungen ihre Konzentrationsrisiken bei IKT-Drittdienstleistern begrenzen und erprobte Ausstiegsstrategien nachweisen. Gleichzeitig untersagt der EU Data Act (Verordnung EU 2023/2854) zwar ab Januar 2027 einmalige Wechselgebühren beim Providerwechsel, schützt aber weder vor laufenden Übertragungsgebühren im Regelbetrieb noch vor Zugriffen nach dem US CLOUD Act.

Der 4-Phasen-Umsetzungsfahrplan: In 90 Tagen von der Cloud-Miete in die eigene Colocation

Eine kontrollierte Rückführung von Cloud-Workloads (Cloud Repatriation) erfolgt heute als schrittweise, datengestützte Übergabe im laufenden Betrieb. Mit dem folgenden 90-Tage-Fahrplan überführen Infrastruktur-Teams ihre Grundlast ohne Serviceunterbrechung in die eigene Colocation.

Phase 1 (Tag 1 bis 20): FinOps-Rechnungsaudit und Workload-Klassifizierung

Am Beginn steht die detaillierte Zerlegung der Cloud-Einzelposten (AWS Cost and Usage Report bzw. Azure Cost Management) der letzten zwölf Monate. Das Architektur-Team trennt statische 24/7-Grundlasten mit hoher Speicherdichte oder hohem Netzwerkdurchsatz von stark schwankenden Komponenten und misst die realen Spitzenwerte für CPU, RAM, IOPS und Egress-Bandbreite zur präzisen Hardware-Dimensionierung.

Phase 2 (Tag 21 bis 45): Colocation-Bereitstellung, Hardware-Rollout und Netzwerkkopplung

Nach der Kontrahierung der BSI-C5- und ISO-27001-zertifizierten Colocation-Racks sowie der Carrier-Uplinks erfolgt der Einbau der vorkonfigurierten Dual-Socket-Server und Spine-Leaf-Switches. Der Basis-Stack aus Debian/KVM, Proxmox VE und Ceph-NVMe-Storage wird vollautomatisiert über PXE-Boot und Ansible ausgerollt und per redundantem WireGuard- oder Direct-Connect-Tunnel mit der bestehenden Cloud-VPC gekoppelt.

Phase 3 (Tag 46 bis 70): Asynchrone Datenreplikation und Pilot-Migration

Bevor produktiver Kundenverkehr umgeschaltet wird, richtet das Team eine kontinuierliche Hintergrundsynchronisation ein. Relationale Datenbanken wie PostgreSQL werden als Read-Replicas im neuen Colocation-Cluster synchronisiert, während Objekt- und Blockdaten im Hintergrund auf den Ceph-Pool gespiegelt werden. Anschließend ziehen zunächst CI/CD-Build-Farmen, Logging-Cluster und Staging-Umgebungen um.

Phase 4 (Tag 71 bis 90): Produktiver Cutover, DNS-Umschaltung und RI-Abschmelzung

In geplanten Wartungsfenstern werden die im Colocation-Cluster mitlaufenden Datenbank-Replikate zum primären Master-Knoten hochgestuft und die Anwendungs-Container oder VMs über verkürzte DNS-TTL-Werte auf das eigene Rechenzentrum geschwenkt. Nach einer zweiwöchigen Stabilitätsphase werden die verwaisten Cloud-Instanzen, EBS-Disks und NAT-Gateways endgültig abgeschaltet.

Fünf Kontrollfragen für Vorstand und IT-Leitung vor der nächsten Cloud-Verlängerung

1. Wie hoch ist der reale Anteil unserer 24/7-Grundlast an der monatlichen Hyperscaler-Rechnung?

Fordern Sie vom Cloud-Team eine Aufschlüsselung an, wie viele Ihrer produktiven Instanzen über das gesamte Jahr hinweg durchgängig aktiv sind. Liegt dieser Anteil bei über 70 Prozent der Gesamtrechnung, bezahlen Sie in der Public Cloud dauerhaft eine Flexibilitätsprämie für eine Elastizität, die Ihre Anwendungslandschaft technisch gar nicht abruft.

2. Welchen Prozentsatz unserer Cloud-Ausgaben machen sekundäre Gebühren für Egress, IOPS und Support aus?

Lassen Sie sich die Kostenblöcke für Datenausleitung (Data Transfer Out), Cross-AZ-Verkehr, NAT-Gateways, Provisioned-IOPS-Aufschläge und prozentuale Enterprise-Support-Verträge separat ausweisen. Häufig zeigt sich, dass allein diese Nebenkosten ausreichen würden, um die gesamte Server- und Netzwerk-Hardware eines eigenen Colocation-Clusters binnen 18 Monaten vollständig zu kaufen.

3. Sind unsere Anwendungen über offene Standards portabel oder in proprietären Cloud-Diensten gefangen?

Prüfen Sie, ob Ihre Architektur auf portablen Grundlagen wie Linux-VMs, Kubernetes-Containern, PostgreSQL, Redis und S3-kompatiblem Objektspeicher beruht oder ob Geschäftslogik tief in proprietäre Dienste wie AWS DynamoDB oder Azure Cosmos DB einprogrammiert wurde. Offene Schnittstellen halten Wechselkosten niedrig und stärken Ihre Verhandlungsposition.

4. Wie sichern wir bei einem Colocation-Eigenbetrieb die 24/7-Hardware-Entstörung ohne eigenes Schichtpersonal ab?

Durch die Kombination aus fehlertolerantem Ceph-Storage (das den Ausfall ganzer Serverknoten ohne Betriebsunterbrechung kompensiert), 4-Stunden-Mission-Critical-Vor-Ort-Verträgen der Serverhersteller und dem Remote-Hands-Service des Colocation-Betreibers bleibt der physische Wartungsaufwand für Ihr eigenes Team im laufenden Betrieb minimal.

5. Entspricht unser Zeitplan den Ablauffristen bestehender Enterprise-Discount- oder RI-Verträge?

Große Cloud-Rahmenverträge (Enterprise Agreements, EDP oder 3-Jahres-Savings-Plans) erzeugen künstliche Stichtage mit hohen Abnahmeverpflichtungen. Starten Sie das technische TCO-Audit und den Aufbau eines Colocation-Pilotclusters mindestens sechs bis neun Monate vor dem Ende der Laufzeit, damit Sie bei den Vertragsgesprächen eine produktionsbereite Alternative vorweisen können.

Strategisches Fazit: Vom blinden Cloud-Dogma zur wirtschaftlichen Hybrid-Souveränität

Die Ära des pauschalen Cloud-First-Dogmas ist vorbei. Die empirischen Bilanzdaten der letzten Jahre belegen unmissverständlich, dass öffentliche Hyperscaler ab einer stabilen Infrastrukturgröße von rund 100 Serverinstanzen keine Kostensenker sind, sondern zu einer dauerhaften Margenbelastung für das Anwenderunternehmen heranwachsen.

Moderne Technologie- und Finanzführung setzt deshalb auf eine nüchterne Arbeitslast-Arbitrage: Berechenbare, daten- und speicherintensive 24/7-Grundlasten gehören auf hochdichte eigene oder dediziert gemietete Bare-Metal-Hardware mit offenen Standards wie KVM und Ceph in europäischen Colocation-Zentren. Wer diesen Schritt vollzieht, senkt seine laufenden Infrastrukturkosten über fünf Jahre um über 44 Prozent, gewinnt die volle Datenhoheit unter DORA und NIS-2 zurück und nutzt die Public Cloud gezielt als elastischen Puffer für echte Spitzenlasten.

Häufig gestellte Fragen (FAQ) zu 5-Jahres-TCO, Colocation und Cloud-Repatriierung