Ein Hyperscaler ist ein Cloud-Anbieter, der Rechenleistung, Speicher und Plattformdienste in einem Umfang bereitstellt, der sich innerhalb von Minuten um Größenordnungen nach oben oder unten skalieren lässt. Kennzeichnend sind ein weltweites Netz eigener Rechenzentrumsregionen, ein Katalog von hunderten verwalteten Diensten und eine nutzungsbasierte Abrechnung ohne Mindestlaufzeit. Zu den Hyperscalern zählen vor allem Amazon Web Services (AWS), Microsoft Azure und Google Cloud, mit Abstand gefolgt von Alibaba Cloud und Oracle.
Der Begriff beschreibt weniger ein Produkt als eine Betriebsphilosophie: Infrastruktur wird nicht mehr beschafft, sondern programmiert. Für mittelständische Unternehmen ist das eine echte Verschiebung — und zwar in beide Richtungen. Die Einstiegshürde für Projekte, die früher einen sechsstelligen Hardware-Invest bedeutet hätten, ist praktisch verschwunden. Gleichzeitig entstehen neue Abhängigkeiten und Kostenmuster, die man erst versteht, wenn die dritte Monatsrechnung eintrifft. Dieser Eintrag ordnet beides ein.
Was einen Hyperscaler technisch ausmacht
Vier Merkmale trennen einen Hyperscaler von jedem anderen Anbieter, der Server vermietet. Sie bedingen sich gegenseitig — wer nur eines davon hat, betreibt klassisches Hosting mit einer schöneren Oberfläche.
Elastizität: Kapazität als API-Aufruf
Elastizität bedeutet, dass Kapazität ohne menschliche Beteiligung entsteht und wieder verschwindet. Ein Autoscaling-Verbund startet zusätzliche Instanzen, wenn die CPU-Auslastung einen Schwellwert überschreitet, und fährt sie herunter, wenn die Last abfällt. Für einen Onlineshop mit Kampagnenspitzen heißt das: Die Black-Friday-Kapazität wird für vier Tage gebucht statt für zwölf Monate. Der entscheidende Punkt ist nicht die Geschwindigkeit, sondern die Richtung — auch das Herunterskalieren funktioniert automatisch, und genau daran scheitern klassische Setups.
Regionen und Availability Zones
Hyperscaler organisieren ihre Infrastruktur in Regionen (geografische Gebiete wie Frankfurt oder Irland), die jeweils aus mehreren Availability Zones bestehen. Eine Availability Zone ist ein oder mehrere physisch getrennte Rechenzentren mit eigener Strom-, Kühl- und Netzanbindung, innerhalb der Region aber über Leitungen mit sehr niedriger Latenz verbunden. Damit lässt sich eine Anwendung so verteilen, dass der Ausfall eines kompletten Rechenzentrums keinen Ausfall des Dienstes bedeutet — ohne dass man selbst zwei Standorte betreibt.
Für den Mittelstand ist die Region-Wahl gleichzeitig eine Rechtsentscheidung. Wer Kundendaten in einer EU-Region ablegt, hat damit die datenschutzrechtliche Frage nicht abschließend beantwortet, aber einen wesentlichen Teil davon geregelt. Welcher Teil offen bleibt, steht weiter unten.
Managed Services statt Eigenbetrieb
Der zweite große Unterschied liegt oberhalb der virtuellen Maschine. Hyperscaler bieten verwaltete Datenbanken, Message-Queues, Objektspeicher, Container-Orchestrierung, Suchindizes, Data Warehouses und Modell-Endpunkte für maschinelles Lernen als fertige Bausteine an. Patches, Backups, Failover und Skalierung liegen beim Anbieter. Wer eine Microservices-Architektur baut, spart damit den größten Teil des Betriebsaufwands — und bindet sich zugleich an die Schnittstellen genau dieses Anbieters.
Das Abrechnungsmodell
Abgerechnet wird sekunden- oder stundengenau nach tatsächlicher Nutzung, in der Regel getrennt nach Rechenzeit, Speichervolumen, Anzahl der Anfragen und übertragenem Datenvolumen. Es gibt keine Grundgebühr und keine Kündigungsfrist. Das ist der größte Vorteil und die größte Falle zugleich: Eine Ressource, die niemand mehr braucht, kostet weiter, bis jemand sie aktiv löscht. Rabattmodelle wie Reserved Instances oder Savings Plans senken den Preis deutlich, tauschen die Flexibilität dafür aber gegen eine ein- oder dreijährige Bindung ein.
Hyperscaler, Hoster, Managed-Service-Provider und europäische Anbieter
Die Begriffe werden im Vertriebsgespräch gerne vermischt. Die Unterschiede sind aber operativ relevant, weil sie festlegen, wer bei einem Ausfall um drei Uhr nachts zuständig ist.
| Typ | Was du bekommst | Wer betreibt | Typische Abrechnung |
|---|---|---|---|
| Hyperscaler | Selbstbedienungs-Baukasten aus hunderten Diensten, weltweite Regionen | Du (bzw. deine Entwickler oder deine Agentur) | Nutzungsbasiert, sekundengenau, keine Laufzeit |
| Klassischer Hoster | Root-Server, VPS oder Webspace, feste Ausstattung | Du, ab Betriebssystem aufwärts | Monatliche Pauschale pro Server |
| Managed-Service-Provider | Betrieb, Monitoring, Updates und Support als Dienstleistung — oft auf Hyperscaler-Infrastruktur | Der Dienstleister, mit vertraglichem SLA | Pauschale oder Aufwand plus durchgereichte Infrastrukturkosten |
| Europäischer Cloud-Anbieter | IaaS und ein kleinerer Katalog an Plattformdiensten, Rechenzentren und Gesellschaft in der EU | Du, mit deutlich schlankerem Dienstekatalog | Nutzungsbasiert oder monatlich, häufig mit Inklusiv-Traffic |
Wo der Unterschied im Alltag wirklich auftaucht
Ein Hyperscaler verkauft dir Fähigkeiten, keine Ergebnisse. Das Modell der geteilten Verantwortung sieht vor, dass der Anbieter für die Sicherheit der Cloud einsteht — Hardware, Netz, Hypervisor, physische Zutrittskontrolle — und du für die Sicherheit in der Cloud: Konfiguration, Identitäten, Verschlüsselung, Patches deiner Anwendungen. Ein offen konfigurierter Objektspeicher ist kein Anbieterproblem. Genau an dieser Stelle scheitern Cloud-Projekte im Mittelstand am häufigsten, weil intern niemand die Rolle übernimmt, die vorher der Systemhaus-Vertrag abgedeckt hat. Ein Managed-Service-Provider schließt exakt diese Lücke und ist deshalb keine Konkurrenz zum Hyperscaler, sondern in vielen Fällen die Ergänzung.
Der Markt: die großen drei, Alibaba, Oracle und die Neoclouds
Wer wie groß ist
Für das zweite Quartal 2026 beziffert die Synergy Research Group die weltweiten Ausgaben für Cloud-Infrastrukturdienste auf 143 Milliarden US-Dollar — ein Plus von 43 Prozent gegenüber dem Vorjahresquartal und die höchste Wachstumsrate seit acht Jahren. Die weltweiten Marktanteile lagen laut Synergys Auswertung vom 30. Juli 2026 bei 28 Prozent für Amazon, 20 Prozent für Microsoft und 15 Prozent für Google. Im engeren Segment der öffentlichen Cloud entfallen auf diese drei Anbieter zusammen 67 Prozent des Marktes. Als Haupttreiber des beschleunigten Wachstums nennt Synergy generative KI; KI-spezifische Cloud-Dienste wuchsen im Quartal um 165 Prozent gegenüber dem Vorjahr.
Zwei Dinge sind daran für die eigene Anbieterwahl wichtig. Erstens verschieben sich die Anteile langsam: In einer Synergy-Analyse vom November 2025 hielten die großen drei zusammen 63 Prozent, Amazons Anteil erodiert seit Jahren graduell, während Microsoft und Google aufholen. Zweitens sind das weltweite Zahlen. Für Europa hält Synergy fest, dass Großbritannien und Deutschland die größten Cloud-Märkte sind — die Anteilsverteilung innerhalb eines einzelnen Landes bildet die globale Verteilung aber nicht zwangsläufig ab.
Alibaba, Oracle und das zweite Feld
Der Abstand zwischen den ersten drei und allen anderen ist erheblich. Synergy-Chefanalyst John Dinsdale formulierte es im November 2025 so, dass der drittplatzierte Anbieter Google fast viermal so groß sei wie der viertplatzierte Anbieter Alibaba. Alibaba Cloud ist damit global relevant, hat sein Gewicht aber klar im asiatischen Raum; für ein deutsches Mittelstandsprojekt spielt der Anbieter praktisch keine Rolle.
Oracle ist der interessantere Sonderfall. Synergy führt Oracle im zweiten Quartal 2026 unter den Anbietern der zweiten Reihe mit den höchsten Wachstumsraten — gemeinsam mit spezialisierten KI-Infrastrukturanbietern wie CoreWeave, Crusoe, Nebius und Nscale, die inzwischen neun Plätze unter den Top 40 belegen. Diese sogenannten Neoclouds sind keine Hyperscaler im hier beschriebenen Sinn: Sie bieten sehr viel GPU-Kapazität, aber keinen breiten Katalog an Plattformdiensten. Wer KI-Training einkauft, sollte sie kennen. Wer eine Geschäftsanwendung betreiben will, nicht.
Die Kostenfallen, die Mittelständler am häufigsten treffen
Egress-Gebühren
Daten in die Cloud zu übertragen ist bei allen großen Anbietern kostenlos. Daten wieder herauszubekommen ist es nicht. Diese Egress-Gebühren fallen pro übertragenem Gigabyte an und werden regelmäßig unterschätzt, weil sie bei der Kalkulation im Projekt nicht auftauchen — die Kalkulation rechnet mit Rechenleistung und Speicher, nicht mit Verkehr. Betroffen sind besonders Anwendungen, die große Dateien ausliefern: Mediatheken, Software-Downloads, Bildserver ohne vorgelagertes CDN, Backup-Restores und Analytics-Pipelines, die Rohdaten aus der Cloud in ein lokales Data Warehouse ziehen.
Ungenutzte und überdimensionierte Ressourcen
Die zweite Kostenquelle ist unspektakulärer und meist größer. Weil das Anlegen von Ressourcen keine Freigabe erfordert, entsteht über die Monate ein Bodensatz, den niemand mehr zuordnen kann. Typische Posten:
- Test- und Staging-Umgebungen, die nachts und am Wochenende durchlaufen, obwohl sie nur werktags gebraucht werden
- Nicht angehängte Speicher-Volumes von längst gelöschten virtuellen Maschinen
- Reservierte IP-Adressen und Load Balancer aus abgeschlossenen Projekten
- Instanzen, die auf Basis einer geschätzten Spitzenlast dimensioniert wurden, die nie eingetreten ist
- Snapshots und Backups ohne Aufbewahrungsregel, die sich seit Jahren stapeln
- Log-Daten in teuren Analysediensten, für die niemand eine Löschfrist gesetzt hat
Der wirksamste Gegenmechanismus ist keine Technik, sondern Buchhaltung: eine verbindliche Tagging-Pflicht, mit der jede Ressource einem Projekt, einer Kostenstelle und einem Verantwortlichen zugeordnet wird, plus ein monatlicher Kostenbericht, der an diese Verantwortlichen geht. Wer das erst nach zwei Jahren einführt, verbringt Wochen mit Archäologie.
Vendor Lock-in, digitale Souveränität und der EU Data Act
Je mehr verwaltete Dienste ein Projekt nutzt, desto größer der Nutzen und desto größer die Bindung. Wer eine Anwendung auf proprietäre Datenbanken, anbieterspezifische Funktionsdienste und eine hauseigene Identitätsverwaltung stützt, hat eine Architektur gebaut, die sich nicht portieren, sondern nur neu schreiben lässt. Das ist nicht per se falsch — aber es ist eine Entscheidung und sollte als solche protokolliert werden. Die Mechanik und die Gegenmaßnahmen sind im Eintrag zu Vendor Lock-in ausführlich beschrieben; dieselbe Frage stellt sich übrigens bei jedem SaaS-Produkt.
Was der EU Data Act ab dem 12. Januar 2027 ändert
Der EU Data Act greift genau hier ein. Die Verordnung wurde am 22. Dezember 2023 im Amtsblatt veröffentlicht und gilt seit dem 12. September 2025. Ihr Kapitel VI regelt den Anbieterwechsel bei Datenverarbeitungsdiensten und verpflichtet Cloud- und Edge-Anbieter unter anderem dazu, Hindernisse für einen Wechsel abzubauen, Mindestanforderungen an Cloud-Verträge einzuhalten und offene Schnittstellen bereitzustellen. Anbieter von Platform as a Service und Software as a Service müssen Daten mindestens in einem gängigen, maschinenlesbaren Format exportierbar machen; Anbieter von Infrastructure as a Service müssen für „funktionale Äquivalenz" sorgen, also dafür, dass ein Kunde beim Wechsel zu einem gleichartigen Dienst bei gleicher Eingabe im Wesentlichen vergleichbare Ergebnisse erhält.
Beim Geld gilt eine eigene, oft falsch wiedergegebene Frist. Die Wechselentgelte einschließlich der Egress-Gebühren fallen laut der Erläuterung der Europäischen Kommission zum Data Act ab dem 12. Januar 2027 vollständig weg. Für die Übergangszeit von drei Jahren nach Inkrafttreten — also vom 11. Januar 2024 bis zum 12. Januar 2027 — dürfen Anbieter weiterhin die ihnen tatsächlich entstandenen Kosten für Wechsel und Datenausleitung berechnen. Die verbreitete Aussage, es gebe seit September 2025 keine Wechselgebühren mehr, ist falsch: Seit dem 12. September 2025 gelten die allgemeinen Pflichten der Verordnung, das vollständige Entgeltverbot kommt erst 2027.
Realbeispiel: AWS und die kostenlose Datenausleitung
Wie sich das in der Praxis auswirkt, lässt sich an Amazon Web Services nachvollziehen. AWS kündigte am 5. März 2024 an, die Gebühren für Data Transfer Out ins Internet zu erlassen, wenn ein Kunde AWS verlässt — ausdrücklich, wie es in der Ankündigung von AWS heißt, in der vom europäischen Data Act vorgegebenen Richtung, und weltweit für alle Kunden aus jeder Region. AWS weist im selben Beitrag darauf hin, dass über 90 Prozent der Kunden ohnehin keine Ausleitungskosten haben, weil pro Monat 100 Gigabyte Transfer aus AWS-Regionen ins Internet kostenlos sind.
Die Details sind aufschlussreicher als die Schlagzeile. Der Erlass läuft nicht automatisch: Man muss den AWS-Support kontaktieren, der Antrag wird auf Ebene des AWS-Kontos geprüft, und die Erstattung erfolgt als Gutschrift. In einer Aktualisierung vom 30. September 2025 ergänzte AWS, dass berechtigte Kunden 90 Tage Zeit für den Wechsel haben und den Support informieren müssen, wenn sie länger brauchen; für EU-Kunden, die einen Wechsel nach dem Data Act vollziehen, verweist AWS auf ein eigenes Data-Act-Addendum. Ein Wechsel bleibt also ein Projekt mit Antrag, Frist und Nachweispflicht — die Gebühr ist nur einer von mehreren Kostenfaktoren.
EU-Datengrenze und Sovereign-Cloud-Angebote
Digitale Souveränität ist die zweite Dimension, die im Mittelstand zunehmend über die Anbieterwahl entscheidet — getrieben weniger von der Technik als von Compliance-Anforderungen aus Ausschreibungen, Konzernkunden und dem eigenen Aufsichtsrat. Alle drei großen Anbieter haben darauf mit EU-spezifischen Angeboten reagiert, die unter Bezeichnungen wie „Sovereign Cloud" oder „EU-Datengrenze" vermarktet werden und zusichern, Daten und teilweise auch Betrieb und Support innerhalb der EU zu halten. Diese Angebote unterscheiden sich erheblich im Umfang; entscheidend ist nicht das Etikett, sondern was der konkrete Vertrag über Datenhaltung, Betriebspersonal, Schlüsselverwaltung und Zugriffswege sagt.
Der Data Act adressiert die Frage in Kapitel VII: Nicht-personenbezogene Daten, die in der EU gespeichert sind, sollen vor rechtswidrigem Zugriff durch Behörden aus Drittstaaten geschützt werden. Die Verordnung verbietet grenzüberschreitende Datenflüsse nicht, legt aber Bedingungen und Garantien für solche Zugriffsersuchen fest und verpflichtet Anbieter zu angemessenen Schutzmaßnahmen wie Verschlüsselung und Audits. Der Spannungsbogen zum CLOUD Act der USA ist damit reguliert, aber nicht aufgelöst — weshalb bei besonders sensiblen Datenbeständen weiterhin die Frage im Raum steht, welcher Rechtsordnung die Muttergesellschaft des Anbieters unterliegt.
Wann ein Hyperscaler passt — und wann nicht
Gute Gründe für einen Hyperscaler
Ein Hyperscaler ist die richtige Wahl, wenn die Lastkurve stark schwankt und Spitzen ein Vielfaches der Grundlast betragen, wenn ein Produkt schnell wachsen soll und niemand weiß, wie schnell, wenn mehrere Länder oder Kontinente mit niedriger Latenz bedient werden müssen, wenn KI- oder Datendienste gebraucht werden, deren Eigenbetrieb sich nicht rechnet, oder wenn Ausfallsicherheit über mehrere Rechenzentren gefordert ist, ohne dass man selbst zwei Standorte unterhalten will. In diesen Fällen ist der Preisaufschlag gegenüber einem Hoster gut angelegt, weil man Optionen kauft.
Gute Gründe für einen europäischen Anbieter oder Managed Hosting
Umgekehrt spricht vieles gegen einen Hyperscaler, wenn die Last planbar und weitgehend konstant ist — ein Shop mit stabilem Umsatz und zwei Kampagnenspitzen im Jahr läuft auf gemieteten Servern zuverlässig und deutlich günstiger. Ebenso, wenn der Datenverkehr nach außen hoch ist, weil Inklusiv-Traffic bei europäischen Anbietern die Rechnung planbar hält. Und wenn im Unternehmen kein Team existiert, das Cloud-Konfiguration und Kostenkontrolle dauerhaft verantwortet, ist ein Managed-Service-Provider mit klarem SLA meist die ehrlichere Lösung als ein Hyperscaler-Konto, das nach der Projektübergabe niemand mehr pflegt. Auch strenge Souveränitätsanforderungen aus einer Ausschreibung können die Entscheidung vorwegnehmen.
Der pragmatische Mittelweg
In der Praxis ist die Entscheidung selten binär. Verbreitet und meist sinnvoll ist ein Zuschnitt, bei dem der planbare Kern — Anwendungsserver, Datenbank, Objektspeicher — dort läuft, wo er günstig und rechtlich unkompliziert ist, während elastische oder spezialisierte Teile beim Hyperscaler liegen: Bildverarbeitung, Suchindex, KI-Inferenz, saisonale Zusatzkapazität. Wichtig ist dabei, die Schnittstellen zwischen den Teilen bewusst offen zu halten und die Datenhoheit an einer Stelle zu verankern. Wie man diesen Schnitt konkret setzt und welche Fragen vor der Migration beantwortet sein müssen, behandelt unser Entscheidungs-Guide zu Cloud-Migration und moderner Software-Architektur.
Die nützlichste Frage vor der Anbieterwahl ist nicht „Wer ist der Beste?", sondern „Was kostet uns der Ausstieg in drei Jahren?". Wer diese Zahl grob beziffern kann, hat die Architekturentscheidung im Griff — unabhängig davon, für welchen Anbieter sie ausfällt.