Amazon Keyspaces offers a fully managed, serverless Apache Cassandra-compatible database — but costs can escalate quickly if you're not careful about capacity mode selection, consistency levels, and storage management.

In November 2024, AWS reduced Keyspaces prices by up to 75% across several dimensions, including a 56-65% cut for on-demand mode and 75% reduction for TTL deletes. Despite these improvements, Keyspaces costs approximately 15% more than DynamoDB anecdotally, largely because Cassandra-style workloads often rely on wide rows, high write volumes, multi-region replication, and query patterns that can be less cost-efficient in a serverless managed model.

This guide covers proven strategies to reduce Keyspaces costs without sacrificing performance, grounded in real cost calculations and practitioner experience.

What Is Amazon Keyspaces?

Amazon Keyspaces is a fully managed, serverless database service for Apache Cassandra workloads. It lets teams run Cassandra-compatible applications on AWS without managing Apache Cassandra clusters, servers, patching, replication, or scaling.

Keyspaces supports the Cassandra Query Language (CQL), so applications can often use existing Cassandra drivers and data models. It is commonly used for high-scale, low-latency workloads such as IoT data, time-series data, user activity, messaging, personalization, and other applications that need fast reads and writes across large datasets.

Because Keyspaces is serverless, you pay based on usage rather than managing database infrastructure directly. Costs depend on read and write throughput, storage, backups, TTL deletes, consistency levels, and whether you use single-Region or multi-Region replication.

How Amazon Keyspaces Pricing Works

Keyspaces charges across four main areas:

Throughput: Priced per read/write request unit, with two capacity modes:

  • On-demand: Pay per request using Write Request Units (WRUs) and Read Request Units (RRUs). No capacity planning, instant scaling to any traffic level.
  • Provisioned: Reserve capacity upfront using Write Capacity Units (WCUs) and Read Capacity Units (RCUs), charged per unit per hour regardless of usage.

Storage: $0.25 per GB-month for data stored in tables.

Point-in-time recovery (PITR): ~$0.15 per GB-month for continuous backups with per-second granularity over the preceding 35 days.

TTL deletes: Charges per TTL delete unit (1 unit = 1 KB of deleted data per row).

1. Choose the Right Capacity Mode

The most impactful cost decision you'll make is choosing between on-demand and provisioned capacity. The November 2024 price cuts fundamentally changed this calculation, making on-demand a much stronger default for many Keyspaces workload patterns.

Database Savings Plans can further reduce eligible Keyspaces usage in either mode, but they do not replace the capacity mode decision. Think of it in layers: first choose on-demand or provisioned based on your workload shape, then use Database Savings Plans to lower the rate on predictable baseline spend. For Amazon Keyspaces, AWS says Database Savings Plans can provide up to 18% savings for on-demand throughput workloads and up to 12% savings for provisioned capacity.

On-Demand Capacity Mode

Keyspaces On Demand mode is the default choice for variable workloads — let's talk about how it works.

Pricing mechanics:

  • 1 WRU = write up to 1 KB per row using LOCAL_QUORUM consistency
  • 1 RRU = read up to 4 KB per row using LOCAL_QUORUM consistency
  • Rows larger than these thresholds consume proportionally more units
  • $0 when tables are idle

After the November 2024 price cuts (56% reduction for single-region, 65% for multi-region), AWS stated that on-demand is now "the recommended and default choice for the majority of Keyspaces workloads." This is a major shift — before the cuts, on-demand was only recommended for unpredictable workloads.

When on-demand makes sense:

  • New tables where traffic patterns are unknown
  • Unpredictable or spiky workloads that can't be forecasted 24+ hours in advance
  • Variable traffic with traffic spikes and idle periods (nights, weekends, seasonal apps)
  • Development environments and testing environments
  • Workloads that need to scale instantly without the 1-2 minute auto-scaling lag that provisioned mode has

Provisioned Capacity Mode

Provisioned mode can be over three times cheaper for steady workloads — let's dive into the details.

