Der billige Cloud-Chip mit dem teuren Rückweg
Eigene Chips von AWS, Azure und Google bringen bis zu zwei Drittel bessere Preisleistung. Haken: ein neuer, stiller Lock-in. Wann sich der Wechsel lohnt.
Bis zu zwei Drittel bessere Preisleistung, weniger Energie pro Rechenoperation, eigene Hardware ohne Nvidia-Aufschlag: Mit diesen Versprechen treiben AWS, Microsoft und Google ihre selbst entwickelten Cloud-Chips. Der Vorteil ist real und messbar. Was die Rechnung verschweigt, ist der Preis für den Rückweg.
Das Wichtigste in Kürze
- Der Preisvorteil ist echt: Die eigenen ARM-Chips der Hyperscaler liefern je nach Workload eine deutlich bessere Preisleistung als klassische x86-Instanzen, im Spitzenfall bis zu zwei Drittel. Bei Scale-out-Diensten ist der Abstand am größten.
- Er gilt nicht für alles: Legacy-x86-Software, HPC-Workloads mit spezialisierten Bibliotheken und ISV-Produkte ohne ARM-Lizenz zahlen den Vorteil wieder ein. Der Rabatt ist an Bedingungen geknüpft.
- Der Lock-in wandert: Jeder Chip ist proprietär. Ein für Graviton optimierter Workload läuft nicht eins zu eins auf Axion oder Cobalt. Wer wechseln will, baut und testet neu.
Verwandt:Cloud-Repatriation: Wann sich Rückholen rechnet / 800-Volt-Gleichstrom im Rechenzentrum
Warum die Hyperscaler plötzlich eigene Chips bauen
Wer heute eine Compute-Instanz bucht, entscheidet längst nicht mehr nur zwischen Anbietern. Er entscheidet zwischen Prozessor-Architekturen, die kein Wettbewerber teilt: Graviton bei AWS, Cobalt bei Azure, Axion bei Google Cloud. Drei eigene ARM-Designs, drei eigene Ökosysteme. Für Cloud-Architekten verschiebt das eine alte Frage an eine neue Stelle, eine Stufe tiefer im Stack.
Das Motiv hinter den Eigenentwicklungen ist rein betriebswirtschaftlich. Custom-Silicon senkt die Abhängigkeit von Intel, AMD und vor allem Nvidia, deren Marge sonst in der Cloud-Rechnung steckt. Es spart Energie pro Rechenoperation und bei vollen Rechenzentren ist Energie längst der härtere Engpass als Kapital. Und es bindet Kunden an Instanztypen, die nur ein einziger Anbieter hat. Bei AWS hat das Geschäft mit eigenen Chips nach Branchenschätzungen inzwischen einen zweistelligen Milliardenumsatz pro Jahr erreicht.
Die Generationen folgen im Jahrestakt. AWS hat im Juni Graviton5 ausgerollt, einen ARM-Prozessor mit 192 Kernen auf TSMCs 3-Nanometer-Prozess und laut Anbieter rund 25 Prozent schneller als der Vorgänger. Für das KI-Training positioniert AWS daneben Trainium2 als Alternative zu Nvidia-GPUs und betreibt dafür eigene Großverbünde im sechsstelligen Chip-Bereich.
Microsoft fährt mit Maia 200 einen eigenen KI-Beschleuniger mit 216 Gigabyte HBM3e-Speicher und mit Cobalt 200 eine ARM-CPU für klassische Server-Last. Google hat mit Axion seinen ersten eigenen ARM-Prozessor in den Instanzfamilien C4A und N4A produktiv. Drei Anbieter, dieselbe Logik: vom Silizium bis zum Service alles selbst kontrollieren.
Custom-Silicon in Zahlen
192 Kerne bringt AWS Graviton5 auf 3-Nanometer-Fertigung, rund 25 Prozent schneller als der Vorgänger.
bis zu 2x bessere Preisleistung nennt Google für die Axion-Variante N4A gegenüber vergleichbaren x86-Instanzen.
rund 60 % bessere Energieeffizienz meldet Google für Axion gegenüber x86.
Wo der Rabatt real ist und wo er kippt
Der Spareffekt ist kein Pauschalrabatt. Er entsteht dort, wo Software sauber für ARM kompiliert und horizontal skaliert. Bei Web-Servern, Microservices, Java- und MySQL-Last, Container-Sidecars und stateless Diensten gewinnt ARM in fast jeder Messung. Google nennt für allgemeine Workloads bis zu 50 Prozent mehr Leistung und 60 Prozent bessere Energieeffizienz gegenüber vergleichbaren x86-Maschinen. SAP berichtete für seine HANA-Datenbanklast spürbare Performance-Gewinne auf Graviton.
Die andere Seite steht selten im Werbematerial. Spezialisierte HPC-Bibliotheken, ältere x86-Binaries ohne ARM-Build und kommerzielle ISV-Software, deren Lizenz die Architektur nicht abdeckt, fressen den Vorteil wieder auf. Wer eine Datenbank-Engine mit x86-only-Lizenz fährt, spart an der Instanz und zahlt beim Support nach.
Zwischen Entscheidung und Ersparnis liegt zudem eine Übergangsphase, die in keiner Preisrechnung auftaucht. Wer migriert, betreibt eine Weile beide Architekturen parallel: doppelte Test-Matrix, doppelte Basis-Images, doppelte Monitoring-Profile. Diese Doppelpflege ist temporär, schiebt den Break-even aber nach hinten. Teams, die das einplanen, weisen den Spareffekt ehrlich erst ab dem Quartal aus, in dem die x86-Altlast abgeschaltet ist.
| Workload-Typ | ARM-Eignung | Realer Kostenvorteil |
|---|---|---|
| Web, Microservices, Sidecars | Sehr hoch | Maximal |
| Java, MySQL, Cache-Layer | Hoch | Voll, nach Rebuild |
| Legacy-x86-Binaries | Gering | Negativ ohne Portierung |
| HPC mit Spezial-Libraries | Selektiv | Fall für Fall prüfen |
| ISV-Software ohne ARM-Lizenz | Blockiert | Vorteil verfällt am Support |
Vor jeder Migration steht deshalb eine Workload-Inventur, keine Preistabelle. Welcher Dienst ist stateless und ARM-fertig, welcher hängt an einer x86-Abhängigkeit, die niemand mehr dokumentiert hat? Über den Business Case entscheidet diese Klassifizierung, nicht der Listenpreis pro vCPU.
Der Lock-in, der nicht im Vertrag steht
Hier liegt die eigentliche Pointe. Der Lock-in sitzt nicht mehr nur im Vertrag, er sitzt im Build. Die alte Cloud-Bindung war eine Frage von Datentransfer und Managed Services. Custom-Silicon zieht eine zweite Bindungsebene ein, eine Stufe tiefer im Stack. Ein Image, das für Graviton getuned wurde, läuft auf Axion oder Cobalt zwar, aber selten mit derselben Effizienz. Die drei ARM-Designs unterscheiden sich in Vektor-Erweiterungen, Cache-Hierarchie und Speicheranbindung. Compiler-Flags, optimierte Bibliotheken und Lastprofile sind pro Chip-Familie kalibriert.
Wer den Anbieter wechselt, baut neu, misst neu und justiert das Tuning erneut. In der Praxis bindet das ein kleines Team über Wochen, am Ende läuft dieselbe Anwendung wie vorher, nur auf anderem Silizium. Genau diese Wechselkosten verschaffen dem Anbieter die Verhandlungsposition, die er beim Einstiegsrabatt scheinbar abgibt.
Der Spar-Chip kostet nichts beim Einstieg. Er kostet beim Ausstieg.
ARM in der Cloud bleibt für große Teile des Portfolios die richtige Wahl. Gefährlich ist allein die Annahme, billiger sei automatisch freier. Wer den Rabatt nimmt, ohne die Exit-Kosten zu kalkulieren, tauscht eine Nvidia-Abhängigkeit gegen eine Architektur-Abhängigkeit. Wie sich diese Verschiebung auf der Kapazitätsseite zuspitzt, zeigt der parallele Run auf GPUs, der ganze Platform-Teams unter Druck setzt.
Wie Teams den Spareffekt sichern, ohne sich zu fesseln
Der Ausweg heißt Disziplin in der Pipeline. Fünf Schritte trennen den belastbaren Business Case vom teuren Reinfall.
- ARM-Kompatibilität früh in die CI ziehen. Multi-Arch-Builds gehören in die Pipeline, bevor der erste Produktiv-Workload migriert. Wer das nachträglich nachrüstet, zahlt doppelt.
- Workloads klassifizieren statt pauschal verschieben. Stateless und ARM-fertig zuerst, Legacy und ISV-gebunden zuletzt oder gar nicht.
- Exit-Kosten in den Business Case rechnen. Nicht nur die monatliche Ersparnis, sondern der Aufwand, den Workload später auf einen anderen Chip oder zurück auf x86 zu bringen.
- FinOps-Tagging pro Architektur. Ohne saubere Kostenzuordnung je Instanztyp bleibt der reale Effekt im Sammelposten unsichtbar.
- Standard-Images portabel halten. Container und Infrastruktur als Code so schreiben, dass der Architektur-Wechsel eine Konfigurationsentscheidung bleibt, kein Rebuild von null.
Für die meisten Teams ist die Sache klar: ARM-Instanzen lohnen sich für den Scale-out-Teil des Portfolios sofort und der Spareffekt rechtfertigt die Portierung. Wer die Migration aber als Einbahnstraße plant, verliert genau die Verhandlungsmacht, die der Wettbewerb der Hyperscaler ihm eigentlich schenkt.
Häufige Fragen
Was ist Custom-Silicon in der Cloud?
Damit sind Prozessoren gemeint, die ein Cloud-Anbieter selbst entwirft, statt sie von Intel, AMD oder Nvidia zu kaufen. Beispiele sind AWS Graviton, Microsoft Cobalt und Google Axion bei den CPUs sowie AWS Trainium und Microsoft Maia bei den KI-Beschleunigern.
Sind ARM-Chips in der Cloud immer günstiger?
Nein. Der genannte Preisvorteil gilt nur für ARM-taugliche Workloads wie Web-Server, Microservices und Java. Legacy-x86-Software, HPC mit Spezialbibliotheken und ISV-Produkte ohne ARM-Lizenz können teurer werden, weil Portierung oder Support den Rabatt aufzehren.
Was kostet der Wechsel zwischen Graviton, Axion und Cobalt?
Jeder Chip ist proprietär. Ein für eine Familie optimierter Workload braucht beim Wechsel neue Builds, neue Tests und oft neues Performance-Tuning. Der Aufwand entspricht einem kleinen Migrationsprojekt, nicht einer Konfigurationsänderung.
Lohnt sich Custom-Silicon für den Mittelstand?
Für moderne, containerisierte Dienste meist, weil die ARM-Portierung gering ausfällt und die Ersparnis schnell wirkt. Bei gewachsenen x86-Landschaften lohnt erst eine Workload-Inventur, die zeigt, welcher Anteil ohne Reibung migrierbar ist.
Verschwindet x86 damit aus der Cloud?
Nicht kurzfristig. Für Scale-out-Last wird ARM zum Standard, für spezialisierte HPC- und Legacy-Workloads bleibt x86 erste Wahl. Die meisten Unternehmen werden auf absehbare Zeit beide Architekturen parallel betreiben.
Bildquelle: KI-generiert (Juni 2026)
