Provisioned IOPS Kosten entstehen, wo Leistung bestellt statt gemessen wird: io2- und Ultra-Disk-IOPS, Hyperdisk-Extreme-IOPS, der Durchsatz eines Premium SSD v2 und die Provisioned IOPS einer RDS-Instanz werden nach der bestellten Zahl abgerechnet, ob die Anwendung sie abruft oder nicht. Die Einsparung entsteht aus der Lücke zwischen bestellt und verbraucht, die die Metriken der Provider je Volume zeigen, und sie wird mit einer Online-Änderung ohne Neustart gehoben. Die Behebung gehört dem Team, das die Datenbank oder den Dienst auf dem Volume betreibt, weil nur dort die Spitzenlast bekannt ist, die bleiben muss.

Symptom

Die Rechnung führt Leistung als eigene Position neben der Kapazität. Bei AWS sind das lineItem/UsageType EUC1-EBS:VolumeP-IOPS.io2 und EBS:VolumeP-IOPS.piops für io1, EBS:VolumeIOPS.gp3 und EBS:VolumeThroughput.gp3 für die Leistung über der gp3-Grundleistung, und bei RDS RDS:PIOPS-Storage und die IOPS-Positionen der gp3-Speicher. Bei Azure stehen Provisioned IOPS und Provisioned Throughput (MBps) als eigene Zeilen unter Azure Premium SSD v2 und Ultra Disks, je 1/Hour. In Google Cloud trägt Hyperdisk Extreme IOPS beziehungsweise Hyperdisk Balanced IOPS und Throughput die Leistung als SKU neben der Kapazität. Daneben liegen Metriken, deren Spitzen weit unter der bestellten Zahl bleiben. Die Typen und ihre Preisdimensionen stehen in Block-, Objekt- und Dateispeicher; der Typwechsel selbst in Volume-Typen modernisieren.

Ein Volume oder eineRDS-Instanz mitbestellter LeistungKapazität, alseigene PositionPosition Leistung: IOPSund Durchsatz, abgerechnetnach der bestellten Zahl,genutzt oder nichtMetriken: Spitzen weitunter der bestellten ZahlDie Lücke zwischen bestelltund verbraucht istdie Einsparung
Die Rechnung führt Leistung als eigene Position nach der bestellten Zahl, während die Spitze der Metrik daneben weit darunter bleibt

So erkennen Sie es

AWS

Die Volumes mit bestellter Leistung:

aws ec2 describe-volumes --filters Name=volume-type,Values=io1,io2,gp3 \
  --query 'Volumes[?Iops>`3000` || Throughput>`125`].[VolumeId,VolumeType,Size,Iops,Throughput,Attachments[0].InstanceId]' --output table

Die genutzte Leistung eines Volumes über zwei Wochen, als Summe je Minute aus VolumeReadOps und VolumeWriteOps:

aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeWriteOps \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 --statistics Maximum \
  --start-time 2026-10-07T00:00:00Z --end-time 2026-10-21T00:00:00Z --period 60

Das Maximum je Minute geteilt durch 60 ist die Spitze in IOPS. Compute Optimizer bewertet Typ, Größe, IOPS und Durchsatz aus 14 Tagen Metriken und nennt bei EC2-Instanzen die Gründe EBS IOPS over-provisioned und EBS throughput over-provisioned; aws compute-optimizer get-ebs-volume-recommendations liefert die Volume-Empfehlungen mit Zielwerten. RDS-Instanzen mit Provisioned IOPS:

aws rds describe-db-instances \
  --query 'DBInstances[?Iops!=null].[DBInstanceIdentifier,StorageType,AllocatedStorage,Iops,StorageThroughput,DBInstanceClass]' --output table

Die Spitze aus ReadIOPS plus WriteIOPS im Namensraum AWS/RDS gegen Iops ist die Lücke; Trusted Advisor führt dazu "Amazon RDS cost optimization recommendations for DB instance storage" und die ältere Prüfung "Amazon EBS over-provisioned volumes" (gelesen am 2026-10-21). In den Abrechnungsdaten sind die VolumeP-IOPS- und PIOPS-Storage-Positionen je Ressource die Kennzahl (AWS Cost and Usage Report).

Azure

Die Disks mit einzeln bestellter Leistung:

az disk list --query "[?sku.name=='PremiumV2_LRS' || sku.name=='UltraSSD_LRS'].{name:name, sku:sku.name, gb:diskSizeGb, iops:diskIopsReadWrite, mbps:diskMBpsReadWrite, vm:managedBy}" -o table

Azure Monitor liefert je VM die Metriken Data Disk IOPS Consumed Percentage und Data Disk Bandwidth Consumed Percentage, die tatsächliche gegen bestellte Leistung je Disk ins Verhältnis setzen, aufgeteilt nach LUN (Disk-Metriken):

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

Ein Maximum weit unter 100 Prozent über zwei Wochen ist die Lücke. Für Premium SSD mit fester Stufe gilt dasselbe über den Stufenwechsel; die Performance-Stufe einer Premium SSD lässt sich ohne Größenänderung senken. Azure Advisor hat zu bestellten IOPS keine Empfehlung. Im Kostenexport sind die Zeilen Provisioned IOPS und Provisioned Throughput (MBps) je disks/-Ressource die Kennzahl (Azure-Kostenexporte).

Google Cloud

Die Disks mit bestellten IOPS oder Durchsatz:

gcloud compute disks list --filter="provisionedIops>0 OR provisionedThroughput>0" \
  --format="table(name,zone.basename(),type.basename(),sizeGb,provisionedIops,provisionedThroughput,users.list())"

Die genutzte Leistung liefern die Metriken compute.googleapis.com/instance/disk/read_ops_count und write_ops_count je Disk in Cloud Monitoring; die Summe je Minute geteilt durch 60 gegen provisionedIops ist die Lücke. Einen Recommender dafür gibt es nicht. Im Abrechnungsexport sind die IOPS- und Throughput-SKUs je resource.name die Kennzahl (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Die Spitze der letzten zwei bis vier Wochen bestimmen, einschließlich Backup-Fenster und Monatsende, und die Zielleistung als Spitze plus Reserve festlegen; was die Anwendung im Mittel braucht, ist nicht der Maßstab.
  2. Die Leistung senken, online: AWS aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --iops 6000 --throughput 250 --dry-run, dann ohne --dry-run; bei RDS aws rds modify-db-instance --db-instance-identifier <id> --iops 6000 --apply-immediately, was die Speicheroptimierung auslöst und die Instanz online lässt. Azure az disk update --name <disk> --resource-group <rg> --disk-iops-read-write 6000 --disk-mbps-read-write 250, bei Premium SSD v2 bis zu viermal in 24 Stunden ohne Abhängen; bei Premium SSD die Performance-Stufe mit --tier. Google Cloud gcloud compute disks update <disk> --zone=<zone> --provisioned-iops=6000 für Hyperdisk, ohne Dry-Run.
  3. Wo die bestellte Leistung nur für ein wöchentliches Fenster nötig ist, die Änderung in beide Richtungen planen, im Rahmen der Änderungsgrenzen je Tag.
  4. Die Zielwerte in die Vorlagen schreiben, mit denen Volumes und Datenbanken entstehen, und BurstBalance-Alarme beziehungsweise die Consumed Percentage-Metriken als Wächter gegen zu wenig Leistung.

Der neue Preis gilt ab Beginn der Änderung; die Positionen für IOPS und Durchsatz sinken im nächsten Tagesexport.

janeinDie Spitze der letzten zweibis vier Wochen bestimmen,Backup-Fenster undMonatsende eingeschlossenZiel: die Spitze plusReserve, nicht das MittelDie Leistung online senken:Dry-Run, dann die ÄnderungNur für ein wöchentlichesFenster nötig?Die Änderung in beideRichtungen planen, im Rahmender Änderungsgrenzen je TagDie Zielwerte in dieVorlagen schreiben;BurstBalance- oderConsumed-Percentage-Alarmeals WächterNeuer Preis ab Beginn derÄnderung; die Positionensinken im nächstenTagesexport
Die Spitze aus zwei bis vier Wochen setzt das Ziel, die Änderung läuft online, und Vorlagen und Alarme halten die Lücke geschlossen

Risiken und Nebenwirkungen

  • Zu wenig IOPS zeigt sich als Latenz, nicht als Fehler: Warteschlangen wachsen, Datenbanken antworten langsamer, Backups laufen länger. Die Metriken IOPS exceeded check bei AWS und Consumed Percentage bei Azure zeigen, wann das Limit erreicht ist.
  • Die Spitze liegt oft außerhalb des Betrachtungszeitraums: Jahresabschluss, Migration, Wiederherstellung. Die Reserve gehört in den Zielwert, und der Weg zurück nach oben muss vor der Senkung geprobt sein.
  • Änderungsgrenzen: bei AWS viermal in 24 Stunden je Volume und je Änderung Minuten bis Stunden, bei Azure zweimal täglich für den Typ und viermal in 24 Stunden für die Leistung eines Premium SSD v2; eine Senkung, die am Freitag endet, lässt sich am Montag nicht sofort umkehren.
  • Bei RDS gilt die Leistung je Instanz; eine Multi-AZ-Instanz braucht sie auf beiden Seiten, und das Senken löst eine Speicheroptimierung aus, in deren Dauer keine weitere Speicheränderung möglich ist.
  • Die Grundleistung von gp3 ist nicht zu unterschreiten; ein Volume, das 3.000 IOPS nicht nutzt, spart durch einen kleineren Wert nichts.

So weisen Sie die Einsparung nach

Vorher: je Volume oder Instanz die Positionen VolumeP-IOPS, VolumeIOPS, VolumeThroughput, PIOPS-Storage, Provisioned IOPS, Provisioned Throughput und die IOPS-SKUs im letzten vollen Monat, als Betrag und bestellte Menge, daneben die gemessene Spitze. Nachher: dieselben Positionen im ersten vollen Monat mit der neuen Menge, bei unveränderter Kapazitätsposition und unveränderter Latenz des Dienstes. Die Differenz aus Recommender oder Preisliste ist die Schätzung, die Freigabe des Teams macht sie akzeptiert, die Änderung umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Das Verhältnis von genutzter zu bestellter Leistung je Volume ist die Kennzahl, die danach regelmäßig im Kostenreview steht.

Quellen

Gelesen am 2026-10-21. Compute Optimizer, EBS-Empfehlungen, Compute Optimizer, EC2-Empfehlungen, Volumes mit Elastic Volumes ändern, Trusted Advisor, Kostenoptimierungsprüfungen, Azure, Disk-Metriken, Azure, Disk-Typen, Azure, Disk-Typen konvertieren, gcloud compute disks list.