Warm Throughput and Planned Spikes
Explore how warm throughput sets the immediate read and write capacity for Amazon Keyspaces tables and how pre-warming prepares your database for known traffic surges. Learn when to apply pre-warming, its relationship with partition-key design, and best practices to prevent throttling and ensure smooth performance during migration cutovers, launch-day spikes, and scheduled events.
Replication readiness across multiple regions, covered in the previous lesson, is only one dimension of capacity planning. A table that can replicate globally still needs enough local throughput to absorb traffic the instant it arrives. When an Amazon Keyspaces table receives a sudden, large burst of reads or writes during a migration cutover, a product launch, or a scheduled promotional event, the table's internal partitions may not yet be scaled to handle that load immediately.
Warm throughput is the number of read and write operations a DynamoDB table or secondary index can support immediately. It shows the throughput already available before DynamoDB scales higher in response to increased traffic. A new on-demand table starts with a default warm throughput of 12,000 read units per second and 4,000 write units per second. As usage increases, DynamoDB can raise the table’s warm throughput based on the new traffic level. For gradual traffic growth, this usually works well, but for a known spike that arrives all at once, traffic above the current warm throughput can be throttled unless the table is pre-warmed. Requests can also be throttled when uneven access patterns overload a hot partition.
Pre-warming lets operators set a higher warm throughput value ahead of an expected traffic spike so the table or index can support more throughput once the update is active. A useful analogy is preheating an oven before baking: you set the temperature in advance so the oven is ready when the food goes in, instead of waiting for it to heat up after you start. ...