Nicht angehängte Volumes und Disks

Nicht angehängte EBS Volumes, nicht zugeordnete Managed Disks und persistente Disks ohne Nutzer sind Blockspeicher, der nach dem Löschen seiner Instanz übrig blieb und seither nach Größe und Monat abgerechnet wird, ob beschrieben oder nicht. Die Einsparung entsteht, weil ein Volume ohne Instanz keinen Zweck mehr hat, den ein Snapshot nicht billiger erfüllt: sichern, löschen, und die Position fällt aus der Rechnung. Die Behebung gehört dem Team, das die Instanz gelöscht hat, mit einer Frist, nach der der Cloud-Verantwortliche die Liste abarbeitet.

Symptom

Die Rechnung führt Volumes, denen keine Instanzposition gegenübersteht. Bei AWS sind das Positionen mit lineItem/UsageType EUC1-EBS:VolumeUsage.gp3 oder EUC1-EBS:VolumeUsage.gp2 und lineItem/ProductCode AmazonEC2, deren lineItem/ResourceId eine vol--ID ist, die kein BoxUsage derselben Instanz begleitet. Bei Azure erscheinen sie unter MeterCategory Storage mit MeterSubCategory Premium SSD Managed Disks oder Standard SSD Managed Disks und einem MeterName wie P10 LRS Disk, die ResourceId endet auf disks/<name>. In Google Cloud ist es die SKU Storage PD Capacity oder Balanced PD Capacity unter Compute Engine je resource.name. Was ein Volume kostet, steht in Block-, Objekt- und Dateispeicher; was ungenutzte und verwaiste Ressourcen unterscheidet, in ungenutzte und verwaiste Ressourcen.

So erkennen Sie es

AWS

Ein Volume ohne Instanz steht im Zustand available. Die Liste mit Größe, Typ und Alter:

aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime,Tags[?Key==`Name`].Value|[0]]' --output table

CreateTime ist das Alter des Volumes, nicht der Zeitpunkt des Abhängens; den liefert CloudTrail mit aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=DetachVolume für die letzten 90 Tage. Zwei Prüfungen von AWS (gelesen am 2026-10-21): Trusted Advisor meldet unter "Underutilized Amazon EBS volumes" ein Volume, das nicht angehängt ist oder in den letzten sieben Tagen weniger als 1 IOPS pro Tag hatte; Compute Optimizer stuft ein Volume als Unattached ein, wenn es über 32 Tage an keiner Instanz hing, und als Idle, wenn die Lese- und Schreibvorgänge über den Betrachtungszeitraum unter einem pro Tag lagen und es kein Root-Volume ist; empfohlen wird in beiden Fällen Snapshot und Löschen:

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

In den Abrechnungsdaten ist der Kandidat eine vol--Ressource mit EBS:VolumeUsage, deren Instanz im selben Monat kein BoxUsage mehr trägt (AWS Cost and Usage Report).

Azure

Eine Managed Disk ohne VM steht im diskState Unattached:

az disk list --query "[?diskState=='Unattached'].{name:name, gb:diskSizeGb, sku:sku.name, rg:resourceGroup, created:timeCreated}" -o table

timeCreated ist auch hier das Alter der Disk; den Zeitpunkt des Abhängens zeigt das Aktivitätsprotokoll der Ressourcengruppe. Azure Advisor führt als Vorschau die Empfehlung "Review disks that aren't attached to a VM and evaluate if you still need the disks", die Replikat-Disks von Azure Site Recovery ausnimmt und vor dem Löschen einen Snapshot verlangt:

az advisor recommendation list --category Cost --query "[?contains(shortDescription.problem, 'disks')].{resource:resourceMetadata.resourceId, problem:shortDescription.problem}" -o table

Im Kostenexport ist der Kandidat eine ResourceId auf disks/ mit einem Disk-Meter, zu deren VM keine Virtual Machines-Zeile existiert; die Disk erbt die Tags der VM nicht, deshalb hilft nur die Ressourcengruppe (Azure-Kostenexporte).

Google Cloud

Eine persistente Disk ohne Nutzer hat ein leeres users-Feld, und lastDetachTimestamp nennt den Zeitpunkt des Abhängens:

gcloud compute disks list --filter="-users:*" \
  --format="table(name,zone.basename(),sizeGb,type.basename(),lastDetachTimestamp,creationTimestamp)"

