Kostenoptimierung für Managed VMs¶
Eine VM kostet für jede Stunde Geld, in der sie zugewiesen ist, egal ob sie genutzt wird oder nicht. Drei Hebel halten die Rechnung niedrig: die richtige Größe, Abschalten dessen, was nicht genutzt wird, und eine Verpflichtung für das, was immer läuft.
flowchart TD
A["Start: VM-Kosten optimieren"] --> Z{"Hat die VM die richtige Größe (CPU, Speicher)?"}
Z -->|Nein| Y["VM auf die richtige Größe ändern"]
Y --> B
Z -->|Ja| B{"Muss die VM rund um die Uhr laufen?"}
B -->|Nein| G["Auto-shutdown-Zeitplan aktivieren: außerhalb der Nutzungszeiten stoppen"]
B -->|Ja| C{"Ist die Last stabil und für 1+ Jahr vorhersehbar?"}
C -->|Ja| D["Eine Reservation kaufen: 1 oder 3 Jahre"]
C -->|Nein| E["Die Nutzung einen Monat beobachten und neu entscheiden"]
E --> B
Eine übliche Regel auf einer Plattform (prüfe deine): Eine VM hat entweder einen Auto-shutdown-Zeitplan oder ist reserviert.
| VM-Typ | Typische Regel |
|---|---|
| Nicht-Produktion | Außerhalb der Geschäftszeiten herunterfahren (zum Beispiel 19:00 bis 07:00). Ausnahmen nur für VMs, die rund um die Uhr laufen müssen. |
| Produktion | Die VM für 1 oder 3 Jahre reservieren, sobald ihre Nutzung stabil ist. Nicht am ersten Tag rightsizen und reservieren. |
Das nächtliche Stoppen von VMs kann bis zu etwa die Hälfte der Compute-Kosten sparen. Eine einjährige Reservation ist um einen zweistelligen Prozentsatz günstiger als Pay-as-you-go; der genaue Rabatt hängt von Größe, Region und Laufzeit ab. Siehe Kosten und Reservations, wie du eine kaufst.
Auto-shutdown¶
Eine Automatisierung der Plattform startet und stoppt VMs anhand eines tags. Du brauchst dafür keine Anfrage. Ob sie verfügbar ist, ist plattformspezifisch, frag also dein Plattform-Team. Wo sie existiert:
Füge der VM den tag AutoShutdownSchedule hinzu. Alle Zeiten werden in einer festen Zeitzone interpretiert (Mitteleuropäische Zeit in
der Beispielplattform; frag, welche bei dir gilt).
| Wert | Wirkung |
|---|---|
Zeitbereich, zum Beispiel 19:00 -> 06:00 oder 7PM -> 6AM |
Die VM wird im Bereich gestoppt und außerhalb davon gestartet |
Wochentag, zum Beispiel Saturday |
Die VM wird den ganzen Tag gestoppt |
Datum, zum Beispiel December 25 |
Die VM wird den ganzen Tag gestoppt |
Kombination, durch Kommas getrennt: 19:00 -> 06:00, Saturday, Sunday |
Werktags von 19:00 bis 06:00 und am Wochenende ganztägig gestoppt |
AllDays |
Die VM wird unbefristet deallokiert und nicht automatisch gestartet |
Um eine VM ausnahmsweise laufen zu lassen, obwohl ein Zeitplan existiert (zum Beispiel bei Wartung oder einem Test), füge den tag
PreventAutoShutdown hinzu. Der Wert spielt keine Rolle. Nimm zur Klarheit true. Entferne den tag, wenn du fertig bist. Die
Automatisierung überspringt das Herunterfahren, solange der tag da ist.
Patching und Zeitplan arbeiten zusammen: Eine VM, die durch ihren Zeitplan gestoppt ist, wird für ihr Wartungsfenster gestartet und danach wieder gestoppt. Siehe Updates und Patching.
Das Modul hat in der VM-Konfiguration außerdem ein Feld auto-shutdown hours (Anfrage und Änderung). Frag dein Plattform-Team, wie es sich zum tag verhält.
Prüfung der Disk-Kosten¶
Disks können mehr kosten als die VM. Premium- und zonenredundante Disks, überdimensionierte Daten-Disks und ungenutzte Disks läppern sich. Prüfe die Disks einer VM-Konfiguration, bevor du sie anfragst und nach großen Änderungen.
Manche Plattformen bieten für diese Prüfung einen Assistenten, zum Beispiel einen Custom Agent für einen KI-Coding-Assistenten, der mit der Konfigurationsdatei im Repository arbeitet. Wenn deine Plattform einen hat, läuft eine Prüfung typischerweise so ab:
- Öffne das Repository mit der VM-Konfigurationsdatei in deinem Editor und starte den Agent in seinem Agent-Modus.
- Gib ihm die Konfigurationsdatei einer Umgebung (Produktion und Nicht-Produktion getrennt, die Regeln unterscheiden sich).
- Beantworte seine Fragen zum workload: was auf den VMs läuft, Leistungsbedarf (IOPS, Durchsatz, Latenz), was auf jeder Daten-Disk liegt, Spitzennutzung und Wachstum. Vage Antworten führen zu vorsichtigen Empfehlungen.
- Der Agent schlägt Änderungen einzeln vor: Titel mit geschätzter monatlicher Ersparnis, die zu ändernde Zeile, aktuelle Konfiguration, Problem, Empfehlung, Abwägungen und Auswirkung. Du antwortest yes (der Agent bearbeitet die Datei), no (sie wird zurückgestellt) oder tell me more.
- Die Prüfung wird als Dokument neben deiner Konfiguration gespeichert (eine Datei pro Konfigurationsdatei). Es enthält den Kontext des workloads, eine Kostenzusammenfassung, die Empfehlungen mit ihrem Status (pending, accepted, deferred) und die geschätzte Ersparnis. Committe es zusammen mit deiner Änderung. Es ist der Nachweis, warum eine Disk herabgestuft wurde, und eine spätere Prüfung beginnt damit.
Führe die Prüfung erneut aus, wenn du Disks hinzufügst oder VMs in der Größe änderst. Betrachte das Ergebnis als Empfehlung: Du entscheidest weiterhin.
Pilot-Tooling
Ein KI-Assistent braucht einen Account und eine Lizenz deiner eigenen Organisation und den passenden Repository-Zugriff. Das Plattform-Team evaluiert möglicherweise noch, ob es sich lohnt, ihn zu behalten. Gib Feedback zu den Fragen, die er stellt, und zur Qualität der Empfehlungen.