Bereitgestellte vs. On-Demand-Kapazität

DynamoDB misst den Durchsatz in Read Capacity Units (RCUs) und Write Capacity Units (WCUs). Eine RCU ermöglicht eine stark konsistente Leseoperation pro Sekunde (oder zwei letztlich konsistente Leseoperationen) für Elemente mit einer Größe von bis zu 4 KB. Eine WCU ermöglicht eine Schreiboperation pro Sekunde für Elemente mit einer Größe von bis zu 1 KB.

Bei größeren Elementen steigen die Kosten proportional: Ein Schreibvorgang für 10 KB kostet 10 WCUs; ein stark konsistenter Lesevorgang für 10 KB kostet 3 RCUs (ceil(10/4) = 3). Das Verständnis der Kapazitätseinheiten ist entscheidend, um Kosten zu schätzen und Drosselungsfehler durch ProvisionedThroughputExceededException zu diagnostizieren.

Im Modus Provisioned Capacity geben Sie die genaue Anzahl der RCUs und WCUs an, die Ihre Tabelle unterstützen soll. DynamoDB reserviert diesen Durchsatz und berechnet ihn unabhängig davon, ob Sie ihn nutzen. Überschreitet Ihre Anwendung die bereitgestellte Kapazität, werden Anfragen gedrosselt und geben eine ProvisionedThroughputExceededException zurück.

Der Provisioned-Modus eignet sich ideal für Workloads mit vorhersehbarem, stabilem Datenverkehr. Die Kosten pro Einheit sind niedriger als im On-Demand-Modus. Außerdem können Sie die Kosten durch den Kauf von DynamoDB Reserved Capacity weiter senken (Laufzeiten von 1 oder 3 Jahren mit einem Rabatt von bis zu 76 %).

Im Modus On-Demand skaliert DynamoDB automatisch, um jedes Datenverkehrsaufkommen ohne Kapazitätsplanung zu bewältigen. Sie zahlen pro tatsächlich verbrauchter Anfrage: pro RRU (Read Request Unit) und pro WRU (Write Request Unit). Es gibt keine bereitgestellte Kapazität, die verwaltet werden muss, und keine Drosselung aufgrund von Grenzen der bereitgestellten Kapazität.

Der On-Demand-Modus eignet sich ideal für: unvorhersehbare oder stark schwankende Workloads, neue Tabellen mit unbekanntem Datenverkehr sowie Entwicklungs- und Testumgebungen mit seltenen Zugriffen. Die Kosten pro Anfrage sind höher als im Provisioned-Modus. Für stabile Workloads mit hohem Durchsatz ist der Provisioned-Modus daher wirtschaftlicher.

Sie können eine Tabelle jederzeit über die Konsole oder die CLI zwischen dem Provisioned- und dem On-Demand-Modus umschalten. Der Modus kann jedoch nur einmal innerhalb von 24 Stunden gewechselt werden. Nach dem Wechsel zu On-Demand behält die Tabelle die zuvor erreichte maximale bereitgestellte Kapazität als anfängliches Durchsatzniveau bei. So wird eine sofortige Drosselung verhindert, wenn der Datenverkehr bereits hoch ist.

Eine gängige Strategie besteht darin, beim anfänglichen Start den On-Demand-Modus zu verwenden, solange die Datenverkehrsmuster unbekannt sind, und später bei vorhersehbarem Datenverkehr zu Provisioned mit Auto Scaling zu wechseln, um Kosten zu senken.

DynamoDB Auto Scaling passt Ihre bereitgestellten RCUs und WCUs automatisch an den tatsächlichen Datenverkehr an. Sie legen einen Zielauslastungsprozentsatz (z. B. 70 %) sowie einen Bereich für die minimale und maximale Kapazität fest. Eine Richtlinie von Application Auto Scaling überwacht die verbrauchte Kapazität der Tabelle und passt die bereitgestellte Kapazität an, um die Zielauslastung beizubehalten.

Auto Scaling reagiert auf anhaltende Änderungen des Datenverkehrs und kann einige Minuten für die Hochskalierung benötigen. Plötzliche Datenverkehrsspitzen werden nicht gut bewältigt. Wärmen Sie die Kapazität in solchen Fällen entweder manuell vor oder verwenden Sie stattdessen den On-Demand-Modus.

DynamoDB hält bis zu 5 Minuten ungenutzter bereitgestellter Kapazität als Burst-Kapazität vor. Wenn der Datenverkehr Ihrer Tabelle die bereitgestellte Kapazität kurzzeitig überschreitet, greift DynamoDB auf diesen Burst-Pool zurück, um die zusätzlichen Anfragen ohne Drosselung zu verarbeiten. Sobald der Burst-Pool erschöpft ist, werden weitere Anfragen oberhalb der Kapazitätsgrenze gedrosselt.

Die Burst-Kapazität ist ein kurzfristiger Puffer und kein Ersatz für eine korrekte Kapazitätsplanung. Überwachen Sie die CloudWatch-Metriken ConsumedReadCapacityUnits und ConsumedWriteCapacityUnits, um zu erkennen, wann Ihr Workload dauerhaft Burst-Kapazität verbraucht, und passen Sie den bereitgestellten Durchsatz entsprechend an.

