Von Skripten zur Einfachheit: AWS Backups native Unterstützung für Amazon EKS

Wie Unternehmen Disaster Recovery für Kubernetes angehen, ändert sich gerade spürbar, und der Anstoß kommt direkt von AWS.

AWS Backup unterstützt Amazon EKS jetzt offiziell nativ. Damit können sich Nutzer von klobigen Skripten, zusammengeflickten Drittanbieter-Tools und endlosem YAML-Troubleshooting verabschieden. Mit dem Release macht AWS klar, dass Backup und Restore für Kubernetes kein Frankenstein-Monster aus Tools und manuellen Prozessen mehr sein müssen.

Im Folgenden geht es darum, was das für DevOps-Teams in der Praxis heißt, was Nutzer bereits dazu sagen und wie das neue Feature verändern könnte, wie wir in der EKS-Welt über State, Skalierung und Sicherheit denken.

Der alte Weg: DIY-Skripte und Tool-Wirrwarr

Vor diesem Update war das Backup von Amazon-EKS-Clustern, sagen wir, „kreativ". Die meisten Teams schrieben eigene Backup-Skripte oder setzten auf Drittanbieter-Tools wie Velero, die zwar beliebt waren, aber ihre eigenen Komplikationen mitbrachten.

Man musste:

• Backup-Skripte für jeden Cluster schreiben und pflegen
• Mit Breaking Changes und Updates Schritt halten
• IAM-Rollen, Storage-Ziele, Verschlüsselung und Versionierung manuell konfigurieren
• Hoffen, dass der Restore-Prozess tatsächlich funktioniert, wenn man ihn braucht

Manche Organisationen bekamen Velero gut zum Laufen, andere hatten weniger Glück. Ein Nutzer fasste die Stimmung in einem Kubernetes-Forum so zusammen: „Das macht mich glücklich. Ich bin kein großer Fan davon, mich auf Velero zu verlassen, nach allem, was mit VMware passiert ist."

Mit Häme hat das wenig zu tun. Die Übernahme von Velero und die anschließende Unsicherheit, wie es unter VMware weitergeht, haben viele Enterprise-Teams nervös gemacht. Dass AWS jetzt mit einer nativen Lösung einsteigt, kommt deshalb zur richtigen Zeit und könnte für Ops-Teams einiges verändern.

Der neue Weg: Nativ, zentralisiert und Policy-gesteuert

AWS Backup behandelt Amazon EKS jetzt als vollwertige Ressource. Man muss nicht mehr für jedes Restore-Szenario scripten, ist nicht mehr von Drittanbieter-Tools abhängig und verwaltet Backups zentral über dieselbe Oberfläche, die man schon für EC2, RDS, EFS und weitere Dienste nutzt.

Technisch sichert AWS Backup dabei sowohl die Konfiguration des EKS-Clusters (etwa Deployments, Services, ConfigMaps und Secrets) als auch die zugehörigen persistenten Daten in EBS, EFS oder optional S3.

Und beim Restore kann AWS auf Basis Ihrer ursprünglichen Einstellungen einen neuen EKS-Cluster bereitstellen und den Restore automatisch abwickeln. Für die Infrastruktur-Automatisierung schließt sich damit ein Kreis, und die Komplexität sinkt enorm.

So sieht das in der Praxis aus

Der Ablauf in einfachen Worten:

1. Aktivieren: Öffnen Sie die AWS-Backup-Einstellungen und aktivieren Sie EKS als geschützte Ressource.
2. Backup: Erstellen Sie ein On-Demand-Backup Ihres laufenden EKS-Clusters (oder automatisieren Sie es per Policy).
3. Rolle auswählen: Wählen Sie eine IAM-Rolle mit den passenden Backup- und Restore-Berechtigungen.
4. Restore: Wählen Sie den Zeitpunkt des Backups und stellen Sie auf einem bestehenden Cluster wieder her, oder lassen Sie AWS einen neuen für Sie hochfahren.
5. Validieren: AWS Backup stellt Kubernetes-Ressourcen und persistente Volumes wieder her, und Sie prüfen den wiederhergestellten Zustand.

Wenn das zu einfach klingt, ist genau das beabsichtigt. Dieselbe Oberfläche verwaltet jetzt EC2-Snapshots, Point-in-Time-Restores für RDS und die vollständige Wiederherstellung von EKS-Clustern an einem Ort.

Wozu Cluster-Backups, wenn die Workloads ephemer sind?

In der Kubernetes-Community hört man oft, man müsse Cluster gar nicht sichern, weil Workloads ephemer sind und die Daten ohnehin woanders liegen, in S3, RDS oder DynamoDB.

