Cluster Review vs Well-Architected: Verfahren 2026

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 12 Min. Lesezeit | 29.09.2026

TL;DR: Cluster Review vs. Well-Architected in fünf Sätzen

Kubernetes Cluster Review ist ein unabhängiges Prüfverfahren für bestehende Cluster, kein Hyperscaler-Well-Architected-Durchlauf und kein DIY-CIS-Scan. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) trennt die drei Verfahren nach Auftraggeber, Tiefe und Schicht. Die Cloud-Checkliste bewertet den Provider-Schnitt. CIS bewertet Controls. Der Review bewertet, ob Runtime, Policy, Daten und Restore wirklich sitzen.

Das Problem: Sie suchen ein Audit und landen in den Audit-Logs

Google liefert zu „Cluster prüfen“ Anleitungen, wie man Audit-Events schreibt. Das ist eine andere Frage als die nach dem richtigen Prüfverfahren für einen laufenden Cluster.

Drei Verfahren liegen auf dem Tisch. Das Team hat eine CIS-Liste. Azure oder AWS hat ein Well-Architected-Review im Kalender. Die Fachseite will wissen, ob der Cluster, den sie schon hat, tragfähig ist, ohne das Rechenzentrum umzuziehen.

Cluster Review vs. Well-Architected ist genau diese Gabel. Dieser Artikel ordnet die drei Verfahren ein, die einzelnen Prüfpunkte stehen in der Kubernetes Cluster Review Checkliste.

Bei Pexon Consulting beginnt der Weg mit einem 45-minütigen Cluster-Check. Das Review folgt, wenn die Frage nach den Schichten danach offen bleibt.

Was unterscheidet ein Cluster Review von einem Well-Architected-Review?

Die kurze Antwort: Auftrag und Schnitt.

Well-Architected (Azure, AWS, Google) bewertet den Cluster gegen die Säulen des Providers: Kosten, Betrieb, Sicherheit, Zuverlässigkeit, Leistung, oft Nachhaltigkeit. Es ist stark, wenn die Frage lautet: nutzen wir AKS oder EKS so, wie der Provider es meint? Es ist schwach, wenn die Frage lautet: welche Falco-Regel ist scharf, welches Barman-Ziel existiert, welche Policy-Zone gilt am zweiten Ingress.

Ein Cluster Review bewertet den bestehenden Cluster unabhängig vom Folien-Set des Hyperscalers. Es zählt Schichten: Control Plane, Admission, Scan, Runtime, Netz-Policy, Daten, Cluster-Backup, Restore-Fähigkeit als Prüffrage. Es verkauft kein Hosting.

Die offiziellen Frameworks der Anbieter: Azure Well-Architected, AWS Well-Architected.

Unsere Position: Well-Architected zuerst, wenn die Cloud schon feststeht und der Streit die Landing Zone ist. Review zuerst, wenn der Cluster schon läuft und niemand die Schichten besitzt. Beides hintereinander ist erlaubt. Beides als dasselbe Wort ist es nicht.

Wann reicht ein DIY-Audit mit CIS-Benchmark und Open-Source-Scannern?

Wenn das Team die Controls selbst tragen will und der Auftrag intern bleibt.

CIS Kubernetes Benchmark ist das übliche Raster. Die genaue Zahl der Controls hängt von der Version ab. Unsere Hardening-Checkliste bezog sich Mitte 2026 auf v1.10, maßgeblich ist die jeweils aktuelle Fassung des Center for Internet Security.

DIY funktioniert, wenn jemand die Findings schließt und jemand das nächste Quartal wiederholt. DIY scheitert, wenn der Scanner-Report in Confluence liegt und Runtime, Daten und Restore niemand anfasst.

Kyverno und der Trivy-Scanner sind Werkzeuge, kein Verfahren. Die Härtungs-Checkliste ist CIS/NIS2, kein unabhängiger Auftrag.

Wir raten davon ab, DIY als „wir haben ein Review“ an den Vorstand zu verkaufen. Es ist ein Scan. Scans sind nötig. Sie sind nicht unabhängig.

Wann brauchen Sie ein unabhängiges Review statt der Cloud-Checkliste?

Wenn der Cluster nicht in der Broschüre des Providers aufgeht.

On-Prem, Rancher-ähnlich, gemischte Ingress-Zonen, Postgres im Cluster, Velero ohne Drill: Well-Architected sieht davon den Teil, der an der Cloud-API hängt. Den Rest sieht es höflich nicht.

Unabhängig heißt: jemand, der den Cluster nicht gebaut hat, stellt die Schichtfrage. Das ist unbequem und deshalb der Grund, es zu beauftragen.

Wann die Cloud-Checkliste reicht: grüne Wiese auf AKS, Team klein, noch keine Stateful-Last, noch keine zweite Policy-Sprache. Dann ist Well-Architected billiger in der Diskussion und ehrlich genug.

