Ungenutzte virtuelle Maschinen sind Instanzen, die laufen, Stunden abrechnen und keine Arbeit leisten: eine Testumgebung nach dem Projekt, ein Bastion-Host ohne Logins, ein Worker, dessen Queue leer blieb. Die Einsparung entsteht, weil eine gestoppte oder gelöschte Instanz keine Compute-Stunden mehr erzeugt; der Rest der Rechnung, Disks und Adressen, bleibt bis zur zweiten Entscheidung. Die Behebung gehört dem Team, das die Instanz gestartet hat, mit einer Frist, nach der der Cloud-Verantwortliche stoppt.

Symptom

Die Rechnung zeigt Instanzstunden ohne passende Last. Bei AWS sind das Positionen mit lineItem/UsageType nach dem Muster EUC1-BoxUsage:m6i.large und lineItem/ProductCode AmazonEC2, deren lineItem/UsageAmount jeden Monat 720 oder 744 Stunden erreicht. Bei Azure tragen die Positionen MeterCategory Virtual Machines und einen MeterName wie D4s v5, mit einer Quantity, die den vollen Monat füllt. In Google Cloud sind es SKUs wie N2 Instance Core running in Frankfurt und N2 Instance Ram running in Frankfurt unter service.description Compute Engine, mit voller Stundenzahl je resource.name. Die Metriken daneben, CPU und Netzwerk, bleiben flach. Was eine ungenutzte von einer verwaisten Ressource unterscheidet, steht in ungenutzte und verwaiste Ressourcen; diese Seite behandelt nur die Instanz selbst.

Eine Instanz, die läuftund nichts tutInstanzstunden füllenden Monat: BoxUsage,Virtual Machines,Instance Core runningDie Metriken daneben,CPU und Netzwerk,bleiben flachVolle Stunden ohnepassende Last
Ungenutzt zeigt sich als Instanzstunden, die den Monat füllen, während CPU und Netzwerk daneben flach bleiben

So erkennen Sie es

Die Schwellen der Provider-Werkzeuge sind der Ausgangspunkt, nicht das Urteil: Sie finden Kandidaten, die das Team bestätigt.

AWS

Konsole: EC2, Instanzen, Filter auf den Zustand running, dann der Reiter Überwachung je Instanz; schneller ist AWS Compute Optimizer, Leerlaufressourcen. Die Kandidaten listet die CLI pro Region:

aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,LaunchTime,Tags[?Key==`Name`].Value|[0]]' \
  --output table

Die Auslastung einer Instanz über 14 Tage, als Tagesmaximum:

aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 --statistics Maximum \
  --start-time 2026-10-07T00:00:00Z --end-time 2026-10-21T00:00:00Z --period 86400

Zwei Prüfungen von AWS selbst, mit dokumentierten Schwellen (gelesen am 2026-10-21): Trusted Advisor meldet eine Instanz mit höchstens 10 Prozent durchschnittlicher CPU-Auslastung und höchstens 5 MB Netzwerk-I/O pro Tag an mindestens 4 der letzten 14 Tage; Compute Optimizer stuft eine Instanz als ungenutzt ein, wenn die CPU-Spitze über 14 Tage unter 5 Prozent und das Netzwerk-I/O unter 5 MB pro Tag bleibt. Die zweite Liste holt die CLI:

aws compute-optimizer get-idle-recommendations --filters name=ResourceType,values=EC2Instance

In den Abrechnungsdaten erkennen Sie den Kandidaten an einer BoxUsage-Position mit vollen Stunden je lineItem/ResourceId, neben der keine Datentransfer-Position nennenswert wächst (AWS Cost and Usage Report).

Azure

Konsole: Azure Advisor, Kosten, die Empfehlung "Right-size or shutdown underutilized virtual machines". Die laufenden VMs listet die CLI mit ihrem Energiezustand:

az vm list -d --query "[?powerState=='VM running'].{name:name, size:hardwareProfile.vmSize, rg:resourceGroup}" -o table

Die CPU-Auslastung einer VM als Tagesmaximum über zwei Wochen:

az monitor metrics list --resource <vm-resource-id> --metric "Percentage CPU" \
  --aggregation Maximum --interval P1D --start-time 2026-10-07T00:00:00Z --end-time 2026-10-21T00:00:00Z

Azure Advisor empfiehlt das Herunterfahren, wenn über die letzten sieben Tage das 95. Perzentil der maximalen CPU-Auslastung unter 3 Prozent, das Maximum der durchschnittlichen CPU der letzten drei Tage bei höchstens 2 Prozent und die ausgehende Netzwerkauslastung unter 2 Prozent liegt; der Betrachtungszeitraum ist auf bis zu 90 Tage einstellbar. Die Empfehlungen liefert az advisor recommendation list --category Cost -o table. Im Kostenexport ist der Kandidat eine ResourceId unter MeterCategory Virtual Machines mit voller Quantity (Azure-Kostenexporte).

Google Cloud

Konsole: Compute Engine, VM-Instanzen, die Spalte Empfehlungen; oder der Recommendation Hub. Die laufenden Instanzen:

gcloud compute instances list --filter="status=RUNNING" \
  --format="table(name,zone.basename(),machineType.basename(),creationTimestamp)"

