.png)
Key takeaways
1
Keyspaces removes the cluster, not the schema work, you keep CQL, your drivers, and your data model. But secondary indexes, materialized views, and user-defined functions aren't supported, so schemas using them need a redesign first.
2
After the mode choice, consistency and expiry drive the bill. LOCAL_ONE reads bills at half an RRU, and TTL deletes got 75% cheaper in November 2024.
3
Database Savings Plans are the only commitment discount for Keyspaces, there are no Reserved Instances. The dollar-per-hour commitment covers both capacity modes, so mode changes don't break it.
Running Apache Cassandra in production means provisioning nodes, tuning compaction, and managing upgrades, that operational cost is the trade-off for its scale.
Amazon Keyspaces eliminates that burden. It is a fully managed, serverless Cassandra-compatible database service on AWS: the same CQL code, the same drivers, the same API, while AWS manages the infrastructure.
No nodes to provision, no replication to configure, no upgrades to plan tables scale automatically with traffic.
That is a default, not a verdict. Row size, idle hours, and your LOCAL_ONE read mix all shift the break-even, so check the decision against your own consumed capacity.
The key word is serverless: no instance types, no node counts, no replication settings. Data is automatically replicated across three Availability Zones with a replication factor of three.
Migration means pointing the application at the Keyspaces endpoint and updating authentication Keyspaces requires TLS and IAM credentials via the SigV4 plugin. The CQL API, drivers, and schema design carry over.
What disappears:
Amazon Keyspaces eliminates that burden. It is a fully managed, serverless Cassandra-compatible database service on AWS: the same CQL code, the same drivers, the same API, while AWS manages the infrastructure.
No nodes to provision, no replication to configure, no upgrades to plan tables scale automatically with traffic.
The Short Answer
On-demand is the right default for most Keyspaces tables since the November 2024 price cut, AWS recommends it even for workloads that used to suit provisioned. Provisioned earns its place only for stable, round-the-clock throughput, since you pay for reserved capacity whether traffic arrives or not.That is a default, not a verdict. Row size, idle hours, and your LOCAL_ONE read mix all shift the break-even, so check the decision against your own consumed capacity.
Keyspaces vs Self-Managed Cassandra: Key Differences
You connect with any standard Cassandra driver (Java, Python, Go, Node.js), use CQL, and work with familiar constructs: keyspaces, tables, partition keys, clustering columns.The key word is serverless: no instance types, no node counts, no replication settings. Data is automatically replicated across three Availability Zones with a replication factor of three.
Migration means pointing the application at the Keyspaces endpoint and updating authentication Keyspaces requires TLS and IAM credentials via the SigV4 plugin. The CQL API, drivers, and schema design carry over.
What disappears:
the nodes
the operational runbooks
the compaction jobs
the repair operations
the capacity planning for cluster growth
What Keyspaces Does NOT Support
CQL compatibility is broad but not complete. Per the supported Cassandra APIs and operations, Keyspaces does not support:secondary indexes (CREATE INDEX is unavailable)
materialized views
user-defined functions (UDFs) and user-defined aggregates (UDAs)
storage-attached indexes (SAI)
some advanced Cassandra configuration parameters
Workloads depending on these need a schema redesign or self-managed Cassandra on EC2.
Keyspaces uses server-side timestamps by default; client-side timestamps are supported as an opt-in table setting for Cassandra-compatible conflict resolution.
Also read: [AWS Savings Plans: complete guide to types and buying strategy]
Billing uses two units. One Write Request Unit (WRU) covers a write up to 1 KB at LOCAL_QUORUM. One Read Request Unit (RRU) covers a read up to 4 KB at LOCAL_QUORUM, or two LOCAL_ONE reads (0.5 RRU each).
Larger rows consume proportionally more units, per the Amazon Keyspaces capacity modes documentation.
Keyspaces uses server-side timestamps by default; client-side timestamps are supported as an opt-in table setting for Cassandra-compatible conflict resolution.
Also read: [AWS Savings Plans: complete guide to types and buying strategy]
On-Demand and Provisioned Capacity Modes
The billing mode determines how every read and write is charged. A table can move to provisioned at any time; switching back to on-demand is limited to once per 24 hours.On-Demand Mode (Recommended Default)
In on-demand mode, you pay for the read and write requests your application performs, with no throughput commitment or minimum throughput charge. Storage, PITR, TTL deletes, Streams, restores, data transfer, and PrivateLink charges can still apply.Billing uses two units. One Write Request Unit (WRU) covers a write up to 1 KB at LOCAL_QUORUM. One Read Request Unit (RRU) covers a read up to 4 KB at LOCAL_QUORUM, or two LOCAL_ONE reads (0.5 RRU each).
Larger rows consume proportionally more units, per the Amazon Keyspaces capacity modes documentation.
Scaling in on-demand capacity mode instantly accommodates up to double a table’s previous traffic peak; growth beyond that should be spaced over roughly 30 minutes to avoid capacity errors. New on-demand tables start with an initial peak of 2,000 WRUs and 6,000 RRUs.
On-demand has no read or write throughput charge when a table receives no requests, making it a strong default for new tables, development environments, infrequently accessed workloads, and seasonal applications. Storage and enabled optional features can still create charges.
Lightweight transactions (LWTs) have no additional Keyspaces charge, but a conditional write whose condition evaluates false can still consume WRUs or WCUs based on the existing row size.
Auto scaling adjusts capacity between bounds you set, but it takes minutes to react.
For sudden sharp spikes, on-demand avoids this throttling risk.
Provisioned wins only when traffic is stable, forecastable, and sustained at volumes where the per-unit rate beats the per-request rate. The practical 2026 default: start on-demand, switch only after 60–90 days of traffic data shows provisioned is cheaper.
LOCAL_QUORUM requires two of the three replicas to agree reads are strongly consistent, and all writes use LOCAL_QUORUM for durability.
LOCAL_ONE returns the first value from any replica, so reads are eventually consistent. The payoff: each RRU covers two LOCAL_ONE reads, halving read costs on paths that accept eventual consistency.
The table below summarizes the most common charges; confirm current Regional rates before estimating a bill.
On-demand has no read or write throughput charge when a table receives no requests, making it a strong default for new tables, development environments, infrequently accessed workloads, and seasonal applications. Storage and enabled optional features can still create charges.
Lightweight transactions (LWTs) have no additional Keyspaces charge, but a conditional write whose condition evaluates false can still consume WRUs or WCUs based on the existing row size.
Provisioned Mode (For Stable, High-Throughput Workloads)
In provisioned mode, you specify read capacity units (RCUs) and write capacity units (WCUs) per second, billed per unit per hour whether or not traffic arrives including idle periods. One RCU covers one LOCAL_QUORUM read per second up to 4 KB (or two LOCAL_ONE reads); one WCU covers one write per second up to 1 KB.Auto scaling adjusts capacity between bounds you set, but it takes minutes to react.
For sudden sharp spikes, on-demand avoids this throttling risk.
Provisioned wins only when traffic is stable, forecastable, and sustained at volumes where the per-unit rate beats the per-request rate. The practical 2026 default: start on-demand, switch only after 60–90 days of traffic data shows provisioned is cheaper.
LOCAL_QUORUM vs LOCAL_ONE: Consistency and Cost
The read consistency level affects correctness and cost.LOCAL_QUORUM requires two of the three replicas to agree reads are strongly consistent, and all writes use LOCAL_QUORUM for durability.
LOCAL_ONE returns the first value from any replica, so reads are eventually consistent. The payoff: each RRU covers two LOCAL_ONE reads, halving read costs on paths that accept eventual consistency.
Amazon Keyspaces Pricing in 2026
Keyspaces charges can include read and write throughput, storage, point-in-time recovery, TTL deletes, Keyspaces Streams, table restores, data transfer, and AWS PrivateLink endpoint charges.The table below summarizes the most common charges; confirm current Regional rates before estimating a bill.
| Dimension | Rate (us-east-1) |
|---|---|
| Throughput (WRU/RRU or WCU/RCU) | Varies by mode and region |
| Storage | $0.25/GB-month |
| PITR continuous backup | $0.15/GB-month, billed per enabled table |
| TTL deletes | Per delete unit (1 unit = 1 KB deleted per row) |
| Data transfer out | 1 GB/month free, aggregated across AWS services |
| Free tier (first 3 months) | 30M WRUs + 30M RRUs + 1 GB storage/month |
Verify current per-unit rates on the Amazon Keyspaces pricing page; for dollar figures, worked examples, and the break-even calculation, see the [Keyspaces pricing guide: complete 2026 breakdown].
What the November 2024 Price Cut Changed
Per the AWS announcement (November 14, 2024), on-demand prices dropped up to 56% (single-Region) and 65% (multi-Region), provisioned up to 13% and 20%, and TTL deletes 75%. AWS stated the change “transforms on-demand mode into the recommended and default choice for the majority of Keyspaces workloads.” Guides published before the cut overstate on-demand costs.On-Demand vs Provisioned: 2026 Decision Framework
| Workload pattern | Recommended mode | Reason |
|---|---|---|
| New table, unknown traffic | On-demand | No capacity planning; no throughput charge when idle |
| Unpredictable or spiky traffic | On-demand | Scales instantly; provisioned auto scaling can throttle spikes |
| Variable with idle periods | On-demand | Provisioned bills 24/7 at the capacity floor |
| Stable, sustained 24/7 throughput | Evaluate provisioned + auto scaling | Per-unit rate may beat per-request rate at volume |
| Development and testing | On-demand | Free tier covers the first 3 months |
| Seasonal events | On-demand (switch before the event) | Handles bursts without pre-provisioning for peak |
How to Reduce Amazon Keyspaces Costs
Use LOCAL_ONE Consistency on Eligible Read Paths
Switching reads to LOCAL_ONE cuts read costs 50% where eventual consistency is acceptable: 100 million 1 KB reads per month consume 100M RRUs at LOCAL_QUORUM but 50M at LOCAL_ONE.Identify read paths that don’t need the latest write profiles, cached recommendations, historical queries. Configuring them to LOCAL_ONE is one line of driver configuration.
Enable TTL for Bounded Data Sets
Any data with a natural expiry session, logs, cache rows should have TTL set at write time. After the 75% TTL price cut, automated expiration is the cheapest way to bound a table; manual deletes consume write capacity that TTL avoids.Enable PITR only where point-in-time recovery is required, since it bills per GB-month on every enabled table.
Database Savings Plans for Keyspaces Workloads
Database Savings Plans reduce Keyspaces costs by up to 18% on a 1-year, no-upfront commitment, per the Database Savings Plans pricing page. The commitment is a dollar-per-hour spend level not tied to specific tables or modes and it is the only commitment discount for Keyspaces, which has no Reserved Instances. Both capacity modes count toward it.Also read: [AWS Database Savings Plans: Complete Guide]
Capacity mode matched
Mode chosen against actual traffic shape, not defaults.
LOCAL_ONE applied
Eventual-consistency reads used on paths that tolerate stale data.
TTL set at write time
Automated expiry on sessions, logs, and bounded data.
PITR scoped
Enabled only on tables where recovery is required.
DSP sized to baseline
Commitment set to stable hourly spend, covering both modes.
Where Amazon Keyspaces Fits: Four Use Cases
| Use case | Access pattern | Why Keyspaces fits |
|---|---|---|
| Cassandra migration | Partition key lookups via CQL | Change endpoint and auth; no application rewrite |
| IoT and telemetry | High-write, time-bucketed by device | Scales to fleet bursts; TTL handles retention |
| Session and profile storage | Direct partition key reads, TTL expiry | Single-digit ms reads; TTL now 75% cheaper |
| Multi-region active-active | Writes to any region, local reads | Fully managed replication; no multi-DC topology to operate |
For migration checklists and schema compatibility, Cassandra-to-Keyspaces AWS migration guide
Keyspaces vs DynamoDB: Which to Choose
Both are managed NoSQL databases on AWS; the difference is the API and data model.- Choose Keyspaces for existing Cassandra workloads, CQL-trained engineers, or LWT-heavy writes (no transaction premium).
- Choose DynamoDB for net-new apps where deep AWS-native integration matters though Keyspaces now offers CDC streams.
Amazon Keyspaces Security and Compliance
Keyspaces encrypts data at rest with AWS KMS (customer-managed keys supported) and in transit with TLS. It is HIPAA-eligible, PCI DSS-compliant, and SOC 1/2/3-certified, with VPC endpoints via AWS PrivateLink verify certifications at AWS services in scope by compliance program.How Usage.ai Optimizes Keyspaces Costs
Keyspaces has no Reserved Instances, a Database Savings Plan is its only commitment discount, and sizing that commitment against your own hourly spend is the step most teams skip.We analyze your usage data and recommend qualifying commitments sized to stable eligible hourly spend.
Because the discount applies in both capacity modes, you can run the on-demand vs. provisioned comparison from this guide first and layer the commitment on top of whichever mode wins.
With Flex Insured Commitments, teams can get the up to 18% savings of a 1-year Keyspaces Database Savings Plan with none of the commitment risk.
If eligible usage drops and a qualifying Keyspaces Flex Commitment ends up costing more than the on-demand rate for that usage, we provide cashback protection on that difference, subject to program terms.
Our fee is a percentage of realized savings only. If we don’t save you money, you don’t pay anything.
Frequently asked questions
What is Amazon Keyspaces Serverless?
Keyspaces is always serverless,no servers to manage or patch. "Keyspaces Serverless" typically means on-demand capacity mode, where you pay per request AWS's recommended default since the November 2024 price cut.
Is Amazon Keyspaces compatible with Apache Cassandra?
Yes, Keyspaces is API-compatible and uses the same CQL; applications connect by changing the endpoint and updating authentication. Unsupported: secondary indexes, materialized views, UDFs/UDAs, and storage-attached indexes.
What changed in November 2024 for Keyspaces pricing?
AWS cut on-demand prices up to 56% (single-Region) and 65% (multi-Region), provisioned up to 13% and 20%, and TTL deleted 75%. Teams on provisioned should recalculate whether on-demand is now cheaper.
What is the difference between RRU/WRU and RCU/WCU?
RRUs and WRUs meter on-demand mode charged per request. RCUs and WCUs meter provisioned mode throughput provisioned per second, billed per unit per hour. Similar mechanics, fundamentally different billing models.
How does Keyspaces handle multi-region replication?
Multi-Region Replication is active-active and fully managed: writes to any region replicate to all others in the keyspace.
Writes bill per WRU per region, a 3 KB row in a 2-region keyspace consumes 6 WRUs with no extra charge for the replication transfer itself.
Share
Facebook
X
LinkedIn
Reddit