Ein Nutzer formulierte es so: „Warum sollte ich meine EKS-Cluster sichern müssen? Alle meine Workloads sind ephemer."

Mehrere Leute widersprachen sofort, und zwar zu Recht. In Kubernetes steckt jede Menge „State", der nicht in externen Datenbanken liegt:

• ConfigMaps
• Secrets
• TLS-Zertifikate
• Im Cluster generierte Keys
• Helm-Metadaten
• Argo-CD-State
• Admission-Controller-Konfigurationen

Dazu kommt das unordentliche Zeug, etwa wenn ein Entwickler spontan eine Notfalländerung macht und vergisst, sie nach Git zu committen. Ein Kommentar traf es genau: „Hat je ein Teammitglied irgendwo eine Änderung gemacht, die nicht in den Source Code committet wurde?"

Backups sind hier also kein Selbstzweck. Sie bringen Geschwindigkeit, Kontrolle und Überlebensfähigkeit, wenn etwas kaputtgeht. Wer schon einmal einen Kubernetes-Cluster erlebt hat, der mitten im Upgrade ausgefallen ist, oder eine Sicherheitsfehlkonfiguration, die sich durch die Produktion gefressen hat, weiß, wie viel ein sauberer Wiederherstellungspunkt wert ist.

Aber was ist mit GitOps?

Ein weiterer häufiger Einwand lautet: „Wir sind GitOps. Wir deployen einfach alles neu."

Theoretisch funktioniert das. In der Praxis ist GitOps selten so ordentlich. Cluster-State, Pipeline-Logik und ephemere Secrets liegen oft außerhalb der Versionskontrolle. Und im Ernstfall ist ein Rollout von Grund auf häufig langsamer und riskanter, als bekanntermaßen funktionierende Infrastruktur wiederherzustellen.

Ein Nutzer merkte dazu an: „Ein Backup wiederherzustellen ist schneller, als IaC aus Dutzenden oder Hunderten von Repositories auszurollen."

Mit Tools wie Argo CD läuft es auch deutlich reibungsloser, wenn man den Cluster-State vorlädt und die Reconciliation alles auf den aktuellen Stand bringen lässt, statt das gesamte Universum neu zu bootstrappen.

Unveränderlich, verschlüsselt, regional redundant

Neben dem Komfort bringt die Art, wie AWS Backup diese Snapshots verwaltet, Vorteile auf Enterprise-Niveau:

• Unveränderliche Backups, die vor versehentlichem oder böswilligem Löschen schützen
• Backups lassen sich über Accounts und Regionen hinweg kopieren
• Integration mit Backup Vaults für Policy-Kontrolle und Zugriffsmanagement
• Unterstützung für verschlüsselte Backups mit AWS KMS

Ihre EKS-Backups erreichen damit denselben Compliance- und Sicherheitsstandard wie Ihre RDS- und EC2-Backups, ohne dass Sie das Rad neu erfinden müssen.

Das bisherige Fazit

Von diesem Rollout profitieren AWS und jeder Kubernetes-Nutzer, der in der realen Welt mit Komplexität, chaotischen Teams und unvorhersehbaren Incidents lebt.

Bei Nutzern kommt vor allem an, dass es innerhalb bestehender AWS-Workflows „einfach funktioniert" und dass sich Cluster wiederherstellen lassen, ohne mit Helm, Terraform und Klebeband zu kämpfen. Flexibel ist es auch, denn man kann ganze Cluster, einzelne Ressourcen oder nur persistente Volumes zurückholen. Für die Sicherheit sorgen KMS-Verschlüsselung und zugriffskontrollierte Vaults.

Vor allem nimmt es Reibung raus, und so sollte sich Cloud-natives Backup anfühlen.

Abschließende Gedanken

Wer bei der eigenen EKS-Backup-Strategie noch unentschlossen war, sollte jetzt handeln. Die native Unterstützung in AWS Backup bringt Einfachheit, Konsistenz und Glaubwürdigkeit in einen Bereich, der oft mühsam aus DIY- oder Drittanbieter-Stacks zusammengeflickt wurde.

Für Teams, die schon tief im AWS-Ökosystem stecken, ist die Integration ein No-Brainer. Und wer in großen Organisationen Mühe hatte, Standards für Kubernetes-Backups durchzusetzen, bekommt damit vielleicht genau den Durchbruch, auf den er gewartet hat.

Die Zeit der Skripte ist vorbei. Skalierung, Sicherheit und Einfachheit gibt es jetzt mit einem Klick, und damit setzt AWS einen neuen Standard für Kubernetes-Resilienz.