Der Recommender für ungenutzte VMs bewertet standardmäßig 14 Tage CPU- und Netzwerknutzung und veröffentlicht seine Schwellen nicht; Instanzen mit lokalen SSDs, GPUs oder TPUs und GKE-Knoten bewertet er nicht. Je Zone:

gcloud recommender recommendations list --project=<project-id> --location=<zone> \
  --recommender=google.compute.instance.IdleResourceRecommender --format="table(name.basename(),description,stateInfo.state)"

Im Abrechnungsexport trägt der Kandidat volle Stunden auf den SKUs Instance Core running und Instance Ram running je resource.name (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Den Verantwortlichen aus dem Tag oder dem Konto ermitteln und die Liste mit einer Frist schicken; eine Instanz ohne Antwort gilt als freigegeben. Wer entscheidet, steht in der Checkliste für das monatliche Review.

  2. Stoppen statt löschen, als reversiblen ersten Schritt. AWS prüft den Aufruf mit --dry-run, bevor er wirkt:

    aws ec2 stop-instances --instance-ids i-0123456789abcdef0 --dry-run

    Azure hat kein Dry-Run; az vm deallocate --resource-group <rg> --name <vm> gibt die Hardware frei, ein Stop aus dem Gastsystem nicht. Google Cloud ebenso: gcloud compute instances stop <vm> --zone=<zone>.

  3. Nach einer Wartefrist, etwa 30 Tage ohne Rückfrage, Snapshot oder Image anlegen und löschen. Was nach dem Stop weiter kostet, Disks, feste Adressen, Lizenzen, steht in gestoppte Instanzen, die weiter kosten.

  4. Die Ursache abstellen: eine Umgebung, die nur tagsüber gebraucht wird, bekommt einen Zeitplan (Zeitpläne und Auto-Scaling); eine zu große Instanz mit geringer Last ist ein Fall für Rightsizing, nicht für diese Seite.

Die Wirkung erscheint sofort: AWS und Google Cloud rechnen sekundengenau, Azure bis zur Freigabe; der nächste Tagesexport zeigt die geringere Stundenzahl.

janein: weiter gebrauchtVerantwortlicher aus Tagoder Konto, die Listemit Frist geschicktFreigegeben oderkeine Antwort?Stoppen, der reversibleerste SchrittLäuft weiter; eine zu großeInstanz mit geringer Lastist Rightsizing, nichtdiese SeiteEine Wartefristohne RückfrageSnapshot oder Imageanlegen, dann löschenDie Ursache abstellen: eineUmgebung nur für tagsüberbekommt einen Zeitplan
Die Frist des Verantwortlichen entscheidet, der Stop kommt vor dem Löschen, und der Zeitplan stellt die Ursache ab

Risiken und Nebenwirkungen

  • Niedrige CPU ist kein Beweis für Leerlauf. Ein Lizenzserver, ein Scheduler, eine Replik, ein Warm-Standby für den Notfall laufen fast ohne Last und sind trotzdem nötig. Die Freigabe des Teams ersetzt die Schwelle.
  • Die Metriken sehen nur, was sie messen. Speicher und Disk-I/O fehlen in den Standardmetriken; ein Prozess, der auf Ereignisse wartet, sieht aus wie Leerlauf.
  • Eine gestoppte Instanz verliert ihre automatisch zugewiesene öffentliche IPv4-Adresse und den Inhalt lokaler Instanzspeicher; bei AWS ist das dokumentiert, bei Azure fällt die dynamische öffentliche IP mit der Freigabe weg.
  • Ein Commitment bleibt. Eine Reserved Instance oder ein Savings Plan deckt die Stunden weiter ab, ob die Instanz läuft oder nicht; die Einsparung ist dann nur die Differenz, die eine andere Instanz unter das Commitment bringt (Commitment-Abdeckung und -Auslastung).
  • Auto-Scaling-Gruppen ersetzen eine gestoppte Instanz; dort wird die Mindestgröße geändert, nicht die Instanz gestoppt.

So weisen Sie die Einsparung nach

Vorher: die BoxUsage-, Virtual Machines- oder Instance Core running-Stunden je Ressourcen-ID im letzten vollen Monat. Nachher: dieselbe Kennzahl im ersten vollen Monat nach dem Stop; sie muss auf null fallen, und die verbleibenden Positionen derselben Ressource, Disks und Adressen, sind die zweite Liste. Die Schätzung aus dem Recommender ist der Wert "geschätzt"; nach der Freigabe des Teams "akzeptiert"; nach dem Stop "umgesetzt"; erst die Rechnung des Folgemonats macht die Differenz zur belegten Einsparung, wie geschätzt, akzeptiert, umgesetzt, verifiziert es anlegt. Ein Commitment verschiebt den Nachweis: die Stunden sinken, der Commitment-Betrag nicht, und die Auslastung des Commitments ist die Kennzahl, die zeigen muss, dass eine andere Instanz die frei gewordene Abdeckung nutzt.

Quellen

Gelesen am 2026-10-21. Trusted Advisor, Kostenoptimierungsprüfungen, Compute Optimizer, Leerlaufressourcen, get-idle-recommendations, EC2-Instanzen stoppen und starten, Azure Advisor, unterausgelastete VMs, Azure VM-Zustände und Abrechnung, Recommender für ungenutzte VMs, Empfehlungen anwenden, Recommender-Übersicht.