Bereitgestellte, ungenutzte Kapazität

DynamoDB Provisioned Capacity Kosten entstehen aus Lese- und Schreibkapazitätseinheiten, die eine Tabelle reserviert und nicht verbraucht; dasselbe Muster heißt bei Cosmos DB Request Units pro Sekunde, bei Kinesis Shards, bei BigQuery Basis-Slots und bei Data Explorer Clusterinstanzen. Bereitgestellte Kapazität wird nach dem bestellten Wert berechnet, ob genutzt oder nicht; die Einsparung entsteht aus der Lücke zwischen bestellt und verbraucht, geschlossen durch Autoscaling, durch einen niedrigeren Wert oder durch den Wechsel in den bedarfsabhängigen Modus. Die Behebung gehört dem Team, das die Anwendung auf der Tabelle oder dem Stream betreibt, weil nur dort die Lastspitze bekannt ist.

Symptom

Die Rechnung zeigt Kapazitätsstunden, nicht Anfragen. Bei AWS sind das lineItem/UsageType EUC1-ReadCapacityUnit-Hrs und EUC1-WriteCapacityUnit-Hrs unter AmazonDynamoDB, gegenüber ReadRequestUnits und WriteRequestUnits im On-Demand-Modus, und EUC1-Storage-ShardHour unter AmazonKinesis. Bei Azure stehen MeterCategory Azure Cosmos DB mit 100 RU/s-Metern je Stunde, standard oder autoscale, und Azure Data Explorer mit Instanzstunden je Cluster. In Google Cloud trägt BigQuery die SKUs für Slot-Stunden je Edition, Basis und automatisch skaliert, unter BigQuery Reservation API. Daneben zeigen die Metriken verbrauchte Einheiten weit unter den bestellten. Was die Dienste grundsätzlich berechnen, steht in verwalteten Datenbanken und Data Warehouses und Analytik; die Reservierungen, die auf Kapazität aufsetzen, in reservierter Kapazität für verwaltete Dienste.

So erkennen Sie es

AWS

Die Tabellen im Provisioned-Modus mit ihren Einheiten:

for t in $(aws dynamodb list-tables --query 'TableNames[]' --output text); do
  aws dynamodb describe-table --table-name "$t" \
    --query 'Table.[TableName,BillingModeSummary.BillingMode,ProvisionedThroughput.ReadCapacityUnits,ProvisionedThroughput.WriteCapacityUnits]' --output text
done

Die verbrauchten Einheiten einer Tabelle über zwei Wochen, als Summe je Stunde geteilt durch 3.600 gegen die bestellten:

aws cloudwatch get-metric-statistics --namespace AWS/DynamoDB --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=<table> --statistics Sum \
  --start-time 2026-10-07T00:00:00Z --end-time 2026-10-21T00:00:00Z --period 3600

Compute Optimizer stuft eine Tabelle im Provisioned-Modus als ungenutzt ein, wenn über 14 Tage weder auf Tabellen- noch auf Indexebene Einheiten verbraucht wurden, und empfiehlt On-Demand oder einen niedrigeren Wert (gelesen am 2026-10-21): aws compute-optimizer get-idle-recommendations --filters name=ResourceType,values=DynamoDBTable. Trusted Advisor führt daneben die Kaufempfehlung für reservierte DynamoDB-Kapazität. Kinesis-Streams mit Modus und Shards:

aws kinesis list-streams --query 'StreamSummaries[].[StreamName,StreamModeDetails.StreamMode]' --output table
aws kinesis describe-stream-summary --stream-name <stream> --query 'StreamDescriptionSummary.[OpenShardCount,StreamModeDetails.StreamMode]'

Die Metrik IncomingBytes je Stream gegen die Kapazität der Shards ist die Lücke; im Provisioned-Modus zählt jede Shard-Stunde, im On-Demand-Modus die Stream-Stunde plus die gelesenen und geschriebenen GB (Kinesis-Preise). In den Abrechnungsdaten ist der Kandidat eine CapacityUnit-Hrs- oder ShardHour-Position mit vollen Stunden (AWS Cost and Usage Report).

Azure

Der Durchsatz je Container und die Auslastung:

az cosmosdb sql container throughput show --account-name <account> --database-name <db> --name <container> --resource-group <rg>
az kusto cluster list --query "[].{name:name, state:state, sku:sku.name, capacity:sku.capacity, autoscale:optimizedAutoscale.isEnabled}" -o table

Die Metrik NormalizedRUConsumption je Container ist das Verhältnis von verbrauchten zu bereitgestellten RU/s je Partition. Autoscale berechnet je Stunde den höchsten erreichten Wert zum 1,5-fachen Satz des Standard-Durchsatzes, skaliert zwischen 10 und 100 Prozent des Maximums, und lohnt sich, wenn der volle Wert in höchstens 66 Prozent der Stunden gebraucht wird (manuell oder Autoscale). Azure Advisor empfiehlt Autoscale aus sieben Tagen Nutzung, meldet Cosmos-DB-Container ohne Aktivität über 30 Tage, und für Data Explorer das Stoppen ungenutzter Cluster, das Löschen seit 60 Tagen gestoppter Cluster und Optimized Autoscale. Im Kostenexport ist der Kandidat ein 100 RU/s-Meter mit vollen Stunden bei niedriger normalisierter Auslastung (Azure-Kostenexporte).

Google Cloud

