Provisioned throughput decreases are limited within a given day

TL;DR — DynamoDB begrenzt, wie oft du die provisionierte Read-/Write-Kapazität einer Tabelle (oder eines GSI) an einem einzelnen UTC-Tag senken kannst. Du hast das Kontingent verbraucht, also wird UpdateTable abgelehnt. Warte auf das stündliche Auffüllen, fasse deine Senkung in wenigere, größere Schritte zusammen oder stelle die Tabelle auf On-Demand um und verwalte Senkungen gar nicht mehr.

Was es bedeutet

LimitExceededException: Subscriber limit exceeded: Provisioned throughput
decreases are limited within a given UTC day

Jede Tabelle beginnt einen UTC-Tag mit einem kleinen Budget an Kapazitäts-Senkungen (Erhöhungen können so oft wie nötig vorgenommen werden, vorbehaltlich der Kontokontingente und der Tatsache, dass DynamoDB dich nicht zu schnell hochfahren lässt). Du beginnst den Tag mit 4 verfügbaren Senkungen und verdienst jede Stunde 1 weitere, bis zu einem Maximum von 4 gleichzeitig verfügbaren — genug für bis zu 27 Senkungen über einen vollen 24-Stunden-Tag. Ist es aufgebraucht, scheitern weitere UpdateTable-Senkungsaufrufe mit einer LimitExceededException (HTTP 400; die generische Meldung des Developer Guide für diese Exception lautet "Too many operations for a given subscriber."), bis sich das Budget wieder auffüllt. Es ist ein Kontingent, also hilft blindes Wiederholen innerhalb desselben Fensters nichts.

Warum es passiert

• Flatterndes Auto-Scaling — ein sprunghafter Workload lässt DynamoDB-Auto-Scaling die Kapazität wiederholt herabstufen und verbrennt das Senkungsbudget.
• Ein Skript, das die Kapazität zu oft senkt — viele kleine Senkungen statt einer größeren.
• Manuelles Feintuning während Lasttests — die Kapazität wiederholt herunterregeln, wenn der Traffic abebbt.
• Budgets pro Index — Senkungslimits für Tabelle und GSI sind entkoppelt, sodass jeder GSI sein eigenes Kontingent hat; eine Tabelle mit mehreren Indizes kann es bei einem davon erreichen. Ein einzelner UpdateTable-Request, der sowohl die Tabelle als auch einen GSI senkt, wird komplett abgelehnt, wenn eines von beiden sein aktuelles Limit überschreitet.

So behebst du es

1. Warte auf das Auffüllen. Jede Stunde wird eine Senkung verfügbar (bis zu 4 gleichzeitig verfügbar); jeden UTC-Tag beginnt ein frisches Budget von 4 Senkungen.
2. Nimm weniger, größere Senkungen vor. Fahre in einem Schritt von 1000 → 200 herunter statt in fünf 160-Einheiten-Schritten.
3. Feintune das Auto-Scaling — erhöhe die Ziel-Auslastung und füge eine Scale-in-Abkühlphase hinzu, damit es nicht mehr so aggressiv senkt.
4. Wechsle zu On-Demand, wenn der Workload sprunghaft oder unvorhersehbar ist:

   aws dynamodb update-table --table-name <Table> \
     --billing-mode PAY_PER_REQUEST

   KopierenKopiert
   On-Demand entfernt das manuelle Kapazitätsmanagement (und dessen Senkungskontingent) vollständig.

Verwandte Fehler

• ProvisionedThroughputExceededException — die Laufzeit-Drosselung, wenn Reads/Writes die provisionierte Kapazität überschreiten.
• LimitExceededException — die breitere Kontingentfamilie der Konto-/Tabellen-Control-Plane.
• Learn: On-Demand vs. provisioniert

Referenzen

• Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• UpdateTable — Amazon DynamoDB API Reference
• DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.