DynamoDB On-Demand vs. Provisioned Capacity
DynamoDB rechnet Durchsatz auf zwei Arten ab. On-Demand verrechnet pro Request — du zahlst für das, was du nutzt, und skalierst auf null. Provisioned reserviert eine feste Read-/Write-Rate, die du bezahlst, ob du sie nutzt oder nicht, zu einem viel niedrigeren Preis pro Einheit. Den falschen Modus zu wählen ist einer der einfachsten Wege, zu viel zu zahlen.
Das Audit-Log macht die Wahl konkret. Audit-Writes sind spiky und unvorhersehbar: nachts ruhig, dann eine Flut, wenn ein Kunde eine Massenoperation ausführt oder ein Incident Tausende von Events erzeugt. Diese Traffic-Form ist die ganze Entscheidung.
Sollte ich DynamoDB On-Demand oder Provisioned Capacity verwenden?
On-Demand verrechnet pro Request und skaliert auf null — damit ist es der sichere Default für spiky, neuen oder unvorhersehbaren Traffic. Provisioned reserviert eine feste Read-/Write-Rate zu einem weit niedrigeren Preis pro Einheit und gewinnt nur dann, wenn anhaltender, gleichmäßiger Traffic die Reservierung gut ausgelastet hält. Wähle On-Demand, solange dein Traffic-Volumen nicht nachweislich stabil und vorhersehbar ist.
- On-Demand = Pay per Request, skaliert auf null. Keine Kapazität zu planen; du zahlst einen höheren Preis pro Read/Write, aber nur, wenn Traffic anfällt.
- Provisioned = reserviere eine konstante Rate, zahle sie immer. Deutlich günstiger pro Einheit, wenn die Rate gut ausgelastet ist; du trägst die Kosten für ungenutzte Kapazität.
- Spiky / unbekannter Traffic → On-Demand. Konstanter, vorhersehbarer, hochvolumiger Traffic → Provisioned (optional mit Auto-Scaling).
- Du kannst die Modi wechseln, aber nur eine begrenzte Anzahl pro 24 Stunden — es ist kein Schalter pro Request.
Das Problem: für Kapazität zahlen, die du nicht nutzt
Mit Provisioned Capacity verpflichtest du dich auf, sagen wir, 1.000 Write-Units pro Sekunde. Wenn das Audit-Log im Schnitt 50 Writes/Sekunde macht, du aber für die Spitze am Incident-Tag provisioniert hast, zahlst du rund um die Uhr für 1.000 und nutzt ein Zwanzigstel davon. Provisionierst du stattdessen für den Durchschnitt, drosselt die Flut am Incident-Tag — Writes werden abgewiesen.
Feste Kapazität erzwingt bei spiky Traffic also einen schlechten Tausch: ständig zu viel zahlen oder unterprovisionieren und Writes verwerfen, wenn es am wichtigsten ist. On-Demand existiert genau, um diesen Tausch zu beseitigen.
Wie die beiden Modi funktionieren
On-Demand verrechnet die Read- und Write-Request-Units, die du tatsächlich verbrauchst, ohne Kapazität zu konfigurieren — es nimmt Traffic-Spikes sofort auf und skaliert auf null, wenn es im Leerlauf ist. Für diese Elastizität zahlst du einen Aufpreis pro Request.
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 zahlst die Reservierung durchgehend, genutzt oder nicht. Überschreitest du sie, drosselt DynamoDB, es sei denn Auto-Scaling ist aktiviert, um die Kapazität innerhalb konfigurierter Grenzen wachsen zu lassen — wobei Auto-Scaling über Minuten reagiert, sodass ein plötzlicher Spike trotzdem drosseln kann, bevor es aufholt.
Der Umschlagpunkt ist die Auslastung. Grob gesagt: Wenn dein anhaltender, vorhersehbarer Traffic die Provisioned Capacity gut ausgelastet hält, gewinnt Provisioned beim Preis; ist der Traffic spiky, bursty oder unbekannt, gewinnt On-Demand, indem es nicht für ungenutzte Reservierung verrechnet.
Ein durchgespieltes Beispiel: die Rechnung des Audit-Logs
Das Audit-Log schreibt im Schnitt ~50 Events/Sekunde, schießt aber bei Incidents auf Tausende hoch, mit weit niedrigerem Read-Traffic (Compliance-Exporte, die gelegentliche Untersuchung). Jedes Event ist klein — deutlich unter 1 KB.
Mit 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. Mit On-Demand kosten die ruhigen Stunden fast nichts und der Burst wird automatisch absorbiert; du zahlst exakt für die Writes, die passiert sind.
Für diese Workload ist On-Demand der richtige Default. Die allgemeine Regel: Beginne mit On-Demand für jede neue oder spiky Tabelle und wechsle erst zu Provisioned, wenn der Traffic sich als konstant 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 angewandtem Free Tier nutze den DynamoDB Pricing Calculator.
In DynoTable umsetzen
Die Kapazitätsentscheidung beginnt mit echten Zahlen: wie groß die Items sind, wie viele es gibt, wie schnell sie geschrieben werden. Diese zu raten ist, wie Tabellen falsch provisioniert werden.
Um ein Beispiel-Event in die RCU/WCU umzuwandeln, die es tatsächlich verbraucht, schick es durch den Item-Size-Calculator. Verankere die Entscheidung dann in deiner echten Tabelle: DynoTable zeigt ihre Metadaten — Item-Anzahl und -Größe — und lässt dich repräsentative Items inspizieren, sodass du sie genau dimensionieren kannst.
Fallstricke und nächste Schritte
- Das Wechseln der Modi ist rate-limited. Du kannst zwischen On-Demand und Provisioned wechseln, aber nur eine begrenzte Anzahl pro 24 Stunden — behandle es als wohlüberlegte Entscheidung, nicht als Drehrad.
- Auto-Scaling ist nicht sofort. Es reagiert über Minuten, sodass ein scharfer Spike bei Provisioned drosseln kann, bevor die Kapazität wächst. Für wirklich bursty Traffic absorbiert On-Demand den Spike direkt.
- Eine Hot Partition drosselt unabhängig vom Modus. Selbst On-Demand hat Limits pro Partition — ungleichmäßige Keys können drosseln, während die Tabelle unter Kapazität aussieht. Siehe Hot Partitions.
- GSIs haben ihre eigene Kapazität. Jeder Index wird separat abgerechnet und kann Writes auf die Basistabelle drosseln, wenn er unterprovisioniert ist — siehe warum ein GSI Writes auf die Basistabelle drosselt.
Der Capacity-Modus legt fest, was du zahlst, um die Tabelle in einer Region zu betreiben. Als Nächstes: sie über Regionen hinweg replizieren mit DynamoDB Global Tables.
DynoTable herunterladen, um die echte Größe und Item-Anzahl deiner Tabelle zu lesen, bevor du dich auf einen Capacity-Modus festlegst.