Search⌘ K
AI Features
Home
Courses
A Comprehensive Guide to AWS Databases

Capacity and Cost

Understand how to choose between on-demand and provisioned capacity modes in Amazon Keyspaces. Explore cost implications, auto scaling behavior, and capacity planning essentials to align your database throughput with workload patterns effectively.

We'll cover the following...

After designing tables around query patterns and partition strategies in the previous lesson, the next decision determines how those tables actually handle throughput at runtime. Amazon Keyspaces is a fully managed, "serverless"-compatible service, but it still requires you to make an explicit capacity model choice before a single row is written. This distinction trips up many practitioners and exam candidates who assume "serverless" means "no capacity decisions." In reality, every Keyspaces table operates under one of two throughput modes, and selecting the wrong one leads to either unexpected cost or unexpected throttling.

The two modes are on-demand and provisioned. Each mode bills through the same primitives. A read request unit (RRU)A billing unit representing one locally consistent read of up to 4 KB of data, where strongly consistent reads consume additional units. measures read consumption, while a write request unit (WRU)A billing unit representing one write of up to 1 KB of data to a Keyspaces table. measures write consumption. These units are the foundation of every cost calculation and scaling decision in the service.

By the end of this lesson, you will be able to match a workload's traffic shape to the correct capacity mode, anticipate cost and performance implications, and understand why capacity planning remains essential even when the infrastructure is managed for you.

On-demand capacity mode

When a table is configured for on-demand mode, Keyspaces automatically allocates read and write capacity as requests arrive. You never specify a throughput target in advance. The service observes incoming traffic and provisions resources behind the scenes, which makes on-demand the simplest operational choice.

Several workload profiles benefit from this approach:

  • Unpredictable traffic: Applications with no historical baseline cannot set meaningful provisioned values, so on-demand absorbs whatever arrives.

  • New applications: A product in its first weeks of production lacks the data needed to forecast request volume accurately.

  • Spiky or bursty workloads: Event-driven systems that idle for hours and then spike sharply avoid paying for idle capacity.

  • Development and test environments: Teams running intermittent integration tests do not need to manage scaling policies for tables that sit ...