Rightsizing

Rightsizing passt die Größe einer Ressource an ihre gemessene Nutzung an: eine kleinere Instanz, weniger Knoten, eine niedrigere Speicher- oder Datenbankstufe. Es verändert die Nutzung, nicht den Preis: Die Rechnung sinkt, weil weniger Einheiten berechnet werden, nicht weil eine Einheit weniger kostet. Für die Rechnung ist das der direkteste Hebel, den ein Team ohne Finance und ohne Vertrag ziehen kann, und zugleich der, dessen Wirkung am häufigsten geschätzt und nie nachgewiesen wird.

So funktioniert es

Die Entscheidung stützt sich auf Metriken, die der Provider ohnehin erhebt. CPU-Auslastung liefert der Hypervisor für jede Instanz; Netzwerk- und Plattendurchsatz ebenso. Arbeitsspeicher sieht der Hypervisor nicht: Er wird nur gemessen, wenn ein Agent im Gastsystem läuft und die Werte meldet. Eine Empfehlung ohne Speichermetrik beruht auf CPU und Netzwerk allein.

Drei Parameter bestimmen, was aus denselben Metriken folgt. Das Betrachtungsfenster legt fest, wie viele Tage zurück die Analyse reicht; was davor lag, existiert für sie nicht. Das Perzentil oder die Aggregation legt fest, ob das Maximum oder ein Durchschnitt zählt: Ein Maximum je Fünf-Minuten-Intervall ist konservativer als ein Tagesmittel. Der Headroom ist die Reserve, die ein Workload absichtlich behält, damit eine Lastspitze nicht in die Sättigung läuft; er ist eine Entscheidung des Verantwortlichen, keine Messung.

AWS

AWS Compute Optimizer analysiert nach dem Opt-in die CloudWatch-Metriken der letzten 14 Tage; mit der kostenpflichtigen Einstellung „enhanced infrastructure metrics“ sind es bis zu 93 Tage. Für EC2 verwendet er den Maximalwert je Fünf-Minuten-Intervall. Speicherauslastung fließt nur ein, wenn der CloudWatch-Agent installiert ist oder ein externes Observability-Produkt die Werte liefert. Jede Instanz erhält eine Einstufung: „Under-provisioned“, wenn mindestens eine Spezifikation die Anforderung des Workloads nicht erfüllt, „Over-provisioned“, wenn mindestens eine verkleinert werden kann und keine zu klein ist, „Optimized“, wenn alle passen; für optimierte Instanzen schlägt das Werkzeug gelegentlich eine neuere Generation vor. Die Empfehlung nennt das Performance-Risiko von „very low“ bis „very high“ und die Preisdifferenz; Headroom, Schwellenwerte und Instanzfamilien lassen sich in den Rightsizing-Präferenzen anpassen. Neben Compute Optimizer gibt es die Rightsizing-Empfehlungen im Cost Explorer: Sie betrachten ebenfalls 14 Tage, stufen eine Instanz mit maximal 1 % CPU-Auslastung als ungenutzt ein und empfehlen die Beendigung, darüber eine Änderung des Typs, und zeigen nur Empfehlungen mit einer Ersparnis von mindestens null.

Azure

Azure Advisor bewertet virtuelle Maschinen standardmäßig über die letzten sieben Tage; das Fenster lässt sich auf 14, 21, 30, 60 oder 90 Tage stellen. Eine Abschaltempfehlung entsteht, wenn das 95. Perzentil der maximalen CPU-Auslastung unter 3 %, der Höchstwert der mittleren CPU der letzten drei Tage bei höchstens 2 % und die ausgehende Netzwerkauslastung unter 2 % liegt; Speicher wird für diese Entscheidung nicht herangezogen. Eine Resize-Empfehlung berücksichtigt CPU, Speicher und ausgehendes Netzwerk und zielt bei nutzerseitigen Workloads auf höchstens 40 % CPU im 95. und 60 % Speicher im 99. Perzentil auf der neuen Größe, bei nicht nutzerseitigen auf 80 %. Advisor empfiehlt kleinere Größen derselben Familie, neuere Versionen und andere Familien, ohne Reservierungen oder Savings Plans zu berücksichtigen; die Ersparnis beruht auf Listenpreisen. Die Größenänderung selbst startet die VM neu und verlangt eine Deallocation, wenn die neue Größe auf dem aktuellen Hardware-Cluster nicht verfügbar ist.

Google Cloud