Wenn die bereitgestellte Kapazität überschritten und der Burst-Pool erschöpft ist, gibt DynamoDB ProvisionedThroughputExceededException zurück. Die AWS-SDKs enthalten eine integrierte Wiederholungslogik mit exponentiellem Backoff und Jitter, die gedrosselte Anfragen automatisch erneut ausführt.

Überprüfen Sie zur Diagnose von Drosselungen die CloudWatch-Metriken SystemErrors und ThrottledRequests. Wenn bestimmte Partition Keys gedrosselt werden, während die Gesamtauslastung der Tabelle niedrig ist, liegt ein Problem mit einer Hot Partition vor. Modellieren Sie den Partition Key neu, fügen Sie einen Sort Key hinzu oder verwenden Sie Write Sharding.

So schätzen Sie die Kapazität für den Provisioned-Modus:

• Berechnen Sie maximale Schreibvorgänge pro Sekunde × durchschnittliche Elementgröße / 1 KB (aufgerundet) = benötigte WCUs
• Berechnen Sie maximale Lesevorgänge pro Sekunde × durchschnittliche Elementgröße / 4 KB (aufgerundet) = benötigte RCUs (stark konsistent); halbieren Sie den Wert für letztlich konsistente Lesevorgänge
• Planen Sie 20–30 % Reserve über dem Spitzenwert ein, damit Spitzen abgefangen werden, bevor die Burst-Kapazität verbraucht ist

Beispiel: 1.000 Schreibvorgänge/s mit Elementen von 2 KB = 2.000 WCUs. 5.000 Lesevorgänge/s mit Elementen von 8 KB (letztlich konsistent) = ceil(8/4) × 5.000 / 2 = 5.000 RCUs.

Mit DynamoDB Reserved Capacity können Sie eine feste Anzahl von RCUs und WCUs für eine Laufzeit von 1 oder 3 Jahren erwerben und durch Vorauszahlung einen erheblichen Rabatt (bis zu 76 %) gegenüber der On-Demand-Preisgestaltung erhalten. Reserved Capacity gilt für alle bereitgestellten Tabellen in einer Region und wird automatisch auf Ihre stündlichen Gebühren angerechnet.

Reserved Capacity gilt nur für den Provisioned-Modus – im On-Demand-Modus können Sie sie nicht verwenden. Sie ist die beste Möglichkeit zur Kostenersparnis bei stabilen, vorhersehbaren Workloads, deren Umfang Sie zuverlässig für einen Zeitraum von 1 bis 3 Jahren prognostizieren können.

Verwenden Sie diese Entscheidungshilfe für Fragen zu Kapazitätsmodi in SAA-C03:

• On-Demand: unvorhersehbarer Datenverkehr, neue Anwendung, seltene Zugriffe, stark schwankender Workload oder wenn Sie keinerlei Kapazitätsverwaltung wünschen
• Provisioned: gleichmäßiger, vorhersehbarer Datenverkehr, kostenbewusste Planung, Bereitschaft zur Kapazitätsverwaltung und Anspruch auf Rabatte für Reserved Capacity
• Provisioned + Auto Scaling: vorhersehbare Grundlast mit gewissen Schwankungen, automatische Anpassung ohne manuelle Änderungen

In der Prüfung weisen Schlüsselbegriffe wie 'spiky', 'unpredictable' oder 'minimal operational overhead' auf On-Demand hin; 'steady traffic' oder 'cost optimisation' auf Provisioned.

Adaptive Capacity von DynamoDB verteilt den Durchsatz automatisch und in Echtzeit von wenig ausgelasteten Partitionen auf stark ausgelastete Partitionen um. Wenn ein Partition Key mehr Datenverkehr erhält als der ihm zugewiesene Anteil, leiht sich die adaptive Kapazität Durchsatz von wenig ausgelasteten Partitionen, um die stark ausgelastete Partition zu unterstützen – solange die Gesamtkapazität der Tabelle nicht überschritten wird.

Adaptive Capacity ist immer aktiviert und erfordert keine Konfiguration. Sie reduziert die Drosselung von Hot Partitions bei mäßig ungleichmäßigen Zugriffsmustern. Bei stark verzerrten Workloads (z. B. wenn ein Partition Key 90 % des Datenverkehrs erhält) reicht adaptive Kapazität nicht aus. Sie müssen den Partition Key neu modellieren oder Write Sharding verwenden.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Der Provisioned-Modus legt feste RCUs/WCUs für vorhersehbare Workloads zu geringeren Kosten fest, der On-Demand-Modus skaliert automatisch für unvorhersehbaren Datenverkehr zu einem höheren Preis pro Anfrage, und Auto Scaling passt die bereitgestellte Kapazität anhand von Zielauslastungsprozentsätzen an. Als Nächstes beschäftigen wir uns mit Global Secondary Indexes und Local Secondary Indexes für alternative Abfragemuster.