Kann DynamoDB automatisch skalieren?
Ja. DynamoDB Auto Scaling nutzt Application Auto Scaling, um die provisionierte Lese- und Schreibkapazität in Richtung einer Ziel-Auslastung anzupassen (einstellbar 20–90 %, üblich 70 %), innerhalb der Min-/Max-Grenzen, die du festlegst. Alternativ skaliert der On-Demand-Kapazitätsmodus sofort mit dem Traffic, ganz ohne Konfiguration. Beide halten Tabellen ohne manuelle Kapazitätsplanung reaktionsfähig gegenüber wechselnder Last.
Auto Scaling bei provisionierter Kapazität
Du legst pro Tabelle (und pro Global Secondary Index) eine Scaling-Policy an, die Folgendes setzt:
- eine Ziel-Auslastung (Prozent der provisionierten Kapazität, die angestrebt wird),
- Minimum und Maximum an Kapazitätseinheiten und
- ob Reads, Writes oder beides skaliert werden.
CloudWatch-Alarme lösen Application Auto Scaling aus, das die Kapazität anhebt oder senkt, sobald der Verbrauch das Ziel kreuzt.
On-Demand-Modus
On-Demand-Kapazität nimmt dir die Planung vollständig ab: DynamoDB passt den Durchsatz selbst an deinen Traffic an — und verkraftet sofort bis zum Doppelten deiner bisherigen Traffic-Spitze — und rechnet pro Anfrage ab. Das passt gut, wenn der Traffic sprunghaft oder schwer vorhersehbar ist.
Was wählen
Provisioniert mit Auto Scaling kostet meist weniger, wenn der Traffic stabil und gut verstanden ist; On-Demand ist einfacher und besser für unbekannten oder sprunghaften Traffic.
Wo sich die Ziel-Auslastung nicht mehr rechnet
Die Ziel-Auslastung ist ein Preisregler, und sie hat einen Boden, unterhalb dessen Auto Scaling gegen On-Demand schlicht verliert.
In us-east-1 kostet eine Write-Kapazitätseinheit 0,00065 $ pro Stunde — sie einen Monat lang zu reservieren kostet also 0,4745 $ und kauft 2.628.000 Writes. Das sind 0,00000018 $ pro Write gegenüber 0,000000625 $ bei On-Demand, womit provisionierte Kapazität 3,46-mal günstiger ist, wenn jede reservierte Einheit auch genutzt wird. Kehr es um, und du hast den Break-even: Provisioniert rechnet sich unterhalb von 28,9 % durchschnittlicher Auslastung nicht mehr. Bei Reads kommen dieselben 28,9 % heraus — das ist also eine Eigenschaft des Preismodells und nicht einer einzelnen Rate.
Dauerhaft 1.000 Writes pro Sekunde bei 1-KB-Items, bepreist mit dem Preisrechner:
| Kapazitätseinstellung | Provisioniert | Monatlich |
|---|---|---|
| 90 % Ziel | 1.112 WCU | 527,64 $ |
| 70 % Ziel | 1.429 WCU | 678,06 $ |
| 50 % Ziel | 2.000 WCU | 949,00 $ |
| 20 % Ziel | 5.000 WCU | 2.372,50 $ |
| On-Demand | keine | 1.642,50 $ |
Die letzten beiden Zeilen tragen die Lektion. Ein 20-%-Ziel — das niedrigste, das AWS akzeptiert — reserviert das Fünffache deines Traffics und kostet 44 % mehr, als dieselbe Arbeit pro Anfrage zu bezahlen. Jede Zeile darüber unterstellt, dass Auto Scaling die Kapazität exakt am Ziel festhält; behandle sie also als Bestfälle: Echter Traffic wandert, und der Algorithmus folgt ihm verspätet, was die tatsächlich erreichte Auslastung unter alles drückt, was du konfiguriert hast.
Was der Regler kauft
Hoch- und Herunterskalieren sind bewusst asymmetrisch, und genau diese Asymmetrie bezahlt der Puffer. AWS dokumentiert, dass das Hochskalieren ausgelöst wird, nachdem die verbrauchte Kapazität das Ziel zwei aufeinanderfolgende Minuten lang überschritten hat, und das Herunterskalieren nach 15 aufeinanderfolgenden Datenpunkten darunter. Der darauf folgende UpdateTable-Aufruf braucht mehrere weitere Minuten, und alles oberhalb der alten Obergrenze wird währenddessen gedrosselt.
Auch Senkungen sind rationiert. Du startest jeden UTC-Tag mit vier und verdienst eine pro Stunde hinzu, hältst aber nie mehr als vier — was dich bei 27 pro Tag und Tabelle deckelt. Global Secondary Indexes bekommen ihr eigenes Kontingent.
Ein hohes Ziel spart also echtes Geld und gibt den Puffer aus, der diese Minuten abdeckt. On-Demand kostet mehr pro Anfrage und nimmt den Tauschhandel ganz weg.
Tiefer einsteigen
Vergleiche beides in On-Demand vs. provisionierte Kapazität und schätze die Kosten mit dem Preisrechner. Lade DynoTable herunter, um Größe und Item-Schätzungen einer Tabelle in den Table stats zu lesen.
Referenzen
- Managing throughput capacity automatically with DynamoDB auto scaling — Amazon DynamoDB Developer Guide
- DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
- DynamoDB provisioned capacity mode — Amazon DynamoDB Developer Guide
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide — das Senkungs-Kontingent, erneut geprüft am 2026-07-28.
Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.
Break-even am 2026-07-28 mit unserem eigenen Preisrechner über die us-east-1-Raten berechnet, die er von der AWS Price List API synchronisiert. Die Skalierungsverzögerungen und das Senkungs-Kontingent wurden am selben Datum erneut aus der oben verlinkten AWS-Dokumentation gelesen.