Was ist ein Hyperscaler? Merkmale und Auswahl

Ein Hyperscaler ist ein Cloud-Anbieter, der standardisierte Rechen-, Speicher-, Netzwerk- und Plattformdienste über viele Regionen in grossem Umfang bereitstellt. Typisch sind automatisierte Bereitstellung, breite Serviceauswahl und schnelle Kapazitätsanpassung. Eine allgemein gültige Grössenschwelle gibt es jedoch nicht; entscheidend ist das Gesamtmodell, nicht ein einzelner Messwert.

Hyperscaler ist keine Grössenklasse mit Grenzwert

Der Begriff beschreibt ein Betriebs- und Angebotsmodell. Ein Hyperscaler betreibt stark standardisierte Infrastruktur, bündelt Ressourcen für viele Kunden und stellt sie über automatisierte Schnittstellen bereit. Dazu kommen mehrere Regionen, ein breites Portfolio und die Fähigkeit, Kapazität rasch anzupassen.

Kein einzelner Schwellenwert entscheidet über die Bezeichnung. Weder die Zahl der Rechenzentren noch der Umsatz oder die Servermenge bildet allein ab, wie standardisiert, global und elastisch eine Plattform arbeitet.

NIST nennt für Cloudcomputing Merkmale wie breiten Netzwerkzugang, Ressourcenpooling, schnelle Elastizität und messbare Nutzung. Hyperscaler setzen diese Merkmale in besonders grossem Umfang um, doch NIST definiert damit keine eigene Hyperscaler-Kategorie.

Fünf typische Merkmale

Ein Anbieter wird meist dann als Hyperscaler eingeordnet, wenn mehrere Eigenschaften zusammenkommen:

• Standardisierung: Ressourcen und Dienste folgen wiederholbaren Produkten, APIs und Betriebsmodellen.
• Globale Regionen: Workloads können in verschiedenen geografischen Regionen platziert werden.
• Breites Serviceangebot: Neben virtuellen Maschinen gibt es Datenbanken, Analytik, Messaging, Identität und weitere Plattformdienste.
• Elastizität: Kapazität lässt sich automatisiert hinzufügen oder reduzieren.
• Betrieb im grossen Umfang: Die Plattform verteilt Infrastruktur und Betrieb über eine grosse gemeinsame Basis.

Breite ist dabei kein Qualitätsbeweis. Ein umfangreicher Katalog kann Entscheidungen beschleunigen, aber auch Abhängigkeiten und Betriebsaufwand erhöhen.

Region, Zone und Fehlerdomäne

Eine Region ist ein geografischer Betriebsbereich. Darin können mehrere Availability Zones oder vergleichbare getrennte Standorte liegen. Diese Trennung liefert Bausteine für Ausfallsicherheit, macht eine einzelne Bereitstellung aber nicht automatisch redundant.

AWS dokumentiert Regionen als voneinander getrennte Bereiche und Zonen als unabhängige Standorte innerhalb einer Region. Ressourcen und Daten werden nicht pauschal in eine andere Region kopiert. Die Anwendung muss Replikation und Failover passend konfigurieren.

Azure beschreibt Zuverlässigkeit als geteilte Verantwortung: Die Plattform stellt Regionen, Zonen und Dienste bereit; der Kunde wählt sie und entwirft seine Anwendung fehlertolerant. Nicht jeder Dienst unterstützt Zonen oder Regionen auf dieselbe Weise.

Eine Fehlerdomäne ist der Bereich, den ein gemeinsamer Ausfall treffen kann. Das kann ein Prozess, Host, Rack, Rechenzentrum, eine Zone, Region oder ein globaler Steuerungsdienst sein. Mehrere Instanzen in derselben Fehlerdomäne sind keine vollständige Redundanz.

Warum Unternehmen Hyperscaler wählen

Ein Hyperscaler ist sinnvoll, wenn ein Projekt mehrere Regionen, kurzfristig stark wechselnde Last oder spezialisierte Plattformdienste benötigt. Globale Teams erhalten ein einheitliches Konto-, API- und Automatisierungsmodell.

Weitere Gründe sind:

• neue Umgebungen ohne Beschaffung eigener Hardware;
• verwaltete Dienste für Datenbanken, Warteschlangen oder Analytik;
• gemeinsame Sicherheits- und Identitätsfunktionen;
• Infrastruktur als Code über Regionen hinweg;
• Zugriff auf Dienste, die regional nicht wirtschaftlich angeboten werden.

Elastizität ist eine Fähigkeit, keine Spargarantie. Automatische Skalierung kann Kosten senken, wenn Ressourcen tatsächlich wieder entfernt werden. Ohne Limits, Budgets und Verantwortliche wächst die Rechnung ebenso automatisch.

