Regionale und spezialisierte Clouds erleben 2026 einen Aufschwung. Die Ökonomie der Hyperscaler, der Druck in Richtung Souveränität und die Marktdynamik nach der Broadcom-Übernahme haben Raum für Cloud-Produkte jenseits der Hyperscaler geschaffen, deren Start vor fünf Jahren noch keinen Sinn ergeben hätte. Sichtbare Beispiele sind souveräne Cloud-Produkte regionaler Anbieter in der EU, in Zentralasien und im MENA-Raum. Viele weitere befinden sich noch im Stealth-Modus oder in einem frühen Stadium.
Warum gerade jetzt
Drei voneinander unabhängige Entwicklungen begünstigen den Start neuer Cloud-Produkte:
Die Hyperscaler-Ökonomie trägt für manche Workloads nicht mehr. Dauerhafte Inference, Workloads mit hohem Egress und regulierte Workloads werden auf Hyperscalern im Vergleich zu dedizierter Infrastruktur immer teurer. Eine regionale Cloud, die genau diese Workloads bedient, hat Vorteile bei den Stückkosten.
Souveränität als Wettbewerbsvorteil. EU-Mitgliedstaaten, Kasachstan und mehrere Rechtsräume im APAC-Raum haben ausdrückliche Vorgaben für souveräne Clouds. Regionale Anbieter, die diese Vorgaben erfüllen, verfügen über einen regulatorischen Burggraben, zu dem Hyperscaler keinen Zugang haben.
Umbruch am Virtualisierungsmarkt nach Broadcom. Workloads, die im Zuge des VMware-Ausstiegs umziehen, müssen irgendwo landen; regionale Anbieter können einen Teil davon aufnehmen, sofern sie das richtige Produkt liefern.
Die sechs Schichten eines Cloud-Produkts
Ein funktionierendes Cloud-Produkt für Endkunden besteht aus sechs Schichten, und jede davon erfordert Engineering:
1. Hardware
Compute-Server, Storage, Netzwerk-Fabric, Rechenzentrum / Colocation. Dimensioniert für die erste Kundenkohorte plus Reserven für Wachstum.
2. Plattform
Eine mandantenfähige, Kubernetes-native Plattform mit KubeVirt für VMs, Cilium und Kube-OVN für das Networking sowie LINSTOR (per DRBD replizierter Block Storage) für Storage. Cozystack ist die Open-Source-Standardlösung für dieses Muster.
3. Servicekatalog
Was Kunden selbst bereitstellen können: VMs, K8s-Cluster, verwaltete Datenbanken (PostgreSQL, MariaDB, MongoDB, Redis, Valkey, Kafka, ClickHouse, OpenSearch usw.), S3-Buckets, GPU-Instanzen, Netzwerk-Grundbausteine.
4. Kundenportal
Self-Service-Oberfläche (Cozystack Dashboard oder eine Eigenentwicklung). Katalog durchsuchen, Ressourcen bereitstellen, Monitoring, Transparenz über die Abrechnung.
5. Abrechnung
Produktionsreife WHMCS-Integration in zwei Modi — von Ænix als WHMCS-Integration ausgeliefert und nicht als Teil des Open-Source-Projekts Cozystack. Individuelle Abrechnungslösungen für bestimmte Märkte.
6. Betrieb
NOC rund um die Uhr, Kundensupport, SLA-Management, Observability pro Tenant, Incident Response.
Architekturentscheidungen, die für Public-Cloud-Produkte spezifisch sind
Ein Public-Cloud-Produkt unterscheidet sich architektonisch in mehreren Punkten von einer internen Plattform:
Die Mandantentrennung muss strikt sein. Kunden vertrauen einander nicht, und regulatorische Audits finden tatsächlich statt. Das Tenant-CRD-Muster mit starker Isolation ist notwendig, nicht optional.
Der Self-Service muss ausgereift sein. Interne Plattformen können „Fragen Sie das Plattform-Team“ als Notausgang haben. Produkte für Endkunden können das nicht.
Die Abrechnung muss vom ersten Tag an stimmen. Kunden werden die erste Rechnung anfechten; das System muss dieses Gespräch tragen können.
Observability für Kunden, nicht nur für den Betrieb. Kunden wollen ihre eigenen Metriken sehen, nicht nur SLA-Daten.
Die Compliance-Ausrichtung ist das Produkt. Souveränität, Datenresidenz und Audit-Fähigkeit sind Differenzierungsmerkmale, keine nachträglichen Ergänzungen.
Reihenfolge beim Markteintritt
Starten Sie in Kohorten:
- Beta mit 3–5 wohlgesonnenen Kunden — beheben Sie die Ecken und Kanten, bevor zahlende Kunden sie zu sehen bekommen.
- Eingeschränkte GA mit 10–50 Kunden — lernen Sie die Muster bei Abrechnung und Support im kleinen Maßstab kennen.
- General Availability — Öffnung für den breiten Markt.
- Spezialisierte Erweiterung — ergänzen Sie gezielte Services (weitere GPU-Klassen, AI-Services usw.) auf Basis der beobachteten Nachfrage.
Zeitrahmen: Die Plattform selbst ist mit dem produktisierten Installer wenige Wochen nach Bereitstellung der Hardware live. Wie schnell danach die General Availability folgt, bestimmen Beta, eingeschränkte GA und Ihre Bereitschaft in Vertrieb und Betrieb. Programme im Betreibermaßstab mit mehreren Regionen rechnen mit 3–6 Monaten Pilot und danach 9–18 Monaten bis zum vollen Multi-Region-Betrieb.
Woran der Markteintritt scheitert
Stolperstein 1: unzureichend ausgebaute Mandantenfähigkeit
„Die richtige Isolation bauen wir in v2 ein.“ Kunde Nr. 1 findet die Lücke; von dem Reputationsschaden erholt man sich nur schwer.
Stolperstein 2: Abrechnung als Nachgedanke
Die Abrechnungsintegration kommt im letzten Monat vor dem Launch. Sie funktioniert nicht, Kunden zahlen nicht, und das Eintreiben der Umsätze wird zum Projekt über mehrere Quartale.
Stolperstein 3: zu geringe Investition in den Betrieb
Die Plattform steht, das Betriebsteam ist für 50 Kunden ausgelegt — und im ersten Quartal unterschreiben 200. Die Servicequalität bricht ein.
Stolperstein 4: Hyperscaler-Architektur eins zu eins kopieren
Für Hyperscaler-Maßstab entworfen, für die tatsächliche Kundenzahl überdimensioniert. Die betriebliche Komplexität übersteigt den Umsatz.
Stolperstein 5: austauschbares Standardangebot
Ein generisches Cloud-Produkt ohne Abgrenzung zum Hyperscaler. Kunden greifen dann standardmäßig zu AWS / Azure / GCP. Spezialisierung, Souveränität und Regionalität zählen als Unterscheidungsmerkmal.
Das Ænix-Engagement
Ænix hat Cloud-Produkte für Endkunden durchgängig auf Cozystack aufgebaut, für Hosting-Anbieter und regionale Cloud-Betreiber. Aufbau des Engagements:
- Platform Readiness Assessment (14 oder 28 Tage, Festpreis) — inklusive Produktreife
- Aufbau — Plattform über den Installer in Wochen live; danach Portal, Abrechnung, Betriebsabläufe und Onboarding der ersten Kohorte (im Betreibermaßstab: 3–6 Monate Pilot, dann 9–18 Monate bis zum vollen Multi-Region-Betrieb)
- Phase 3 (optional) — Managed Services während der Hochlaufphase
Details finden Sie auf der Seite zu unseren Public-Cloud-Builder-Services.
