DEV Community: Aleksei Aleinikov

Kubernetes Autoscaling: Drei Controller, die nicht miteinander reden

Aleksei Aleinikov — Wed, 26 Aug 2026 10:00:00 +0000

Die meisten Teams installieren alle drei Kubernetes-Autoscaler und nehmen an, daraus ergebe sich ein System. Tut es nicht. HPA, VPA und der Node-Autoscaler sind drei unabhängige Controller ohne gemeinsamen Zustand und ohne Abstimmungsprotokoll.

Was sie teilen, ist ein Input: Resource Requests. Jeder von ihnen liest Requests, um zu entscheiden. Keiner liest, was Ihre Anwendung tatsächlich verbraucht — außer indirekt. Sind die Requests falsch, degradieren alle drei gleichzeitig. Leise, ohne ein einziges Fehler-Event.

Dies ist eine Tour durch die Mechanik, die wirklich darüber entscheidet, ob Ihr Cluster skaliert oder nur flattert.

Drei Controller, drei Objekte, ein gemeinsamer Input und null Koordination.

Was jede Ebene tatsächlich ändert

	Ändert	Lebt in	Liest
HPA	Replica-Anzahl	Kubernetes-Kern-API	Metrics API, Requests
VPA	CPU-/Memory-Requests	Add-on-CRD	Metrics API, Historie, OOM-Events
Node-Autoscaler	Anzahl Maschinen	Add-on + Cloud-API	Ausstehende Pods, Requests

Nur HPA gehört zum Lieferumfang von Kubernetes. VPA ist eine separate Installation mit drei eigenen Komponenten. Node-Autoscaling braucht eine Cloud-Anbieter-Integration. Diese Asymmetrie zählt bei der Fehlersuche: Zwei der drei haben Sie selbst hinzugefügt.

HPA: Die Formel ist einfacher als gedacht

Der Controller läuft in einer Schleife — standardmäßig alle 15 Sekunden — und rechnet:

desiredReplicas = ceil[currentReplicas × ( currentMetricValue / desiredMetricValue )]

Das ist die ganze Idee. Aktueller Wert doppelt so hoch wie das Ziel? Doppelte Replica-Zahl. Halb so hoch? Halbieren.

Drei Eigenschaften dieser Formel verursachen die meisten Überraschungen im Betrieb.

Auslastung wird gegen Requests gemessen, nicht gegen Limits. Mit averageUtilization: 60 sagen Sie: „Halte den Durchschnittsverbrauch bei 60% dessen, was die Pods angefordert haben.“ Der Request ist der Nenner. Deshalb sind Requests kein bloßer Scheduling-Hinweis — sie sind die Kalibrierung Ihres Autoscalers.

Kleine Änderungen werden übersprungen. Liegt das Verhältnis nahe genug bei 1,0, passiert nichts. Die Standardtoleranz beträgt clusterweit 10%. Ein Workload bei 105% seines Ziels skaliert nicht — und kein Event erklärt die Untätigkeit. Kubernetes 1.35 hat ein tolerance-Feld pro HPA als Beta ergänzt, sodass Sie es für einen einzelnen Workload verschärfen können:


behavior:

  scaleUp:

    tolerance: 0.05

Vorher ging das nur über das Flag --horizontal-pod-autoscaler-tolerance am Controller Manager — mit Wirkung auf jeden Workload im Cluster.

Bei mehreren Metriken gewinnt das Maximum. Geben Sie CPU, Memory und eine eigene Queue-Metrik an, berechnet HPA aus jeder eine gewünschte Replica-Zahl und nimmt die größte. Ein ODER, keine Mischung. Eine zusätzliche Metrik kann Ihren Workload nur vergrößern.

Der stille Fehler: kein Request, kein Autoscaling

Das ist die häufigste Ursache für ein totes HPA und verdient einen eigenen Abschnitt — wegen der Art, wie es scheitert.

Fehlt einem Container im Pod der relevante Resource Request, ist die CPU-Auslastung für diesen Pod undefiniert, und der Autoscaler unternimmt für diese Metrik nichts.

Kein Fehler. Kein Warn-Event. kubectl get hpa zeigt das Objekt an. In der Spalte TARGETS steht <unknown> — leicht zu lesen als „sammelt noch Metriken“ statt als „dauerhaft kaputt“.

Die Behebung ist trivial, sobald man es weiß. Das Herausfinden ist der teure Teil:

Terminal window


kubectl get hpa -A -o custom-columns=\

NS:.metadata.namespace,NAME:.metadata.name,TARGETS:.status.currentMetrics

Was nach einigen Minuten keine aktuellen Metriken zeigt, wärmt sich nicht auf. Es ist falsch konfiguriert.

Der zweite stille Fehler: Ihr Sidecar verwässert das Signal

HPA summiert den Ressourcenverbrauch über alle Container im Pod. Die Dokumentation weist ausdrücklich darauf hin, dass dies den Verbrauch einzelner Container nicht abbildet — ein Container kann heißlaufen, während der Pod-Durchschnitt entspannt aussieht und HPA nie hochskaliert.

Service Meshes und Logging-Sidecars machen das zum Regelfall. Ein Anwendungscontainer bei 95% seines Requests, gepaart mit einem untätigen Sidecar bei 5%, ergibt einen unauffälligen Durchschnitt.

Seit Kubernetes 1.30 gibt es dafür eine stabile Lösung — auf einen benannten Container skalieren statt auf den Pod:


metrics:

  - type: ContainerResource

    containerResource:

      name: cpu

      container: application

      target:

        type: Utilization

        averageUtilization: 60

Eine Feinheit: Benennen Sie diesen Container um, müssen Sie das HPA vor dem Rollout auf beide Namen einstellen — sonst wird die Empfehlung mitten im Rollout blind.

Schnell hoch, langsam runter — mit Absicht

Das Standardverhalten ist bewusst asymmetrisch, und Missverständnisse darüber produzieren viele falsche Fehlermeldungen.

	Stabilisierungsfenster	Ratenbegrenzung
Hochskalieren	0 Sekunden	100% der Replicas oder 4 Pods je 15s, je nachdem was größer ist
Herunterskalieren	300 Sekunden	100% je 15s, nach dem Fenster

Hochskalieren erfolgt sofort. Beim Herunterskalieren betrachtet der Algorithmus alle Empfehlungen der letzten fünf Minuten und nimmt die höchste — ein gleitendes Maximum, das verhindert, dass Pods entfernt werden, die kurz darauf wieder gebraucht würden.

Wenn also jemand meldet, „das HPA skaliert nicht herunter“, arbeitet es meist exakt wie entworfen und die Person schaut auf ein Fünf-Minuten-Fenster. Wenn Sie es wirklich schneller brauchen:


behavior:

  scaleDown:

    stabilizationWindowSeconds: 60

    policies:

      - type: Percent

        value: 10

        periodSeconds: 60

Auch im Deployment lauert eine Falle. Behalten Sie spec.replicas in einem Manifest, das ein HPA verwaltet, setzt jedes kubectl apply die Zahl auf den Wert aus der Datei zurück — und das HPA zieht sie wieder hin. Genau dieser Kampf sieht auf dem Dashboard wie Flattern aus. Entfernen Sie das Feld, sobald das HPA den Workload besitzt.

VPA: anderes Problem, andere Fehlerart

Der VerticalPodAutoscaler beantwortet eine Frage, die HPA nicht kann: Wie groß sollte jeder Pod sein? Er besteht aus drei Komponenten — einem Recommender , der Verbrauchshistorie, Spitzen und OOM-Events auswertet, einem Updater , der Änderungen anwendet, und einem Admission-Controller-Webhook , der die empfohlenen Requests in neue Pods injiziert.

Der Update-Modus ist die eigentliche Entscheidung:

Modus	Verhalten
`Off`	Nur empfehlen. Nichts wird angewendet.
`Initial`	Requests bei Pod-Erstellung setzen, danach nie wieder.
`Recreate`	Pods evakuieren, wenn Requests von der Empfehlung abweichen.
`InPlaceOrRecreate`	Wenn möglich in-place ändern, sonst evakuieren.
`InPlace`	In-place ändern, nie evakuieren — stattdessen aufschieben und erneut versuchen.
`Auto`	Seit VPA 1.4.0 veraltet. Alias für `Recreate`.

Beginnen Sie mit Off. Das ist für sich genommen wertvoll: Der Recommender schreibt Zielwert, untere und obere Schranke nach .status.recommendation — ein kostenloses Rightsizing-Audit ohne Produktionsrisiko.

Die große Änderung 2026 — und ein Widerspruch in der Doku

Jahrelang lautete der ehrliche Einwand gegen VPA, vertikales Skalieren bedeute, den Pod zu töten. In-Place Pod Resize ist seit Kubernetes 1.35 stable und standardmäßig aktiv. CPU und Memory eines laufenden Containers lassen sich jetzt ändern:

Terminal window


kubectl patch pod my-pod --subresource resize --patch \

  '{"spec":{"containers":[{"name":"app",

     "resources":{"requests":{"cpu":"800m"},"limits":{"cpu":"800m"}}}]}}'

Eine Policy je Ressource steuert, ob ein Neustart nötig ist — bei Memory meist ja, weil die wenigsten Runtimes ihren Heap spontan verkleinern:


resizePolicy:

  - resourceName: cpu

    restartPolicy: NotRequired # Standard

  - resourceName: memory

    restartPolicy: RestartContainer

Hier muss ich etwas kennzeichnen. Die Kubernetes-Dokumentation widerspricht sich, ob VPA das nutzen kann. Die Autoscaling-Übersichtsseite hält fest, VPA unterstütze In-Place-Resizing ab 1.36 nicht. Die VPA-Seite dokumentiert InPlaceOrRecreate und InPlace vollständig und vermerkt, InPlace sei Alpha in VPA 1.7.0 und erfordere Kubernetes 1.33+ mit dem Gate InPlacePodVerticalScaling sowie InPlace-Gates auf Updater und Admission Controller.

Die VPA-Seite wurde später überarbeitet, die Übersicht ist also vermutlich veraltet. Auflösen ließ sich das aus der Doku allein nicht — prüfen Sie Ihre installierte VPA-Version und testen Sie außerhalb der Produktion, bevor Sie jemandem neustartfreies Rightsizing versprechen.

Unabhängig vom Modus wichtig: Ein Resize kann die QoS-Klasse des Pods nicht ändern. Ein Guaranteed-Pod muss danach weiter Requests gleich Limits haben. Ein Burstable-Pod kann nicht zu Guaranteed werden. Windows-Pods werden gar nicht unterstützt. Passt ein Resize nicht auf den Node, erhält der Pod die Condition PodResizePending mit reason: Infeasible — darauf sollten Sie alarmieren, denn sonst sagt es Ihnen nichts.

Warum HPA und VPA sich in die Quere kommen

Setzen Sie beide auf CPU an und folgen Sie der Arithmetik.

HPA berechnet die Auslastung als Verbrauch / Request. Die gesamte Aufgabe von VPA ist es, Request zu ändern.

VPA beobachtet niedrigen Verbrauch und senkt den Request.
Dieselbe unveränderte Anwendung zeigt nun deutlich höhere Auslastung — der Nenner ist geschrumpft.
HPA sieht die Auslastung über dem Ziel und fügt Replicas hinzu.
Die Last verteilt sich auf mehr Pods, der Verbrauch pro Pod sinkt.
VPA beobachtet niedrigen Verbrauch und senkt den Request erneut.

Kein Controller ist defekt. Beide bewegen Zähler und Nenner desselben Bruchs, ohne voneinander zu wissen.

Kombinationen, die in der Praxis funktionieren:

VPA auf Memory, HPA auf CPU. Verschiedene Ressourcen, kein gemeinsamer Bruch. Die verbreitetste Paarung.
VPA im Modus Off. Empfehlungen gehen an einen Menschen oder eine Pipeline, nicht an den laufenden Workload.
VPA per controlledResources eingegrenzt , sodass es die Ressource von HPA nie anfasst:


resourcePolicy:

  containerPolicies:

    - containerName: "application"

      controlledResources: ["memory"]

      controlledValues: RequestsOnly

controlledValues: RequestsOnly verdient eine Anmerkung. Der Standard ist RequestsAndLimits — dabei skaliert das Limit proportional mit, um Ihr Verhältnis von Request zu Limit zu wahren. Haben Sie bewusst einen großen Abstand für Burst-Reserven gesetzt, wandert dieser Abstand mit. Das kann genau richtig sein — oder Ihre Limits still weit über das Gewollte hinauswachsen lassen.

Nichts ist kaputt. Beide Controller bearbeiten korrekt gegenüberliegende Hälften desselben Bruchs.

Die Node-Ebene: Provisioning und Konsolidierung

Unter beiden Pod-Autoscalern sitzt der Node-Autoscaler, der zwei Dinge tut, welche die Kubernetes-Doku inzwischen ausdrücklich benennt:

Provisioning — Nodes hinzufügen, damit ausstehende Pods geplant werden können. Früher Scale-up.
Konsolidierung — unterausgelastete Nodes entfernen. Früher Scale-down.

Zwei Implementierungen werden von der SIG Autoscaling getragen, und der Unterschied liegt nicht wirklich in der Skalierungsqualität:

	Cluster Autoscaler	Karpenter
Node-Typen	Vorab konfigurierte Node-Gruppen	Aus Constraints automatisch bestimmt
Umfang	Nur Node-Autoscaling	Kompletter Node-Lebenszyklus
Erneuerung / Upgrade	Nein	Ja — Nodes werden nach fester Laufzeit neu erstellt
Cloud-Anbieter	Viele, auch kleinere	Wenige — AWS, Azure
Auslieferung	Integrationen im Kubernetes-Projekt	Als Bibliothek für Anbieter veröffentlicht

Cluster Autoscaler fragt: „Welche meiner konfigurierten Gruppen passt zu diesen ausstehenden Pods?“ Karpenter fragt: „Welche Maschine sollte für diese Pods existieren?“ — und übernimmt anschließend auch die Verantwortung, sie wieder außer Dienst zu stellen.

Der dritte stille Fehler: Konsolidierung ignoriert die reale Nutzung

Dieser kostet am meisten Geld und folgt direkt aus dem gemeinsamen Input.

Konsolidierung berücksichtigt wie Provisioning ausschließlich die Resource Requests der Pods — nicht die reale Nutzung.

Ein Node, dessen Pods 90% der Kapazität anfordern und tatsächlich 5% verbrauchen, ist für den Autoscaler ein voll belegter Node. Er wird nie zurückgegeben. Ihre Dashboards zeigen ein nahezu untätiges Cluster, Ihre Rechnung ein volles, und kein Controller meldet dazu etwas — aus Sicht des Schedulers ist ja alles in Ordnung.

Deshalb ist Rightsizing eine Voraussetzung für Kosteneffizienz auf Node-Ebene und keine spätere Zusatzoptimierung. Die Kubernetes-Doku sagt es deutlich: Requests korrekt zu setzen ist für die Kosteneffizienz genauso wichtig wie die Node-Auslastung selbst.

Eine verwandte Warnung: Setzen Sie VPA nicht auf DaemonSet-Pods ein, wenn Sie Node-Autoscaling nutzen. Der Autoscaler muss vorhersagen, was DaemonSet-Pods auf einem hypothetischen neuen Node verbrauchen werden, um dessen nutzbare Kapazität zu schätzen. Ein VPA, das diese Requests laufend ändert, macht die Vorhersage unzuverlässig — und falsche Vorhersagen ergeben falsche Skalierungsentscheidungen.

Wo KEDA hineinpasst

HPA skaliert auf Ressourcenauslastung, ein nachlaufendes Signal — die CPU steigt erst, wenn Arbeit bereits angekommen ist und sich staut. Für queue-getriebene Workloads ist das die falsche Richtung.

KEDA, ein CNCF-graduiertes Projekt, skaliert auf die Ereignisquelle selbst: Nachrichten in einer Queue, Lag auf einem Topic, wartende Zeilen. Es deckt auch den Fall ab, den CPU gar nicht ausdrücken kann — auf null skalieren, wenn die Queue leer ist. Der Cron-Scaler übernimmt geplantes Skalieren, die ehrliche Antwort für vorhersehbare Tagesmuster, bei denen Reagieren schlechter ist als Wissen.

KEDA ersetzt HPA nicht. Es erzeugt und steuert eines.

Eine funktionierende Reihenfolge

Requests bewusst setzen. Alles andere liest sie. Raten korrumpiert hier alle drei Ebenen gleichzeitig.
VPA im Modus Off installieren und eine Woche beobachten lassen. Vergleichen Sie .status.recommendation mit dem, was Sie angefordert haben. Die Lücke ist Ihr reales Rightsizing-Potenzial.
Requests korrigieren auf Basis dieser Daten — von Hand oder über die Pipeline. Node-Konsolidierung beginnt zu wirken, sobald Requests die Realität abbilden.
HPA ergänzen auf der Metrik, die Ihre Last abbildet. Bei Sidecars ContainerResource verwenden.
HPA und VPA von derselben Ressource fernhalten. Memory-VPA mit CPU-HPA ist die sichere Standardpaarung.
Node-Autoscaling zuletzt aktivieren. Es verstärkt, was Ihre Requests aussagen — zutreffend oder nicht.
Auf PodResizePending mit reason: Infeasible alarmieren , wenn Sie In-Place-Resize nutzen, und auf HPA ScalingActive: false. Beides sind sonst stille Fehler.

Der Punkt

„Kubernetes-Autoscaling einschalten“ gibt es nicht. Es gibt drei Controller an drei verschiedenen Objekten, die sich über nichts abstimmen außer über die Resource Requests, die Sie geschrieben haben.

Jede Fehlerart in diesem Artikel führt auf dieselbe Wurzel zurück: Ein Controller hat einen Request gelesen, ihm geglaubt und korrekt auf schlechter Information gehandelt. HPA skaliert nicht, weil ein Request fehlt. HPA flattert, weil VPA den Request darunter verändert. Nodes konsolidieren nie, weil Requests ein Cluster beschreiben, das es nicht gibt.

Autoscaling macht die Dimensionierung nicht zum Problem von jemand anderem. Es macht sie zum einzigen Problem.

Weiterlesen: Zur Ebene, in der diese Controller laufen, siehe Platform Engineering auf Kubernetes. Wenn Sie zuerst eine Distribution wählen, siehe k3s vs k0s vs MicroK8s vs RKE2. Zum Abwägen zwischen verwaltet und selbstverwaltet auf GKE siehe GKE Autopilot vs Standard. Um durchzusetzen, dass Requests überhaupt gesetzt sind, siehe OPA vs Kyverno.

Quellen: Horizontal Pod Autoscaling, Vertical Pod Autoscaling (überarbeitet am 31. Mai 2026), Autoscaling Workloads, Node Autoscaling und Resize CPU and Memory Resources assigned to Containers, sämtlich Kubernetes-Dokumentation, CC BY 4.0.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Kubernetes Autoscaling: Three Controllers That Do Not Talk to Each Other

Aleksei Aleinikov — Wed, 26 Aug 2026 10:00:00 +0000

Most teams install all three Kubernetes autoscalers and assume they add up to a system. They do not. HPA, VPA and the node autoscaler are three independent controllers with no shared state and no negotiation protocol.

What they do share is an input: resource requests. Every one of them reads requests to make decisions. None of them read what your application actually uses, except indirectly. Get requests wrong and all three degrade at once — quietly, without a single error event.

This is a tour of the mechanics that actually decide whether your cluster scales or just thrashes.

Three controllers, three different objects, one shared input and zero coordination.

What Each Layer Actually Changes

	Changes	Lives in	Reads
HPA	Replica count	Core Kubernetes API	Metrics API, requests
VPA	CPU/memory requests	Add-on CRD	Metrics API, history, OOM events
Node autoscaler	Number of machines	Add-on + cloud API	Pending Pods, requests

The HPA is the only one that ships with Kubernetes. VPA is a separate install with three of its own components. Node autoscaling requires a cloud provider integration. That asymmetry matters when you are debugging: two of the three are things you added.

HPA: The Formula Is Simpler Than You Think

The controller runs on a loop — every 15 seconds by default — and computes:

desiredReplicas = ceil[currentReplicas × ( currentMetricValue / desiredMetricValue )]

That is the whole idea. Current metric double the target? Double the replicas. Half the target? Halve them.

Three things about this formula cause most production surprises.

Utilization is measured against requests, not limits. When you set averageUtilization: 60, you are saying “keep average usage at 60% of what the Pods requested.” The request is the denominator. This is why requests are not just a scheduling hint — they are the calibration of your autoscaler.

The controller skips small changes. If the ratio is close enough to 1.0 it does nothing. The default tolerance is 10%, cluster-wide. A workload sitting at 105% of its target will not scale, and there is no event explaining the inaction. Kubernetes 1.35 added a per-HPA tolerance field in beta, so you can now tighten it for one workload:


behavior:

  scaleUp:

    tolerance: 0.05

Before that, changing it meant a --horizontal-pod-autoscaler-tolerance flag on the controller manager, affecting every workload in the cluster.

Multiple metrics take the maximum. Specify CPU and memory and a custom queue-depth metric, and the HPA computes a desired replica count from each and picks the largest. It is an OR, not a blend. Adding a metric can only make your workload bigger.

The Silent Failure: No Request, No Autoscaling

This is the single most common broken-HPA cause, and it deserves its own section because of how it fails.

If a container in the Pod does not have the relevant resource request set, CPU utilization for that Pod is undefined, and the autoscaler takes no action for that metric.

No error. No warning event. kubectl get hpa shows the object exists. The TARGETS column shows <unknown>, which is easy to read as “still gathering metrics” rather than “permanently broken.”

The fix is trivial once you know. Finding out is the expensive part:

Terminal window


