Im Cloud Engineering zählt vor allem eines: Tempo. Teams stehen unter Dauerdruck, Features schneller auszuliefern, Systeme effizienter zu skalieren und ohne Verzögerung geschäftlichen Mehrwert zu liefern.
Vor diesem Hintergrund überrascht es kaum, dass routinemäßige Wartungsaufgaben in der Cloud regelmäßig hinten runterfallen. Selbst wenn Maßnahmen zur Kostenoptimierung Einsparungen versprechen, lässt sich der konkrete ROI im Vorfeld nur schwer beziffern – und damit auch nur schwer gegenüber anderen kritischen Engineering-Aufgaben priorisieren.
Auf lange Sicht summieren sich diese vermeintlich kleinen, vernachlässigten Aufgaben jedoch zu erheblichen Kostenineffizienzen – und zu einem operativen Risiko.
Was ungenutzte Cloud-Optimierungen wirklich kosten
In jedem Unternehmen schlummern Cloud-Ineffizienzen direkt vor aller Augen. Manche sind offensichtlich – etwa überdimensionierte Instances oder Zombie-workloads. Andere sind subtiler, etwa Buckets mit unvollständigen Multipart-Uploads in S3, die schleichend Speicherkosten verursachen.
Den meisten Cloud-Teams sind diese Probleme bekannt. Es scheitert nicht am Bewusstsein, sondern an der Priorität. Wenn Engineers an der Produktgeschwindigkeit gemessen werden, ist es kaum zu rechtfertigen, Stunden damit zu verbringen, S3-Buckets zu durchforsten oder fehlende Cleanup-Regeln aufzuspüren.
Und doch haben diese ungenutzten Optimierungen oft messbare finanzielle Folgen. Es sind genau die Aufgaben, die gerade lästig genug sind, um sie zu ignorieren – und gerade teuer genug, um über die Zeit ins Gewicht zu fallen.
Warum Wartungsaufgaben unter den Tisch fallen
Fragen Sie einen beliebigen Cloud Engineer, wofür seine Zeit draufgeht, hören Sie immer wieder die gleichen Themen: neue Features bauen, auf Incidents reagieren, die Developer Productivity unterstützen, mit neuen Services und APIs Schritt halten – die Liste scheint endlos.
Cloud-Hygiene wie das Auditieren von IAM-Policies, das Konfigurieren von Auto-Delete für nicht angehängte Volumes oder das Setzen von Lifecycle-Regeln für unvollständige S3-Uploads landet derweil in einer Kategorie, die sich am besten so beschreiben lässt: "Das machen wir später."
Das Problem dabei: "Später" kommt selten.
Ein Beispiel aus der Praxis: Cleanup von S3-Multipart-Uploads
Nehmen wir den konkreten Fall der Multipart-Uploads in Amazon S3. Wird ein Upload gestartet, aber nie abgeschlossen (was häufiger vorkommt, als man denkt), speichert AWS die hochgeladenen Teile weiter – und stellt Ihnen den Speicher in Rechnung, selbst wenn das Objekt nie finalisiert wurde.
Die Lösung ist simpel: eine Lifecycle-Regel konfigurieren, die unvollständige Multipart-Uploads nach einer festgelegten Anzahl von Tagen abbricht (typischerweise 7). In der Praxis fehlt diese Regel jedoch in vielen S3-Buckets.
Warum? Weil das Vorgehen in der AWS-Konsole Folgendes bedeutet:
Manueller Prozess für das Cleanup von S3-Multipart-Uploads über die AWS-Konsole
1. In der AWS-Konsole anmelden
- Zur AWS Management Console navigieren
- Zum S3-Service-dashboard wechseln
2. Lifecycle-Regeln für jeden Bucket prüfen
An dieser Stelle wird es ineffizient: In der AWS-Konsole gibt es keine native Möglichkeit, Buckets nach Lifecycle-Konfigurationen oder fehlenden Regeln zu filtern oder zu durchsuchen. Stattdessen muss man:
- jeden Bucket einzeln öffnen
- zu Management → Lifecycle rules wechseln.
- Falls Regeln existieren, prüfen, ob eine davon "Incomplete multipart uploads" abdeckt
- Existiert eine entsprechende Regel (üblicherweise "Abort incomplete multipart uploads after X days"), ist nichts weiter zu tun
- Existiert keine Regel, muss eine angelegt werden
3. Multipart-Cleanup-Regel anlegen
Für jeden Bucket, dem die Regel fehlt:
- Auf "Create lifecycle rule" klicken
- Einen Regelnamen vergeben (z. B. abort-multipart-uploads)
- Den Geltungsbereich der Regel wählen (z. B. auf alle Objekte im Bucket anwenden)
- Unter Lifecycle rule actions die Option "Delete expired object delete markers or incomplete multipart upload" aktivieren
- Unter Incomplete multipart uploads die Option "Delete incomplete multipart uploads" aktivieren
- Die Anzahl der Tage nach Initiierung festlegen (AWS empfiehlt 7 oder weniger)
- Die Regel prüfen und speichern
- Den Vorgang für jeden weiteren Bucket wiederholen, der die Regel braucht
Wie Sie sehen: Bei dutzenden, hunderten oder gar tausenden Buckets wird daraus ein repetitiver, langsamer und fehleranfälliger Prozess – der in der Praxis schlicht liegen bleibt.
Das Problem mit Workflow-Automatisierung lösen
Genau solche Aufgaben sind ideale Kandidaten für Automatisierung – nicht, weil sie technisch komplex wären, sondern weil sie operativ stinklangweilig sind. Und genau diese langweiligen Aufgaben fressen manuell ausgeführt Produktivität auf und untergraben ignoriert die Effizienz.
Mit CloudFlow, der No-Code-Lösung für Workflow-Automatisierung innerhalb von DoiT Cloud Intelligence™, konfiguriert ein Cloud Engineer den gewünschten Workflow einfach einmal – und das System erledigt die Arbeit in Sekunden.
Im vorliegenden Fall könnte ein passender CloudFlow so aussehen, wobei jeder Schritt im Flow einen oder mehrere manuelle Schritte ersetzt, die Sie sonst in der AWS-Konsole ausführen müssten:
- Einen geplanten Trigger für den Zeitpunkt und die Frequenz festlegen, in der der CloudFlow laufen soll
- Über die API-Funktionalität von CloudFlow zunächst die vollständige Liste der S3-Buckets in Ihren AWS-Konten abrufen ("ListBuckets")
- Für die gelisteten Buckets die Lifecycle-Konfigurationsregeln abrufen ("GetBucketLifecycleConfiguration")
- Einen Filter-Node erstellen, um alle Buckets zu finden, denen die erforderliche Regel fehlt ("Filter for missing policy")
- Über eine weitere AWS-API die neue Regel auf alle gefilterten Buckets anwenden ("PutBucketLifecycleCongifuration")
- Einen Benachrichtigungsschritt ergänzen, um die Änderung zu dokumentieren und alle Stakeholder auf dem Laufenden zu halten
Für die Compliance lässt sich an jedem Schritt im Prozess zusätzlich ein Approval einbauen, sodass keine Buckets ohne Freigabe eines Account-Admins verändert werden:
Dieser CloudFlow ersetzt nicht nur den mühsamen und zeitraubenden Prozess, ALLE S3-Buckets in den angegebenen Konten zu bereinigen – er lässt sich zudem wöchentlich ausführen, sodass neu angelegte Buckets ohne Lifecycle-Regel zuverlässig erkannt und korrekt um die Regel ergänzt werden.
Ein solcher Schritt spart nicht nur Zeit, er verändert die Arbeitsweise ganzer Teams. Statt Stunden in das initiale Cleanup zu stecken und dieselbe Wartung anschließend wieder und wieder zu durchlaufen, schaltet CloudFlow den Prozess auf Autopilot. Cloud Engineers können sich auf Aufgaben konzentrieren, die stärker auf die langfristigen Unternehmensziele einzahlen – und sparen sich nebenbei stumpfsinnige Routinearbeit.
Und das S3-Lifecycle-Management ist nur einer von vielen möglichen Use Cases für CloudFlow: Genauso lassen sich autonom Tags oder Labels auf Ressourcen anwenden, Instances ein- und ausschalten, workloads right-sizen oder praktisch alles abbilden, was über die APIs von AWS oder Google Cloud machbar ist.
Um mehr darüber zu erfahren, wie CloudFlow die Arbeitsweise Ihres Teams verändern kann, werfen Sie einen Blick auf diese geführte Tour oder sprechen Sie mit einem DoiT-Experten.