Welche Schichten muss jedes Verfahren treffen – Control Plane, Policies, Daten, Restore-Fähigkeit?

Mindestens diese vier, sonst ist das Verfahren unvollständig.

1. Control Plane und Zugang: wer darf was an der API, welche Audit-Events existieren.
2. Policies: Admission getrennt von Runtime, Netz-Policy getrennt von Mesh-AuthZ.
3. Daten: Volume ist nicht PITR. Operator ist nicht Cloud-DB.
4. Restore-Fähigkeit: Gibt es einen Nachweis, dass die Wiederherstellung funktioniert?

Ein Review, das nur Nodes zählt, ist unvollständig. CNI und Policy, mehrere Eingänge, Kyverno getrennt von Falco, Trivy getrennt von Admission, Daten getrennt von Velero und etcd: das ist das Vergleichskriterium.

Wie hängt der 45-Minuten-Cluster-Check mit einem Festpreis-Review zusammen?

Der Check ist der Filter: 45 Minuten für den Cluster, den Sie schon haben, ohne Umzug des Rechenzentrums.

Das Review ist der Auftrag danach, wenn sich die Schichtfrage nicht in 45 Minuten klären lässt. Umfang und Festpreis stehen auf der Seite zum Kubernetes Cluster Review.

Das Review ist ein Projekt mit klarem Ende, kein laufender Betriebsvertrag.

So wählen Sie das Verfahren, ohne drei Aufträge zu vermischen

Cluster Review vs. Well-Architected wird teuer, wenn Sie alle drei Verfahren parallel beauftragen und dieselbe Finding dreimal hören. Besser eine Reihenfolge:

1. Frage klären: Geht es um Audit-Logs oder einen Pentest, ist ein anderes Verfahren gefragt. Geht es um die Tragfähigkeit des Clusters, weiter mit dem nächsten Punkt.
2. Cloud schon fest und Streit ist Landing Zone: Well-Architected zuerst.
3. Cluster läuft, Schichten unklar: Review. Einstieg 45 Minuten Check.
4. Team will selbst tragen: DIY-CIS, aber schriftlich, wer Findings schließt.
5. Restore immer mitprüfen: Gibt es einen geübten Nachweis?

Ein Review, das nur Nodes zählt, lassen wir nicht als Review stehen. Es muss Control Plane, Policy, Daten, Restore-Frage treffen. Falco, Kyverno, Trivy, Cilium Policy, Barman und Velero prüfen wir als Schichten, nicht als einzelne Werkzeuge.

Ein Well-Architected-Workshop, der drei Tage die Landing Zone durchdekliniert und den laufenden Cluster nur als Folie „Workload“ kennt, beantwortet die Provider-Frage. Er beantwortet nicht, ob falco-k8saudit Events liefert. Deshalb die Gabel, nicht die Wertung „besser“.

DIY mit Open-Source-Scannern gewinnt Tempo. Es verliert, sobald Findings niemand schließt. Wir haben Scans gesehen, die 400 Seiten PDF erzeugen und null Tickets. Das ist keine Prüfung, das ist ein Export.

Der 45-Minuten-Check filtert genau das: welche der drei Verfahren die offene Frage trifft. Ein Ausgang ist „CIS reicht, macht es selbst“. Ein anderer ist Well-Architected beim Provider. Der dritte ist das Review. Alle drei sind ehrlich. Der vierte Ausgang ist es nicht: drei Verfahren, eine Folie, kein Besitzer.

# Verfahren wählen, kein kubectl
diy     = Team schließt Findings selbst
wa      = Cloud steht fest, Landing Zone ist der Streit
review  = Cluster läuft, Schichten unklar

Das Raster hängt im Protokoll, nicht nur in diesem Artikel. Es verhindert den vierten Ausgang: drei Verfahren, eine Folie, und niemand, der die Findings schließt.

Häufig gestellte Fragen

Was kostet der Cluster-Check?

Der Cluster-Check ist ein 45-minütiges Einstiegsgespräch. Umfang und Preis des eigentlichen Reviews stehen auf der Seite zum Kubernetes Cluster Review.

Ist ein Cluster Review dasselbe wie ein Security-Audit?

Nein. Ein Audit kann Logs, einen Pentest oder eine Norm meinen. Das Review prüft die Schichten des bestehenden Clusters.

Cluster Review vs Well-Architected: können wir beides tun?

Ja, nacheinander. Zuerst klären, welches die offene Frage beantwortet. Parallel beide als dasselbe Arbeitspaket vermischt die Findings.

Reicht CIS allein für den Vorstand?

Kommt darauf an, aber selten. CIS ohne Runtime, Daten und Restore-Frage ist eine Teilliste. Für interne Verbesserung reicht sie oft. Für Unabhängigkeit nicht.

Ersetzt der Check das Review?

Nein. Der Check sortiert. Das Review prüft. Wer nur den Check will, bekommt 45 Minuten, keine Schichtkarte.

Nächster Schritt

Verwandte Themen