kubectl get hpa -A -o custom-columns=\

NS:.metadata.namespace,NAME:.metadata.name,TARGETS:.status.currentMetrics

Anything showing no current metrics after a few minutes is not warming up. It is misconfigured.

The Second Silent Failure: Your Sidecar Is Diluting the Signal

HPA sums resource usage across all containers in the Pod. The docs are explicit that this may not represent individual container usage — a single container can run hot while the Pod average stays comfortable, and the HPA never scales out.

Service meshes and logging sidecars make this routine. An application container at 95% of its request paired with an idle sidecar at 5% averages to something that looks fine.

Since Kubernetes 1.30 there is a stable fix — scale on one named container instead of the Pod:


metrics:

  - type: ContainerResource

    containerResource:

      name: cpu

      container: application

      target:

        type: Utilization

        averageUtilization: 60

One caveat worth knowing: if you rename that container, update the HPA to track both names before rolling out the workload change, otherwise the recommendation goes blind mid-rollout.

Scale Up Fast, Scale Down Slow — On Purpose

The default behaviour is deliberately asymmetric, and misreading it produces a lot of false bug reports.

	Stabilization window	Rate limit
Scale up	0 seconds	100% of replicas or 4 Pods per 15s, whichever is larger
Scale down	300 seconds	100% per 15s, after the window

Scale-up is immediate. Scale-down looks at all recommendations from the past five minutes and takes the highest one — a rolling maximum that stops the autoscaler from removing Pods it will need again moments later.

So when someone reports “the HPA is not scaling down,” the answer is usually that it is working exactly as designed and they are watching a five-minute window. If you genuinely need it faster:


behavior:

  scaleDown:

    stabilizationWindowSeconds: 60

    policies:

      - type: Percent

        value: 10

        periodSeconds: 60

There is also a trap in how you deploy. If you keep spec.replicas in a manifest that an HPA is managing, every kubectl apply resets the count to whatever is in the file — and the HPA pulls it back. That fight is what thrashing looks like on a dashboard. Remove the field from the manifest once the HPA owns the workload.

VPA: Different Problem, Different Failure Mode

The VerticalPodAutoscaler answers a question HPA cannot: how big should each Pod be? It runs three components — a recommender that analyses usage history, peaks and OOM events, an updater that applies changes, and an admission controller webhook that injects the recommended requests into new Pods.

The update mode is the whole decision:

Mode	Behaviour
`Off`	Recommend only. Nothing is applied.
`Initial`	Set requests at Pod creation, never again.
`Recreate`	Evict Pods when requests drift from recommendation.
`InPlaceOrRecreate`	Resize in place if possible, evict if not.
`InPlace`	Resize in place, never evict — defer and retry instead.
`Auto`	Deprecated since VPA 1.4.0. Alias for `Recreate`.

Start at Off. It is genuinely useful on its own: the recommender writes a target, a lower bound and an upper bound into .status.recommendation, which is a free rightsizing audit with no production risk.

The Big 2026 Change — and a Documentation Contradiction

For years the honest objection to VPA was that vertical scaling meant killing the Pod. In-place Pod resize reached stable in Kubernetes 1.35 and is enabled by default. You can now change CPU and memory on a running container:

Terminal window


kubectl patch pod my-pod --subresource resize --patch \

  '{"spec":{"containers":[{"name":"app",

     "resources":{"requests":{"cpu":"800m"},"limits":{"cpu":"800m"}}}]}}'

Per-resource policy controls whether a restart is needed — and memory usually still needs one, because most runtimes cannot shrink their heap on demand:


resizePolicy:

  - resourceName: cpu

    restartPolicy: NotRequired # default

  - resourceName: memory

    restartPolicy: RestartContainer

Here I have to flag something. The Kubernetes documentation contradicts itself on whether VPA can use this. The autoscaling overview page states that as of 1.36 VPA does not support resizing Pods in place. The VPA page documents InPlaceOrRecreate and InPlace in full, noting InPlace is alpha in VPA 1.7.0 and needs Kubernetes 1.33+ with the InPlacePodVerticalScaling gate plus InPlace gates on the VPA updater and admission controller.

The VPA page was revised more recently, so the overview is most likely stale. But I could not resolve this from the docs alone, and neither can you — check your installed VPA version and test in a non-production cluster before promising anyone restart-free rightsizing.

Worth knowing regardless of mode: a resize cannot change the Pod’s QoS class. A Guaranteed Pod must keep requests equal to limits after the resize. A Burstable Pod cannot become Guaranteed. Windows Pods are not supported at all. If a resize does not fit the node, the Pod gets a PodResizePending condition with reason: Infeasible — a condition to alert on, because nothing else will tell you.

Why HPA and VPA Fight

Now put the two together on CPU and follow the arithmetic.

HPA computes utilization as usage / request. VPA’s entire job is to change request.

VPA observes low usage and lowers the request.
The same unchanged application now shows much higher utilization — the denominator shrank.
HPA sees utilization above target and adds replicas.
Load spreads across more Pods, so per-Pod usage drops.
VPA observes low usage and lowers the request again.

Neither controller is malfunctioning. They are moving the numerator and denominator of the same fraction with no knowledge of each other.

Combinations that work in practice:

VPA on memory, HPA on CPU. Different resources, no shared fraction. The most common production pairing.
VPA in Off mode. Recommendations feed a human or a pipeline, not the live workload.
VPA scoped with controlledResources so it never touches the resource HPA scales on:


resourcePolicy:

  containerPolicies:

    - containerName: "application"

      controlledResources: ["memory"]

      controlledValues: RequestsOnly

controlledValues: RequestsOnly is worth calling out. The default is RequestsAndLimits, which scales the limit proportionally to preserve your request-to-limit ratio. If you have deliberately set a wide gap between request and limit for burst headroom, the default will maintain that gap as it moves — which may be exactly what you want, or may quietly grow your limits far beyond what you intended.

Nothing is broken. Both controllers are correctly editing opposite halves of the same fraction.

The Node Layer: Provisioning and Consolidation

Underneath both Pod-level autoscalers sits the node autoscaler, which does two things the Kubernetes docs now name explicitly:

Provisioning — add nodes so pending Pods can schedule. Formerly called scale-up.
Consolidation — remove underutilised nodes. Formerly called scale-down.

Two implementations are sponsored by SIG Autoscaling, and the difference is not really about scaling quality:

	Cluster Autoscaler	Karpenter
Node shapes	Pre-configured node groups	Auto-provisioned from constraints
Scope	Node autoscaling only	Full node lifecycle
Node refresh / upgrade	No	Yes — recreates nodes after a set lifetime
Cloud providers	Many, including smaller ones	Fewer — AWS, Azure
Delivery	Integrations in the Kubernetes project	Published as a library providers integrate

Cluster Autoscaler asks “which of my configured groups fits these pending Pods?” Karpenter asks “what machine should exist for these pending Pods?” — and then also takes responsibility for retiring that machine later.

The Third Silent Failure: Consolidation Ignores Real Usage

This one costs the most money, and it follows directly from the shared-input problem.

Consolidation, like provisioning, considers only Pod resource requests — not real resource usage.

A node whose Pods request 90% of capacity and actually consume 5% is, to the autoscaler, a fully packed node. It will never be reclaimed. Your dashboards show a nearly idle cluster, your invoice shows a full one, and no controller emits an event about it, because from the scheduler’s point of view nothing is wrong.

This is why rightsizing is a prerequisite for node-level cost efficiency rather than a separate optimisation you get to later. The Kubernetes docs say it plainly: setting requests correctly matters as much to cost-effectiveness as node utilisation does.

One related caution: do not run VPA on DaemonSet Pods when using node autoscaling. The autoscaler has to predict what DaemonSet Pods will consume on a hypothetical new node in order to estimate its usable capacity. A VPA that keeps changing those requests makes the prediction unreliable, and wrong predictions produce wrong scaling decisions.

Where KEDA Fits

HPA scales on resource utilization, which is a lagging signal — CPU rises only after work has already arrived and started queueing. For queue-driven workloads, that is backwards.

KEDA, a CNCF-graduated project, scales on the event source itself: messages in a queue, lag on a topic, rows pending. It also handles the case CPU cannot express at all — scaling to zero when the queue is empty. Its Cron scaler covers scheduled scaling, which is the honest answer for predictable daily traffic patterns where reacting is strictly worse than knowing.

KEDA does not replace HPA. It creates and drives one.

A Working Order of Operations

Set requests deliberately. Everything else reads them. Guessing here corrupts all three layers at once.
Install VPA in Off mode and let it observe for a week. Compare .status.recommendation against what you actually requested. The gap is your real rightsizing opportunity.
Fix requests based on that data — by hand or through your pipeline. Node consolidation starts working the moment requests reflect reality.
Add HPA on the metric that reflects your load. Use ContainerResource if the Pod has sidecars.
Keep HPA and VPA off the same resource. Memory-VPA with CPU-HPA is the default safe pairing.
Enable node autoscaling last. It amplifies whatever your requests already say — accurate or not.
Alert on PodResizePending with reason: Infeasible if you use in-place resize, and on HPA ScalingActive: false. Both are silent failures otherwise.

The Point

There is no such thing as “turning on Kubernetes autoscaling.” There are three controllers operating on three different objects, coordinating through nothing but the resource requests you wrote.

Every failure mode in this article traces back to the same root: a controller read a request, believed it, and acted correctly on bad information. HPA does not scale because a request is missing. HPA thrashes because VPA is editing the request underneath it. Nodes never consolidate because requests describe a cluster that does not exist.

Autoscaling does not make resource sizing someone else’s problem. It makes it the only problem.

Related reading: for the layer these controllers run inside, see platform engineering on Kubernetes. If you are choosing a distribution first, see k3s vs k0s vs MicroK8s vs RKE2. For the managed-versus-self-managed trade-off on GKE, see GKE Autopilot vs Standard. To enforce that requests are actually set, see OPA vs Kyverno.

Sources: Horizontal Pod Autoscaling, Vertical Pod Autoscaling (revised 31 May 2026), Autoscaling Workloads, Node Autoscaling and Resize CPU and Memory Resources assigned to Containers, all Kubernetes documentation, CC BY 4.0.

Originally published at alekseialeinikov.com

Was wirklich in eine Landing Zone gehört — und was ohne Grund hineingeschoben wird

Aleksei Aleinikov — Tue, 25 Aug 2026 12:00:00 +0000

Fragen Sie fünf Ingenieure, was eine Landing Zone ist, und Sie bekommen fünf Inventarlisten. Eine enthält die CI/CD-Pipeline. Eine den Monitoring-Stack. Eine besteht darauf, dass nichts fertig ist, solange die FinOps-Dashboards nicht laufen.

Die Anbieter helfen wenig weiter. Azure dokumentiert acht Design-Bereiche, Google nennt vier Kernelemente, und AWS definiert den Begriff in einem einzigen Satz, der das Netzwerk komplett auslässt.

Alle beschreiben etwas Reales. Nur nicht dasselbe.

Die brauchbare Definition ist keine Komponentenliste, sondern diese: Eine Landing Zone ist die Menge der Entscheidungen, die Sie nicht mehr zurücknehmen können, sobald Workloads darauf laufen. Alles andere ist ein Roadmap-Punkt, der zum Blocker befördert wurde.

Azure, AWS und Google Landing Zones sind sich beim Kern einig

Das interessante Indiz: Unabhängig entstandene Frameworks mit unterschiedlicher Terminologie und unterschiedlichen Produkten kommen inhaltlich am selben Punkt heraus.

Google nennt vier Kernelemente, die für eine Landing Zone entworfen werden müssen: Identitätsbereitstellung, Ressourcenhierarchie, Netzwerk und Sicherheitskontrollen.

Microsofts Cloud Adoption Framework teilt Azure Landing Zones in acht Design-Bereiche in zwei Gruppen. Umgebungsbereiche: Azure-Abrechnung und Tenant, Identitäts- und Zugriffsverwaltung, Ressourcenorganisation, Netzwerktopologie und Konnektivität. Compliance-Bereiche: Sicherheit, Management, Governance sowie Plattformautomatisierung und DevOps.

AWS definiert eine Landing Zone als gut architektierte Multi-Account-Umgebung auf Basis von Sicherheits- und Compliance-Best-Practices — als unternehmensweiten Container für Ihre Organisationseinheiten, Konten, Benutzer und weiteren Ressourcen.

Acht gegen vier gegen einen Satz sieht nach Uneinigkeit aus. Stellt man sie nebeneinander, ist es keine:

Substanz	Google	Microsoft	AWS
Wer Sie sind	Identitätsbereitstellung	Identitäts- und Zugriffsverwaltung	IAM-Identity-Center-Verzeichnis
Wie Ressourcen angeordnet sind	Ressourcenhierarchie	Ressourcenorganisation	Organizations-OUs, Account Factory
Wie Pakete fließen	Netzwerk	Netzwerktopologie und Konnektivität	nicht Teil der Definition
Was erzwungen wird	Sicherheitskontrollen	Sicherheit, Governance	Controls: preventive, detective, proactive
Wie es ausgerollt wird	(Best Practice: IaC + GitOps)	Plattformautomatisierung und DevOps	Account Factory, CloudFormation StackSets
Wie es betrieben wird	(zusätzliches Element)	Management	Dashboard, Drift-Erkennung
Kaufmännischer Rahmen	(Voraussetzung: Organisation + Abrechnungskonto)	Abrechnung und Tenant	Management-Konto, Organizations

Microsoft erhebt zu erstklassigen Bereichen, was Google unter Voraussetzungen und Best Practices ablegt. Das ist eine Dokumentationsentscheidung, keine architektonische Meinungsverschiedenheit.

AWS ist der wirklich abweichende Fall, und der lohnt einen Moment.

Die AWS Landing Zone hat einen anderen Zuschnitt

AWS fasst den Begriff enger als die beiden anderen. Eine Control-Tower-Landing-Zone liefert Ihnen einen Root, eine Security-OU mit den Konten Log Archive und Audit, optional eine Sandbox-OU, ein IAM-Identity-Center-Verzeichnis und einen Satz Controls, die organisationsweit greifen. Das Netzwerk steht nicht auf dieser Liste. Kein Adressplan, kein Konnektivitätsdesign, kein Segmentierungsmodell — das bleibt Ihre Aufgabe und läuft separat.

Diese Asymmetrie hat eine praktische Folge: Eine zwischen Clouds kopierte Landing-Zone-Checkliste führt in die Irre. Wer als Azure-Architekt einem AWS-Team „die Landing-Zone-Anforderungen“ übergibt, überspezifiziert Konten und unterspezifiziert VPCs. Umgekehrt gilt dasselbe.

Der zweite Unterschied ist die Zeitangabe. AWS nennt für Control Tower weniger als eine Stunde. Google sagt, Entwurf und Bereitstellung könnten mehrere Wochen dauern. Beides stimmt, weil Verschiedenes gemessen wird: Control Tower rollt eine fertige Meinung aus, während Googles Leitfaden den Prozess beschreibt, sich eine eigene zu bilden. Passt die Meinung von AWS zu Ihrer Organisation, haben Sie den teuren Teil legitim übersprungen. Passt sie nicht, ist die eingesparte Stunde nicht die relevante Zahl.

Und Tempo kauft keine Umkehrbarkeit. Die AWS-Dokumentation ist da erfreulich direkt:

these cannot be renamed later, and existing accounts cannot be added for security and logging after initial launch

Eine Entscheidung über Namen und Einbindung der geteilten Konten, getroffen in der ersten Stunde, mit der Sie dauerhaft leben. Dem Umkehrbarkeitstest ist gleichgültig, wie schnell das Deployment war.

Vier Entscheidungen, die man einmal trifft, und eine Schicht, die man jahrelang ergänzt.

Es gibt keine Standard-Landing-Zone, und Google sagt das selbst

Bevor Sie irgendeine Landing-Zone-Checkliste übernehmen, lesen Sie diesen Satz aus Googles Architecture Center:

The diagram above is only an example, because there is no single or standard implementation of a landing zone.

Das Design hängt ab von Branche, Organisationsstruktur, Sicherheits- und Compliance-Anforderungen, den zu migrierenden Workloads, der vorhandenen Infrastruktur sowie dem Standort von Unternehmen und Kunden.

Das ist auch kaufmännisch relevant. Wenn ein Partner oder ein Blogbeitrag die Landing Zone als festes Lieferobjekt präsentiert, verkauft man Ihnen eine Meinung mit Preisschild. Manchmal ist diese Meinung ausgezeichnet und der Kauf richtig. Aber Sie sollten wissen, dass Sie eine Meinung kaufen und keine Spezifikation.

Der eigentliche Test: Lässt sich das später ändern?

Hier ist der Filter, der die Diskussion sortiert. Fragen Sie zu jedem Kandidaten: Was kostet die Korrektur, wenn Workloads bereits laufen?

Besteht den Test nicht — vor dem ersten Workload entscheiden

Ressourcenhierarchie. Ihre Struktur aus Organisation, Ordnern und Projekten bestimmt, wo Richtlinien greifen und wo Budgets zusammenlaufen. Projekte zwischen Ordnern zu verschieben ist möglich; eine Hierarchie unter laufenden Workloads neu zu bauen, während IAM und Organisationsrichtlinien daraus erben, ist ein Projekt, für das sich niemand meldet.

Netz-Adressraum. Die CIDR-Vergabe ist die klassische unumkehrbare Entscheidung. Überlappende Bereiche tauchen Jahre später auf, bei einer Übernahme oder einer Partneranbindung, und die Korrektur heißt Umadressierung der Produktion. Planen Sie auch für Regionen, die Sie noch nicht eröffnet haben.

Identitätsdomäne und Föderation. Welches Verzeichnis maßgeblich ist, wie es synchronisiert, wie der Vertrauenspfad aussieht. Alles Weitere in Ihrem Sicherheitsmodell erbt daraus.

Sicherheitsgrenzen. Wo die Grenzen tatsächlich verlaufen — VPC-Service-Controls-Perimeter in Googles Beispielarchitektur, Netzsegmentierung, der Zuschnitt Ihrer Shared VPC. Sie bestimmen, was später überhaupt ausdrückbar ist.

Besteht den Test — ergänzen, wenn nötig

Google listet diese ausdrücklich als Elemente jenseits des Kerns, zu ergänzen nach Geschäftsanforderung:

Monitoring und Logging
Backup und Disaster Recovery
Compliance-Werkzeuge
Kosteneffizienz und -kontrolle
API-Management
Cluster-Management

Keines davon zwingt Sie, irgendetwas neu zu bauen. Sie werden die meisten wollen, einige dringend. Das ist eine andere Aussage als „das Fundament ist ohne sie nicht fertig“.

Der am häufigsten überdimensionierte Punkt jedes Fundamentprojekts

Dieser Punkt verdient einen eigenen Abschnitt, weil Googles Dokumentation etwas sagt, das die meisten Fundamentprojekte nicht glauben wollen:

if your first workload does not require access to on-premises network resources, you could build connectivity to your on-premises environment later.

Hybride Konnektivität — Interconnect, Direct Connect, ExpressRoute, der VPN-Rückfall, das Routing-Design, die Firewall-Change-Requests, die Warteschlange des Netzwerkteams — ist regelmäßig der längste Balken im Plan. Und sie ist für den ersten Workload häufig unnötig, weil dieser oft ein neuer, cloud-nativer, internetseitiger Dienst ist, der mit nichts im Rechenzentrum spricht.

Sie nach dem ersten Deployment einzuplanen macht sie nicht optional. Es macht sie parallel statt blockierend.

Die Reihenfolge zählt mehr als die Inventarliste. Am falschen Punkt zu blockieren kostet Monate.

Modular heißt: Die erste Version ist absichtlich falsch

Googles Empfehlung enthält ein Eingeständnis, das zitiert gehört, weil es dem üblichen Projektzuschnitt widerspricht:

because a landing zone is modular, your first iteration of a landing zone is often not your final version.

Und die praktische Anweisung dazu: das Anfangsdesign auf die Elemente ausrichten, die für die Migration der ersten Workloads nötig sind, und weitere Elemente später ergänzen.

Vergleichen Sie das mit dem typischen Fundamentprogramm, das vollständig sein will, bevor irgendetwas läuft. Diese Programme überziehen — Google merkt an, die Bereitstellung könne „mehrere Wochen“ dauern und Projektmanagement sei unerlässlich, was in Dokumentationssprache das verschiebt sich heißt — und liegen am Ende trotzdem daneben, weil jede Anforderung darin ohne echten Workload erraten wurde.

Teams, die das gut machen, liefern ein bewusst unvollständiges Fundament, setzen einen echten Workload darauf und lassen diesen Workload sagen, was die zweite Iteration braucht.

Wenn eine Landing Zone nicht reicht

Gut zu wissen, bevor Sie ein einziges Design für einen sperrigen Workload verbiegen: Google unterstützt ausdrücklich mehr als eine Landing Zone , wenn einzelne Workloads sehr abweichende Skalierungs- oder Compliance-Anforderungen haben.

Teilbar: Identitäten, Abrechnung, Organisationsressource. Typischerweise unterschiedlich: Netzwerkaufbau, Deployment-Mechanismen, Richtlinien auf Ordnerebene.

Wenn ein regulierter Workload das gesamte Design verformt, ist eine zweite Landing Zone womöglich günstiger als der Kompromiss. Sie kostet dauerhaft — also treffen Sie die Entscheidung bewusst.

Was tatsächlich schiefgeht

Muster, die es zu benennen lohnt, weil sie Quartale kosten und nicht Sprints:

Auf hybride Konnektivität warten , die der erste Workload gar nicht nutzt. Der häufigste Terminkiller.
Adressplanung verschieben , weil „wir starten ja nur in einer Region“. Die Rechnung kommt bei der Übernahme, der Partneranbindung oder der zweiten Region.
Die Pipeline für das Fundament halten. IaC und GitOps sind eine technische Best Practice für den Rollout der Landing Zone — wirklich wichtig, aber nicht dasselbe wie eine unumkehrbare Entscheidung.
Für erdachte Workloads bauen. Ohne echten Dienst erratene Anforderungen sind Vermutungen mit einem Terraform-Modul daran.
Eine Landing-Zone-Checkliste zwischen Clouds kopieren. Azure und Google zählen das Netzwerk zum Kern, AWS lässt es aus der Definition heraus. Ein zwischen Anbietern portiertes Anforderungsdokument überspezifiziert die eine Hälfte und lässt die andere still unter den Tisch fallen.
„Wir wollen das“ mit „ohne das können wir nicht starten“ verwechseln. Monitoring ist essenziell. Und an einem Dienstag ergänzbar.
Das falsche Team. Googles Empfehlung verlangt Sicherheit, Identität, Netzwerk und Betrieb in einem Raum, mit einer Leitung, die die Plattform kennt. Eine nur vom Netzwerkteam entworfene Landing Zone sieht auch genau so aus.

Landing-Zone-Checkliste: acht Fragen vor dem Bau

Schreiben Sie Ihre vier auf: Identitätsquelle, Ressourcenhierarchie, Adressplan, Sicherheitsgrenzen. Fehlt eine, haben Sie noch kein Fundament.
Fragen Sie zu jedem weiteren Element, was es kostet, es in sechs Monaten zu ergänzen. Lautet die Antwort „wenig“, gehört es vom kritischen Pfad.
Prüfen Sie, ob Ihr erster Workload wirklich Zugriff aufs Rechenzentrum braucht. Wenn nicht, entkoppeln Sie das Konnektivitätsprojekt.
Planen Sie Adressraum für Regionen, die noch nicht offen sind. Jetzt kostenlos, später teuer.
Auf AWS: Entscheiden Sie Namen und Einbindung der geteilten Konten vor dem Start — das ist dokumentiert dauerhaft — und planen Sie das Netzwerk separat, denn Control Tower nimmt Ihnen das nicht ab.
Rollen Sie es als Code mit Pipeline aus — Googles eigene Best Practice — aber lassen Sie den Pipeline-Bau nicht zum Fundamentprojekt werden.
Wählen Sie einen echten ersten Workload, bevor das Design fertig ist. Er findet die Lücken, die Ihr Dokument nicht kennt.
Verformt ein Workload alles, kalkulieren Sie stattdessen eine zweite Landing Zone.

Der Punkt

Eine Landing Zone ist kein Produkt, keine Checkliste und kein Partnerprojekt. Googles Dokumentation sagt unmissverständlich, dass es keine standardisierte Umsetzung gibt und die erste Version nicht die letzte sein soll. AWS baut Ihnen eine in einer Stunde — und händigt Ihnen dabei Entscheidungen aus, die es selbst als dauerhaft bezeichnet.

Was sie tatsächlich ist: vier Entscheidungen, deren Rücknahme teuer ist, plus eine modulare Schicht, die Sie erweitern, solange die Plattform existiert. Ihre Anforderungen in diese beiden Töpfe zu sortieren, ist der größte Teil der Architekturarbeit — und die Projekte, die scheitern, sind fast immer die, die etwas Aufschiebbares auf den kritischen Pfad und etwas Dauerhaftes ins Backlog gelegt haben.

Weiterlesen: Für die Schicht darüber siehe Platform Engineering auf Kubernetes und die Secure-by-Default-GKE-Referenzarchitektur. Zur Identitätsentscheidung in der Praxis siehe Service-Account-Schlüssel abschaffen. Zum Resilienz-Element siehe Backups sind kein Disaster Recovery.

Quellen: Landing zone design in Google Cloud (zuletzt geprüft am 2. Januar 2026), Azure landing zone design areas (Cloud Adoption Framework, aktualisiert Dezember 2025) sowie What is AWS Control Tower und How AWS Control Tower works.

Ursprünglich veröffentlicht auf alekseialeinikov.com

What Actually Belongs in a Landing Zone — and What Gets Pushed Into One for No Reason

Aleksei Aleinikov — Tue, 25 Aug 2026 12:00:00 +0000

Ask five engineers what a landing zone is and you will get five inventories. Someone will include the CI/CD pipeline. Someone will include the monitoring stack. Someone will insist it is not done until the FinOps dashboards are live.

The vendors are not much help either. Azure documents eight design areas, Google names four core elements, and AWS defines the term in a single sentence that leaves out networking entirely.

They are all describing something real. They are not describing the same thing.

The useful definition is not a list of components. It is this: a landing zone is the set of decisions you cannot reverse once workloads are running on top of them. Everything else is a roadmap item that got promoted into a blocker.

Azure, AWS and Google Landing Zones Agree on the Core

The interesting evidence is that frameworks built independently, with different terminology and different products, land on the same substance.

Google names four core elements you must design for a landing zone: identity provisioning, resource hierarchy, network, and security controls.

Microsoft’s Cloud Adoption Framework splits Azure landing zones into eight design areas across two groups. The environment areas: Azure billing and tenant, identity and access management, resource organisation, network topology and connectivity. The compliance areas: security, management, governance, and platform automation and DevOps.

AWS defines a landing zone as a well-architected, multi-account environment based on security and compliance best practices — the enterprise-wide container that holds your organizational units, accounts, users and other resources.

Eight versus four versus one sentence looks like disagreement. Line them up and it is not:

Substance	Google	Microsoft	AWS
Who you are	Identity provisioning	Identity and access management	IAM Identity Center directory
How resources are arranged	Resource hierarchy	Resource organisation	Organizations OUs, Account Factory
How packets move	Network	Network topology and connectivity	Outside the definition
What is enforced	Security controls	Security, Governance	Controls: preventive, detective, proactive
How it gets deployed	(Best practice: IaC + GitOps)	Platform automation and DevOps	Account Factory, CloudFormation StackSets
How it is run	(Additional element)	Management	Dashboard, drift detection
Commercial setup	(Prerequisite: org + billing account)	Billing and tenant	Management account, Organizations

Microsoft promotes to first-class status what Google files under prerequisites and best practices. That is a documentation choice, not an architectural disagreement.

AWS is the genuinely different one, and it is worth pausing on.

The AWS Landing Zone Is a Different Shape

AWS scopes the word more narrowly than the other two. A Control Tower landing zone gives you a root, a Security OU containing Log Archive and Audit accounts, an optional Sandbox OU, an IAM Identity Center directory, and a set of controls applied across the organisation. Networking is not in that list. There is no address plan, no connectivity design, no segmentation model — those remain your problem, handled separately.

That asymmetry has a practical consequence: a landing zone checklist copied from one cloud to another will mislead you. An Azure architect handing an AWS team “the landing zone requirements” will over-specify accounts and under-specify VPCs. It runs the other way too.

The second difference is the timeline claim. AWS says Control Tower builds a landing zone in less than an hour. Google says designing and deploying one can take multiple weeks. Both are accurate, because they are measuring different things: Control Tower deploys a pre-made opinion, while Google’s guidance describes the process of forming your own. If AWS’s opinion fits your organisation, you have skipped the expensive part legitimately. If it does not, the hour you saved is not the relevant number.

And speed does not buy reversibility. AWS’s own documentation is refreshingly blunt about it:

these cannot be renamed later, and existing accounts cannot be added for security and logging after initial launch

That is a shared-account naming and enrolment decision, made in the first hour, that you live with permanently. The reversibility test does not care how fast the deployment was.

Four decisions you make once, and a layer you can keep adding to for years.

There Is No Standard Landing Zone, and Google Says So

Before accepting anyone’s landing zone checklist, read this line from Google’s architecture centre:

The diagram above is only an example, because there is no single or standard implementation of a landing zone.

The design depends on your industry, your organisational structure, your security and compliance requirements, the workloads you are moving, your existing infrastructure and where your business and customers are.

This matters commercially. If a partner or a blog post presents the landing zone as a fixed deliverable, what you are being sold is an opinion with a price attached. Sometimes that opinion is excellent and buying it is the right call. But you should know you are buying an opinion, not a specification.

The Real Test: Can You Change It Later?

Here is the filter that sorts the argument. For each candidate element, ask: if we get this wrong, what does fixing it cost after workloads are live?

Fails the test — decide before the first workload

Resource hierarchy. Your organisation, folder and project structure determines where policy attaches and where budgets aggregate. Moving projects between folders is possible; rebuilding a hierarchy under running workloads while IAM and org policies inherit from it is a project nobody volunteers for.

Network address space. CIDR allocation is the classic irreversible decision. Overlapping ranges surface years later when you acquire a company or connect a partner network, and the fix is re-addressing production. Decide the plan even for regions you have not opened yet.

Identity domain and federation. Which directory is authoritative, how it synchronises, what the trust path looks like. Everything else in your security model inherits from this.

Security perimeters. Where the boundaries actually sit — VPC Service Controls perimeters in Google’s example architecture, network segmentation, the shape of your Shared VPC. These define what is even expressible later.

Passes the test — add it when you need it

Google lists these explicitly as elements beyond the core, to be added according to business requirements:

Monitoring and logging
Backup and disaster recovery
Compliance tooling
Cost efficiency and control
API management
Cluster management

None of these require you to rebuild anything to introduce. You will want most of them, some of them urgently. That is a different statement from “the foundation is not finished without them.”

The Most Over-Scoped Item on Every Foundation Project

This one deserves its own section, because Google’s documentation says something most foundation projects refuse to believe:

if your first workload does not require access to on-premises network resources, you could build connectivity to your on-premises environment later.

Hybrid connectivity — Interconnect, Direct Connect, ExpressRoute, the VPN fallback, the routing design, the firewall change requests, the network team’s queue — is routinely the longest pole in the tent. It is also frequently unnecessary for the first workload, which is often a new, cloud-native, internet-facing service that talks to nothing in the data centre.

Sequencing it after the first deployment does not make it optional. It makes it parallel instead of blocking.

The order matters more than the inventory. Blocking on the wrong item costs months.

Modular Means Your First Version Is Wrong on Purpose

Google’s guidance contains an admission worth quoting because it contradicts how these projects are usually run:

because a landing zone is modular, your first iteration of a landing zone is often not your final version.

And the practical instruction that follows: centre the initial design on the elements required to migrate your first workloads, and plan to add other elements later.

Compare that with the typical foundation programme, which sets out to be complete before anything runs. Those programmes overrun — Google notes deployment “can take multiple weeks” and that project management is essential, which is documentation-speak for this slips — and they are still wrong at the end, because every requirement in them was guessed at without a real workload to test against.

The teams that do this well ship a deliberately incomplete foundation, put one real workload on it, and let that workload tell them what the second iteration needs.

When One Landing Zone Is Not Enough

Worth knowing before you contort a single design to satisfy one awkward workload: Google explicitly supports running more than one landing zone when some workloads have very different scalability or compliance requirements.

What can be shared across them: identities, billing, and the organisation resource. What typically differs: network setup, deployment mechanisms, folder-level policies.

If you have one regulated workload bending the entire design out of shape, a second landing zone may be cheaper than the compromise. It is a real ongoing cost, so make it a decision rather than an accident.

What Actually Goes Wrong

Patterns worth naming, because they cost quarters, not sprints:

Blocking on hybrid connectivity that the first workload does not use. The single most common schedule killer.
Deferring address planning because “we’ll only use one region at first.” The bill arrives at the acquisition, or the partner integration, or the second region.
Treating the pipeline as foundation. IaC and GitOps are a technical best practice for deploying the landing zone — genuinely important, and not the same as a decision you cannot reverse.
Building for imagined workloads. Requirements guessed without a real service are guesses with a Terraform module attached.
Copying a landing zone checklist between clouds. Azure and Google put the network in the core; AWS leaves it out of the definition. A requirements document ported across vendors over-specifies one half and silently drops the other.
Confusing “we want this” with “we cannot start without this.” Monitoring is essential. It is also addable on a Tuesday.
Assembling the wrong team. Google’s guidance calls for security, identity, network and operations in one room with a lead who knows the platform. A landing zone designed only by the network team looks exactly like one.

Landing Zone Checklist: Seven Questions Before You Build

Write down your four: identity source, resource hierarchy, address plan, security boundaries. If any is undecided, you do not have a foundation yet.
For every other proposed element, ask what it costs to add in six months. If the answer is “not much,” take it off the critical path.
Check whether your first workload actually needs on-premises access. If not, decouple the connectivity project.
Plan address space for regions you have not opened. It is free now and expensive later.
If you are on AWS, decide the shared-account names and enrolment before launch — that one is documented as permanent — and plan the network separately, because Control Tower will not do it for you.
Deploy it as code with a pipeline — Google’s own best practice — but do not let building the pipeline become the foundation project.
Pick a real first workload before finishing the design. It will find the gaps your document cannot.
If one workload is distorting everything, price a second landing zone instead.

The Point

A landing zone is not a product, a checklist, or a partner engagement. Google’s documentation says outright there is no standard implementation, and that the first version is not meant to be the last. AWS will build you one in an hour and still hand you decisions it tells you are permanent.

What it actually is: four decisions that are expensive to unwind, plus a modular layer you will extend for as long as the platform exists. Sorting your requirements into those two buckets is most of the architecture work — and the projects that fail are almost always the ones that put a deferrable item on the critical path and a permanent one in the backlog.

Related reading: for the layer that sits on top, see platform engineering on Kubernetes and the secure-by-default GKE reference architecture. For the identity decision in practice, see killing service account keys with Workload Identity Federation. For the resilience element, see backups are not disaster recovery.

Sources: Landing zone design in Google Cloud (last reviewed 2 January 2026), Azure landing zone design areas (Cloud Adoption Framework, updated December 2025), and What is AWS Control Tower plus How AWS Control Tower works.

Originally published at alekseialeinikov.com

Wazuh vs Microsoft Sentinel vs Google SecOps: Das SIEM, das Sie wählen, ist die Rechnung, die Sie bekommen

Aleksei Aleinikov — Mon, 24 Aug 2026 12:00:00 +0000

Die meisten SIEM-Vergleiche sind Feature-Tabellen. Sie sind auch nutzlos, weil die Funktionen konvergieren und die Preismodelle nicht.

Wazuh, Microsoft Sentinel und Google SecOps nehmen alle Logs auf, erkennen alle Bedrohungen und stehen alle im Zentrum eines Security-Operations-Workflows. Was sie trennt, ist, was jedes von ihnen zählt — und diese Wahl entscheidet still darüber, was Ihr Team zu loggen bereit ist, und damit, was Sie um drei Uhr nachts untersuchen können.

Hier sind die drei Zähler, aus der Anbieterdokumentation, geprüft im August 2026.

Sentinel zählt Ihre Gigabyte

Microsoft Sentinel rechnet nach dem aufgenommenen Datenvolumen ab, bepreist nach der Stufe, in der die Daten landen.

Die Analytics-Stufe kennt zwei Modi:

Pay-as-you-go — der Standard, basierend auf dem gespeicherten Datenvolumen. Microsoft misst ein GB hier als 10⁹ Bytes; anders als bei S3 sind das dezimale Gigabyte.
Commitment Tiers — vorab gekaufte Kapazität ab 100 GB pro Tag zu einem vergünstigten effektiven Satz. Nutzung darüber hinaus wird zum selben effektiven Satz berechnet, nicht zum Pay-as-you-go-Preis.

Die ersten 90 Tage Aufbewahrung sind enthalten. Danach zahlen Sie die Log-Analytics-Preise.

Ein Vorbehalt zu den Zahlen in diesem Artikel: Microsoft hält die tatsächlichen Preise pro GB auf der Preisseite und im Kostenrechner fest, nicht in der Abrechnungsdokumentation, und sie variieren nach Region und Commitment Tier. Dokumentiert ist — und architektonisch entscheidend — die Struktur weiter unten. Für den für Sie geltenden Satz rechnen Sie Ihr Volumen durch den Sentinel-Kostenrechner.

Neu ist zudem eine Data-Lake-Stufe , die vier Dinge getrennt misst: Aufnahme, Verarbeitung, Speicherung und Abfragen. Der Speicherwert wird mit einer festen Kompressionsrate von 6:1 berechnet — 600 GB Rohdaten werden als 100 GB abgerechnet. Abfragen dagegen kosten pro GB unkomprimiert gescannter Daten. Beide Angaben stehen in der Doku nebeneinander und werden beim Schätzen leicht verwechselt.

Eine wirklich nützliche Menge an Quellen ist kostenlos: Azure-Activity-Logs, Sentinel Health, Office-365-Audit-Logs für SharePoint, Exchange und Teams sowie Sicherheitswarnungen der Defender-Familie. Der Vorbehalt ist scharf — die Warnungen sind kostenlos, die Rohlogs hinter mehreren dieser Produkte nicht.

Die Falle in den Commitment Tiers

Sie können eine Stufe jederzeit erhöhen. Senken können Sie sie nur alle 31 Tage.

Diese Asymmetrie sollte man einplanen. Legen Sie sich auf ein Niveau fest, das Ihr Logvolumen nicht hält — weil eine laute Quelle abgeschaltet wurde oder eine Migration endete — zahlen Sie diese Kapazität den Rest des Monats.

Ein Datum für den Kalender

Nach dem 31. März 2027 wird Microsoft Sentinel im Azure-Portal nicht mehr unterstützt und ist nur noch im Microsoft-Defender-Portal verfügbar. Wenn Ihre Runbooks, Schulungsunterlagen oder Automatisierungen auf Azure-Portal-Pfade verweisen, ist das eine terminierte Migrationsaufgabe, keine optionale.

Dieselbe Aufgabe, drei verschiedene Zähler. Was ein Anbieter zählt, wird zu dem, wogegen Ihre Architektur optimiert.

Google SecOps zählt Ihre Detection-Regeln

Google veröffentlicht drei Pakete und überhaupt keine Preise. Bei jeder Stufe steht “contact sales for pricing”.

Öffentlich ist die Form der Grenzen, und sie ist ungewöhnlich: Die Obergrenzen sind in Detection-Regeln ausgedrückt, nicht in Gigabyte.

	Standard	Enterprise	Enterprise Plus
Single-Event-Regeln	1.000	2.000	3.500
Multi-Event-Regeln	75	125	200
Umgebungen	1	unbegrenzt	unbegrenzt
Hot-Retention	12 Monate	12 Monate	12 Monate
UEBA	—	ja	ja
Gemini in SecOps	—	ja	ja
Applied Threat Intelligence	—	—	Mandiant, VirusTotal, Google

Alle drei enthalten 12 Monate Hot-Retention , über 700 Parser und über 300 SOAR-Integrationen. Enterprise Plus ergänzt fortgeschrittenes Data-Pipeline-Management, 12 Monate Routing an ein anderes Ziel zur Unterstützung von SIEM-Migrationen sowie kostenlosen BigQuery-Speicher für UDM-Exporte.

Zwei Beobachtungen, eine günstige und eine nicht.

Für Google: Zwölf Monate Hot-Retention als Standard sind eine andere Haltung als 90 Tage inklusive und danach monatliche Zahlung. Wenn Ihre Compliance oder Ihre Vorfallszeiträume ein Jahr durchsuchbarer Daten voraussetzen, ist das ein struktureller Unterschied, kein Rabatt.

Gegen Google: Ohne Vertriebsgespräch lässt sich kein Budget modellieren. Für ein Plattformteam, das drei Optionen in einer Tabelle vergleichen will, ist “contact sales” selbst ein Kostenfaktor — Wochen Beschaffung, bevor überhaupt klar ist, ob die Option je infrage kam.

Wazuh zählt Ihre Agenten — oder nichts

Wazuh ist der Open-Source-Vertreter, und seine Bepreisung teilt sich sauber in zwei Hälften.

Selbst gehostet kostet keine Lizenzgebühr. Das ist wirklich kostenlos in dem Sinn, dass die Software nichts kostet, und wirklich nicht kostenlos in dem Sinn, dass Sie nun einen Indexer-Cluster betreiben, dessen Speicher mit jeder angebundenen Logquelle wächst — plus Upgrades, plus Kapazitätsplanung, plus die Person, die das versteht.

Wazuh Cloud startet bei 571 $ pro Monat für die Small-Stufe: bis zu 100 aktive Agenten, ein Monat indizierte Aufbewahrung und drei Monate Archivaufbewahrung, mit Standard-Support. Größere Stufen skalieren von dort. Die Plattform ist PCI-DSS- und SOC-2-zertifiziert, mit 14-tägiger Testphase.

Schauen Sie genau auf diesen Zähler, denn er ist der entscheidende Teil: Wazuh Cloud zählt aktive Agenten und Aufbewahrungsfenster , nicht aufgenommene Gigabyte. Ein gesprächiger Endpunkt kostet so viel wie ein stiller.

Das dreht den Anreiz komplett um. Unter Sentinel erhöht eine ausführliche Audit-Richtlinie auf einem Server Ihre Rechnung. Unter Wazuh Cloud nicht.

Der Vergleich, auf den es ankommt

Jeder Zähler erzeugt ein Verhalten. Die Frage ist, ob Sie mit diesem Verhalten im Ernstfall leben können.

	Wazuh	Microsoft Sentinel	Google SecOps
Zähler	Agenten (Cloud) oder nichts (selbst gehostet)	GB pro Tag	Paketstufe + Regel-Limits
Einstiegspreis	0 $ selbst gehostet; 571 $/Mo Cloud	Pay-as-you-go pro GB	nicht veröffentlicht
Bindung	monatliche Stufen	ab 100 GB/Tag, Senkung alle 31 Tage	jährlich, über Vertrieb
Enthaltene Aufbewahrung	1 Monat indiziert, 3 Monate Archiv (Small)	90 Tage	12 Monate hot
Detection-Limits	keine	keine	1.000–3.500 Regeln je Stufe
Sie betreiben	alles (selbst gehostet)	nichts	nichts
Preistransparenz	öffentlich	öffentlich	Vertrieb kontaktieren