Google Cloud erzeugt Empfehlungen zum Maschinentyp über den Recommender aus den Systemmetriken von Cloud Monitoring der letzten acht Tage. CPU-Werte sind Mittelwerte über 60 Sekunden, kurze Spitzen gehen also unter; die Dokumentation empfiehlt den Ops Agent für genauere Empfehlungen. Ausgeschlossen sind VMs aus GKE, Dataflow und App Engine Flex sowie VMs mit GPUs, TPUs oder flüchtigen Platten und die speicheroptimierte Familie. Die Kostenschätzung vergleicht die Monatskosten des aktuellen und des empfohlenen Typs vor Rabatten für kontinuierliche Nutzung.

Was es für Ihre Kosten bedeutet

Die Einsparung ist die Preisdifferenz der beiden Größen multipliziert mit den Stunden, die die Ressource läuft; Compute Optimizer rechnet genau so. In den Abrechnungsdaten erscheint sie als dieselbe Position mit kleinerer Menge oder anderem Produkt, nicht als Gutschrift. Nachgewiesen ist sie erst, wenn die nächste Rechnung die Position mit dem neuen Typ zeigt und die alte verschwunden ist; eine Einsparungschance wird so zur belegten Einsparung.

Ein Commitment verändert die Rechnung. Deckt eine Reserved Instance die Instanz, senkt eine Verkleinerung die Rechnung nur, wenn der Rabatt der freigewordenen Reservierung anderswo greift. Bei AWS gilt für regionale Reserved Instances mit Linux und Standard-Tenancy die Größenflexibilität innerhalb der Familie über den Normalisierungsfaktor; der Cost Explorer nimmt an, dass eine größenflexible Reservierung die kleinere Instanz derselben Familie weiter abdeckt, und rechnet sonst nur mit On-Demand-Stunden. Für Windows, dedizierte Tenancy und zonale Reservierungen gilt die Flexibilität nicht. Azure erlaubt den Umtausch von Reservierungen, wobei die neue Reservierung mindestens das verbleibende Commitment der alten tragen muss; laut Dokumentation sind Reservierungen, die ab dem 1. Februar 2027 für Dienste gekauft werden, die Savings Plans abdecken, nicht mehr umtauschbar; früher gekaufte behalten einen letzten Umtausch. Ein Savings Plan folgt der Nutzung, läuft aber nach einer Verkleinerung ebenfalls leer, wenn nichts anderes die zugesagte Stunde füllt.

Die Modernisierung ist der Fall, der Nutzung und Preis zugleich berührt: Eine neuere Generation leistet dieselbe Arbeit zu einem niedrigeren Listenpreis, Compute Optimizer schlägt sie auch für als „Optimized“ eingestufte Instanzen vor, und Advisor führt neuere Versionen unter seinen Resize-Zielen.

Wo es schiefgeht

• Spitzen außerhalb des Fensters: Der Monatsabschluss, der Batch am Sonntag oder die Kampagne lagen vor den 14 Tagen, und die Empfehlung kennt sie nicht. Symptom: eine Instanz, die zwei Wochen nach der Änderung in die Sättigung läuft.
• Speicher nie gemessen: Ohne Agent beruht die Empfehlung auf CPU; ein speichergebundener Dienst sieht leer aus und wird zu klein.
• Eine Verkleinerung, die ein Limit reißt: Netzwerkbandbreite, EBS-Durchsatz, angehängte Platten oder eine Lizenz, die an Kerne gebunden ist, hängen an der Größe. Die Plattformunterschiede in der Empfehlung sind die Liste, die vor der Änderung gelesen werden muss.
• Rightsizing vor der Zuordnung: Ohne Verantwortlichen nimmt niemand die Empfehlung an, und niemand merkt, wenn sie bricht. Der Kreislauf beginnt bei der Zuordnung, nicht beim Werkzeug.
• Geschätzt und nie verifiziert: Die Ersparnis stand im Bericht, bevor die Instanz geändert war, und blieb dort stehen. Eine Einsparung existiert erst auf der Rechnung.
• Angewendet ohne Verantwortlichen: Eine Empfehlung mit niedrigem Risiko ist keine Freigabe. Wer die Ressource betreibt, entscheidet; derselbe Grundsatz gilt für ungenutzte und verwaiste Ressourcen.

Quellen

Gelesen am 2026-10-15. AWS Was ist Compute Optimizer, EC2-Empfehlungen und Einstufungen, Berechnung der Rightsizing-Empfehlungen im Cost Explorer, Anwendung von Reserved Instances und Größenflexibilität; Microsoft Advisor-Empfehlungen für unterausgelastete VMs, VM-Größe ändern, Reservierungen umtauschen und erstatten; Google Cloud Empfehlungen zum Maschinentyp anwenden.