DynamoDB On-Demand vs. Provisioned Capacity
DynamoDB berechnet Durchsatz auf zwei Arten. On-Demand rechnet pro Anfrage ab — du bezahlst für das, was du nutzt, und skalierst auf null. Provisioned reserviert eine feste Lese-/Schreibrate, die du bezahlst, ob du sie nutzt oder nicht, zu einem deutlich niedrigeren Preis pro Einheit. Den falschen zu wählen ist eine der einfachsten Arten, zu viel zu bezahlen.
Der Audit-Log macht die Wahl greifbar. Audit-Writes sind sprunghaft und unvorhersehbar: nachts ruhig, dann eine Flut, wenn ein Kunde eine Massenoperation ausführt oder ein Incident Tausende von Ereignissen erzeugt. Diese Traffic-Form ist die ganze Entscheidung.
Sollte ich DynamoDB On-Demand oder Provisioned Capacity nutzen?
On-Demand rechnet pro Anfrage ab und skaliert auf null, was es zum sicheren Standard für sprunghaften, neuen oder unvorhersehbaren Traffic macht. Provisioned reserviert eine feste Lese-/Schreibrate zu einem weit niedrigeren Preis pro Einheit und gewinnt nur, wenn anhaltender, stetiger Traffic diese Reservierung gut ausgelastet hält. Wähle On-Demand, es sei denn, dein Volumen ist bewiesen und vorhersehbar.
- On-Demand = Pay-per-Request, skaliert auf null. Keine Kapazität zu planen; du bezahlst einen höheren Preis pro Read/Write, aber nur wenn Traffic auftritt.
- Provisioned = eine stetige Rate reservieren, immer dafür bezahlen. Viel günstiger pro Einheit, wenn die Rate gut ausgelastet ist; du trägst die Kosten für ungenutzte Kapazität.
- Sprunghafter oder unbekannter Traffic verlangt nach On-Demand. Stetiger, vorhersehbarer, hochvolumiger Traffic verlangt nach Provisioned (optional mit Auto-Scaling).
- Du kannst die Modi wechseln, aber das Limit ist asymmetrisch: Provisioned zu On-Demand ist auf viermal pro 24 Stunden begrenzt, während On-Demand zu Provisioned unbeschränkt ist — es ist kein Umschalter pro Anfrage.
Das Problem: für Kapazität bezahlen, die du nicht nutzt
Mit Provisioned Capacity legst du dich auf, sagen wir, 1.000 Write-Units pro Sekunde fest. Wenn der Audit-Log im Schnitt 50 Writes/Sekunde macht, du aber für den Incident-Tag-Spitzenwert provisioniert hast, bezahlst du rund um die Uhr für 1.000 und nutzt ein Zwanzigstel davon. Provisioniere stattdessen für den Durchschnitt, und die Flut am Incident-Tag wird gedrosselt — Writes werden zurückgewiesen.
Feste Kapazität erzwingt also einen schlechten Kompromiss bei sprunghaftem Traffic: ständig zu viel bezahlen oder unterprovisionieren und Writes verwerfen, wenn es am wichtigsten ist. On-Demand existiert genau dazu, diesen Kompromiss aufzuheben.
Wie die beiden Modi funktionieren
On-Demand rechnet die Read- und Write-Request-Units ab, die du tatsächlich verbrauchst, ohne Kapazität zu konfigurieren — es nimmt Spitzen bis zum Doppelten deines vorherigen Traffic-Höchststands sofort auf und skaliert auf null, wenn es untätig ist. Über diesen 2x-Sprung innerhalb eines kurzen Zeitfensters hinaus kann es immer noch drosseln, während es hochfährt. Du bezahlst einen Aufschlag pro Anfrage für diese Elastizität.
Provisioned reserviert eine Anzahl von Read Capacity Units (RCU) und Write Capacity Units (WCU) pro Sekunde. Der Preis pro Einheit ist weit niedriger, aber du bezahlst für die Reservierung fortlaufend, genutzt oder nicht. Überschreite sie, und DynamoDB drosselt, es sei denn, Auto-Scaling ist aktiviert, um die Kapazität innerhalb konfigurierter Grenzen zu erhöhen — allerdings reagiert Auto-Scaling über Minuten, sodass eine plötzliche Spitze immer noch drosseln kann, bevor es aufholt.
Der Umschlagpunkt ist die Auslastung. Grob: Wenn dein anhaltender, vorhersehbarer Traffic die Provisioned Capacity gut ausgelastet hält, gewinnt Provisioned beim Preis; wenn der Traffic sprunghaft, stoßweise oder unbekannt ist, gewinnt On-Demand, indem es nicht für ungenutzte Reservierung berechnet.
Ein durchgerechnetes Beispiel: die Rechnung des Audit-Logs
Der Audit-Log schreibt im Schnitt etwa 50 Ereignisse/Sekunde, springt aber während Incidents auf Tausende, mit weit niedrigerem Read-Traffic (Compliance-Exporte, die gelegentliche Untersuchung). Jedes Ereignis ist klein — deutlich unter 1 KB.
Bei Provisioned müsstest du für den Burst reservieren (und ihn rund um die Uhr bezahlen) oder riskieren, die Flut am Incident-Tag zu drosseln — der schlechteste Zeitpunkt, um Audit-Writes zu verwerfen. Bei On-Demand kosten die ruhigen Stunden fast nichts, und ein Burst bis zum Doppelten des jüngsten Höchststands wird ohne Konfiguration aufgefangen; du bezahlst für genau die Writes, die stattfanden.
Für diesen Workload ist On-Demand der richtige Standard. Die allgemeine Regel: Starte bei On-Demand für jede neue oder sprunghafte Tabelle und wechsle erst zu Provisioned, sobald der Traffic sich als stetig genug erwiesen hat, um eine Reservierung ausgelastet zu halten.
Setze deine eigenen Zahlen ein — Reads/Writes pro Sekunde, Item-Größe, Speicher —, um die beiden Modi für eine Region nebeneinander zu sehen:
Für das vollständige Multi-Region-Bild mit angewendetem Free Tier nutze den DynamoDB-Preisrechner.
In DynoTable umsetzen
Die Kapazitätsentscheidung startet bei echten Zahlen: wie groß die Items sind, wie viele es sind, wie schnell sie geschrieben werden. Diese zu raten ist, wie Tabellen falsch provisioniert enden.
Um ein Beispiel-Ereignis in die RCU/WCU umzurechnen, die es tatsächlich verbraucht, jage es durch den Item-Size-Rechner. Dann verankere die Entscheidung in deiner echten Tabelle: DynoTable zeigt deren Metadaten — Item-Anzahl und -Größe — an und lässt dich repräsentative Items inspizieren, damit du sie genau dimensionieren kannst.
Fallstricke und nächste Schritte
- Der Moduswechsel ist ratenbegrenzt, und zwar asymmetrisch. Provisioned zu On-Demand ist auf vier Wechsel pro 24 Stunden begrenzt; On-Demand zu Provisioned ist unbeschränkt. Behandle es als überlegte Entscheidung, nicht als Drehregler, den du herumdrehst.
- Auto-Scaling ist nicht sofort. Es reagiert über Minuten, sodass eine scharfe Spitze bei Provisioned drosseln kann, bevor die Kapazität wächst. Für wirklich stoßweisen Traffic bewältigt On-Demand die Spitze besser — sofort bis zum Doppelten deines vorherigen Höchststands. Wenn du weißt, dass eine Spitze das überschreiten wird (ein Launch oder Sale), setze Warm Throughput auf der Tabelle im Voraus, um den Burst-Spielraum vorzuprovisionieren.
- Eine Hot Partition drosselt unabhängig vom Modus. Selbst On-Demand hat Grenzen pro Partition — ungleiche Schlüssel können drosseln, während die Tabelle unter Kapazität aussieht. Siehe Hot Partitions.
- haben ihre eigene Kapazität. Jeder Index wird separat abgerechnet und kann Basistabellen-Writes drosseln, wenn er unterprovisioniert ist — siehe warum ein GSI Basistabellen-Writes drosselt.
Der Kapazitätsmodus bestimmt, was du zahlst, um die Tabelle in einer Region zu betreiben. Als Nächstes: sie über Regionen hinweg mit DynamoDB Global Tables replizieren.
Lade DynoTable herunter, um die echte Größe und Item-Anzahl deiner Tabelle zu lesen, bevor du dich auf einen Kapazitätsmodus festlegst.