Der Teil, den niemand in den Vergleich schreibt

Ein Volumenzähler erzeugt einen perversen Anreiz, und man sollte ihn klar benennen: Je besser Ihr Logging, desto höher Ihre Rechnung.

Aktivieren Sie ausführliches Audit-Logging auf einem Domain Controller, bewegt sich die Rechnung. Binden Sie eine laute, aber gelegentlich entscheidende Quelle an — DNS-Abfragelogs etwa oder Prozesserstellungs-Events — fragt jemand aus dem Controlling nach dem Warum. Die rationale Teamreaktion ist Filtern: Debug-Level senken, laute Quellen samplen, Anbindung verschieben.

Jede dieser Entscheidungen bleibt unsichtbar bis zum Vorfall. Dann stellt sich die fehlende Telemetrie als genau das heraus, was die Untersuchung gebraucht hätte, und niemand erinnert sich, dass es eine Budgetentscheidung von vor acht Monaten war.

Das ist kein Argument dagegen, dass Pro-GB-Preise legitim sind. Es ist ein Argument dafür, den Zähler als architektonische Randbedingung zu behandeln:

Wirklich hochwertige Sicherheitstelemetrie in die teure Analytics-Stufe leiten, wo die Detections laufen.
Volumenstarke, geringwertige Daten in einer günstigeren Stufe halten, die Sie im Bedarfsfall trotzdem durchsuchen können — Sentinels Lake-Stufe existiert genau dafür, und Googles Enterprise-Plus-Paket enthält Routing an ein anderes Ziel.
Aufschreiben, welche Quellen Sie nicht aufgenommen haben, und warum. Dieses Dokument werden Sie beim ersten ernsten Vorfall sehen wollen.

Die Wahl

Nehmen Sie Sentinel , wenn Sie ohnehin ein Microsoft-Security-Haus sind. Die kostenlosen Datenquellen — Office-365-Audit-Logs, Defender-Warnungen, Azure Activity — sind ein realer wirtschaftlicher Vorteil, den kein Wettbewerber für diesen Bestand erreicht, und das Defender-Portal ist erkennbar die Richtung, in die Microsoft geht.

Nehmen Sie Google SecOps , wenn Aufbewahrungstiefe und Detection-Qualität mehr zählen als planbare Budgets. Zwölf Monate Hot-Daten als Standard sind eine andere Betriebshaltung, und die Mandiant-Intelligence in Enterprise Plus lässt sich nicht selbst zusammenbauen. Kalkulieren Sie die Beschaffungszeit ein.

Nehmen Sie Wazuh , wenn Sie die Ingenieurskapazität haben und den Zähler loswerden wollen. Selbst gehostet, keine Lizenzkosten, keine Pro-GB-Angst, volle Kontrolle über die Aufbewahrung. Sie tauschen eine Softwarerechnung gegen eine Betriebsrechnung — ein guter Tausch für manche Teams und ein schlechter für Teams ohne Plattformfunktion.

Und prüfen Sie den Zähler gegen Ihre eigene Form. Wenige Endpunkte mit riesigen Logs? Volumenpreise sind Ihr Feind. Zehntausende stille Endpunkte? Agentenpreise sind es. Komplexe Korrelationslogik? Dann sind die Regel-Obergrenzen die Randbedingung, vor der Sie niemand gewarnt hat.

Eine kurze Checkliste

Messen Sie Ihr aktuelles tägliches Logvolumen in GB und Ihre Endpunktzahl. Sie brauchen beide Zahlen, weil verschiedene Anbieter jeweils eine davon abrechnen.
Listen Sie Ihre Quellen nach Wert, nicht nach Volumen. Die teure Stufe ist für die wertvollen.
Prüfen Sie, welche Ihrer Quellen auf der erwogenen Plattform kostenlos sind — bei Microsoft-Beständen auf Sentinel kann das ein großer Anteil sein.
Modellieren Sie die Aufbewahrung ausdrücklich: 90 Tage inklusive ist ein ganz anderes Budget als 12 Monate inklusive.
Wenn Sie ein Commitment Tier erwägen, modellieren Sie den Monat, in dem Ihr Volumen sinkt. Senken geht nur alle 31 Tage.
Für Google: Beginnen Sie das Vertriebsgespräch früh — was man nicht bepreisen kann, kann man nicht bewerten.
Schreiben Sie auf, welche Quellen Sie nicht aufgenommen haben. Prüfen Sie diese Liste nach jedem Vorfall.

Der eigentliche Punkt

Jeder SIEM-Anbieter wird Ihnen sagen, seine Plattform erkenne mehr mit weniger Aufwand. Sie konkurrieren mit denselben Detections, denselben Integrationen, zunehmend denselben KI-Assistenten.

Wirklich unterscheiden sie sich darin, was sie zählen — und was sie zählen, wird zu dem, wogegen Ihr Team optimiert. Ein Pro-Gigabyte-Zähler erzeugt eine Organisation, die Logs filtert. Ein Agentenzähler erzeugt eine, die die Endpunktabdeckung begrenzt. Eine Regel-Obergrenze erzeugt eine, die Detections zu wenigen, breiteren Regeln zusammenfasst.

Wählen Sie die Randbedingung, mit der Sie leben können, und gestalten Sie bewusst um sie herum — statt sie auf einer Rechnung zu entdecken.

Weiterlesen: Was überhaupt in ein SIEM fließt, steht in Falco in Produktion und Eigenes CSPM auf GCP. Dieselbe Ökonomie beim Speicher: Was Egress wirklich kostet.

Quellen: Alle Angaben stammen aus der Anbieterdokumentation, geprüft im August 2026 — Microsoft Sentinel Billing (Stand Juni 2026), die Produktseite Google Security Operations und Wazuh Cloud. Preise ändern sich; prüfen Sie vor jeder Budgetzusage.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Wazuh vs Microsoft Sentinel vs Google SecOps: The SIEM You Pick Is the Bill You Get

Aleksei Aleinikov — Mon, 24 Aug 2026 12:00:00 +0000

Most SIEM comparisons are feature tables. They are also useless, because the features converge and the pricing models do not.

Wazuh, Microsoft Sentinel and Google SecOps all ingest logs, all detect threats, all sit at the centre of a security operations workflow. What separates them is what each one counts — and that choice quietly determines what your team is willing to log, which determines what you can investigate at 3am.

Here are the three meters, from vendor documentation checked in August 2026.

Sentinel Counts Your Gigabytes

Microsoft Sentinel bills on the volume of data ingested, priced by the tier the data lands in.

The analytics tier has two modes:

Pay-as-you-go — the default, based on data volume stored. Note that Microsoft measures a GB as 10⁹ bytes here; unlike S3, these are decimal gigabytes.
Commitment tiers — pre-purchased capacity starting at 100 GB per day , at a discounted effective rate. Usage beyond your commitment is billed at that same effective rate rather than at pay-as-you-go.

Retention of the first 90 days is included. Beyond that you pay Log Analytics retention prices.

One caveat about the numbers in this article: Microsoft keeps the actual per-GB rates on its pricing page and cost estimator rather than in the billing documentation, and they vary by region and commitment tier. What is documented — and what actually shapes your architecture — is the structure below. Run your own volume through the Sentinel cost estimator for the rate that applies to you.

There is now also a data lake tier , which meters four things separately: ingestion, data processing, storage and query. The storage figure is calculated on a fixed 6:1 compression ratio — retain 600 GB of raw data and you are billed for 100 GB. Queries, however, are charged per GB of uncompressed data scanned. Those two facts sit next to each other in the docs and are easy to conflate when estimating.

A genuinely useful set of sources is free: Azure Activity logs, Sentinel Health, Office 365 audit logs covering SharePoint, Exchange and Teams, and security alerts from the Defender family. The caveat is sharp — the alerts are free, the raw logs behind several of those products are not.

The trap in commitment tiers

You can raise a commitment tier at any time. You can lower it only once every 31 days.

That asymmetry is worth planning around. Commit at a level your log volume does not sustain — because a noisy source got switched off, or a migration finished — and you are locked into paying for that capacity for the rest of the month.

One date to put in the calendar

After 31 March 2027 , Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. If your runbooks, training material or automation reference Azure portal paths, that is a dated migration task, not an optional one.

Same job, three different meters. What each vendor counts is what your architecture will optimise against.

Google SecOps Counts Your Detection Rules

Google publishes three packages and no prices at all. Every tier says “contact sales for pricing.”

What is public is the shape of the limits, and it is unusual: the ceilings are expressed in detection rules , not gigabytes.

	Standard	Enterprise	Enterprise Plus
Single-event rules	1,000	2,000	3,500
Multi-event rules	75	125	200
Environments	1	Unlimited	Unlimited
Hot retention	12 months	12 months	12 months
UEBA	—	Yes	Yes
Gemini in SecOps	—	Yes	Yes
Applied Threat Intelligence	—	—	Mandiant, VirusTotal, Google

All three include 12 months of hot data retention , 700+ parsers and 300+ SOAR integrations. Enterprise Plus adds advanced data pipeline management, 12 months of routing to another destination to support SIEM migrations, and free BigQuery storage for UDM exports.

Two observations, one favourable and one not.

In Google’s favour: twelve months of hot retention as standard is a different posture from 90 days included and pay-per-month afterwards. If your compliance regime or your incident timelines assume a year of searchable data, that is a meaningful structural difference rather than a discount.

Against: you cannot model a budget without a sales call. For a platform team trying to compare three options in a spreadsheet, “contact sales” is itself a cost — it is weeks of procurement before you know whether the option was ever viable.

Wazuh Counts Your Agents, or Nothing

Wazuh is the open-source entry, and its pricing splits cleanly in two.

Self-hosted carries no licence fee. That is genuinely free in the sense that the software costs nothing, and genuinely not free in the sense that you now run an indexer cluster whose storage grows with every log source you onboard — plus upgrades, plus capacity planning, plus the engineer who understands it.

Wazuh Cloud starts at $571 per month for the Small tier: up to 100 active agents, one month of indexed data retention and three months of archive retention, with standard support. Larger tiers scale up from there. The platform is PCI DSS and SOC 2 certified, with a 14-day free trial.

Look closely at that meter, because it is the important part: Wazuh Cloud counts active agents and retention windows , not gigabytes ingested. A chatty endpoint costs the same as a quiet one.

That inverts the incentive completely. Under Sentinel, a verbose audit policy on one server increases your bill. Under Wazuh Cloud, it does not.

The Comparison That Matters

Every meter creates a behaviour. The question is whether that behaviour is one you can live with during an incident.

	Wazuh	Microsoft Sentinel	Google SecOps
Meter	Agents (cloud) or nothing (self-hosted)	GB ingested per day	Package tier + rule limits
Entry price	$0 self-hosted; $571/mo cloud	Pay-as-you-go per GB	Not published
Commitment	Monthly tiers	From 100 GB/day, lower once per 31 days	Annual, via sales
Included retention	1 month indexed, 3 months archive (Small)	90 days	12 months hot
Detection limits	None imposed	None imposed	1,000–3,500 rules by tier
You operate	Everything (self-hosted)	Nothing	Nothing
Price transparency	Public	Public	Contact sales

The Part Nobody Puts in the Comparison

A volume meter creates a perverse incentive, and it is worth naming plainly: the better your logging, the higher your bill.

Enable verbose audit logging on a domain controller and the invoice moves. Onboard a noisy but occasionally crucial source — DNS query logs, say, or process creation events — and someone in finance asks why. The rational team response is to filter: drop the debug level, sample the high-volume source, postpone onboarding.

Every one of those decisions is invisible until an incident. Then the missing telemetry turns out to be exactly the thing the investigation needed, and nobody remembers that it was a budget decision made eight months earlier.

This is not an argument that per-GB pricing is illegitimate. It is an argument that the meter is an architectural constraint , and should be treated like one:

Route genuinely high-value security telemetry into the expensive analytics tier where detections run.
Keep high-volume, low-value data in a cheaper tier you can still search when you need it — Sentinel’s lake tier exists precisely for this, and Google’s Enterprise Plus package includes routing to another destination.
Write down which sources you chose not to ingest, and why. That document is what you will want during your first serious incident.

Choosing

Choose Sentinel if you are already a Microsoft security shop. The free data sources — Office 365 audit logs, Defender alerts, Azure Activity — are a real economic advantage that no competitor can match for that estate, and the Defender portal consolidation is where Microsoft is clearly heading.

Choose Google SecOps if retention depth and detection quality matter more than budget predictability. Twelve months of hot data as standard is a genuinely different operating posture, and the Mandiant intelligence in Enterprise Plus is not something you can assemble yourself. Budget the procurement time.

Choose Wazuh if you have the engineering capacity and want the meter off. Self-hosted, no licence cost, no per-GB anxiety, complete control of retention. You are trading a software bill for an operational one — which is a good trade for some teams and a terrible one for teams without a platform function.

And check the meter against your own shape. Few endpoints producing enormous logs? Volume pricing is your enemy. Tens of thousands of quiet endpoints? Agent pricing is. Complex correlation logic? Rule ceilings are the constraint nobody warned you about.

A Short Checklist

Measure your current daily log volume in GB and your endpoint count. You need both numbers, because different vendors bill each one.
List your sources by value, not by volume. The expensive tier is for the valuable ones.
Check which of your sources are free on the platform you are considering — for Microsoft estates on Sentinel this can be a large fraction.
Model retention explicitly: 90 days included is a very different budget from 12 months included.
If you are considering a commitment tier, model the month your volume drops. You can only lower it once every 31 days.
For Google, start the sales conversation early — you cannot evaluate what you cannot price.
Write down the sources you decided not to ingest. Review that list after every incident.

The Real Point

Every SIEM vendor will tell you their platform detects more with less effort. They are competing on the same detections, the same integrations, increasingly the same AI assistants.

Where they genuinely differ is in what they count — and what they count becomes what your team optimises against. A per-gigabyte meter produces an organisation that filters logs. An agent meter produces one that limits endpoint coverage. A rule ceiling produces one that consolidates detections into fewer, broader rules.

Pick the constraint you can live with, then design around it deliberately, instead of discovering it in an invoice.

Related reading: for what goes into a SIEM in the first place, see Falco for production runtime security and build your own CSPM. For the same economics applied to storage, see what egress actually costs.

Sources: all figures come from vendor documentation checked in August 2026 — Microsoft Sentinel billing (updated June 2026), the Google Security Operations product page, and Wazuh Cloud. Prices change; verify before committing a budget.

Originally published at alekseialeinikov.com

Cloudflare R2 vs S3: Was Egress wirklich kostet (und wo R2 stattdessen abrechnet)

Aleksei Aleinikov — Fri, 21 Aug 2026 12:00:00 +0000

Die Rechnung für Objektspeicher handelt selten vom Speichern.

Sehen Sie sich eine große S3-Rechnung an: Die Gigabyte, die Sie aufbewahren, sind oft die kleinere Hälfte. Die größere Hälfte sind die Gigabyte, die Sie versenden — und dieser Posten leistet etwas, das kein anderer leistet: Er macht das Weggehen teuer. Ein Datensatz, dessen Umzug Sie sich nicht leisten können, liegt nicht einfach irgendwo. Er wird dort festgehalten.

Cloudflare R2 greift genau diesen Posten an, indem es nichts dafür berechnet. Das ist die Schlagzeile, sie stimmt — und sie ist nicht die ganze Geschichte. Hier ist, was beide Seiten tatsächlich abrechnen, mit Zahlen aus der Dokumentation der Anbieter, geprüft im August 2026.

Warum es Egress überhaupt gibt

Bytes zu speichern ist günstig und wird weiter günstiger. Bytes über die Netzgrenze eines Anbieters zu bewegen ist der Punkt, an dem die Kostenkurve aufhört zu fallen — und an dem die Preismacht sitzt.

Die Asymmetrie ist der verräterische Teil. Bei S3 ist eingehender Datenverkehr aus dem Internet kostenlos. Ausgehender nicht. Kostenlos sind ebenfalls Daten zwischen Buckets derselben Region, Daten von S3 zu einem AWS-Dienst in derselben Region und Daten zu CloudFront. Ihre Daten hineinzubekommen kostet nichts; sie irgendwohin zu bekommen, das nicht AWS ist, kostet pro Gigabyte.

Das ist keine Verschwörung — Bandbreite kostet wirklich Geld — aber die Form bedeutet, dass der Zähler am schnellsten läuft, wenn Sie Ihre Daten anderswo verwenden.

Die Schlagzeilenzahlen

S3 stellt die ersten 100 GB pro Monat ausgehenden Internetverkehrs kostenlos, aggregiert über alle AWS-Dienste und Regionen (außer China und GovCloud). Danach zahlen Sie pro Gigabyte, abhängig von Region und Volumen. AWS’ eigene Dokumentation nennt in einem Beispiel zu Multi-Region Access Points 0,09 $ pro GB für die Übertragung aus Europa (Irland) ins Internet.

Regionsübergreifende Übertragung ist günstiger, aber weiterhin bepreist: AWS nennt 0,01 $/GB von N. Virginia nach Ohio und 0,02 $/GB von Oregon nach N. Virginia.

R2 berechnet 0 $ für Egress auf jeder Speicherklasse. Cloudflares Fußnote zieht die Grenze präzise: Egress direkt aus R2 — über die Workers-API, die S3-kompatible API oder r2.dev-Domains — löst keine Übertragungsgebühr aus. Hängen Sie andere kostenpflichtige Dienste an den Bucket, können diese abrechnen.

Bei 5 TB monatlichem Egress aus Irland — bequem innerhalb der ersten Preisstufe — sind das rund 450 $ auf einer einzigen Zeile , bevor überhaupt jemand etwas gespeichert hat.

Widerstehen Sie der Versuchung, das einfach hochzurechnen. AWS wendet Volumenstufen an und hält fest, dass diese Stufen die aggregierte Nutzung des ausgehenden Datenverkehrs über alle AWS-Dienste hinweg berücksichtigen. Der überall zitierte Gigabyte-Preis gilt nur für die erste Stufe; spätere Gigabyte kosten weniger. Eine flache Multiplikation über 50 TB überschätzt die Rechnung — die Richtung stimmt, die Summe nicht.

Dieselbe Last, zwei Zähler. R2 entfernt die Egress-Zeile und verlagert das Gewicht auf Operationen.

Was R2 stattdessen abrechnet

R2 ist nicht kostenlos. Es verschiebt den Zähler von ausgehenden Bytes auf Operationen, und bei manchen Lasten läuft dieser Zähler schnell.

	Standard	Infrequent Access
Speicher	0,015 $ / GB-Monat	0,01 $ / GB-Monat
Class-A-Operationen	4,50 $ / Million	9,00 $ / Million
Class-B-Operationen	0,36 $ / Million	0,90 $ / Million
Datenabruf	keiner	0,01 $ / GB
Egress	kostenlos	kostenlos

Das Freikontingent umfasst 10 GB-Monat Speicher, 1 Million Class-A- und 10 Millionen Class-B-Operationen pro Monat — nur Standard , nicht Infrequent Access.

Die Aufteilung zählt mehr als die Tarife:

Class A (teuer, verändernd): PutObject, CopyObject, ListObjects, ListBuckets, PutBucket, die gesamte Multipart-Familie, Lifecycle-Übergänge und PutBucket*-Konfigurationsaufrufe.
Class B (günstig, lesend): GetObject, HeadObject, HeadBucket, UsageSummary, GetBucket*-Aufrufe.
Kostenlos : DeleteObject, DeleteBucket, AbortMultipartUpload.

Beachten Sie: Auflisten ist Class A. Ein Job, der bei jedem Durchlauf einen Bucket auflistet, zahlt den teuren Tarif für etwas, das sich wie Lesen anfühlt.

Cloudflares eigenes Asset-Hosting-Beispiel macht den Punkt besser als jedes Argument. 100.000 Dateien à durchschnittlich 100 KB, 10 Millionen Lesevorgänge pro Tag:

	Nutzung	Abgerechnet
Speicher	100.000 × 100 KB	0,00 $ (im Freikontingent)
Class A	100.000 Schreibvorgänge	0,00 $ (im Freikontingent)
Class B	300 Millionen Lesevorgänge	104,40 $
Gesamt		104,40 $

Speicher: nichts. Egress: nichts. Die gesamte Rechnung besteht aus Leseoperationen. Wer zu R2 migriert und eine von Gigabyte dominierte Rechnung erwartet, wird von einer Rechnung überrascht, die von Anfragen dominiert wird.

Das Kleingedruckte, das die Summe bewegt

Die Grundpreise sind der einfache Teil. Diese Klauseln verändern, was Sie tatsächlich zahlen — und sie schneiden in beide Richtungen.

Nichts davon steht im Grundpreis. Alles davon steht auf der Rechnung.

S3 misst in binären Gigabyte. AWS hält ausdrücklich fest, dass die S3-Speichernutzung in binären GB berechnet wird, wobei 1 GB 2³⁰ Bytes entspricht — ein Gibibyte. Wer sein Budget mit dezimalen Gigabyte kalkuliert hat, liegt um rund 7,4 % daneben, bevor irgendetwas anderes passiert.

Egress ist gestuft, und die Stufen gelten kontoweit. Der genannte Gigabyte-Preis gilt nur für die erste Stufe. AWS merkt an, dass die Preisstufen die aggregierte Nutzung des ausgehenden Datenverkehrs über alle AWS-Dienste hinweg berücksichtigen — Ihre S3-Rechnung hängt also davon ab, was CloudFront, EC2 und alles andere in diesem Monat hinausgeschickt haben. Das schneidet in beide Richtungen: Schätzungen mit einem einzigen Satz fallen zu hoch aus, und die Zuordnung pro Dienst ist schwieriger, als sie aussieht.