Pricing mechanics:

  • 1 RCU = one LOCAL_QUORUM read per second for rows up to 4 KB (or two LOCAL_ONE reads per second)
  • 1 WCU = one LOCAL_QUORUM write per second for rows up to 1 KB
  • Charged per capacity unit per hour, even during idle periods
  • Supports automatic scaling, but takes 1-2 minutes to react to traffic changes

When provisioned makes sense:

  • Steady, predictable workloads with consistent 24/7 traffic
  • High-throughput applications where the per-unit provisioned rate is cheaper than the per-request on-demand rate at your specific volume
  • Workloads where you can forecast capacity requirements 24+ hours in advance
  • Production systems where you're willing to enable auto-scaling and monitor capacity utilization

2. Use LOCAL_ONE Consistency for Read Paths

The simplest cost optimization for read-heavy Keyspaces workloads: switch read operations from LOCAL_QUORUM to LOCAL_ONE consistency on paths where eventual consistency is acceptable.

How it works:

  • LOCAL_QUORUM (strong consistency): Requires at least two of the three storage replicas to return a consistent value before the read completes. Guarantees the most recently written value. Cost: 1 RRU per 4 KB read.
  • LOCAL_ONE (eventual consistency): Returns the first value received from any replica, which may not be the most recently written value if a recent write hasn't propagated to all replicas yet. Cost: 0.5 RRU per 4 KB read.

Cost impact: Each LOCAL_ONE read of a row up to 4 KB consumes 0.5 RRUs instead of 1 RRU — a 50% read cost reduction for eligible paths.

Example: An application reading 1 KB user profile records 100 million times per month. With LOCAL_QUORUM: 100 million RRUs consumed. With LOCAL_ONE: 50 million RRUs consumed. (Source: AWS official Keyspaces pricing examples)

When to use LOCAL_ONE:

  • User activity feeds, recommendation results, or cached data where slightly stale reads are acceptable
  • Session data where the application can tolerate reading a value from 100-200ms ago
  • Historical event queries or time-series data where the most recent second isn't critical
  • Any read path where your application logic can handle eventual consistency

When to stick with LOCAL_QUORUM:

  • Reads that must reflect the most recent write (account balances, order statuses, inventory counts)
  • Any path where a stale read could cause incorrect application behavior or data corruption

3. Use Table Tagging for Cost Visibility

One of the biggest challenges with Keyspaces cost management is tracking which tables drive the most spend. AWS Cost Explorer doesn't filter by individual tables by default — it aggregates costs across all tables.

Solution: Use AWS resource tagging to identify each table with metadata tags. Tag each table with a `table_name` key, activate the tag in Cost Explorer, and filter by tag value to see per-table read, write, storage, and backup costs.

Process:

1. Tag each table with `table_name: orders`, `table_name: sessions`, etc.

2. Activate the tag in Cost Explorer (Billing Console → Cost Allocation Tags)

3. Wait 1-2 days for tags to appear

4. Filter Cost Explorer by tag to see per-table costs broken down by read, write, storage, and backup

Consider making `table_name` tags mandatory in your table creation process. This gives you ongoing visibility into which tables consume the most resources and where to focus optimization efforts. You can also use tags like `environment: prod`, `team: analytics`, or `cost_center: marketing` for chargeback and showback workflows.

4. Optimize Storage Costs

At $0.25 per GB-month (US East), storage costs add up for large datasets. Here's how to keep them in check:

Use TTL for Automated Data Expiration

Time-to-live (TTL) automatically deletes rows after a specified period. With the 75% price reduction in November 2024, TTL is now significantly more cost-effective for workloads that don't need historical data indefinitely.

When TTL helps:

  • Session data that expires after hours or days
  • Event logs that only need to be retained for compliance windows (90 days, 1 year)
  • Metrics or telemetry data with a rolling retention policy
  • Cache entries with expiration times