Die Reservierungen mit Basis-Slots und Autoscaling:

bq ls --reservation --project_id=<project-id> --location=EU
bq show --reservation --project_id=<project-id> --location=EU <reservation>

Basis-Slots werden immer berechnet, ob genutzt oder nicht; automatisch skalierte Slots je Sekunde in Schritten von 50 Slots mit einer Mindestdauer von einer Minute, und berechnet wird die Zahl der skalierten Slots, nicht der genutzten (Slot-Autoscaling). Der Recommender google.bigquery.capacityCommitments.Recommender schlägt Slot-Commitments aus der Nutzung vor (Recommender-Übersicht); die Auslastung je Reservierung zeigt die Metrik slots/allocated_for_reservation gegen die Basis. Im Abrechnungsexport ist der Kandidat eine Slot-SKU mit vollen Stunden je Reservierung (Google-Cloud-Abrechnungsexport).

So beheben Sie es

1. Je Tabelle, Container, Stream oder Reservierung die Spitze und den Mittelwert der letzten zwei bis vier Wochen bestimmen; die Regel der Provider ist dieselbe: gleichmäßige, hohe Auslastung bleibt bereitgestellt, alles andere skaliert oder wechselt den Modus.
2. Den Modus wechseln, wo die Last schwankt oder gering ist: DynamoDB aws dynamodb update-table --table-name <table> --billing-mode PAY_PER_REQUEST, von Provisioned zu On-Demand bis zu viermal in 24 Stunden, zurück jederzeit (Kapazitätsmodus wechseln); Kinesis aws kinesis update-stream-mode --stream-arn <arn> --stream-mode-details StreamMode=ON_DEMAND; Cosmos DB az cosmosdb sql container throughput migrate --account-name <account> --database-name <db> --name <container> --resource-group <rg> --throughput-type autoscale.
3. Den Wert senken, wo die Last gleichmäßig ist: aws dynamodb update-table --table-name <table> --provisioned-throughput ReadCapacityUnits=50,WriteCapacityUnits=20 mit Auto Scaling auf 70 Prozent Zielauslastung, az cosmosdb sql container throughput update --throughput 1000, bq update --reservation --slots 100 --project_id=<project-id> --location=EU <reservation> für die Basis, az kusto cluster update --name <cluster> --resource-group <rg> --sku name=<sku> capacity=2 tier=Standard oder Optimized Autoscale.
4. Die Werte in die Vorlagen schreiben: Tabellen- und Container-Definitionen mit Autoscale oder On-Demand als Standard, eine Basis von null Slots, wo BigQuery nur Berichte rechnet, und ein Stopp-Zeitplan für Data-Explorer-Cluster ohne Nachtbetrieb.

Keiner dieser Aufrufe hat ein Dry-Run; die Liste aus der Erkennung ersetzt es. Der neue Wert gilt ab der Änderung, bei Cosmos DB ab der nächsten Stunde.

Risiken und Nebenwirkungen

• Zu wenig Kapazität zeigt sich als Drosselung: DynamoDB antwortet mit ProvisionedThroughputExceededException, Cosmos DB mit HTTP 429, Kinesis mit ProvisionedThroughputExceededException je Shard. Die Spitze gehört in den Zielwert, und Alarme auf diese Fehler vor die Senkung.
• On-Demand ist je Anfrage teurer als gut ausgelastete bereitgestellte Kapazität; bei gleichmäßiger, hoher Last kehrt die Rechnung um, und die Grenzen der Provider, 66 Prozent bei Cosmos DB, sind die Faustregel.
• Der Wechsel zu On-Demand bei DynamoDB löscht in der Konsole die Auto-Scaling-Einstellungen; über CLI und SDK bleiben sie erhalten.
• Reservierte Kapazität, DynamoDB Reserved Capacity oder eine Cosmos-DB-Reservierung, deckt nur bereitgestellte Einheiten; ein Wechsel zu On-Demand lässt sie leerlaufen (reservierte Kapazität für verwaltete Dienste).
• Basis-Slots bei BigQuery sichern die Latenz von Dashboards zu festen Zeiten; eine Basis von null spart, bis der erste Bericht am Montagmorgen auf Slots wartet.

So weisen Sie die Einsparung nach

Vorher: je Ressource die Kapazitätsstunden und ihr Betrag im letzten vollen Monat, CapacityUnit-Hrs, ShardHour, 100 RU/s, Slot-Stunden, daneben die verbrauchten Einheiten. Nachher: dieselbe Ressource im ersten vollen Monat nach der Änderung, im neuen Modus mit Anfrage-, Byte- oder skalierten Slot-Positionen, oder mit dem niedrigeren Wert; die Summe muss bei gleicher Anfragezahl sinken, und die Drosselungsfehler bei null bleiben. Die Differenz aus dem Recommender oder der eigenen Rechnung 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 verbrauchten zu bereitgestellten Einheiten je Ressource ist die Kennzahl für das Kostenreview.

Quellen

Gelesen am 2026-10-21. Kapazitätsmodus in DynamoDB wechseln, Compute Optimizer, Leerlaufressourcen, Trusted Advisor, Kostenoptimierungsprüfungen, Kinesis Data Streams, Preise, Azure Cosmos DB, manuell oder Autoscale, Azure Cosmos DB, Autoscale, Azure Advisor, Kostenempfehlungen, BigQuery, Slot-Autoscaling, Recommender-Übersicht.