LIST wird bei S3 zum PUT-Tarif abgerechnet. Nicht zum GET-Tarif. AWS schreibt es direkt: “LIST requests for any storage class are charged at the same rate as S3 Standard PUT, COPY, and POST requests.” Sich durch einen großen Bucket zu blättern ist keine günstige Leseoperation.

Ein Verbindungsabbruch kann mehr kosten, als Sie erhalten haben. Das ist zweimal Lesen wert. AWS dokumentiert: Fordern Sie ein 10-GB-Objekt an und brechen nach 2 GB ab, versucht S3 den Stream zu stoppen, schafft das aber nicht sofort — abgerechnet werden können 3 GB. Clients, die Downloads aggressiv abbrechen, zahlen für Bytes, die niemand konsumiert hat.

R2 rundet auf die nächste Abrechnungseinheit auf. Cloudflares Beispiele: Eine Million und eine Operation wird als zwei Millionen abgerechnet; 1,1 GB-Monat als 2 GB-Monat. Bei kleinen Konten ist diese Rundung anteilig brutal.

Mindestwerte beißen auf beiden Seiten. S3 Standard-IA und One Zone-IA haben eine mindestens abgerechnete Objektgröße von 128 KB und 30 Tage Mindestdauer; Glacier-Stufen liegen bei 90 oder 180 Tagen und ergänzen 40 KB Metadaten je archiviertem Objekt. R2s Infrequent Access trägt eine Mindestdauer von 30 Tagen.

Unautorisierte Anfragen sind bei R2 kostenlos. Cloudflare hält fest, dass keine Gebühren anfallen, wenn dem Aufrufer die Berechtigung fehlt (HTTP 401). Gut zu wissen, wenn Ihr Bucket öffentlich adressierbar ist und Rauschen anzieht.

Wenn Infrequent Access mehr kostet als Standard

Die deutlichste Falle in R2s Preisliste ist die eigene günstigere Stufe. Cloudflare veröffentlicht beide Beispiele nebeneinander.

1.000 Objekte à 1 GB schreiben und jedes im Monat 1.000-mal lesen:

Standard : 14,85 $ gesamt (990 abrechenbare GB-Monate nach Freikontingent; Operationen im Freikontingent)
Infrequent Access : 29,90 $ gesamt

IA kostet das Doppelte. Die Mechanik: IA hat kein Freikontingent, die Class-A-Operationen kosten das Doppelte, die Class-B das 2,5-Fache, der Abruf kommt mit 0,01 $/GB hinzu, und die Mindestdauer von 30 Tagen bedeutet, dass fünf Tage Speicherung trotzdem 1.000 GB-Monate abrechnen statt 167.

Daraus folgt die Regel: Infrequent Access ist eine Wette darauf, dass Sie die Daten nicht lesen. Verlieren Sie die Wette, zahlen Sie mehr als mit Standard.

Was der EU Data Act verändert hat

Die Verordnung (EU) 2023/2854 — der Data Act — trat am 11. Januar 2024 in Kraft und gilt seit dem 12. September 2025. Zu ihren Maßnahmen gehören Regeln, die Kunden einen wirksamen Wechsel zwischen Anbietern von Datenverarbeitungsdiensten ermöglichen sollen, ausdrücklich mit dem Ziel, den EU-Cloud-Markt zu öffnen.

Interessant ist, wie sich das in einer Preisliste niederschlägt. Auf der S3-Preisseite von AWS steht inzwischen:

EU customers may request reduced data transfer rates for eligible use cases under the European Data Act. Please contact AWS Customer Support for more information.

Lesen Sie genau. Die Erleichterung existiert, und sie ist eine Anfrage, die Sie stellen müssen , für geeignete Anwendungsfälle, über den Support. Es ist keine Tarifänderung, die Ihrem Konto zugewiesen wird, weil Sie in der EU sitzen.

Das ist die praktische Form der Regulierung heute: Der Lock-in-Mechanismus ist verhandelbar geworden, nicht abwesend. Wer aus der EU heraus eine Migration weg von AWS plant, für den ist das Öffnen dieses Support-Tickets ein konkreter, datierbarer Schritt im Plan — keine Fußnote.

Also welches

Die Entscheidung lautet nicht “was ist billiger”, sondern welcher Zähler zu Ihrem Verkehr passt.

R2 gewinnt klar, wenn Bytes die Cloud verlassen. Öffentliche Asset-Auslieferung, Medien, Downloads, Backups, die von Systemen außerhalb von AWS gezogen werden — alles, was in Menge ins offene Internet geht. Dafür wurde R2 gebaut, und die Zahlen sind nicht knapp.

S3 bleibt sinnvoll, wenn Bytes nie hinausgehen. Sind Ihre Konsumenten EC2, Lambda, Athena oder Glue in derselben Region, zahlen Sie bereits null Egress. Diese Last zu R2 zu migrieren, um an einer Zeile zu sparen, die Ihnen nicht berechnet wird, ist Bewegung ohne Fortschritt.

Zählen Sie Operationen, bevor Sie sich festlegen. Eine Last mit vielen kleinen Objekten und hoher Anfragerate kann bei R2 mehr kosten, als sie an Egress spart. Cloudflares eigenes 104,40-$-Beispiel besteht vollständig aus Operationen.

Prüfen Sie, was Sie verlieren. R2 spricht die S3-API, aber “S3-kompatibel” ist nicht “S3-identisch”. Verifizieren Sie vor einer Migration die konkreten Funktionen, von denen Ihr Stack abhängt, statt Gleichwertigkeit anzunehmen.

Migrationswerkzeuge sind kostenlos, größtenteils. Cloudflares Super Slurper (Massenkopie) und Sippy (inkrementell, Migration beim Lesen) kosten nichts — Sie zahlen nur die Class-A-Operationen, die sie gegen Ihren R2-Bucket erzeugen. Ihr Quell-Bucket kann Ihnen die Lesevorgänge und den Egress auf dem Weg hinaus trotzdem berechnen, was die letzte Ironie der ganzen Anordnung ist: Das Weggehen kostet Egress.

Eine Checkliste vor dem Umzug

Ziehen Sie den tatsächlichen Egress des letzten Monats in GB aus dem Cost Explorer — keine Schätzung.
Zählen Sie Ihre Anfragen, getrennt nach Schreiben/Auflisten (Class A) und Lesen (Class B). Multiplizieren Sie mit R2s Tarifen.
Prüfen Sie, wie viel Ihres Verkehrs AWS-intern in derselben Region bleibt. Dieser Teil ist bereits kostenlos und gewinnt nichts.
Messen Sie den Speicher in binären und dezimalen Gigabyte neu, damit Sie Gleiches mit Gleichem vergleichen.
Nutzt ein Bucket IA oder Glacier, prüfen Sie Mindestdauer und Mindestobjektgröße, bevor Sie irgendetwas umlagern.
Sitzen Sie in der EU, eröffnen Sie das AWS-Support-Ticket zu den Data-Act-Übertragungstarifen — holen Sie sich die Zahl schriftlich, bevor Sie die Migration durchrechnen.
Budgetieren Sie die einmaligen Kosten der Migration selbst: Lesevorgänge plus Egress auf der Quellseite.

Der eigentliche Punkt

Egress-Preise sind keine Bandbreitengebühr. Sie sind der Mechanismus, der gespeicherte Daten in gehaltene Kunden verwandelt — weshalb ein Wettbewerber, der genau diese Zeile angreift, immer Aufmerksamkeit bekommen würde, und weshalb irgendwann auch eine Regulierungsbehörde hinsah.

Aber “kostenloser Egress” ist eine Aussage über eine Zeile einer Rechnung, nicht über die Rechnung. Cloudflare berechnet Operationen, rundet auf und bestraft die falsche Speicherklasse genauso konsequent wie AWS. Der Anbieter hat gewechselt; die Notwendigkeit, das Kleingedruckte zu lesen, nicht.

Rechnen Sie Ihre eigene Last gegen beide Zähler. Für ein Medien-CDN lautet die Antwort anders als für eine Analytics-Pipeline, die us-east-1 nie verlässt — und wer etwas anderes behauptet, zitiert einen Grundpreis.

Weiterlesen: Wie Daten überhaupt beweglich bleiben, steht in Backups sind kein Disaster Recovery und Sovereign by Design. Zur Analytics-Seite der Speicherökonomie siehe BigQuery vs Snowflake.

Quellen: Alle Zahlen stammen aus der Anbieterdokumentation, geprüft im August 2026 — Cloudflare R2 Pricing (Stand 7. August 2026), Amazon S3 Pricing und die Data-Act-Seite der Europäischen Kommission. Tarife ändern sich; prüfen Sie vor jeder Budgetzusage die Kalkulatoren der Anbieter.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Cloudflare R2 vs S3: What Egress Actually Costs You (and Where R2 Bills Instead)

Aleksei Aleinikov — Fri, 21 Aug 2026 12:00:00 +0000

The bill for object storage is rarely about storage.

Look at a large S3 invoice and the gigabytes you keep are often the smaller half. The larger half is the gigabytes you send — and that line item does something no other line item does: it makes leaving expensive. A dataset you can’t afford to move isn’t just stored somewhere. It’s held there.

Cloudflare R2 attacks that specific line by charging nothing for it. That’s the headline, it’s true, and it’s not the whole story. Here is what each side actually bills, with the numbers from both vendors’ own documentation, checked in August 2026.

Why Egress Exists at All

Storing bytes is cheap and getting cheaper. Moving bytes across a provider’s network edge is where the cost curve stops falling and where the pricing power sits.

The asymmetry is the tell. On S3, data in from the internet is free. Data out is not. So is data between buckets in the same region, data from S3 to any AWS service in the same region, and data out to CloudFront. Getting your data in costs nothing; getting it out to anywhere that isn’t AWS costs per gigabyte.

That’s not a conspiracy — bandwidth genuinely costs money — but the shape of it means the meter runs hardest precisely when you use your data somewhere else.

The Headline Numbers

S3 gives you the first 100 GB per month of data transfer out to the internet free, aggregated across all AWS services and regions (excluding China and GovCloud). After that, you pay per gigabyte at a rate that varies by region and volume. AWS’s own documentation, in a Multi-Region Access Point example, quotes $0.09 per GB for transfer out from Europe (Ireland) to the internet.

Cross-region transfer is cheaper but still metered: AWS quotes $0.01/GB from N. Virginia to Ohio and $0.02/GB from Oregon to N. Virginia.

R2 charges $0 for egress on every storage class. Cloudflare’s footnote defines the boundary precisely: egressing directly from R2 — through the Workers API, the S3-compatible API, or r2.dev domains — incurs no data transfer charge. If you attach other metered services to the bucket, those services may bill you.

At 5 TB of monthly egress from Ireland — comfortably inside the first pricing tier — that is roughly $450 on one line , before anyone has stored anything.

Resist the urge to scale that up by multiplication. AWS applies volume tiers , and states that rate tiers take into account your aggregate data transfer out across all AWS services. The per-gigabyte figure everyone quotes is the first tier; later gigabytes cost less. A flat multiplication across 50 TB overstates the bill — the direction is right, the total is not.

The same workload, two meters. R2 removes the egress line and puts more weight on operations.

What R2 Bills Instead

R2 is not free. It moves the meter from bytes-out to operations, and for some workloads that meter runs fast.

Standard storage:

	Standard	Infrequent Access
Storage	$0.015 / GB-month	$0.01 / GB-month
Class A operations	$4.50 / million	$9.00 / million
Class B operations	$0.36 / million	$0.90 / million
Data retrieval	None	$0.01 / GB
Egress	Free	Free

The free tier covers 10 GB-month of storage, 1 million Class A and 10 million Class B operations per month — Standard only , not Infrequent Access.

The split matters more than the rates:

Class A (expensive, mutating): PutObject, CopyObject, ListObjects, ListBuckets, PutBucket, the whole multipart family, lifecycle transitions, and PutBucket* configuration calls.
Class B (cheap, reading): GetObject, HeadObject, HeadBucket, UsageSummary, GetBucket* calls.
Free : DeleteObject, DeleteBucket, AbortMultipartUpload.

Note that listing is Class A. A job that lists a bucket on every iteration is paying the expensive rate for what feels like a read.

Cloudflare’s own asset-hosting example makes the point better than any argument. Host 100,000 files averaging 100 KB, serve 10 million reads per day:

	Usage	Billed
Storage	100,000 × 100 KB	$0.00 (under free tier)
Class A	100,000 writes	$0.00 (under free tier)
Class B	300 million reads	$104.40
Total		$104.40

Storage: nothing. Egress: nothing. The entire bill is read operations. If you migrate to R2 expecting a bill dominated by gigabytes, you will be surprised by a bill dominated by requests.

The Fine Print That Moves the Total

Headline rates are the easy part. These are the clauses that change what you actually pay, and they cut both ways.

None of these appear in a headline rate. All of them appear on the invoice.

S3 measures in binary gigabytes. AWS states plainly that S3 storage usage is calculated in binary GB, where 1 GB is 2³⁰ bytes — a gibibyte. If you sized your budget with decimal gigabytes, you are off by about 7.4% before anything else happens.

Egress is tiered, and the tiers are account-wide. The headline per-gigabyte rate applies to the first tier only. AWS notes that rate tiers take into account your aggregate usage for data transfer out across all AWS services — so your S3 bill depends on what CloudFront, EC2 and everything else sent out that month. This cuts both ways: it makes single-rate estimates too high, and it makes per-service attribution harder than it looks.

LIST is billed at the PUT rate on S3. Not the GET rate. AWS says so directly: “LIST requests for any storage class are charged at the same rate as S3 Standard PUT, COPY, and POST requests.” Paginating through a large bucket is not a cheap read operation.

A dropped connection can cost more than you received. This one is worth reading twice. AWS documents that if you request a 10 GB object and terminate after receiving 2 GB, S3 attempts to stop streaming but does not do so instantly — you may be billed for 3 GB. Clients that abort downloads aggressively pay for bytes nobody consumed.

R2 rounds up to the next billing unit. Cloudflare’s examples: one million and one operations bills as two million operations; 1.1 GB-month bills as 2 GB-month. On small accounts this rounding is proportionally brutal.

Minimums bite on both sides. S3 Standard-IA and One Zone-IA have a minimum billable object size of 128 KB and a 30-day minimum duration; Glacier tiers run 90 or 180 days and add 40 KB of metadata per archived object. R2’s Infrequent Access carries a 30-day minimum duration.

Unauthorized requests are free on R2. Cloudflare states you are not charged for operations where the caller lacks permission (HTTP 401). Worth knowing if your bucket is publicly addressable and attracting noise.

When Infrequent Access Costs More Than Standard

The clearest trap in R2’s pricing is its own cheaper tier. Cloudflare publishes both examples side by side.

Write 1,000 objects of 1 GB, read each 1,000 times over the month:

Standard : $14.85 total (990 billable GB-months after free tier; operations covered by free tier)
Infrequent Access : $29.90 total

IA is twice the price. The mechanics: IA has no free tier, its Class A operations cost double, its Class B cost 2.5×, retrieval adds $0.01/GB, and the 30-day minimum means storing objects for five days still bills 1,000 GB-months rather than 167.

The rule that falls out: Infrequent Access is a bet that you will not read the data. Break that bet and you pay more than you would have on Standard.

What the EU Data Act Changed

Regulation (EU) 2023/2854 — the Data Act — entered into force on 11 January 2024 and has applied since 12 September 2025. Among its measures are rules letting customers switch effectively between providers of data-processing services, aimed explicitly at unlocking the EU cloud market.

The interesting part is how that shows up in a price list. AWS’s S3 pricing page now carries this line:

EU customers may request reduced data transfer rates for eligible use cases under the European Data Act. Please contact AWS Customer Support for more information.

Read it carefully. The relief exists, and it is a request you have to make , for eligible use cases, through support. It is not a rate change applied to your account because you are in the EU.

That is the practical shape of the regulation today: the lock-in mechanism is now negotiable rather than absent. If you are planning a migration out of AWS from the EU, opening that support case is a concrete, dated step in your plan — not a footnote.

So Which One

The decision is not “which is cheaper.” It is which meter matches your traffic.

R2 wins decisively when bytes leave the cloud. Public asset delivery, media, downloads, backups pulled by systems outside AWS, anything served to the open internet at volume. This is the case R2 was built for and the numbers aren’t close.

S3 stays sensible when bytes never leave. If your consumers are EC2, Lambda, Athena or Glue in the same region, you are already paying zero egress. Migrating that workload to R2 to save on a line you aren’t being charged for is motion without progress.

Count operations before you commit. A workload with many small objects and high request rates can cost more on R2 than the egress it saves. Cloudflare’s own $104.40 example is entirely operations.

Check what you lose. R2 speaks the S3 API, but “S3-compatible” is not “S3-identical.” Before migrating, verify the specific features your stack depends on rather than assuming parity.

Migration tooling is free, mostly. Cloudflare’s Super Slurper (bulk copy) and Sippy (incremental, migrate-on-read) cost nothing to use — you pay only the Class A operations they generate against your R2 bucket. Your source bucket may still bill you for the reads and the egress on the way out, which is the last irony of the whole arrangement: leaving costs egress.

A Checklist Before You Move

Pull last month’s actual egress in GB from Cost Explorer — not an estimate.
Count your requests, split into writes/lists (Class A) and reads (Class B). Multiply by R2’s rates.
Check how much of your traffic is same-region AWS-to-AWS. That part is already free and gains nothing.
Re-measure storage in binary vs decimal gigabytes so you compare like with like.
If any bucket uses IA or Glacier, check minimum-duration and minimum-object-size penalties before transitioning anything.
If you are in the EU, open the AWS support case about Data Act transfer rates — get the number in writing before you model the migration.
Budget the one-time cost of the migration itself: reads plus egress on the source side.

The Real Point

Egress pricing is not really a bandwidth charge. It is the mechanism that converts stored data into retained customers, which is why a competitor attacking exactly that line was always going to get attention — and why a regulator eventually did too.

But “free egress” is a claim about one line on an invoice, not about the invoice. Cloudflare bills you for operations, rounds usage up, and penalises the wrong storage class just as firmly as AWS does. The provider changed; the need to read the fine print did not.

Price your own workload against both meters. The answer is different for a media CDN and for an analytics pipeline that never leaves us-east-1, and anyone who tells you otherwise is quoting a headline rate.

Related reading: on keeping data movable in the first place, see backups are not disaster recovery and sovereign by design. For the analytics side of storage economics, see BigQuery vs Snowflake.

Sources: all figures come from vendor documentation checked in August 2026 — Cloudflare R2 pricing (updated 7 August 2026), Amazon S3 pricing, and the European Commission’s Data Act page. Rates change; verify against the vendor calculators before committing a budget.

Originally published at alekseialeinikov.com

k3s vs k0s vs MicroK8s vs RKE2: Welches Kubernetes, wenn das volle nicht nötig ist

Aleksei Aleinikov — Thu, 20 Aug 2026 12:00:00 +0000

Jeder Vergleich leichtgewichtiger Kubernetes-Distributionen beginnt mit einer Tabelle von Speicherbedarfen — und jeder verfehlt damit den Kern.

Die interessante Frage ist nicht, welche Distribution die kleinste ist. Sie lautet: Was hat jede weggelassen, und können Sie darauf verzichten? Eine Kubernetes-Control-Plane hat eine feste Menge an Aufgaben; der Unterschied zwischen diesen vier Projekten liegt darin, welche dieser Aufgaben sie Ihnen überlassen, welche sie verstecken und zu welchen sie sich bewusst nicht äußern.

Hier ist, was sie 2026 tatsächlich trennt — inklusive einer Änderung aus diesem Jahr, die die Standardwerte einer Distribution still umgeschrieben hat.

Zuerst: “Leichtgewichtig” bedeutet dreierlei

Bevor man irgendetwas vergleicht, lohnt es sich, drei Behauptungen zu trennen, die ständig vermischt werden:

Ein kleines Installationsartefakt. k3s wird als einzelne Binärdatei unter 100 MB ausgeliefert. k0s ist eine selbstentpackende, statisch kompilierte Binärdatei mit eingebetteten Kubernetes-Komponenten.
Eine niedrige Speicheruntergrenze. Wie wenig RAM die Control Plane braucht, bevor irgendein Workload darauf liegt.
Wenige mitgelieferte Komponenten. Wie viel Cluster Sie bekommen, bevor Sie selbst etwas installieren.

Diese Ziele ziehen in verschiedene Richtungen. Eine Distribution, die Ingress-Controller, Load Balancer und Storage-Provisioner mitbringt, liefert schneller ein funktionierendes Cluster — und verbraucht dabei mehr Speicher. Wenn ein Projekt einen kleineren Fußabdruck als ein anderes behauptet, prüfen Sie, ob dasselbe Cluster gemessen wurde.

k3s — Batteries included, für den Edge optimiert

k3s ist das, was die meisten meinen, wenn sie “leichtgewichtiges Kubernetes” sagen. Der Name ist ein Größenwitz: Kubernetes ist ein Zehn-Buchstaben-Wort, stilisiert als K8s, also ist etwas halb so Großes ein Fünf-Buchstaben-Wort, stilisiert als K3s. Es gibt keine Langform und keine offizielle Aussprache.

Bemerkenswert ist, wie viel in dieser einen Binärdatei ankommt:

