VM-Cloud-Kosten in sieben Schritten senken

Überdimensionierte virtuelle Maschinen sind eine der grössten Quellen von Cloud-Verschwendung. Der Flexera 2025 State of the Cloud Report hält fest, dass 59 % der Organisationen inzwischen ein eigenes FinOps-Team betreiben, was zeigt, wie strukturell das Problem geworden ist. Für Schweizer IT-Verantwortliche und Cloud-Ingenieure ist Right-Sizing keine optionale Aufräumarbeit mehr, sondern ein messbarer finanzieller Hebel.

Dieser Artikel beschreibt sieben konkrete Schritte, um Überdimensionierung zu erkennen, Ressourcen an die tatsächliche Nutzung anzupassen und die Rechnung dauerhaft zu senken.

Kurzüberblick: die sieben Schritte

1. Aktuelle Ressourcennutzung prüfen: CPU-, RAM- und Storage-Metriken über mindestens 30 Tage erfassen.
2. Überdimensionierte VMs identifizieren: Instanzen unter 20 % der zugeteilten Ressourcen finden.
3. Schwellen je Workload festlegen: vCPU/RAM-Verhältnisse nach Profil kalibrieren, Rechenlast, Speicher oder allgemein.
4. Zuerst ausserhalb der Produktion anpassen: neue Grössen in Testumgebungen anwenden.
5. In Phasen produktiv ausrollen: in Losen migrieren, in Wartungsfenstern.
6. Monitoring und Alarme automatisieren: Abweichungen laufend erkennen.
7. Periodische Überprüfung einführen: ein Quartalsrhythmus hält Ressourcen und Nutzung beieinander.

Ressourcen an die Nutzung anpassen

1. Aktuelle Nutzung prüfen

Zuerst CPU-, RAM- und Disk-I/O-Metriken über mindestens 30 Tage erfassen. Dieses Fenster erfasst die zyklischen Schwankungen: Monatsendspitzen, Nacht-Batches, ruhige Phasen.

Monitoring-Werkzeuge wie Grafana oder VictoriaMetrics aggregieren die Daten je Instanz und je Projekt. Ziel ist eine faktische Grundlage für die Differenz zwischen Zuteilung und Verbrauch.

Ohne diese Sicht lässt sich strukturelle Überdimensionierung nicht von einer einmaligen Spitze unterscheiden.

2. Überdimensionierte VMs identifizieren

Das Symptom: eine VM hält 8 vCPU und 32 GB RAM, während die Durchschnittsnutzung unter 15 % CPU und 25 % Speicher bleibt. Abgerechnet wird die Zuteilung, nicht der Verbrauch.

Drei Kategorien erleichtern die Sortierung: überdimensioniert unter 20 % Durchschnittsnutzung, korrekt dimensioniert zwischen 40 und 70 %, unterdimensioniert mit regelmässigen Spitzen über 85 %. Die Einteilung stützt sich auf die Daten aus dem vorherigen Schritt.

Instanzen unter 20 % über 30 Tage haben Vorrang. Die Konzentration auf dieses Segment macht den Aufwand rentabel.

3. Schwellen je Workload festlegen

Jeder Workload verlangt sein eigenes vCPU/RAM-Verhältnis, und die drei Hikube-Instanzfamilien sind auf diesen Verhältnissen aufgebaut. CPU-intensive Arbeit wie CI/CD und Kompilierung entspricht der Familie s1 mit 1:2. Allgemeine Anwendungen, APIs und Webdienste entsprechen u1 mit 1:4. Datenbanken und Caches entsprechen m1 mit 1:8, Speicher zuerst.

Die Schwellen vor dem Anpassen festzulegen verhindert zwei häufige Fehler: zu aggressiv kürzen und die Leistung beeinträchtigen, oder aus Vorsicht grosszügige Reserven behalten und das Problem reproduzieren.

Zielschwellen je Kategorie dokumentieren und mit den Applikationsteams validieren. Das dauert je nach Grösse des Bestands zwei bis vier Stunden und trägt alles Folgende.

4. Zuerst ausserhalb der Produktion anpassen

Die neuen Grössen in Entwicklung und Staging anzuwenden misst die Wirkung auf die Anwendungsleistung, ohne die Produktion zu gefährden.

Auf Hikube Cloud-Instanzen halbiert der Wechsel von u1.2xlarge mit 8 vCPU und 32 GB auf u1.xlarge mit 4 vCPU und 16 GB die verrechneten Ressourcen, sofern die tatsächliche Nutzung das hergibt. Der Katalog reicht von s1.small bis m1.8xlarge, und die Preise sind publiziert.

Anschliessend die üblichen Last- und Funktionstests auf den angepassten Instanzen ausführen. Bleiben Latenz und Durchsatz im akzeptablen Bereich, ist die Konfiguration validiert.

5. In Phasen produktiv ausrollen

In Losen von 10 bis 20 % des Bestands vorgehen. Migrationen in Ihren eigenen Wartungsfenstern planen und die Anwendungsmetriken nach jedem Los 48 bis 72 Stunden beobachten.

Das gestufte Vorgehen begrenzt das Risiko. Tritt nach einem Los eine Auffälligkeit auf, betrifft der Rückbau nur einen Teil des Bestands.

Beobachtete Grössenordnung: zwei bis fünf Tage Umsetzungsaufwand für 20 bis 40 % Reduktion der Monatsrechnung, je nach Ausgangslage. Die ersten Effekte erscheinen im nächsten Abrechnungszyklus.

6. Monitoring und Alarme automatisieren

