AKS oder Sovereign Kubernetes: die Entscheidung im Detail

Robin Werner, Head of Azure & Kubernetes bei Pexon Consulting | 10 Min. Lesezeit | 10.09.2026

TL;DR: AKS oder Sovereign Kubernetes kurz erklärt

Die Frage AKS oder Sovereign hängt nicht an der DSGVO – AKS läuft bei uns täglich konform. Sie hängt an sechs Achsen und einem harten Ausschluss. Pexon betreibt beide Wege im Kunden-RZ, ohne Flagge. Hybrid ist oft die tragfähige Antwort.

Was AKS wirklich ist – und was „managed“ dort bedeutet

AKS ist inzwischen selbst ein Buzzword geworden, so wie Container oder Kubernetes generell. Jeder möchte irgendwie ein AKS haben. Sortieren wir das.

AKS ist die Kubernetes-Lösung von Microsoft Azure. Laut der AKS-Produktdokumentation übernimmt Azure die Control Plane, die Node-Provisionierung und den Cluster-Aufbau. Alles Themen, um die Sie sich beim Eigenaufbau kümmern müssten.

Aber „managed“ steht hier in Anführungszeichen. Updates fahren Sie weiterhin selbst. Auto-Patch-Mechanismen und Skalierungslogik müssen konfiguriert werden und sind nicht so vollautomatisch, wie viele annehmen. Fire and forget ist AKS nicht.

Der eigentliche Vorteil liegt woanders: in der Integration. Wer bereits stark in Azure unterwegs ist, bindet Load Balancer, Azure WAF und vor allem Key Vault praktisch out of the box an. Das gesamte Secrets Management ist im Azure-Universum vorhanden und in einem AKS leicht anschließbar. Genau deshalb ist AKS oder Sovereign in den meisten Häusern keine Glaubensfrage, sondern eine Inventarfrage: Wo liegen Subscription, Identitäten und Secrets schon heute?

Was Azure Ihnen nicht abnimmt, ist der Teil, an dem Prüfungen später hängen: Policies, Netzwerk, Schlüssel, Dokumentation. Genau deshalb scheitern viele AKS-Projekte nicht am Cluster, sondern an der Landing Zone drumherum. Wer das unterschätzt, hat nach sechs Wochen ein laufendes Cluster und nach sechs Monaten eine Prüfungsliste.

Warum das Thema Souveränität gerade jetzt hochkommt

Wir sehen eine spürbare Welle von Kunden, die sich ein Stück weit von amerikanischen Unternehmen und Clouds lösen möchten – zurück in eine europäische Cloud oder in das eigene Rechenzentrum. Der Auslöser ist weniger technisch als politisch: die Beobachtung, dass sich Rahmenbedingungen jenseits des Atlantiks schneller ändern können, als Vertragslaufzeiten lang sind.

Und das ist eine sinnvolle Überlegung. Gerade wenn Sie die Vorteile der Public Cloud gar nicht wirklich brauchen – die Hyperskalierbarkeit, die breite Feature-Palette, die Azure sonst noch mitbringt -, lohnt sich der Blick auf ein selbst betriebenes Kubernetes oder auf einen deutschen Managed-Service-Anbieter.

Der Vorteil im eigenen Rechenzentrum ist Gestaltungsfreiheit. Sie legen fest, wie die Umgebung aussieht, und können sie dadurch auch ein Stück weit sicherer bauen, weil keine Vorgabe existiert, bestimmte Bausteine nutzen zu müssen. Bei AKS ist das anders: Dort nutzen Sie Azure-Techniken, weil es die Plattform so vorsieht.

Wir betreiben beide Wege – AKS ebenso wie ein eigenes, von uns betreutes Kubernetes im Rechenzentrum des Kunden. Was wir nicht tun: selbst hosten. Der Cluster bleibt in jedem Fall bei Ihnen.

Wer den technischen Pfad innerhalb von Azure braucht, also Region, Schlüssel und Nachweise statt eines eigenen RZs, findet den Aufbau in AKS und Sovereign Kubernetes DSGVO-konform. Dieser Text hier entscheidet davor: welcher Weg überhaupt trägt.

Die ehrliche Grenze: wann AKS oder Sovereign fällt

Hier braucht es eine klare Ansage, und wir machen sie regelmäßig gegen den eigenen Umsatz.

Wenn Ihre Unternehmens-Policy besagt, dass wirklich keine einzelne Datei in die USA gehen darf, dann fällt die Wahl AKS oder Sovereign eindeutig: AKS ist raus. Punkt. Das darf man sich auch nicht vormachen – dass sich das vollständig verhindern lässt, ist eine Annahme, die einer Prüfung nicht standhält. Wer in dieser Kategorie ist, baut souverän.