containerd als Container-Runtime
Flannel als CNI
CoreDNS als Cluster-DNS
Traefik als Ingress-Controller
ServiceLB als Load-Balancer-Controller
Kube-router für Network Policies
local-path-provisioner für persistente Volumes
Spegel , ein eingebetteter verteilter Container-Image-Registry-Spiegel
Host-Werkzeuge wie iptables und socat

Der vorletzte Punkt wiegt schwerer, als er aussieht. Spegel lässt Knoten Images voneinander ziehen, statt eine Registry zu kontaktieren — das ist der Unterschied zwischen einem funktionierenden Edge-Standort und einem hängenden Rollout, wenn die Anbindung dünn ist.

Der Datastore ist die zweite Schlagzeile. k3s nutzt standardmäßig SQLite statt etcd; etcd, MySQL und PostgreSQL stehen als Alternativen bereit. Für Hochverfügbarkeit betreiben Sie drei oder mehr Server mit eingebettetem etcd oder richten k3s auf eine externe Datenbank.

Die Mindestanforderungen liegen bei 2 Kernen und 2 GB für einen Server, 1 Kern und 512 MB für einen Agent. Der veröffentlichte Sizing-Leitfaden ist nützlicher als die Minima: Ein Server mit 2 vCPU / 4 GB trägt bis zu 350 Agents, 4 vCPU / 8 GB bis zu 900, und ein Drei-Server-HA-Setup skaliert rund 50 % weiter — drei Server mit 4 vCPU / 8 GB erreichen etwa 1.200 Agents.

Ein Hinweis aus der Dokumentation, der Homelab-Bauer erwischt: etcd ist schreibintensiv, und SD-Karten sowie eMMC halten die IO-Last nicht aus. Wer k3s mit eingebettetem etcd auf einem Raspberry Pi betreibt, sollte eine externe SSD verwenden.

k0s — Minimal aus Prinzip, und die einzige mit isolierter Control Plane

k0s bezieht die Gegenposition und sagt das offen. Der dokumentierte Anspruch lautet, so wenige Add-ons wie möglich mitzuliefern, weil Dinge wie Ingress, Service Meshes und Storage “VERY opinionated” seien und das Nachziehen vieler gebündelter Add-ons bei Upstream-Releases sehr wartungsintensiv ist.

Sie bekommen also den Kern — Konnectivity, CoreDNS, Metrics Server, containerd mit runc, Kube-router als Standard-CNI mit Calico als vorkonfigurierter Alternative — und keinen Ingress-Controller.

Die architektonische Entscheidung, die k0s wirklich abhebt, ist diese: Auf den Controllern laufen standardmäßig weder Container-Engine noch Kubelet. Die Control-Plane-Komponenten laufen als gewöhnliche Prozesse, überwacht von der k0s-Binärdatei selbst. Die praktische Folge: Ein Cluster-Nutzer kann auf Controller-Knoten keine Workloads planen — Control-Plane-Isolation ist der Standard, nicht etwas, das man mit Taints konfiguriert.

Dieselbe Control Plane, vier verschiedene Verpackungen. Unterschiedlich ist, wo die Komponenten laufen und wie viel mitkommt.

Auch die Paketierung ist stärker, als sie zunächst wirkt. Die Binärdatei ist statisch kompiliert und hat außer dem Kernel keine Abhängigkeiten auf Betriebssystemebene: keine RPMs, keine Snaps, keine distributionsspezifische Paketierung. Die in der Doku genannte Motivation ist ein reales Betriebsproblem — wenn Kubernetes auf einem Host-OS läuft, das unabhängig aktualisiert wird, gehört niemandem die Lücke dazwischen. k0s schließt sie, indem es nicht vom Host abhängt.

Die Anforderungen liegen bei 1 vCPU und 1 GB für einen Controller, 0,5 vCPU und 1 GB für einen Worker. Die gemessenen Zahlen sind ehrlicher als Minima: Ein Controller mit einem Worker und ohne Pods liegt bei etwa 510 MB, mit 20 Workern und 2.000 Pods bei rund 1 GB, mit 200 Workern und 20.000 Pods bei etwa 3,3 GB.

Die Architekturen umfassen x86-64, ARM64 und ARMv7 sowie RISC-V — mit dem in der Doku genannten Vorbehalt, dass es für RISC-V keine vorkompilierten Binärdateien und keine CI-Abdeckung gibt. Windows-Unterstützung ist experimentell.

Das gemeinsame Geheimnis: beide laufen auf kine

Ein Detail erklärt, warum sich k3s und k0s unter der Haube ähneln. Kubernetes unterstützt normalerweise nur etcd als Datastore. Beide Projekte umgehen das mit kine , einem Shim, der die etcd-API in SQL übersetzt — und k0s übernimmt kine direkt aus dem k3s-Projekt.

Deshalb können beide ein Einzelknoten-Cluster auf SQLite starten und später auf MySQL oder PostgreSQL wechseln. Es bedeutet aber auch, dass für beide derselbe Kompromiss gilt: SQLite ist eine einzelne Datei auf einem einzelnen Knoten. Hervorragend für eine Maschine — und kein hochverfügbarer Datastore.

MicroK8s — Das Workstation-Cluster, mit einer Meinung zur Paketierung

MicroK8s ist Canonicals Distribution, und ihr prägendes Merkmal ist der Auslieferungsweg: Sie installiert sich als Snap.

Terminal window


sudo snap install microk8s --classic --channel=1.35

Diese eine Zeile ist tatsächlich der schnellste Weg zu einem Cluster auf einem Ubuntu-Laptop — und zugleich der Grund, warum MicroK8s in manchen Flotten ausscheidet. Wenn Ihre Produktionshosts kein snapd betreiben — und viele gehärtete, minimale oder nicht-Ubuntu-basierte Server-Images tun das nicht — ist das ein hartes Ausschlusskriterium, keine Unbequemlichkeit.

Canonical gibt an, dass MicroK8s mit nur 540 MB Arbeitsspeicher läuft, empfiehlt aber 4 GB Speicher und 20 GB Festplatte für echte Workloads. Behandeln Sie die 540 MB als Untergrenze für ein leerlaufendes Cluster, nicht als Zusage für Ihre Anwendung.

Zwei betriebliche Eigenheiten, die man vorher kennen sollte:

kubectl ist namensraumgebunden. MicroK8s bringt ein eigenes mit, aufgerufen als microk8s kubectl, um Kollisionen mit einer bestehenden kubectl-Installation zu vermeiden. Die meisten legen sofort einen Alias an.

DNS ist standardmäßig aus. MicroK8s liefert “the minimum of components for a pure, lightweight Kubernetes”, alles Weitere kommt über Add-ons:

Terminal window


microk8s enable dns

microk8s enable hostpath-storage

Wer je zugesehen hat, wie ein frisches MicroK8s-Cluster einen Servicenamen nicht auflöst und etwas für kaputt hielt: Das ist der Grund. Es ist eine Designentscheidung, kein Fehler — aber die häufigste Überraschung in der ersten Stunde.

Besser als sein Ruf: die Hochverfügbarkeit

MicroK8s wird meist als “Laptop-Cluster” abgelegt, was seine Clustering-Fähigkeiten untertreibt. Hochverfügbarkeit schaltet sich automatisch ein, sobald ein Cluster drei oder mehr Knoten hat — es gibt keinen separaten HA-Modus zu konfigurieren.

Dahinter steht dqlite , und die Knotenrollen lohnen sich zu kennen, weil sie das Ausfallverhalten erklären:

voters replizieren die Datenbank und nehmen an der Leader-Wahl teil
standby -Knoten replizieren die Datenbank, stimmen aber nicht ab
spare -Knoten tun beides nicht und existieren, um befördert zu werden

Die dokumentierten Zeiten sind erfreulich konkret: Verschwindet der Leader unsanft, dauert die Wahl eines neuen bis zu 5 Sekunden , und die Beförderung eines Nicht-Wählers zum Wähler bis zu 30 Sekunden. Jeder Knoten eines HA-MicroK8s-Clusters betreibt die Control Plane, sodass microk8s-Befehle von überall im Cluster funktionieren.

RKE2 — Die, die ein Audit bestehen soll

RKE2 ist SUSEs Distribution und der Ausreißer hier: Sie will gar nicht klein sein. Sie will vor einer Prüferin bestehen. Ihr zweiter Name sagt es deutlich — RKE Government — und ihr erklärter Fokus ist Sicherheit und Compliance im Sektor der US-Bundesbehörden.

Konkret heißt das:

Standardwerte und Konfigurationsoptionen, mit denen Cluster den CIS Kubernetes Benchmark v1.7 oder v1.8 mit minimalem Eingriff bestehen
Unterstützung für FIPS-140-2 -Compliance
CVE-Scans der Komponenten mit Trivy in der Build-Pipeline

Architektonisch ist RKE2 eine bewusste Mischung. Von k3s erbt es Bedienbarkeit und Deployment-Modell. Von RKE1 erbt es die enge Ausrichtung am Upstream-Kubernetes — und Ranchers Doku ist erfreulich direkt darin, warum das zählt: k3s weicht vom Upstream ab, um für Edge-Deployments zu optimieren, während RKE1 und RKE2 eng ausgerichtet bleiben.

Auch die Control Plane läuft anders als bei allen anderen hier. RKE2 startet die Control-Plane-Komponenten als statische Pods, verwaltet vom Kubelet , mit containerd als eingebetteter Runtime. Keine Docker-Abhängigkeit, anders als bei RKE1.

Beim Netzwerk bringt RKE2 vier primäre CNI-Plugins mit — Canal ist der Standard , dazu Cilium, Calico und Flannel sowie Multus als sekundäres Plugin. Eine Warnung aus der Doku verdient Wiederholung, weil man sie sonst teuer lernt: RKE2 unterstützt es nicht, das primäre CNI, das CNI-Backend oder die Cluster- und Service-CIDRs an einem laufenden Cluster zu ändern. Ein späterer Wechsel ist ungetestet und kann verwaiste Interfaces und Routen hinterlassen; das dokumentierte Mittel ist, das Cluster neu zu bauen. Entscheiden Sie vor dem ersten Start.

Ebenfalls neu in diesem Jahr: nftables-Unterstützung , verfügbar ab den Releases vom Juli 2026 (v1.36.3+rke2r1, v1.35.7+rke2r1, v1.34.10+rke2r1) und weiterhin als experimentell markiert. Sie wird von kube-proxy und den meisten mitgelieferten CNIs unterstützt und pro Komponente aktiviert — proxy-mode=nftables für kube-proxy plus eine HelmChartConfig für das CNI.

Die Änderung von 2026: Ingress NGINX ist Geschichte

Das ist das Neueste auf dieser Seite und leicht zu übersehen. Ingress NGINX hat im März 2026 sein Lebensende erreicht. Als direkte Folge liefert RKE2 ab v1.36 Traefik als Standard-Ingress-Controller für neue Cluster aus; für bestehende Cluster gibt es einen dokumentierten Migrationspfad.

Wer sich gerade jetzt auf RKE2 festlegt, den wird dieses Detail später einholen: Cluster, die vor und nach v1.36 gebaut wurden, haben nicht denselben Ingress-Controller, und alle Helm-Werte, Annotationen oder IngressClass-Verweise, die Sie gegen nginx templatisiert haben, müssen überarbeitet werden. Annotationslastige NGINX-Konfigurationen lassen sich nicht sauber übertragen.

Die Vergleichstabelle

	k3s	k0s	MicroK8s	RKE2
Getragen von	SUSE / CNCF, Linux Foundation	Mirantis / LF Projects	Canonical	SUSE Rancher
Paketierung	Einzelne Binärdatei <100 MB	Einzelne statische, selbstentpackende Binärdatei	Snap (`--classic`)	Installer; Control Plane als statische Pods
Standard-Datastore	SQLite	SQLite (ein Knoten), etcd (mehrere)	dqlite	etcd
Control Plane läuft als	Komponenten in einem Prozess	“Nackte” überwachte Prozesse	Snap-Dienste	Statische Pods unter dem Kubelet
Workloads auf der Control Plane	Ja	Nein — standardmäßig isoliert	Ja	Ja
Standard-CNI	Flannel	Kube-router	Im Snap enthalten	Canal (Cilium, Calico, Flannel ebenfalls dabei)
Ingress enthalten	Traefik	Keiner	Add-on	Traefik ab v1.36
Upstream-Nähe	Weicht für Edge ab	100 % Upstream	Upstream	Eng ausgerichtet
Compliance	—	CIS via kube-bench	—	CIS v1.7/v1.8, FIPS 140-2, Trivy
OS-Abhängigkeit	Kernel + cgroups	Nur Kernel	Benötigt snapd	Standard-Linux
Dokumentiertes Minimum	2 Kerne / 2 GB Server	1 vCPU / 1 GB Controller	540 MB Untergrenze, 4 GB empfohlen	Nicht als einzelne Zahl veröffentlicht

Auswählen: Distribution an die Randbedingung anpassen

Vergessen Sie Ranglisten. Jede dieser vier ist die richtige Antwort auf eine bestimmte Frage.

Beginnen Sie bei der Randbedingung, über die Sie nicht verhandeln können — nicht beim Speicherbedarf.

Nehmen Sie RKE2, wenn ein Mensch dieses Cluster prüfen wird. FIPS, CIS-Benchmark-Standardwerte und CVE-Scans in der Pipeline rüstet man an einer anderen Distribution nicht an einem Wochenende nach. Wenn “reguliert”, “Behörde” oder “unser Security-Team muss freigeben” in Ihren Anforderungen auftaucht, ist die Entscheidung bereits gefallen.

Nehmen Sie k3s, wenn das Cluster dort steht, wo Sie schwer hinkommen. Entfernte Standorte, Einplatinencomputer, Air-Gapped-Installationen, CI-Runner. Mitgelieferter Ingress, Load Balancer und Storage-Klasse bedeuten weniger Teile zum Bereitstellen, und der eingebettete Registry-Spiegel hält einen Standort am Leben, wenn seine Anbindung es nicht tut.

Nehmen Sie k0s, wenn Sie Ihre eigene Plattform über eine Flotte standardisieren. Keine Host-OS-Abhängigkeit, Control-Plane-Isolation gratis, k0sctl fürs Lifecycle-Management und die bewusste Weigerung, Ihren Ingress für Sie auszuwählen. Wenn Sie ohnehin wissen, welches CNI und welchen Ingress Sie wollen, bleibt k0s Ihnen aus dem Weg — und die isolierte Control Plane ist eine echte Sicherheitseigenschaft, die Sie sonst mit Taints und Hoffnung durchsetzen müssten.

Nehmen Sie MicroK8s, wenn das Cluster auf einer Ubuntu-Workstation lebt. Für lokale Entwicklung, Demos und Lehre ist ein Snap-Befehl plus Add-on-Liste schwer zu schlagen. Prüfen Sie, ob snapd auf Ihren Servern akzeptabel ist, bevor Sie es weiter befördern.

Und minikube für nichts davon. Es ist ein Entwicklungswerkzeug für ein Cluster auf der eigenen Maschine und gehört nicht in dieselbe Kategorie wie die vier oben — es ist nichts, was man an einen Standort ausrollt.

Was häufig schiefgeht

Ein paar Fehlermuster, die echte Zeit kosten:

Einzelknoten-k3s auf SQLite als Produktion behandeln. Das ist eine Datei auf einer Maschine. Für alles mit Verfügbarkeitserwartung: drei Server mit eingebettetem etcd oder ein externer Datastore.
Veröffentlichte Speicherminima direkt vergleichen. Sie werden unter verschiedenen Bedingungen und gegen verschiedene Komponentensätze gemessen. Ein nackter k0s-Controller und ein k3s-Server mit Traefik plus ServiceLB sind nicht dasselbe Cluster.
Annehmen, ARM sei gleich ARM. k0s deckt ARM64 und ARMv7 ab und nennt RISC-V — ohne vorkompilierte Binärdateien und ohne CI-Abdeckung. Prüfen Sie die konkrete Architektur, nicht die Familie.
Eingebettetes etcd auf Flash-Speicher betreiben. etcd ist schreibintensiv; SD-Karten und eMMC überleben das nicht. Nutzen Sie eine SSD.
Heute auf RKE2 gegen nginx templatisieren. Mit dem Lebensende von Ingress NGINX und Traefik als Standard ab v1.36 hat diese Annahme ein Ablaufdatum.
Planen, “das CNI später zu wechseln” bei RKE2. Die Doku sagt klar, dass das Ändern des primären CNI, seines Backends oder der Cluster- und Service-CIDRs an einem laufenden Cluster nicht unterstützt wird. Diese Entscheidung fällt einmal, vor dem ersten Start.

Eine kurze Checkliste

Schreiben Sie die Randbedingung auf, über die Sie nicht verhandeln können — Audit, Anbindung, Host-OS oder gar keine.
Prüfen Sie, ob snapd auf den Zielhosts erlaubt ist. Das schließt MicroK8s in einem Schritt aus oder ein.
Entscheiden Sie, ob Sie einen vorgegebenen Ingress wollen oder Ihren eigenen. Das trennt k3s und k0s klarer als jeder Benchmark.
Wenn die Control Plane keine Workloads tragen darf: Nur k0s liefert das ohne Konfiguration.
Für alles Hochverfügbare zuerst den Datastore planen: drei Server mit eingebettetem etcd oder eine externe Datenbank. SQLite ist eine Einzelknoten-Antwort.
Wenn es RKE2 wird: Version festnageln und prüfen, auf welcher Seite von v1.36 Sie stehen, bevor Sie Ingress-Manifeste schreiben.

Das ehrliche Fazit

Diese vier Distributionen konkurrieren nicht darum, die leichteste zu sein. Sie kodieren vier verschiedene Meinungen darüber, was ein Team selbst entscheiden sollte.

k3s entscheidet das meiste für Sie und optimiert für Orte, an denen selten jemand vorbeischaut. k0s entscheidet fast nichts und übergibt Ihnen eine saubere, isolierte Basis. MicroK8s entscheidet die Paketierung und überlässt den Rest den Add-ons. RKE2 entscheidet die Sicherheitshaltung, weil in seinem Zielsektor nur diese Entscheidung zählt.

Nehmen Sie die, deren Meinungen Sie ohnehin teilen. Das ist eine haltbarere Grundlage als ein Speicherbedarf, der sich mit dem nächsten Release ändert.

Weiterlesen: Für die Schicht über diesen Clustern siehe Platform Engineering auf Kubernetes und GitOps mit Argo CD. Zum Härten der gewählten Distribution siehe OPA vs Kyverno und die Secure-by-Default-GKE-Referenzarchitektur.

Quellen: Alle Zahlen und Aussagen stammen aus der jeweiligen Projektdokumentation — k3s-Doku, k3s-Anforderungen, k0s-Doku, k0s-Architektur, MicroK8s Getting Started und RKE2-Doku.

Ursprünglich veröffentlicht auf alekseialeinikov.com

k3s vs k0s vs MicroK8s vs RKE2: Which Kubernetes to Install When You Don't Need the Full One

Aleksei Aleinikov — Thu, 20 Aug 2026 12:00:00 +0000

Every comparison of lightweight Kubernetes distributions opens with a table of memory footprints, and every one of them misses the point.

The interesting question is not which distribution is smallest. It is what each one decided to throw away, and whether you can live without it. A Kubernetes control plane has a fixed set of jobs; the difference between these four projects is which of those jobs they hand to you, which they hide, and which they refuse to have an opinion about at all.

Here is what actually separates them in 2026 — including a change that landed this year and quietly rewrote one distribution’s defaults.

First: “Lightweight” Means Three Different Things

Before comparing anything, it is worth separating three claims that get blended together:

A small install artifact. k3s ships as a single binary under 100MB. k0s is a single self-extracting binary that embeds the Kubernetes components and is statically compiled.
A low memory floor. How little RAM the control plane needs before you put any workload on it.
Few bundled components. How much of a cluster you get before you install anything yourself.

These pull in opposite directions. A distribution that bundles an ingress controller, a load balancer and a storage provisioner gives you a working cluster faster — and uses more memory doing it. When you see one project claim a lower footprint than another, check whether it is measuring the same cluster.

k3s — Batteries Included, Optimised for the Edge

k3s is the one most people mean when they say “lightweight Kubernetes.” The name is a joke about size: Kubernetes is a ten-letter word stylised as K8s, so something half as big is a five-letter word stylised as K3s. There is no long form and no official pronunciation.

What makes it distinctive is how much arrives in that single binary:

containerd as the container runtime
Flannel for CNI
CoreDNS for cluster DNS
Traefik as the ingress controller
ServiceLB as a load-balancer controller
Kube-router for network policy
local-path-provisioner for persistent volumes
Spegel , an embedded distributed container image registry mirror
host utilities like iptables and socat

That last one matters more than it looks. Spegel lets nodes pull images from each other instead of reaching out to a registry, which is the difference between a working edge site and a stalled rollout when the uplink is thin.

The datastore is the other headline. k3s defaults to SQLite rather than etcd, with etcd, MySQL and PostgreSQL available as alternatives. For high availability you run three or more servers with embedded etcd, or point k3s at an external database.

Minimum requirements are 2 cores and 2GB for a server, 1 core and 512MB for an agent. The published sizing guide is more useful than the minimums: a 2 vCPU / 4GB server handles up to 350 agents, 4 vCPU / 8GB handles up to 900, and a three-server HA setup scales roughly 50% further — three servers at 4 vCPU / 8GB reach about 1,200 agents.

One caveat from the docs that catches homelab builders: etcd is write-intensive, and SD cards and eMMC cannot handle the IO. If you run k3s on a Raspberry Pi with embedded etcd, use an external SSD.

k0s — Minimal on Purpose, and the Only One That Isolates the Control Plane

k0s takes the opposite position, and states it openly. Its documented scope is to bundle as few add-ons as possible, because things like ingress, service meshes and storage are “VERY opinionated” and keeping up with upstream releases of many bundled add-ons is maintenance-heavy.

