Gestoppte Instanzen kosten weiter, weil der Stop nur die Compute-Stunden beendet: die Disks, die festen öffentlichen Adressen, ein dedizierter Host, ein Commitment und bei Azure sogar die Instanz selbst, wenn sie nur aus dem Gastsystem heruntergefahren wurde, laufen auf der Rechnung weiter. Die Einsparung entsteht erst, wenn die Instanz freigegeben, ihre Disks gesichert und gelöscht und ihre Adressen zurückgegeben sind. Die Behebung gehört dem Team, das die Instanz gestoppt hat und seither nicht entschieden hat, ob es sie noch braucht.
Symptom
Die Rechnung zeigt für eine Ressource keine Instanzstunden mehr, aber weiter Speicher und Netzwerk. Bei AWS sind das Positionen mit lineItem/UsageType EUC1-EBS:VolumeUsage.gp3 und EUC1-PublicIPv4:IdleAddress oder InUseAddress für eine lineItem/ResourceId, deren BoxUsage-Position verschwunden ist. Bei Azure erscheint die VM unter MeterCategory Virtual Machines weiter mit voller Quantity, wenn sie nur aus dem Betriebssystem gestoppt wurde; bei einer freigegebenen VM bleiben MeterCategory Storage mit Disk-Metern und MeterCategory Virtual Network mit IP Addresses. In Google Cloud bleiben die SKUs Storage PD Capacity und Static Ip Charge je resource.name, während Instance Core running fehlt. Was ein Stop bei den drei Providern genau beendet, steht in den Abrechnungsseiten der Instanzen; diese Seite nennt, was übrig bleibt, und wie Sie es finden.
So erkennen Sie es
AWS
Was AWS nach einem Stop weiter berechnet, ist dokumentiert (gelesen am 2026-10-21): keine Nutzungs- und Datentransfergebühren für die Instanz, aber die EBS-Volumes und alle Elastic-IP-Adressen, ob zugeordnet oder nicht; die automatisch vergebene öffentliche IPv4-Adresse geht beim Stop verloren. Dedicated Hosts werden pro Host berechnet, mit oder ohne laufende Instanzen, und eine Reserved Instance läuft weiter, ob die Instanz läuft oder nicht. Die gestoppten Instanzen mit ihrem Stoppgrund und ihren Volumes:
aws ec2 describe-instances --filters Name=instance-state-name,Values=stopped \
--query 'Reservations[].Instances[].[InstanceId,InstanceType,PlatformDetails,StateTransitionReason,BlockDeviceMappings[].Ebs.VolumeId|join(`,`,@)]' \
--output table
StateTransitionReason trägt den Zeitpunkt des Stops, etwa User initiated (2026-08-03 14:02:11 GMT). Die Adressen, die an gestoppten Instanzen hängen:
aws ec2 describe-addresses --query 'Addresses[].[PublicIp,InstanceId,AssociationId]' --output table
Dedizierte Hosts ohne Instanzen zeigt aws ec2 describe-hosts --query 'Hosts[?length(Instances)==0].[HostId,HostProperties.InstanceFamily,State]'. Die Prüfung "Amazon EC2 instances stopped" in Trusted Advisor listet gestoppte Instanzen; Compute Optimizer meldet die Volumes dazu als Unattached erst, wenn sie 32 Tage an keiner Instanz hingen, was bei einer gestoppten Instanz nie eintritt. In den Abrechnungsdaten erkennen Sie den Fall an EBS:VolumeUsage ohne BoxUsage für dieselbe Ressource im selben Monat (AWS Cost and Usage Report).
Azure
Azure unterscheidet zwei Zustände, und nur einer spart: "Stopped" nach einem Herunterfahren aus dem Gastsystem lässt die VM auf dem Host zugeteilt und wird weiter berechnet; "Stopped (deallocated)" nach az vm deallocate gibt die Hardware frei und beendet die Compute-Abrechnung, während Disks und Netzwerk weiter berechnet werden (VM-Zustände und Abrechnung). Beide Zustände auf einen Blick:
az vm list -d --query "[?powerState=='VM stopped' || powerState=='VM deallocated'].{name:name, state:powerState, size:hardwareProfile.vmSize, rg:resourceGroup}" -o table
Die Disks und öffentlichen Adressen, die an diesen VMs hängen:
az disk list --query "[?managedBy!=null].{disk:name, vm:managedBy, sku:sku.name, gb:diskSizeGb}" -o table
az network public-ip list --query "[].{name:name, alloc:publicIPAllocationMethod, sku:sku.name, attached:ipConfiguration.id}" -o table
Azure Advisor hat für gestoppte VMs keine eigene Empfehlung; die Empfehlung zu unterausgelasteten VMs erfasst nur laufende. Im Kostenexport ist eine aus dem Gastsystem gestoppte VM an voller Quantity unter Virtual Machines bei flachen Metriken zu erkennen, eine freigegebene an Storage- und IP Addresses-Zeilen ohne Virtual Machines-Zeile (Azure-Kostenexporte).
Google Cloud
Ein gestoppter Compute-Engine-Server steht im Status TERMINATED und berechnet weiter Disks, Disk-Snapshots und externe IP-Adressen, die ihm zugeordnet bleiben (Instanzen stoppen und starten). Ein angehaltener steht in SUSPENDED: sein Arbeitsspeicher wird als persistenter Speicher gesichert und zählt gegen die Persistent-Disk-Quote, und nach 60 Tagen setzt Compute Engine ihn selbst auf TERMINATED (Instanzen anhalten und fortsetzen). Beide Zustände mit ihren Disks:
gcloud compute instances list --filter="status=(TERMINATED,SUSPENDED)" \
--format="table(name,zone.basename(),status,lastStopTimestamp,disks[].deviceName.list())"
Die reservierten externen Adressen, zugeordnet oder nicht:
gcloud compute addresses list --format="table(name,region.basename(),address,status,users.list())"
Der Recommender für ungenutzte IP-Adressen, google.compute.address.IdleResourceRecommender, und der für ungenutzte persistente Disks, google.compute.disk.IdleResourceRecommender, finden die Reste, wenn die Instanz gelöscht, nicht nur gestoppt ist (Recommender-Übersicht). Im Abrechnungsexport trägt der Fall Storage PD Capacity und Static Ip Charge ohne Instance Core running für dasselbe resource.name (Google-Cloud-Abrechnungsexport).
So beheben Sie es
- Für jede gestoppte Instanz den Stoppzeitpunkt und den Verantwortlichen festhalten; eine Instanz, die länger gestoppt ist als die Frist der Kostenrichtlinie, etwa 30 Tage, kommt auf die Löschliste.
- Bei Azure zuerst den Zustand korrigieren:
az vm deallocate --resource-group <rg> --name <vm>macht aus einer nur heruntergefahrenen VM eine freigegebene. Das allein beendet die Compute-Abrechnung. - Sichern, dann löschen. AWS: ein Image oder Snapshot je Volume, dann
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0 --dry-run, ohne--dry-runerst nach der Freigabe; die Root-Disk wird mit der Instanz gelöscht, wennDeleteOnTerminationgesetzt ist, Datenvolumes bleiben und brauchenaws ec2 delete-volume --volume-id vol-0123456789abcdef0 --dry-run. Adressen gibtaws ec2 release-address --allocation-id eipalloc-0123456789abcdef0 --dry-runzurück. Azure:az vm deletelöscht nur die VM, Disks und Adressen bleiben;az disk deleteundaz network public-ip deletefolgen ohne Dry-Run, also nur gegen die geprüfte Liste. Google Cloud:gcloud compute instances delete <vm> --zone=<zone>fragt, was mit den Disks geschehen soll;gcloud compute addresses deletegibt eine Adresse frei. - Die Ursache abstellen: Instanzen, die regelmäßig gestoppt werden, bekommen einen Zeitplan mit Löschung nach Ablauf (Zeitpläne und Auto-Scaling), und
DeleteOnTerminationoder das Azure-Löschverhalten für OS-Disks gehört in die Vorlage, aus der neue Instanzen entstehen.
Die Compute-Einsparung aus Schritt 2 wirkt sofort; die Speicher- und Adresseinsparung aus Schritt 3 erscheint im Tagesexport nach dem Löschen.
Risiken und Nebenwirkungen
- Eine gestoppte Instanz ist oft ein Backup, das niemand so genannt hat. Vor dem Löschen muss ein Snapshot oder Image existieren, und die Wiederherstellung muss einmal geprobt sein; alte Snapshots und Maschinen-Images sagt, wie lange die dann bleiben.
- Eine freigegebene Elastic-IP-Adresse oder eine dynamische Azure-Adresse kommt nicht zurück. DNS-Einträge, Firewall-Regeln beim Kunden und Allowlists bei Partnern zeigen weiter auf die alte Adresse.
- Ein Dedicated Host oder ein Commitment spart durch das Löschen der Instanz nichts; dort ist die Frage, ob der Host freigegeben oder das Commitment auf andere Instanzen gelenkt wird (Commitment-Abdeckung und -Auslastung).
- Lizenzen folgen unterschiedlichen Regeln: eine im Instanzpreis enthaltene Windows-Lizenz endet mit den Stunden, eine mitgebrachte Lizenz nicht, und eine Marketplace-Gebühr pro Stunde endet mit der Instanz, ein Abonnement nicht (vergessene Marketplace-Abos und Lizenzgebühren).
- Beim Neustart einer lange gestoppten Instanz fehlen Sicherheitsupdates, und bei Google Cloud ist ein nach 60 Tagen beendeter angehaltener Server ohne seinen Arbeitsspeicherzustand.
So weisen Sie die Einsparung nach
Vorher: je Ressourcen-ID die Positionen, die nach dem Stop übrig blieben: EBS:VolumeUsage und PublicIPv4, die Storage- und IP Addresses-Zeilen, Storage PD Capacity und Static Ip Charge, als Betrag des letzten vollen Monats. Nachher: dieselben Positionen im ersten vollen Monat nach dem Löschen, erwartet null, und bei Azure zusätzlich die Virtual Machines-Zeile, die nach der Freigabe verschwinden muss. Der Betrag der Löschliste ist die Schätzung; die Zustimmung des Teams macht sie akzeptiert; das Löschen umgesetzt; die Rechnung des Folgemonats belegt sie, wie geschätzt, akzeptiert, umgesetzt, verifiziert es anlegt. Ein Snapshot, der statt der Disk bleibt, ist eine neue Position; der Nachweis rechnet ihn gegen.
Quellen
Gelesen am 2026-10-21. So funktioniert Stoppen und Starten von EC2-Instanzen, Elastic-IP-Adressen, Trusted Advisor, Kostenoptimierungsprüfungen, Compute Optimizer, Leerlaufressourcen, Azure VM-Zustände und Abrechnung, Compute-Engine-Instanzen stoppen und starten, Instanzen anhalten und fortsetzen, Recommender-Übersicht.