How it works: Set a TTL value (in seconds) when writing rows. Keyspaces automatically deletes the row after the TTL expires. The delete operation is charged per TTL delete unit (1 unit = 1 KB deleted per row).

Trade-off: TTL deletes incur charges (now 75% cheaper than before November 2024), but eliminating months or years of storage costs ($0.25/GB-month) typically outweighs the deletion cost.

Archive Cold Data to S3

For data you rarely query but need to retain long-term, export old partitions to S3 and query them with Athena when needed. S3 standard storage ($0.023 per GB-month) is roughly 10x cheaper than Keyspaces storage.

Example: Application event logs from 2022-2023 that are queried once per quarter for compliance audits. Export to S3, delete from Keyspaces, and save $0.227/GB-month on the archived data.

Right-Size Your Tables

Periodically review table sizes in the Keyspaces console (Monitor tab → Billable table size). If tables have grown unexpectedly, investigate:

  • Are you storing denormalized data that could be compressed or deduplicated?
  • Are you retaining rows that should have been deleted?
  • Can you archive historical partitions to S3?

5. Optimize Throughput Costs

Batch Write Operations

Keyspaces supports Cassandra BATCH statements to group multiple insert or update operations into a single CQL call. While batched writes still consume WRUs per row written (not per batch), batching reduces API call overhead and can improve throughput efficiency.

Best practice: Keep batches within a single partition or a small number of partitions. Keyspaces does not support unlogged batches that span multiple partition keys efficiently.

Optimize Read Patterns

Keyspaces charges per read request based on data returned. To minimize read costs:

  • Use `LIMIT` clauses to restrict result size to only what you need
  • Avoid `SELECT *` — query only the columns your application uses
  • Design partition keys to minimize partition scans (use composite partition keys for high-cardinality data)
  • Use secondary indexes sparingly — they add read overhead

Use Multi-Region Selectively

Multi-region replication costs significantly more than single-region. For on-demand mode, multi-region writes are billed per WRU per region: writing a 3 KB row to a 2-region keyspace = 3 WRUs × 2 regions = 6 WRUs.

On-demand multi-region is 65% cheaper and provisioned is 20% cheaper — but it's still a premium over single-region.

Only enable multi-region if:

  • You need low-latency global access for active-active applications
  • You require disaster recovery across AWS Regions
  • Your application serves users distributed across multiple continents

If your application is region-specific, stick with single-region to avoid the replication cost premium.

6. Monitor Costs with CloudWatch

Keyspaces publishes CloudWatch metrics for capacity consumption, throttled requests, and storage. Set alarms to catch cost spikes early:

Key metrics to monitor:

  • ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits (on-demand and provisioned): Track actual throughput consumption
  • ReadThrottleEvents and WriteThrottleEvents: May indicate you need to switch from provisioned to on-demand, or increase provisioned capacity
  • SystemErrors and UserErrors: May indicate inefficient queries driving up costs
  • BillableTableSizeInBytes: Storage growth trends

Set up alarms:

“`bash

aws cloudwatch put-metric-alarm \

–alarm-name keyspaces-read-throttling \

–namespace AWS/Cassandra \

–metric-name ReadThrottleEvents \

–dimensions Name=Keyspace,Value=my_application Name=TableName,Value=orders \

–statistic Sum \

–period 60 \

–threshold 10 \

–comparison-operator GreaterThanThreshold \

–evaluation-periods 3

“`

For on-demand mode, review your Cost Explorer dashboard weekly to identify unexpected cost trends before they accumulate.

Comparison: Keyspaces vs. Alternatives