Echtzeit-Monitoring verhindert, dass die Abweichung nach getaner Arbeit zurückkehrt. Zwei Schwellen genügen: durchschnittliche CPU unter 15 % über sieben Tage als Hinweis auf Überdimensionierung, über 85 % über sieben Tage als Hinweis auf das Gegenteil.

Der im Tenant deployfähige Stack, Grafana mit VictoriaMetrics und VictoriaLogs, erstellt diese Alarme mit Schwellen je Projekt und Umgebung. Erst die Anbindung an einen Benachrichtigungskanal macht aus einem Alarm eine Reaktionszeit. Die Monitoring-Dokumentation beschreibt die Einrichtung.

Ohne sie kehrt die Überdimensionierung in drei bis sechs Monaten zurück: Teams dimensionieren neue VMs nach vorsichtigen Schätzungen, und die Lücke öffnet sich erneut.

7. Periodische Überprüfung einführen

Eine vierteljährliche Überprüfung der Zuteilungen macht Right-Sizing zur laufenden Praxis statt zum einmaligen Projekt. Jede Überprüfung vergleicht die aktuelle Nutzung mit den Schwellen aus Schritt 3 und bringt die neuen Kandidaten hervor.

In den Budgetprozess eingebettet werden die Einsparungen quantifizierbar und die Werkzeuge begründbar. Der TCO-Rechner über 36 Monate liefert den Rahmen, der Artikel zum TCO-Vergleich die Methode.

Vier bis acht Stunden je Zyklus einplanen. Ohne regelmässige Überprüfung erreicht die Überdimensionierung in sechs bis zwölf Monaten wieder ihr Ausgangsniveau.

Was Überdimensionierung tatsächlich kostet

Die direkten Kosten sind die Verrechnung zugeteilter, aber ungenutzter Ressourcen. Sie machen üblicherweise 20 bis 40 % des Cloud-Budgets aus, abhängig von der FinOps-Reife. Der Flexera 2025 State of the Cloud Report zeigt, dass das Wachstum der Workloads diese Verschwendung jedes Jahr mechanisch verstärkt.

Die indirekten Kosten sind weniger sichtbar: Instanztypen vervielfachen sich, die Abrechnung wird undurchsichtig, Ausgaben lassen sich schwer planen. Für ein Schweizer Unternehmen unter nDSG, DSGVO oder FINMA erschwert ein schlecht dimensionierter Bestand zudem Infrastruktur-Audits. Die Zuständigkeitsfrage behandelt der Artikel zur souveränen Cloud.

Manuelles oder automatisiertes Right-Sizing

Manuell passt zu Beständen unter 50 VMs mit stabilen Lastprofilen: Metrik-Exporte, eine Tabelle, dokumentierte Entscheide. Der Vorteil ist die Kontrolle über jede Entscheidung.

Automatisiert lohnt sich ab 100 VMs oder wenn die Profile häufig wechseln. FinOps-Werkzeuge analysieren Trends und liefern Empfehlungen mit angegebenem Konfidenzniveau.

Der hybride Ansatz ist der pragmatische: Erkennung und Empfehlung automatisieren, vor der Produktion eine menschliche Freigabe behalten. Nur die Applikationsteams haben den Kontext, der dem Werkzeug fehlt.

Was Hikube dazu beiträgt

Die drei Instanzfamilien sind auf explizite vCPU/RAM-Verhältnisse kalibriert, s1 mit 1:2, u1 mit 1:4, m1 mit 1:8. Anpassen heisst damit, die Grösse zum realen Lastprofil zu wählen, nicht einen Rabatt zu verhandeln.

Der in jedem Tenant deployfähige Monitoring-Stack gibt Sicht je Projekt und Umgebung, ohne Drittwerkzeug zu integrieren.

Nutzungsbasierte Abrechnung bedeutet, dass jede Anpassung unmittelbar zur Reduktion wird, ohne Mindestbindung und ohne Änderungsgebühr. Die Daten bleiben in der Schweiz, auf drei unabhängigen Rechenzentren in Genf, Gland und Luzern.

Für ein Dimensionierungs-Audit antwortet ein Ingenieur innert 24 Arbeitsstunden.

Häufige Fragen

Welche Einsparung ist zu erwarten

Organisationen mit einem strukturierten Programm sehen 20 bis 40 % weniger auf der Monatsrechnung. Das Ausmass hängt ganz davon ab, wie überdimensioniert der Bestand war: ein bereits enger Bestand gibt nichts her.

Wie oft soll die Dimensionierung überprüft werden

Ein Quartalsrhythmus passt den meisten Organisationen. Monitoring-Dashboards halten die Differenz zwischen Zuteilung und Verbrauch jederzeit sichtbar, sodass offensichtliche Fälle nicht auf die Überprüfung warten müssen.

Kann Right-Sizing die Leistung beeinträchtigen

Ja, bei falscher Dimensionierung. Genau dafür sind die Validierung ausserhalb der Produktion in Schritt 4 und die Migration in Losen in Schritt 5 da. Ein Grössenwechsel wird beim Neustart der Instanz wirksam, und Sie bestimmen, wann das geschieht: kein Fenster wird Ihnen vorgegeben.

Welche Werkzeuge erkennen Überdimensionierung

Grafana und VictoriaMetrics decken Metrikerfassung und Alarme ab und werden im Tenant deployt. Für containerisierte Workloads ergänzt ein Kostenwerkzeug je Namespace die Sicht auf Managed Kubernetes.

Lohnt sich Right-Sizing bei kleinem Bestand

Ein Bestand von 10 bis 50 VMs zeigt in zwei bis vier Wochen eine messbare Rendite. Die Granularität des Katalogs, von s1.small bis m1.8xlarge, erlaubt feine Anpassung auch auf kleiner Infrastruktur.