Der Recommender für ungenutzte persistente Disks, google.compute.disk.IdleResourceRecommender, liefert dieselbe Liste mit Kostenschätzung je Zone (Recommender-Übersicht):

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

Im Abrechnungsexport trägt der Kandidat Storage PD Capacity oder Balanced PD Capacity auf einem resource.name, zu dem keine Instance Core running-Position gehört (Google-Cloud-Abrechnungsexport).

So beheben Sie es

1. Die Liste nach Alter sortieren und mit dem Verantwortlichen aus Tag oder Ressourcengruppe abstimmen; eine Frist aus der Kostenrichtlinie, etwa 30 Tage ohne Instanz, entscheidet, wann ein Volume auf die Löschliste kommt.
2. Sichern, dann löschen. AWS: aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "orphan 2026-10-21" --dry-run, dann aws ec2 delete-volume --volume-id vol-0123456789abcdef0 --dry-run; beide ohne --dry-run erst nach der Freigabe. Azure: az snapshot create --resource-group <rg> --name <snapshot> --source <disk> --incremental true, dann az disk delete --resource-group <rg> --name <disk>, ohne Dry-Run, also nur gegen die geprüfte Liste. Google Cloud: gcloud compute disks snapshot <disk> --zone=<zone> --snapshot-names=<snapshot>, dann gcloud compute disks delete <disk> --zone=<zone>.
3. Die Ursache abstellen: bei AWS DeleteOnTermination in der Blockgerätezuordnung der Launch-Vorlage für Datenvolumes, die zur Instanz gehören; bei Azure die Löschoption für OS- und Datendisks in der VM-Definition; bei Google Cloud --auto-delete an der Disk-Anbindung. Ein Volume, das die Instanz überleben soll, bekommt stattdessen ein Tag mit Zweck und Verantwortlichem.
4. Die Snapshots aus Schritt 2 bekommen ein Ablaufdatum, sonst wandert die Position nur in alte Snapshots und Maschinen-Images.

Die Position endet mit dem Löschen; der nächste Tagesexport zeigt sie nicht mehr.

Risiken und Nebenwirkungen

• Ein Volume ohne Instanz ist zuweilen Absicht: ein Datenträger, der zwischen Batch-Läufen abgehängt wird, ein vorbereitetes Volume für einen Failover, ein Datensatz, der auf eine Übergabe wartet. Tag oder Name sagen es, die Rückfrage beim Verantwortlichen entscheidet.
• Das Löschen ist bei allen drei Providern endgültig; der Snapshot aus Schritt 2 ist der einzige Rückweg, und eine Wiederherstellung sollte einmal geprobt sein.
• Ein Snapshot ist nicht kostenlos: er kostet nach gespeicherten Daten, bei Azure inkrementell auf Standard-HDD-Speicher, bei AWS inkrementell je Volume. Für ein Volume, das ohnehin leer ist, lohnt er nicht; für eines mit Daten ist er für die Frist der Richtlinie billiger als das Volume.
• Azure Site Recovery und Backup-Dienste halten Replikat-Disks ohne VM, die zur Konfiguration gehören; Advisor nimmt sie aus, eine eigene Liste muss es auch tun.
• Bei Azure bleibt ein reservierter Disk-SKU, etwa eine Reservierung für P30, nach dem Löschen unbenutzt, bis eine andere Disk sie füllt (Commitment-Abdeckung und -Auslastung).

So weisen Sie die Einsparung nach

Vorher: je Volume-ID der Betrag der EBS:VolumeUsage-, Disk-Meter- oder PD Capacity-Position im letzten vollen Monat, als Summe über die Löschliste. Nachher: dieselben IDs im ersten vollen Monat nach dem Löschen, erwartet null, und daneben die neuen Snapshot-Positionen, EBS:SnapshotUsage, Snapshots-Meter und Storage Snapshot-SKUs, die der Nachweis gegenrechnet. Die Summe der Löschliste ist die Schätzung, die Zustimmung des Teams macht sie akzeptiert, das Löschen umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Die Zahl der Volumes ohne Instanz, älter als die Frist, ist die Kennzahl, die danach bei null bleiben muss.

Quellen

Gelesen am 2026-10-21. Trusted Advisor, Kostenoptimierungsprüfungen, Compute Optimizer, Leerlaufressourcen, describe-volumes, Azure Advisor, Kostenempfehlungen, az disk, Recommender-Übersicht, gcloud compute disks list.