So you get the core — Konnectivity, CoreDNS, Metrics Server, containerd with runc, Kube-router as the default CNI with Calico as a preconfigured alternative — and no ingress controller.

The architectural decision that actually distinguishes k0s is this: its controllers run no container engine and no kubelet by default. The control plane components run as ordinary processes supervised by the k0s binary itself. The practical consequence is that a cluster user cannot schedule workloads onto controller nodes — control plane isolation is the default, not something you configure with taints.

The same control plane, packaged four different ways. What differs is where the components run and how much arrives with them.

The packaging claim is also stronger than it first appears. The binary is statically compiled with no OS-level dependencies besides the kernel: no RPMs, no snaps, no distro-specific packaging. The motivation stated in the docs is worth repeating, because it is a real operational problem — when Kubernetes runs on a host OS that upgrades independently, nobody owns the vulnerabilities that come from the gap between them. k0s closes the gap by not depending on the host.

Requirements are 1 vCPU and 1GB for a controller, 0.5 vCPU and 1GB for a worker. The measured numbers are more honest than minimums: a controller with one worker and no pods sits around 510MB; with 20 workers and 2,000 pods, about 1GB; with 200 workers and 20,000 pods, about 3.3GB.

Architectures cover x86-64, ARM64 and ARMv7, plus RISC-V — with the caveat, stated in the docs, that RISC-V has no pre-compiled binaries and no CI coverage. Windows support is experimental.

The shared secret: both run on kine

Here is a detail that explains why k3s and k0s feel similar under the hood. Kubernetes normally supports only etcd as its datastore. Both projects get around this using kine , a shim that translates the etcd API into SQL — and k0s takes kine directly from the k3s project.

That is why both can boot a single-node cluster on SQLite and scale to MySQL or PostgreSQL later. It also means the same trade-off applies to both: SQLite is a single file on a single node. It is excellent for one machine and it is not a highly available datastore.

MicroK8s — The Workstation Cluster, With a Packaging Opinion

MicroK8s is Canonical’s distribution, and its defining characteristic is the delivery mechanism: it installs as a snap.

Terminal window


sudo snap install microk8s --classic --channel=1.35

That single line is genuinely the fastest path to a cluster on an Ubuntu laptop, and it is also the reason MicroK8s is a non-starter in some fleets. If your production hosts do not run snapd — and many hardened, minimal or non-Ubuntu server images do not — this is a hard blocker rather than an inconvenience.

Canonical states MicroK8s runs in as little as 540MB of memory , while recommending 4GB of memory and 20GB of disk to actually accommodate workloads. Treat the 540MB as the floor for an idle cluster, not a promise about your workload.

Two operational quirks worth knowing before you start:

kubectl is namespaced. MicroK8s bundles its own, invoked as microk8s kubectl, specifically to avoid colliding with an existing kubectl install. Most people immediately alias it away.

DNS is not on by default. MicroK8s ships “the minimum of components for a pure, lightweight Kubernetes” and everything else arrives through add-ons:

Terminal window


microk8s enable dns

microk8s enable hostpath-storage

If you have ever watched a fresh MicroK8s cluster fail to resolve a service name and assumed something was broken, this is why. It is a design decision, not a bug — but it is the single most common first-hour surprise.

The part that is better than its reputation: HA

MicroK8s is usually filed under “laptop cluster”, which undersells its clustering story. High availability turns on automatically once a cluster has three or more nodes — there is no separate HA mode to configure.

The datastore behind it is dqlite , and the node roles are worth knowing because they explain the failure behaviour:

voters replicate the database and take part in leader election
standby nodes replicate the database but do not vote
spare nodes do neither, and exist to be promoted

The documented timings are refreshingly specific: if the leader disappears ungracefully it takes up to 5 seconds to elect a new one, and promoting a non-voter to voter takes up to 30 seconds. Every node in an HA MicroK8s cluster runs the control plane, so microk8s commands work from anywhere in the cluster.

RKE2 — The One Built to Pass an Audit

RKE2 is SUSE’s distribution, and it is the outlier here: it is not trying to be small. It is trying to be defensible in front of an auditor. Its other name says it plainly — RKE Government — and its stated focus is security and compliance within the U.S. Federal Government sector.

Concretely, that means:

Defaults and configuration options that let clusters pass the CIS Kubernetes Benchmark v1.7 or v1.8 with minimal operator intervention
FIPS 140-2 compliance support
Components scanned for CVEs with Trivy in the build pipeline

Architecturally, RKE2 is a deliberate hybrid. From k3s it inherits the usability and deployment model. From RKE1 it inherits close alignment with upstream Kubernetes — and Rancher’s docs are refreshingly direct about why that matters: k3s has diverged from upstream in order to optimise for edge deployments, while RKE1 and RKE2 stay closely aligned.

It also runs its control plane differently from everything else here. RKE2 launches control plane components as static pods managed by the kubelet , with containerd as the embedded runtime. No Docker dependency, unlike RKE1.

On networking, RKE2 bundles four primary CNI plugins — Canal is the default , with Cilium, Calico and Flannel also included, plus Multus as a secondary plugin. One warning from the docs deserves repeating because it is expensive to learn the hard way: RKE2 does not support changing the primary CNI, the CNI backend, or the cluster and service CIDRs on a running cluster. Switching later is untested and may leave stale interfaces and routes behind; the documented remedy is to rebuild the cluster. Choose before first start.

Also new this year: nftables support , available as of the July 2026 releases (v1.36.3+rke2r1, v1.35.7+rke2r1, v1.34.10+rke2r1) and still marked experimental. It is supported by kube-proxy and most bundled CNIs, and enabled per component — proxy-mode=nftables for kube-proxy, plus a HelmChartConfig for the CNI.

The 2026 change: Ingress NGINX is gone

This is the newest thing on this page and it is easy to miss. Ingress NGINX reached end-of-life in March 2026. As a direct result, starting with v1.36, RKE2 ships Traefik as the default ingress controller for new clusters ; existing clusters have a documented migration path.

If you are standardising on RKE2 right now, this is the detail that will bite you later: clusters built before and after v1.36 will not have the same ingress controller, and any Helm values, annotations or IngressClass references you templated against nginx will need revisiting. Annotation-heavy NGINX configurations do not port over cleanly.

The Comparison Table

	k3s	k0s	MicroK8s	RKE2
Backed by	SUSE / CNCF, Linux Foundation	Mirantis / LF Projects	Canonical	SUSE Rancher
Packaging	Single binary <100MB	Single static self-extracting binary	snap (`--classic`)	Installer; control plane as static pods
Default datastore	SQLite	SQLite (single node), etcd (multi-node)	dqlite	etcd
Control plane runs as	Components in one process	“Naked” supervised processes	snap services	Static pods under kubelet
Workloads on control plane	Yes	No — isolated by default	Yes	Yes
Default CNI	Flannel	Kube-router	Bundled with the snap	Canal (Cilium, Calico, Flannel also bundled)
Ingress included	Traefik	None	Add-on	Traefik from v1.36
Upstream alignment	Diverges for edge	100% upstream	Upstream	Closely aligned
Compliance story	—	CIS via kube-bench	—	CIS v1.7/v1.8, FIPS 140-2, Trivy
OS dependency	Kernel + cgroups	Kernel only	Requires snapd	Standard Linux
Documented minimum	2 core / 2GB server	1 vCPU / 1GB controller	540MB floor, 4GB advised	Not published as a single figure

Choosing: Match the Distribution to the Constraint

Forget rankings. Every one of these is the right answer to a specific question.

Start from the constraint you cannot negotiate, not from the memory footprint.

Choose RKE2 if a person will audit this cluster. FIPS, CIS benchmark defaults and pipeline CVE scanning are not things you retrofit onto another distribution in a weekend. If “regulated”, “government”, “FedRAMP” or “our security team must sign off” appear anywhere in your requirements, the decision is already made.

Choose k3s if the cluster lives somewhere you cannot easily reach. Remote sites, single-board computers, air-gapped installs, CI runners. The bundled ingress, load balancer and storage class mean fewer moving parts to provision, and the embedded registry mirror keeps a site working when its connection does not.

Choose k0s if you are standardising your own platform across a fleet. No host OS dependency, control plane isolation for free, k0sctl for lifecycle management, and a deliberate refusal to pick your ingress for you. If you already know which CNI and ingress you want, k0s stays out of the way — and the isolated control plane is a genuine security property you would otherwise have to enforce with taints and hope.

Choose MicroK8s if the cluster lives on an Ubuntu workstation. For local development, demos and teaching, one snap command and an add-on list is hard to beat. Verify snapd is acceptable on your servers before promoting it further than that.

And use minikube for none of these. It is a development tool for running a cluster on your own machine, and it is not in the same category as the four above — it is not what you deploy to a site.

What People Get Wrong

A few failure patterns worth naming, since they cost real time:

Treating single-node k3s on SQLite as production. It is one file on one machine. For anything with an uptime expectation, run three servers with embedded etcd or point k3s at an external datastore.
Comparing published memory minimums directly. They are measured under different conditions and against different bundled component sets. A bare k0s controller and a k3s server running Traefik plus ServiceLB are not the same cluster.
Assuming ARM means ARM. k0s covers ARM64 and ARMv7 and lists RISC-V — with no pre-compiled binaries and no CI coverage. Check the specific architecture, not the family.
Running embedded etcd on flash storage. etcd is write-intensive; SD cards and eMMC will not survive it. Use an SSD.
Templating ingress against nginx on RKE2 today. With Ingress NGINX end-of-life and Traefik becoming the v1.36 default, that assumption has an expiry date.
Planning to “switch the CNI later” on RKE2. The docs say plainly that changing the primary CNI, its backend, or the cluster and service CIDRs on a running cluster is unsupported. That decision is made once, before first start.

A Short Checklist

Write down the constraint you cannot negotiate — audit, connectivity, host OS, or nothing at all.
Check whether snapd is permitted on your target hosts. This eliminates or elects MicroK8s in one step.
Decide whether you want an opinionated ingress or your own. That splits k3s from k0s more cleanly than any benchmark.
If the control plane must not run workloads, note that only k0s gives you this without configuration.
For anything highly available, plan the datastore first: three servers with embedded etcd, or an external database. SQLite is a single-node answer.
If you land on RKE2, pin your version and check which side of v1.36 you are on before writing ingress manifests.

The Honest Summary

These four distributions are not competing to be the lightest. They are encoding four different opinions about what a team should have to decide for itself.

k3s decides most of it for you and optimises for places engineers rarely visit. k0s decides almost nothing and hands you a clean, isolated base. MicroK8s decides the packaging and lets add-ons do the rest. RKE2 decides the security posture, because in its target sector that is the only decision that matters.

Pick the one whose opinions you already agree with. That is a more durable basis than a memory footprint that will change with the next release.

Related reading: for the layer above these clusters, see platform engineering on Kubernetes and GitOps with Argo CD. For hardening whichever one you pick, see OPA vs Kyverno and the secure-by-default GKE reference architecture.

Sources: all figures and claims come from each project’s own documentation — k3s docs, k3s requirements, k0s docs, k0s architecture, MicroK8s getting started and RKE2 docs.

Originally published at alekseialeinikov.com

DORA-Metriken 2026: Warum aus vier fünf wurden (und was die meisten Dashboards falsch machen)

Aleksei Aleinikov — Wed, 19 Aug 2026 12:00:00 +0000

Öffnen Sie irgendein Engineering-Dashboard, das DORA zu messen behauptet, und Sie sehen mit ziemlicher Sicherheit vier Kacheln: Deployment-Frequenz, Lead Time, Change Failure Rate und MTTR.

Drei dieser vier Bezeichnungen sind veraltet, und die Auswahl selbst ist unvollständig. DORA ist in der Forschung von 2024 auf fünf Metriken für Software-Delivery-Performance umgestiegen, hat eine davon bereits 2023 umbenannt und eine weitere in eine Kategorie verschoben, die die meisten Teams bis heute falsch einsortieren. Im Jahresrückblick 2025 formuliert DORA es unmissverständlich: “We have also officially evolved the four software delivery performance metrics into five metrics.”

Das ist keine Wortklauberei. Die Änderungen kodieren Erkenntnisse, die unmittelbar beeinflussen, wie Sie Ihre eigenen Zahlen lesen sollten — und eine davon existiert nur deshalb, weil Teams die falsche Art von Fehlern gemessen haben.

Die fünf Metriken, wie sie heute stehen

DORA gruppiert die fünf Metriken in zwei Faktoren: Durchsatz und Instabilität.

Durchsatz — wie Änderungen durch das System fließen

Metrik	Was sie misst
Change Lead Time	Zeit vom Commit in die Versionsverwaltung bis zum Deployment in die Produktion
Deployment-Frequenz	Wie oft Änderungen deployt werden, oder der Abstand zwischen Deployments
Failed Deployment Recovery Time	Wie lange die Erholung von einem Deployment dauert, das fehlschlug und sofortiges Eingreifen erforderte

Instabilität — wie gut diese Deployments verlaufen

Metrik	Was sie misst
Change Fail Rate	Anteil der Deployments, die sofortiges Eingreifen erfordern — ein Rollback oder einen Hotfix
Deployment Rework Rate	Anteil der Deployments, die ungeplant sind und aus einem Produktionsvorfall resultieren

Zwei Dinge in dieser Tabelle überraschen alle, die die vier Keys vor Jahren gelernt haben.

Die Recovery-Zeit steht beim Durchsatz. Ein Jahrzehnt lang lebte sie auf der Stabilitätsseite, als Gegengewicht zur Geschwindigkeit. Heute gehört sie zu den Flussmaßen. Die Logik trägt, sobald man auf die Form der Zahlen schaut: Instabilität wird in Verhältnissen ausgedrückt — welcher Anteil Ihrer Deployments schiefgeht — während der Durchsatz die Zeit- und Mengenmaße dafür abdeckt, wie Änderungen in die Produktion gelangen. Die Erholung von einem fehlgeschlagenen Deployment ist selbst eine Änderung, die in die Produktion geht, nur unter maximalem Druck.

Es gibt eine Metrik, die die meisten Teams nie erfasst haben. Die Deployment Rework Rate ist die Neuzugängerin, und ihre Entstehungsgeschichte ist der interessanteste Teil der Forschung von 2024.

Warum eine fünfte Metrik nötig war

DORAs Forschende bemerkten, dass die Change Fail Rate still und leise zwei Aufgaben erfüllte. Sie sollte erfassen, wie oft Deployments schiefgehen — Teams nutzten sie aber zugleich als Stellvertreter dafür, wie viel Nacharbeit ein Team leisten muss.

Das ist nicht dasselbe, und die Vermischung verdeckt einen realen Fehlermodus. Ein Team kann eine respektable Change Fail Rate haben, während ein großer Teil seines Deployment-Volumens ungeplante Arbeit ist, die aus Vorfällen entsteht. Auf einem Vier-Metriken-Dashboard sieht dieses Team gut aus. Tatsächlich wird ein wachsender Anteil seiner Kapazität dafür verbraucht, die Produktion zu reparieren, statt Neues zu liefern.

Die Deployment Rework Rate trennt beides. Die Change Fail Rate fragt: Hat dieses Deployment etwas kaputtgemacht? Die Rework Rate fragt: War dieses Deployment nur nötig, weil bereits etwas kaputt war?

Wer je beobachtet hat, wie die Deployment-Frequenz eines Teams steigt und trotzdem niemand ein einziges neues Feature benennen kann, hat genau die Lücke gesehen, die diese Metrik schließt.

Fünf Metriken, zwei Faktoren. Die Recovery-Zeit wanderte zum Durchsatz; die Rework Rate ist die Ergänzung von 2024.

Die Umbenennung, die einen echten Messfehler behob

Bevor sich die Anzahl änderte, änderten sich die Definitionen. 2023 benannte DORA die lange als MTTR oder Time to Restore Service bekannte Metrik in Failed Deployment Recovery Time um.

Die Begründung war präzise. Die alten Definitionen unterschieden nicht zwischen:

einem Ausfall, der durch eine von Ihnen deployte Änderung verursacht wurde, und
einem Ausfall, der ganz andere Ursachen hat — eine ausgefallene Cloud-Region, eine Störung beim Anbieter, ein Problem im Rechenzentrum.

Das gehört zu verschiedenen Systemen. Das erste ist eine Eigenschaft Ihres Lieferprozesses, das zweite eine Eigenschaft Ihrer Infrastruktur und Ihres Glücks. Beides zusammenzumitteln ergab eine Zahl, die sich aus Gründen bewegte, die nichts mit der Arbeitsweise des Teams zu tun hatten — genau das, was man von einer Delivery-Metrik nicht will. Die Einengung auf Beeinträchtigungen, die durch eine Änderung an der Produktion verursacht wurden, brachte sie statistisch mit den übrigen Delivery-Metriken in Einklang.

Die praktische Konsequenz: Wenn die MTTR-Kachel Ihres Dashboards von jedem Vorfall in Ihrem Incident-Tracker gespeist wird, ist sie nicht die DORA-Metrik. Sie ist eine Mischung aus zwei verschiedenen Signalen, und man kann nicht sauber auf sie reagieren.

Der Mythos von “Reliability, der fünften Metrik”

Sie finden bis heute Artikel, Präsentationen und Anbieterseiten, die Reliability als fünfte DORA-Metrik bezeichnen. Diese Einordnung stammt aus DORAs eigenem Report von 2021 — und DORA hat sie inzwischen korrigiert.

Die Historie der Metriken hält fest, dass der Report von 2021 “inaccurately called the ‘reliability’ metric the ‘fifth metric’ when, in reality, ‘reliability’ is more a measure of operational performance than a measure of software delivery performance.”

Die Unterscheidung ist wichtig. Reliability, gemessen über Service Level Objectives, beschreibt, wie gut sich die Software für Nutzer verhält, sobald sie läuft. Software-Delivery-Performance beschreibt, wie gut Änderungen in die Produktion gelangen. Beides gehört ins DORA-Core-Modell, aber es sind verschiedene Konstrukte, und sie beantworten verschiedene Arbeit.

Beachten Sie auch, was das für die Prüfung der eigenen Dokumentation bedeutet: Die Vier-gegen-fünf-Verwirrung ist nicht nur ein Nachhinken der Branche. Selbst DORAs Core-Modell, das bewusst konservativ ist und — in DORAs Worten — “deliberately trails the research”, zeigt weiterhin die ältere Vierergruppierung. Die Guides und die aktuelle Forschung sind ihm voraus. Das ist Absicht, aber ein guter Grund, bei allem, was Sie lesen, auf das Datum zu schauen.

Messen, ohne eine Plattform zu kaufen

Sie brauchen keinen Anbieter, um anzufangen. Vier der fünf Metriken fallen aus Deployment-Ereignissen heraus; die fünfte braucht ein wenig menschliche Eingabe, die keine API für Sie ableiten kann.

Beginnen Sie bei Deployments , nicht bei Pull Requests. Das ist der mit Abstand häufigste Instrumentierungsfehler, und er lässt die Lead Time weit besser aussehen, als sie ist.

# Change Lead Time aus GitHub-Deployment-Ereignissen.
# Entscheidend: ab dem ERSTEN Commit der Änderung messen, nicht ab dem PR-Merge.

import statistics

from datetime import datetime, timezone

def lead_time_seconds(deployment_finished_at, commit_authored_at):

    return (deployment_finished_at - commit_authored_at).total_seconds()

def summarise(samples):

    """Median berichten. Lieferzeiten haben lange Ausläufer, die ein Mittelwert verdeckt."""

    if not samples:

        return None

    return {

        "p50": statistics.median(samples),

        "p90": statistics.quantiles(samples, n=10)[8] if len(samples) > 1 else samples[0],

        "n": len(samples),

    }

Warum der erste Commit und nicht der Merge? Weil die Review-Warteschlange Teil Ihrer Lead Time ist. Ein Team mit einer Zwei-Stunden-Pipeline und einem Vier-Tage-Review-Rückstau hat keine Lead Time von zwei Stunden — und ab dem Merge zu messen ist genau der Weg, auf dem dieser Rückstau für alle oberhalb des Teams unsichtbar bleibt.

Für die übrigen Metriken übersetzen sich die Definitionen in einfache Verhältnisse über ein Zeitfenster:

deployment_frequenz = erfolgreiche_produktions_deployments / zeitfenster
change_fail_rate = deployments_mit_sofortigem_eingriff / alle_deployments
deployment_rework_rate = ungeplante_deployments_nach_vorfall / alle_deployments

Die Eingabe, die Ihr Git-Host nicht liefern kann, ist die Information, welche Deployments sofortiges Eingreifen erforderten und welche ungeplante Vorfallsarbeit waren. Sie muss von dort kommen, wo Ihr Team die Realität ohnehin festhält — aus dem Incident-Tracker, einem Rollback-Label, einer Deployment-Annotation. Ein pragmatischer Anfang ist ein einziges Pflichtfeld an jedem Produktions-Deployment: planned, hotfix oder rollback. Drei Werte, beim Deployment ausgefüllt, genügen für beide Instabilitätsmetriken.

DORA sagt ausdrücklich, dass Teams hier überinvestieren. Integrationen über alle Systeme hinweg zu bauen, um präzise Zahlen zu bekommen, “might not be worth the initial investment” — mit Gesprächen zu beginnen oder mit dem DORA Quick Check führt oft schneller zu Verbesserung als eine perfekte Telemetrie-Pipeline.

Wer die schnellstmögliche Bestätigung will, dass die fünfte Metrik real und keine reine Dokumentationsänderung ist: DORA hat den Quick Check im April 2026 aktualisiert, sodass er die Deployment Rework Rate und neue Branchen-Benchmarks enthält. Das Werkzeug fragt sie inzwischen ab.

