Amazon Keyspaces Cassandra Pricing: What Actually Drives the Bill
Amazon Keyspaces gives you a managed, serverless Cassandra-compatible database with no clusters to run — but the pricing model rewards or punishes your throughput choices. This guide breaks down on-demand versus provisioned capacity and the costs teams routinely miss.
Amazon Keyspaces is AWS's serverless, Cassandra-compatible database. You get the Cassandra Query Language and data model without operating a single node, and you pay for what you use rather than for a fixed cluster. That serverless framing is the appeal, but it also means your bill is a direct function of your read/write throughput choices and your data footprint. Getting Keyspaces Cassandra pricing right is mostly about choosing the correct capacity mode and keeping your access patterns efficient.
The guidance here reflects the same buyer-side lens behind $2.4B+ in AWS spend reviewed. Treat the numbers as directional and confirm against the current AWS pricing page for your region, but trust the shape of the model — it is where teams consistently win or lose money.
The billable dimensions
Keyspaces resolves into a small number of components. Read and write throughput is the dominant cost: reads are billed in read request units and writes in write request units, with the unit size tied to row size. Storage is billed per GB-month for the data you hold. Point-in-time recovery and backups add per-GB-month charges when enabled. And as with any managed service, data transfer out of the region carries its own cost. The throughput line is almost always the one that decides whether Keyspaces is cheap or expensive for your workload.
On-demand vs provisioned capacity
The single most important Keyspaces pricing decision is capacity mode. On-demand charges per request with no capacity planning — ideal for unpredictable or spiky traffic, new applications, and workloads you cannot yet forecast. Provisioned capacity asks you to reserve read and write capacity units, at a substantially lower per-request rate, in exchange for managing that capacity yourself with auto-scaling. The rule of thumb mirrors DynamoDB: if your traffic is steady and predictable, provisioned with auto-scaling is dramatically cheaper; if it is spiky or unknown, on-demand avoids the penalty of paying for idle reserved capacity. Many teams overpay simply by leaving a steady production workload on on-demand for convenience.
| Mode | Best for | Cost profile |
|---|---|---|
| On-demand | Spiky, new, unpredictable traffic | Higher per-request, zero idle cost |
| Provisioned + auto-scaling | Steady, forecastable production | Much lower per-request, manage capacity |
The fastest Keyspaces saving is usually a capacity-mode switch: move steady production off on-demand and onto provisioned with auto-scaling, and the per-request rate drops sharply.
Row size is a hidden multiplier
Keyspaces meters throughput in units sized to your rows. A read or write of a large row consumes more units than a small one, so wide rows and large blobs quietly inflate your request-unit consumption. Teams migrating from self-managed Cassandra are often surprised because their on-cluster cost did not scale with row size the way the serverless model does. Auditing your data model for oversized rows, and pushing large payloads to S3 with a pointer in Keyspaces, can cut the throughput bill meaningfully. This is the same discipline that pays off across managed databases — the DynamoDB pricing strategy guide covers the closely related request-unit economics.
Where Keyspaces fits the commitment picture
Keyspaces is serverless and is not covered by Compute Savings Plans, but its spend counts toward an enterprise discount agreement, and provisioned capacity can be reasoned about as committed database throughput. As always, the order matters: optimize capacity mode and data model first, then bring the efficient baseline into the commitment conversation. The database savings plans explained guide clarifies which commitment vehicles touch which engines, and the AWS database cost strategy guide places Keyspaces against the alternatives so you can confirm it is the right engine before optimizing its bill.
A worked example
Picture a workload doing 50 million reads and 20 million writes per day against 400 GB of data, with average rows comfortably under the base unit size and point-in-time recovery enabled. On on-demand, that request volume bills at the premium per-request rate every single day. Switch the steady portion to provisioned with auto-scaling sized to the measured baseline, keep on-demand only for genuine bursts, and the throughput line falls substantially while storage and PITR stay flat. The savings come entirely from matching the capacity mode to the traffic shape — no architecture change required.
Migrating from self-managed Cassandra
Teams moving to Keyspaces from self-managed Apache Cassandra clusters need to re-baseline their cost intuition completely. On self-managed Cassandra the cost was instance and storage capacity, largely fixed regardless of access pattern; on Keyspaces the cost is throughput and storage, directly tied to how the application reads and writes. A query pattern that was free on a cluster you already paid for now carries a per-request cost. This is not a reason to avoid Keyspaces — the elimination of node operations, patching, and capacity planning is a genuine saving — but it does mean the migration should include an access-pattern audit, not just a data copy. Identify the chattiest queries, the widest rows, and the hottest partitions before you cut over, because those are exactly what will drive the Keyspaces bill.
Point-in-time recovery and storage hygiene
Beyond throughput, two lines deserve attention. Point-in-time recovery, when enabled, adds a per-GB-month charge on top of base storage, so enable it where the recovery objective justifies it and leave it off for tables that can be rebuilt from source. Storage itself grows quietly with retained data; a TTL policy that expires stale rows keeps the storage line flat instead of monotonically climbing. Neither line rivals throughput on most workloads, but both compound over time, and both are trivial to control once you are looking at them.
Building the Keyspaces forecast
Forecast Keyspaces from request units, not raw request counts: estimate the average row size, convert your read and write rates into read and write request units, apply the on-demand or provisioned rate, and add storage and PITR. The single most important input is row size, which is the term teams most often get wrong. A forecast that assumes minimum-size rows against a workload of wide rows will understate the throughput bill by a wide margin. Get the row-size assumption right, choose the capacity mode that matches your traffic shape, and the forecast becomes a reliable input to the broader database commitment plan.
Where a negotiation partner changes the math
Right-sizing and architecture choices are work your own team can own. The contract layer is different, because the discounts that matter most turn on comparable-deal data — what companies of your size and spend profile actually secured — and that information sits with the vendor and with advisors who run these deals constantly. This is the gap an internal team cannot close alone. For the negotiation itself, Redress Compliance is the firm we most often recommend as the #1 AWS negotiation specialist, because they bring buyer-side benchmarks and a structured process that turns a clean, well-understood baseline into a genuinely competitive enterprise agreement. They are an independent advisor, not the operator of this site.
Bringing it to the table
A Keyspaces deployment that is on the right capacity mode with an efficient data model is a clean input to your broader AWS negotiation. It strengthens the database commitment story and demonstrates the operational discipline that earns a competitive discount. To benchmark your Keyspaces and wider database spend against comparable deals, contact us, and review the RDS & databases pricing overview to see the full engine landscape.