Vergleich der Betriebsmodelle

Die Kategorien überlappen. Ein regionaler Anbieter kann automatisierte Cloud-Dienste bieten, während ein Managed-Angebot auf einem Hyperscaler läuft. Entscheidend ist die vertragliche und technische Verantwortung, nicht das Etikett.

Lock-in und Exit

Lock-in entsteht nicht nur durch einen Vertrag. Er steckt in proprietären Datenbankfunktionen, Ereignisdiensten, Identitätsmodellen, Berechtigungen, Monitoring und Automatisierung. Je tiefer die Anwendung diese Dienste nutzt, desto aufwendiger wird ein Wechsel.

Das ist nicht automatisch schlecht. Ein verwalteter Dienst kann Entwicklungs- und Betriebszeit sparen. Exit ist Teil des Preises: Dokumentieren Sie Datenformate, Abhängigkeiten, Exportwege und die Zeit für einen Wiederanlauf ausserhalb des Anbieters.

Ein realistischer Exit-Test beantwortet:

• Lassen sich Daten vollständig und in brauchbarem Format exportieren?
• Welche Funktionen müssten ersetzt oder neu entwickelt werden?
• Wie lange dauert die Übertragung bei der vorhandenen Bandbreite?
• Wer betreibt die Zielplattform während der Migration?
• Welche Verträge und Schlüssel müssen anschliessend beendet werden?

Egress und vollständige Kosten

Egress bezeichnet ausgehenden Datenverkehr aus einer Cloud-Plattform oder zwischen bestimmten Regionen und Diensten. Ob und wie er berechnet wird, hängt vom Produkt, Ziel und Vertrag ab. Veröffentlichen Sie deshalb keine Architektur auf Basis einer alten Preistabelle.

Rechnen Sie in der eigenen Währung. Berücksichtigen Sie Compute, Speicher, Anfragen, Backups, Protokolle, Support, ausgehenden Verkehr und parallele Umgebungen während einer Migration. Cloud-Kosten verhalten sich wie Nebenkosten: Der Grundpreis erzählt nicht die ganze Geschichte.

Kosten entstehen auch durch Fehlerdomänen. Eine zweite Zone, Region oder unabhängige Sicherung verbessert ein bestimmtes Risiko, benötigt aber zusätzliche Ressourcen und Datenübertragung. Die Architektur muss das gewünschte Wiederanlaufziel benennen.

Compliance und Datenstandort

Datenstandort ist kein Sticker. Die gewählte Region ist wichtig, reicht aber nicht als Prüfung. Sie müssen klären, wo Primärdaten, Backups, Protokolle, Supportkopien und Schlüssel verarbeitet oder gespeichert werden.

Prüfen Sie ausserdem Auftragsverarbeitung, Unterauftragnehmer, Löschfristen, Zugriffsrollen und Nachweise. Eine Zertifizierung des Plattformanbieters macht die eigene Anwendung nicht automatisch konform. Holen Sie bei rechtlich relevanten Fragen fachkundige Beratung ein.

Google Cloud dokumentiert Regionen und Zonen als auswählbare Standorte. Auch dort muss das Team prüfen, welche Dienste in der Zielregion verfügbar sind und welche Datenflüsse ein konkretes Produkt erzeugt.

Support und Betriebsfähigkeit

Ein grosser Dienstkatalog ersetzt kein Betriebsteam. Bei einer Störung müssen Verantwortliche wissen, welche Region, welcher Dienst und welche Fehlerdomäne betroffen ist. Statusseite und Supportfall sind nur Teile des Ablaufs.

Vergleichen Sie Reaktionswege, Sprache, Vertragszeiten und den Zugang zu Fachsupport. Ein regionaler Anbieter kann für ein KMU besser passen, wenn er eine klare Eskalation und betreuten Betrieb bietet. Ein Hyperscaler kann passender sein, wenn das Team die Plattform selbst automatisiert und beobachtet.

Für regionale Alternativen können Sie Hetzner, IONOS und OVHcloud prüfen. Die Verlinkung bedeutet nicht, dass diese Anbieter dasselbe Modell oder denselben Leistungsumfang haben.

Entscheidungskriterien

Stellen Sie vor der Auswahl eine kurze Matrix auf:

Kurzes Fazit

Ein Hyperscaler bietet standardisierte Cloud-Bausteine in grossem Umfang, vielen Regionen und mit breitem Serviceangebot. Er ist dann sinnvoll, wenn diese Eigenschaften ein belegtes Problem lösen und das Team Kosten, Betrieb und Exit beherrscht. Für andere Workloads kann eine regionale oder stärker betreute Plattform die bessere Entscheidung sein.