Wo diese Zahlen kaputtgehen

Jede DORA-Metrik hat eine triviale Gaming-Strategie. Das ist kein Mangel der Metriken; das passiert jedem Maß, das zum Ziel wird. DORA führt “Metriken zum Ziel machen” als ersten häufigen Fallstrick auf und nennt Goodharts Gesetz beim Namen.

Jede Metrik lässt sich offensichtlich fälschen. Alle fünf auf dieselbe Weise: indem man die Erfassung ändert, nicht das System.

Metrik	Wie sie manipuliert wird	Was Sie tatsächlich sehen
Deployment-Frequenz	Eine Änderung auf sechs Deployments aufteilen	Die Zahl verdreifacht sich, nichts geht schneller live
Change Lead Time	Ab PR-Merge statt ab erstem Commit messen	Der Review-Rückstau verschwindet aus den Daten
Failed Deployment Recovery Time	Erholung mit dem Ende des Rollbacks erklären, nicht mit bedienten Nutzern	Schnelle Erholung, unzufriedene Nutzer
Change Fail Rate	Kleine Fehler nicht mehr als Fehler erfassen	Eine Weltklassezahl bei sich verschlechterndem System
Deployment Rework Rate	Den Hotfix als geplante Arbeit einbuchen	Nacharbeit wird unsichtbar

Beachten Sie das Muster: Keine dieser Maßnahmen ändert das System, alle ändern die Erfassung. Das ist das verräterische Zeichen. Wenn sich eine Metrik verbessert und niemand eine geänderte Praxis benennen kann, hat sich die Erfassung geändert.

Die übrigen Fallstricke, die DORA benennt, lohnen sich zu kennen, weil sie in fast jeder Einführung auftauchen:

Eine Metrik, die alle beherrscht. Komplexe Systeme brauchen mehrere Maße, die in Spannung zueinander stehen. Eine einzelne Zahl wird immer auf Kosten von etwas Ungemessenem optimiert.
Ungleiche Vergleiche. Diese Metriken gelten für eine Anwendung oder einen Service. Eine Mobile-App mit einem Mainframe-System zu vergleichen oder Zahlen über eine ganze Organisation zu mischen, ergibt etwas, das wie eine Rangliste aussieht und nichts bedeutet.
Getrennte Verantwortung. Wenn nur Ops für Stabilität und nur Dev für Durchsatz zuständig ist, haben Sie eine Maschine zum Fingerzeigen gebaut. Die fünf sind als gemeinsame Verantwortung gedacht.
Wettbewerb. Ziel ist die Verbesserung gegenüber der eigenen Vergangenheit, nicht der Sieg über ein anderes Team.
Die Branche als Schutzschild. “Wir sind reguliert, deshalb können wir nicht häufiger deployen” ist meist eine Aussage über einen Prozess, den niemand überprüft hat, nicht über die Regulierung.

Die schärfste Version dieses Problems ist der Einsatz von DORA-Metriken auf Einzelpersonen. Die Metriken sind als Prädiktoren auf Teamebene für organisationale Performance und Wohlbefinden validiert. Auf eine Person angewendet, messen sie deren Position in einer Warteschlange.

Die Ausgabe 2026 desselben Fehlers: Tokenmaxxing

Das neueste Beispiel ist gar keine DORA-Metrik — und genau das macht es lehrreich.

Im Juni 2026 veröffentlichte DORA zu einem Trend, den es Tokenmaxxing nennt: Organisationen erfassen und belohnen den reinen Verbrauch von KI-Tokens über interne Ranglisten, um die Einführung zu beschleunigen. DORAs Einschätzung ist abgewogen — diese Gamification kann KI-skeptische Entwickelnde tatsächlich zum Ausprobieren bewegen — aber das Fazit ist deutlich: Token-Verbrauch als Leistungsindikator zu behandeln, ist eine gefährliche Falle.

Es ist derselbe Fehler wie die Deployment-Frequenz im Mitarbeitergespräch, nur eine Abstraktionsebene höher. Token-Verbrauch misst Aktivität. Er lässt sich trivial maximieren, indem man mehr generiert, weniger prüft und größere Kontexte einfügt. Wer in seiner Organisation gelernt hat, blanke Commit-Zählungen nicht zu belohnen, weiß bereits, warum das hier schlecht endet.

Was KI verändert hat

DORA benannte seinen Jahresreport 2025 von Accelerate State of DevOps in State of AI-assisted Software Development um, und die Kernaussage dieser Forschung ist ein nützliches Korrektiv — sowohl gegen den Hype als auch gegen die Gegenreaktion.

KI wird als Verstärker beschrieben: Sie vergrößert die vorhandenen Stärken und Schwächen einer Organisation. Konkret fand DORA, dass KI den Durchsatz verbessert, oft aber auf Kosten der Stabilität, wenn das Fundament nicht solide ist. Der Report formuliert es so, dass die größten Erträge einer KI-Investition “not from the tools themselves, but from a strategic focus on the underlying organizational system” kommen.

Liest man das gegen das Fünf-Metriken-Modell, wirkt dessen Aufbau plötzlich vorausschauend. Wenn KI den Durchsatz hebt, während schwache Fundamente diese Geschwindigkeit in Defekte verwandeln, dann sind genau die beiden Instabilitätsverhältnisse die Metriken, die den Schaden auffangen — und eine davon, die Deployment Rework Rate, existierte vor zwei Jahren noch nicht auf Ihrem Dashboard. Ein Team, das mit KI schneller liefert und nur vier Metriken verfolgt, hat genau die Hälfte des Bildes instrumentiert, die garantiert gut aussieht.

DORAs begleitendes AI Capabilities Model von Ende 2025 benennt sieben Fähigkeiten, die den Nutzen von KI verstärken, darunter starke Versionsverwaltungspraktiken, Arbeit in kleinen Losgrößen, eine hochwertige interne Plattform, KI-zugängliche interne Daten sowie eine klare und kommunizierte KI-Haltung. Drei davon sind gewöhnliche Delivery-Hygiene, die KI um ein Jahrzehnt vorausgeht. Genau das ist der Punkt.

DORAs Folgearbeiten aus 2026 verschärfen die Warnung. Die Analyse zu den KI-Spannungen vom März 2026 beschreibt die versteckten Kosten, die mit schnellerer Codegenerierung einhergehen: Prüfaufwand, Kompetenzverlust und Integrationsreibung. Der aktuelle Report ROI of AI-assisted Software Development ist um dieselbe Realität herum gebaut und gibt Führungskräften einen Rahmen für den anfänglichen “productivity dip” einer Einführung. Nichts davon taucht im Durchsatz auf. Alles davon taucht in der Nacharbeit auf.

Eine praktische Checkliste

Wenn Sie Ihr DORA-Setup modernisieren wollen, grob nach Wirkung sortiert:

Zählen Sie Ihre Kacheln. Sind es vier, fehlt die Deployment Rework Rate.
Prüfen Sie, was Ihre Recovery-Metrik speist. Enthält sie Vorfälle, die nicht von einem Deployment stammen, ist sie nicht die Failed Deployment Recovery Time.
Verlegen Sie den Start der Lead Time auf den ersten Commit. Beginnt sie beim Merge, verstecken Sie Ihre Review-Warteschlange.
Ergänzen Sie drei Werte am Deployment-Datensatz : planned, hotfix, rollback. Beide Instabilitätsmetriken fallen daraus ab.
Berichten Sie Mediane — und n. Ein p50 ohne Stichprobengröße ist ein Gerücht.
Beschränken Sie sich auf einen Service. Über die Organisation gemischte Zahlen sind für Folien, nicht für Entscheidungen.
Nehmen Sie sie aus Mitarbeitergesprächen heraus. Hängen sie an individuellen Ergebnissen, ist alles Obige vergeudet.
Koppeln Sie jede Metrik an ein Gespräch. DORAs eigene Empfehlung ist, dass die Verbesserung aus der Diskussion über Engpässe kommt, nicht aus dem Dashboard.

Was bleibt

Streicht man die Versionsänderungen, steht DORAs zentrale Erkenntnis von 2015 unverändert — und sie ist weiterhin der Grund, warum diese Metriken zählen: Geschwindigkeit und Stabilität sind kein Zielkonflikt. Teams, die gut sind, sind es über alle fünf hinweg. Teams, die schlecht sind, sind es über alle fünf hinweg. Die Metriken korrelieren.

Dave Farleys Formulierung, die DORA im eigenen Guide zitiert, ist die, die man sich merken sollte: “the real trade-off, over long periods of time, is between better software faster and worse software slower.”

Die fünf Metriken sind ein Kompass dafür, mehr nicht. Sie zeigen Ihnen, wo Ihr Liefersystem eingeschränkt ist. Sie sagen Ihnen nicht, wen Sie befördern sollen, welches Team das beste ist oder ob sich Ihre KI-Einführung gelohnt hat — und jeder Fehlermodus in diesem Artikel entsteht daraus, ihnen eine Frage zu stellen, für die sie nie gebaut wurden.

Weiterlesen: Wenn Sie das Liefersystem bauen, das diese Metriken messen, beginnen Sie mit Platform Engineering auf Kubernetes und GitOps mit Argo CD. Für die Pipeline selbst siehe das Hardening-Playbook für sichere GitLab-CI/CD-Pipelines.

Quellen: Alle Fakten in diesem Artikel stammen aus DORAs eigenen Publikationen — dem Guide zu den Software-Delivery-Performance-Metriken, der Historie der DORA-Metriken, dem Jahresrückblick 2025 und der Übersicht zum Report 2025.

Ursprünglich veröffentlicht auf alekseialeinikov.com

DORA Metrics in 2026: Why Four Became Five (and What Most Dashboards Still Get Wrong)

Aleksei Aleinikov — Wed, 19 Aug 2026 12:00:00 +0000

Open any engineering dashboard that claims to track DORA and you will almost certainly see four tiles: deployment frequency, lead time, change failure rate, and MTTR.

Three of those four labels are out of date, and the set itself is incomplete. DORA moved to five software delivery metrics in its 2024 research, renamed one of them back in 2023, and moved another into a category most teams still get wrong. In its 2025 year in review, DORA stated it plainly: “We have also officially evolved the four software delivery performance metrics into five metrics.”

This is not pedantry about naming. The changes encode findings that directly affect how you should read your own numbers — and one of them exists specifically because teams were measuring the wrong kind of failure.

The Five Metrics, As They Stand Now

DORA groups the five metrics into two factors: throughput and instability.

Throughput — how changes move through the system

Metric	What it measures
Change lead time	Time from a change being committed to version control until it is deployed to production
Deployment frequency	How often application changes are deployed, or the time between deployments
Failed deployment recovery time	How long it takes to recover from a deployment that failed and required immediate intervention

Instability — how well those deployments go

Metric	What it measures
Change fail rate	The ratio of deployments that require immediate intervention — a rollback or a hotfix
Deployment rework rate	The ratio of deployments that are unplanned, happening as a result of a production incident

Two things in that table surprise people who learned the four keys years ago.

Recovery time is under throughput. For a decade it lived on the stability side, as the counterweight to speed. It is now grouped with the flow measures. The logic holds up once you look at the shape of the numbers: instability is expressed as ratios — what proportion of your deployments go badly — while throughput covers the time and count measures of changes moving to production. Recovering from a failed deployment is itself a change being pushed to production, just under maximum pressure.

There is a metric most teams have never recorded. Deployment rework rate is the newcomer, and its origin story is the most interesting part of the 2024 research.

Why a Fifth Metric Was Needed

DORA’s researchers noticed that change fail rate was quietly doing two jobs. It was meant to capture how often deployments go wrong, but teams were also treating it as a proxy for how much rework the team ends up doing.

Those are not the same thing, and conflating them hides a real failure mode. A team can have a respectable change fail rate while a large share of its deployment volume is unplanned work generated by incidents. On a four-metric dashboard that team looks fine. In reality a growing fraction of its capacity is being consumed by fixing production rather than delivering anything new.

Deployment rework rate separates the two. Change fail rate asks did this deployment break something? Rework rate asks was this deployment only necessary because something was already broken?

If you have ever watched a team’s deployment frequency climb while nobody could name a single new feature that shipped, you have seen the gap that this metric fills.

Five metrics, two factors. Recovery time moved into throughput; rework rate is the 2024 addition.

The Renaming That Fixed a Real Measurement Bug

Before the count changed, the definitions did. In 2023, DORA renamed the metric long known as MTTR or time to restore service to failed deployment recovery time.

The reasoning was precise. The old definitions did not distinguish between:

a failure caused by a change you deployed, and
a failure caused by something else entirely — a cloud region going down, a provider outage, a data centre problem.

Those belong to different systems. The first is a property of your delivery process; the second is a property of your infrastructure and your luck. Averaging them together produced a number that moved for reasons unrelated to how the team worked, which is exactly what you do not want from a delivery metric. Narrowing the definition to impairments caused by a change to production aligned it statistically with the other delivery metrics.

The practical consequence: if your dashboard’s “MTTR” tile is fed by every incident in your incident tracker, it is not the DORA metric. It is a mix of two different signals, and you cannot act on it cleanly.

The Myth of “Reliability, the Fifth Metric”

You will still find articles, decks, and vendor pages calling reliability the fifth DORA metric. That framing came from DORA’s own 2021 report — and DORA has since corrected it.

The history of the metrics states that the 2021 report “inaccurately called the ‘reliability’ metric the ‘fifth metric’ when, in reality, ‘reliability’ is more a measure of operational performance than a measure of software delivery performance.”

The distinction matters. Reliability, measured through service level objectives, is about how well the software behaves for users once it is running. Software delivery performance is about how well changes get to production. Both belong in the DORA Core model, but they are different constructs and they answer to different work.

Note also what this means for anyone auditing their own documentation: the four-versus-five confusion is not just an industry lag. Even DORA’s Core model, which is deliberately conservative and — in DORA’s words — “deliberately trails the research”, still presents the older four-key grouping. The guides and the current research are ahead of it. That is by design, but it is a good reason to check the date on whatever you are reading.

Measuring Them Without Buying a Platform

You do not need a vendor to get started. Four of the five come out of deployment events; the fifth needs a small amount of human input that no API can infer for you.

Start from deployments , not pull requests. This is the single most common instrumentation mistake, and it makes lead time look far better than it is.

# Change lead time from GitHub deployment events.
# Key detail: measure from the FIRST commit in the change, not from PR merge.

import statistics

from datetime import datetime, timezone

def lead_time_seconds(deployment_finished_at, commit_authored_at):

    return (deployment_finished_at - commit_authored_at).total_seconds()

def summarise(samples):

    """Report the median. Delivery distributions have long tails that a mean will hide."""

    if not samples:

        return None

    return {

        "p50": statistics.median(samples),

        "p90": statistics.quantiles(samples, n=10)[8] if len(samples) > 1 else samples[0],

        "n": len(samples),

    }

Why the first commit and not the merge? Because the review queue is part of your lead time. A team with a two-hour pipeline and a four-day review backlog does not have a two-hour lead time — and measuring from merge is precisely how that four-day backlog stays invisible to everyone above the team.

For the remaining metrics, the definitions translate into simple ratios over a window:

deployment_frequency = successful_production_deployments / window
change_fail_rate = deployments_needing_immediate_intervention / total_deployments
deployment_rework_rate = unplanned_deployments_caused_by_incident / total_deployments

The input your Git host cannot give you is which deployments needed immediate intervention and which were unplanned incident work. That has to come from somewhere your team already records reality — an incident tracker, a rollback label, a deployment annotation. A pragmatic starting point is a single required field on every production deployment: planned, hotfix, or rollback. Three values, filled in at deploy time, are enough to compute both instability metrics.

DORA is explicit that this is where teams over-invest. Building integrations across every system to get precise numbers “might not be worth the initial investment” — starting with conversations, or with the DORA Quick Check, often produces improvement faster than a perfect pipeline of telemetry does.

If you want the fastest possible confirmation that the fifth metric is real rather than a documentation change: DORA updated the Quick Check in April 2026 to include deployment rework rate, along with refreshed industry benchmarks. The tool asks you for it now.

Where These Numbers Break

Every DORA metric has a trivial gaming strategy. This is not a flaw in the metrics; it is what happens to any measure that becomes a target. DORA lists “setting metrics as a goal” as its first common pitfall and cites Goodhart’s law by name.

Each metric has an obvious way to fake it. All five are faked the same way: by changing the recording, not the system.

Metric	How it gets gamed	What you actually see
Deployment frequency	Split one change into six deployments	The number triples, nothing ships faster
Change lead time	Measure from PR merge instead of first commit	The review backlog disappears from the data
Failed deployment recovery time	Declare recovery when the rollback finishes, not when users are served	Fast recovery, unhappy users
Change fail rate	Stop recording small failures as failures	A world-class number and a worsening system
Deployment rework rate	File the hotfix as planned work	Rework becomes invisible

Notice the pattern: none of these change the system, all of them change the recording. That is the tell. If a metric improves and nobody can point to a practice that changed, the recording changed.

The other pitfalls DORA calls out are worth knowing because they show up in almost every rollout:

One metric to rule them all. Complex systems need several measures held in tension. A single number always gets optimised at the expense of something unmeasured.
Disparate comparisons. These metrics apply to one application or service. Comparing a mobile app to a mainframe system, or blending numbers across an entire org, produces something that looks like a leaderboard and means nothing.
Siloed ownership. If only the ops team owns stability and only dev owns throughput, you have built a finger-pointing machine. The five are meant to be shared.
Competing. The goal is to improve against your own past, not to beat another team.
Industry as a shield. “We’re regulated, so we can’t deploy more often” is usually a claim about a process nobody has revisited, not about the regulation.

The deepest version of this problem is using DORA metrics on individuals. The metrics are validated as team-level predictors of organisational performance and employee well-being. Applied to a person, they measure that person’s position in a queue.

The 2026 version of this mistake: tokenmaxxing

The newest example is not a DORA metric at all, which is what makes it useful.

In June 2026 DORA published on a trend it calls tokenmaxxing: organisations tracking and rewarding raw AI token consumption through internal leaderboards to spur adoption. DORA’s read is balanced — the gamification can genuinely nudge AI-hesitant developers into experimenting — but its conclusion is blunt: treating token spend as a performance indicator is a dangerous trap.

It is the same failure as putting deployment frequency in a performance review, one abstraction layer up. Token spend measures activity. It is trivially maximised by generating more, verifying less, and pasting bigger contexts. If your organisation has learned not to reward raw commit counts, it already knows why this one ends badly.

What AI Changed

DORA renamed its annual report in 2025 from Accelerate State of DevOps to State of AI-assisted Software Development, and the finding that headlines that research is a useful corrective to both the hype and the backlash.

AI is framed as an amplifier : it magnifies an organisation’s existing strengths and weaknesses. Concretely, DORA found that AI improves throughput but often at the cost of stability when the underlying foundation is not solid. The report’s own framing is that the greatest returns on AI investment come “not from the tools themselves, but from a strategic focus on the underlying organizational system.”

Read that against the five-metric model and the design suddenly looks prescient. If AI raises throughput while weak foundations turn that speed into defects, then the metrics that catch the damage are exactly the two instability ratios — and one of those, deployment rework rate, did not exist on your dashboard two years ago. A team shipping faster with AI and tracking only four metrics has instrumented the half of the picture that is guaranteed to look good.

DORA’s companion AI Capabilities Model , published at the end of 2025, names seven capabilities that amplify AI’s benefits, including strong version control practices, working in small batches, a quality internal platform, AI-accessible internal data, and a clear and communicated AI stance. Three of those are ordinary delivery hygiene that predates AI by a decade. That is the point.

DORA’s 2026 follow-up work sharpens the warning. Its March 2026 analysis of AI tensions describes the hidden taxes that arrive with faster code generation: verification overhead, skill degradation, and integration friction. The current ROI of AI-assisted Software Development report is built around the same reality, giving leaders a framework for the initial “productivity dip” of a rollout. None of that shows up in throughput. All of it shows up in rework.

A Practical Checklist

If you want to modernise your DORA setup, in rough order of payoff:

Count your tiles. If there are four, you are missing deployment rework rate.
Check what feeds your recovery metric. If it includes incidents not caused by a deployment, it is not failed deployment recovery time.
Move lead time’s start to the first commit. If it starts at merge, you are hiding your review queue.
Add three values to your deploy record : planned, hotfix, rollback. Both instability metrics fall out of that.
Report medians, and report n. A p50 with no sample size is a rumour.
Scope to one service. Blended org-wide numbers are for slides, not for decisions.
Remove them from performance reviews. If they are attached to individual outcomes, everything above is wasted.
Pair every metric with a conversation. DORA’s own guidance is that the improvement comes from the discussion about constraints, not from the dashboard.

The Part Worth Keeping

Strip away the version changes and DORA’s central finding from 2015 still stands, and it is still the reason these metrics matter: speed and stability are not a trade-off. Teams that do well do well across all five. Teams that do badly do badly across all five. The metrics correlate.

Dave Farley’s formulation, quoted in DORA’s own guide, is the one to remember: “the real trade-off, over long periods of time, is between better software faster and worse software slower.”

The five metrics are a compass for that, and nothing more. They will tell you where your delivery system is constrained. They will not tell you who to promote, which team is best, or whether your AI rollout was worth it — and every failure mode in this article comes from asking them a question they were never designed to answer.

Related reading: if you are building the delivery system these metrics measure, start with platform engineering on Kubernetes and GitOps with Argo CD. For the pipeline itself, see the secure GitLab CI/CD hardening playbook.

Sources: all facts in this article come from DORA’s own publications — the software delivery performance metrics guide, the history of DORA’s metrics, the 2025 year in review, and the 2025 report overview.

Originally published at alekseialeinikov.com