Häufig ist die Lage aber differenzierter. Wenn die Verschlüsselung ausreichend hoch ist, wenn Daten anonymisiert werden und die Policy-Werke so gezogen sind, dass die Gefahr eines Datenabflusses gering bleibt, dann ist AKS regulatorisch sehr gut machbar. Wir betreiben AKS für große Banken, Versicherungen und Energieversorger – DSGVO-konform, compliance-konform, mit Nachweisen in Richtung C5 und KRITIS.

Die Arbeit, die zählt, ist diese Grenze für Ihr Unternehmen ehrlich zu ziehen, bevor die Architektur steht. Nachträglich umzubauen kostet ein Vielfaches. Ein Satz in der Policy, der „keine Daten außerhalb der EU“ meint, ist etwas anderes als ein Satz, der „keine Daten, die ein US-Konzern theoretisch einsehen könnte“ meint. Beides klingt ähnlich. Beides führt auf verschiedene Plattformen.

Für regulierte Branchen, die AKS halten wollen, ist die Baseline nicht das Portal-Default. Was KRITIS- und BaFin-seitig zusätzlich sitzen muss, beschreiben wir unter AKS für regulierte Branchen.

AKS regulatorikkonform aufbauen: die Stellschrauben

Generell ist das gar nicht so schwer, wenn man von Anfang an die richtigen Hebel setzt.

Azure Policies. Azure bringt ein umfangreiches Policy-Werk mit. Damit lässt sich das Cluster direkt so aufsetzen, dass es regulatorikkonform ist – und, wichtiger, dass es das auch bleibt, wenn später jemand etwas deployt, das nicht passt. Policies sind der Unterschied zwischen einer einmalig korrekten und einer dauerhaft korrekten Umgebung.

Customer Managed Keys. Statt der plattformverwalteten Schlüssel übernehmen Sie die Schlüsselverwaltung selbst. Das ist der wirksamste einzelne Hebel für Datensouveränität innerhalb von Azure: Microsoft hat dann die Schlüssel nicht, um in Daten hineinsehen zu können – auch wenn jemand es wollte. Microsoft beschreibt den Mechanismus unter Customer-managed keys für AKS. Das lässt sich konsequent durch die gesamte Umgebung ziehen.

Anonymisierung. Daten, die in das Cluster hineinlaufen, lassen sich anonymisieren oder pseudonymisieren. Das ist weniger ein Kubernetes-Thema als eines der Applikation – gehört aber in dieselbe Architekturentscheidung, weil es die Bewertung des Restrisikos verschiebt.

Netzwerk und Secrets. Private Cluster, kontrollierte Egress-Pfade, Key Vault als zentrale Secrets-Instanz. Das sind Standardbausteine, die aber aktiv konfiguriert werden müssen.

Ohne Policy bleibt CMK eine Absicht. Mit Policy bleibt es eine Regel, auch wenn jemand später einen Node-Pool „schnell mal“ ohne Verschlüsselung anlegt:

# Illustrativ: Disks ohne Customer Managed Keys im Subscription-Scope blocken.
resource "azurerm_subscription_policy_assignment" "cmk_pflicht" {
  name                 = "aks-cmk-required"
  subscription_id      = data.azurerm_subscription.current.id
  policy_definition_id = azurerm_policy_definition.cmk_disks.id
  display_name         = "AKS: Customer Managed Keys Pflicht"

  identity {
    type = "SystemAssigned"
  }
}

Das Cluster selbst steht schnell. Was danach kommt, dauert: Policies schreiben, Netz und Secrets schließen, Nachweise so ablegen, dass ein Prüfer sie findet. Dieser Block fehlt in den meisten Zeitplänen.

Der Vorteil, den das eigene Rechenzentrum nicht hat

Ein Punkt wird in der Souveränitätsdiskussion regelmäßig unterschätzt: Ausfallsicherheit.

Azure bringt massive Kapazitäten und mehrere Rechenzentrumsstandorte mit – in Deutschland und in der EU. Daten an einem zweiten geografischen Ort abzulegen und einen Ausfall abzufangen, ist dort eine Konfigurationsentscheidung. Im eigenen Rechenzentrum ist es ein Investitionsprojekt.

Wer also souverän bauen will, sollte die Verfügbarkeitsanforderung genauso ernst nehmen wie die Datenschutzanforderung. Beide gegeneinander abzuwägen ist der eigentliche Kern der Entscheidung – nicht die Frage, welche Technologie sympathischer ist.

Ein zweites RZ, getestetes Restore und ein Wiederanlaufziel, das nicht nur auf der Folie steht, ändern die Rechnung. Viele Teams, die „wir müssen souverän“ sagen, haben gleichzeitig ein RTO, das ohne zweiten Standort nicht haltbar ist. Dann ist die ehrliche Antwort hybrid oder AKS mit harter Konfiguration, nicht ein einzelnes Rack im Keller.

Die Entscheidungsmatrix: AKS oder Sovereign Kubernetes

Wir arbeiten in Projekten mit einer Entscheidungs-Roadmap entlang von sechs Achsen:

1. Regulatorik – Welcher Rahmen gilt? Gibt es eine harte Ausschlussklausel?
2. Datenklassifikation – Wie sensibel sind die Daten wirklich, und lassen sie sich anonymisieren?
3. Skalierungsbedarf – Brauchen Sie Hyperscaler-Elastizität oder ein Cluster mit stabiler Last?
4. Kosten – Azure ist pro Ressource teurer, dafür fällt Betriebs- und Hardwareaufwand weg.
5. Geschwindigkeit – Wie schnell muss die Plattform stehen?
6. HA und Disaster Recovery – Welches Wiederanlaufziel gilt, und in wie vielen Regionen?

Aus diesen Achsen ergibt sich in der Praxis fast immer eine klare Empfehlung. Und häufig ist sie hybrid: sensible Workloads souverän, skalierende Workloads in Azure. AKS oder Sovereign als Entweder-oder ist die Ausnahme. Wir betreiben AKS, EKS, GKE, souveräne Setups und hybride Landschaften – die Kombination ist eher die Regel.

Die Achsen sind kein Scoring-Spiel, bei dem am Ende eine Zahl fällt. Sie sind ein Gespräch, das Sie führen sollten, bevor jemand ein Cluster bestellt. Wer nur Achse 1 betrachtet, landet oft im eigenen RZ und wundert sich später über Restore-Zeiten. Wer nur Achse 3 betrachtet, landet in Azure und wundert sich später über die Policy. Beide Überraschungen sind teurer als die Matrix vorher.

Ob Betrieb intern bleibt oder abgegeben wird, ist eine zweite, unabhängige Frage. Das Betriebsmodell – Eigenbetrieb gegen Partner – behandeln wir unter Managed Kubernetes vs. Self-Hosted. Die Plattformwahl AKS oder Sovereign Kubernetes kommt zuerst.

Häufig gestellte Fragen

Ist AKS DSGVO-konform?

AKS lässt sich DSGVO-konform betreiben, und wir tun das für regulierte Kunden regelmäßig – mit Standort Deutschland oder EU, Customer Managed Keys, Azure Policies und entsprechender Dokumentation. „Konform“ ist dabei kein Produktmerkmal, sondern das Ergebnis einer Konfiguration. Ein Standard-AKS aus dem Portal ist es nicht automatisch.

Was kostet ein souveränes Kubernetes im Vergleich zu AKS?

Das lässt sich nicht pauschal beantworten, weil die Kostenarten verschieden sind. AKS kostet laufend pro Ressource und ist im Vergleich zu anderen Anbietern eher teuer. Ein eigenes Cluster kostet Hardware, Rechenzentrum und Betriebsaufwand – dieser Aufwand ist der Posten, der in Kalkulationen am häufigsten zu niedrig angesetzt wird.

Können wir später von AKS auf ein eigenes Cluster wechseln?

Grundsätzlich ja, und wir begleiten solche Migrationen. Der Aufwand hängt davon ab, wie tief Sie azure-spezifische Dienste in die Applikationen gezogen haben. Wer von Anfang an weiß, dass ein Wechsel möglich sein soll, hält diese Kopplung bewusst flach – das ist eine Architekturentscheidung am ersten Tag, keine am letzten.

Reicht ein europäischer Cloud-Anbieter statt eigenem Rechenzentrum?

Für viele Fälle ja, und das ist oft der pragmatische Mittelweg: europäischer Anbieter oder deutscher Managed-Service-Provider statt vollständigem Eigenaufbau. Sie behalten Rechtsraum und Datenhoheit, ohne die Investition in eigene Hardware und eigenes Betriebspersonal.

Wo geht beim Aufbau eines regulatorikkonformen AKS die Zeit hin?

Nicht in den Cluster – der steht schnell. Landing Zone, Policy-Set, privates Netz und die Nachweise für den nächsten Audit fressen die Kalenderzeit. Wer nur den Cluster schätzt, liegt um Wochen daneben.

Nächster Schritt

Bevor Sie AKS oder Sovereign festnageln, lohnt ein Blick von außen. Mitbringen sollten Sie drei Dinge: die Regulatorik, die für Sie tatsächlich gilt (nicht die, von der man annimmt, dass sie gilt), eine Einschätzung Ihres Skalierungsbedarfs für die nächsten drei Jahre, und Ihre Wiederanlaufziele bei einem Ausfall.

Unabhängig davon, welche Infrastruktur Sie heute betreiben – AKS, EKS, GKE, on-prem oder gemischt – können Sie offen mit uns ins Gespräch gehen. Wir haben keine Flagge hinter uns.

Robin Werner und Philipp Pham diskutieren AKS oder Sovereign Kubernetes im Gespräch – inklusive der Frage, wann AKS ehrlicherweise ausscheidet. Video auf YouTube ansehen.

Verwandte Themen