SolutionBest ForCost ModelTrade-offs
Amazon KeyspacesCassandra workloads, serverless, multi-regionPer read/write request + storageSimpler than self-hosted; ~15% more expensive than DynamoDB; no UDFs or materialized views
DynamoDBKey-value, document store, AWS-native workloadsPer read/write request + storage~15% cheaper than Keyspaces; no Cassandra compatibility; deep AWS integration with Streams, DAX, and Global Tables
Cassandra self-hostedFull Cassandra control, data sovereigntyEC2 + EBS + operational overheadRequires managing infrastructure, backups, scaling, compaction, and repairs; cheaper at massive scale
DataStax Astra DBManaged Cassandra, multi-cloud deploymentsInstance + storage pricingSimilar cost to Keyspaces; vendor lock-in outside AWS; full Cassandra feature set
S3 + AthenaArchival data, infrequent queriesStorage + query scan costsMuch cheaper storage than Keyspaces; high latency; not for real-time workloads

When Keyspaces makes sense: Cassandra-compatible workloads where you want serverless management and can optimize capacity mode selection, consistency levels, and storage retention.

When to consider alternatives:

  • If you don't need Cassandra compatibility, DynamoDB is roughly 15% cheaper with deeper AWS native integration
  • For full Cassandra control (UDFs, materialized views, SAI), self-hosted Cassandra on EC2 is the alternative
  • For archival/cold data, S3 + Athena provides 10x cheaper storage

Optimize Keyspaces Costs with nOps

nOps helps teams understand where Amazon Keyspaces costs are coming from, detect unexpected spend changes, and optimize AWS costs across the broader cloud environment.

Real-Time Cost Visibility & Allocation: Track, allocate, and report on Amazon Keyspaces spend alongside your other AWS services, Azure, GCP, SaaS, Kubernetes, and AI costs in a single pane of glass.

Anomaly Detection: Get alerted when Keyspaces or related database spend increases unexpectedly, whether from higher read/write request volume, inefficient capacity mode selection, multi-Region replication, storage growth, PITR, or TTL delete activity.

Automated Commitment Management: nOps automatically manages AWS commitments to maximize savings and flexibility across your broader AWS environment. Savings are often 20% higher than competitors.

Curious how optimized you are on AWS? A 30-minute free savings analysis shows your current Effective Savings Rate and where the opportunities are. Setup takes 5 minutes with no agents or infrastructure changes needed.

nOps manages $4 billion in cloud spend for its customers and is rated 5 stars on G2.

Frequently Asked Questions

Let's dive into a few FAQ about Amazon Keyspaces.

Should I use on-demand or provisioned capacity for Keyspaces?

After the November 2024 price cuts, on-demand is now the recommended default for most Keyspaces workloads. It eliminates capacity planning, scales instantly, and avoids paying for unused minimum capacity when tables are idle or traffic is unpredictable. Provisioned capacity can still make sense for steady, predictable workloads with consistently high utilization, especially when you can forecast read and write capacity requirements 24+ hours in advance.

How much does Amazon Keyspaces storage cost?

Storage costs $0.25 per GB-month (US East). Point-in-time recovery (PITR) adds ~$0.15 per GB-month. For long-term archival, consider exporting cold data to S3 ($0.023 per GB-month), which is roughly 10x cheaper.

How do I track costs for individual Keyspaces tables?

Use AWS resource tagging. Tag each Amazon Keyspaces table with `table_name: orders`, activate the tag in Cost Explorer (Billing Console → Cost Allocation Tags), wait 1-2 days, then filter by tag value to see per-table read, write, storage, and backup costs broken down by dimension.

What changed with the November 2024 Keyspaces price reduction?

AWS reduced prices by up to 75%:

  • On-demand: 56% cheaper for single-region, 65% cheaper for multi-region
  • Provisioned: 13% cheaper for single-region, 20% cheaper for multi-region
  • TTL deletes: 75% cheaper, making automated data expiration significantly more cost-effective

AWS stated that on-demand is now "the recommended and default choice for the majority of Keyspaces workloads."

Is Keyspaces more expensive than DynamoDB?

Yes, Keyspaces is approximately 15% more expensive than DynamoDB depending on your workload. Keyspaces provides Cassandra compatibility (CQL API, same drivers, same schema design); if you don't need that compatibility, DynamoDB is the cheaper managed option with deeper AWS native integration (Streams, DAX caching, Global Tables).