cloudparts

Amazon Keyspaces (for Apache Cassandra)

A serverless AWS database that speaks Cassandra’s CQL and drivers, with no nodes to run: you pay per read, write and gigabyte, and every write is stored three times across Availability Zones.

Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
24 October 2026

What it is

Keyspaces accepts the Cassandra Query Language over the Cassandra wire protocol, so existing Apache 2.0 Cassandra drivers, cqlsh and CQL code work against it, but there is no Cassandra cluster underneath for you to see. There are no nodes, JVMs or cassandra.yaml: tables scale with traffic, and settings for compaction, compression, caching and Bloom filters are accepted and ignored. Sign-in uses IAM (SigV4) instead of Cassandra roles, connections must use TLS, and keyspace and table changes run asynchronously.

Every write is stored in three Availability Zones and acknowledged at LOCAL_QUORUM; other write levels are rejected. Reads can be LOCAL_QUORUM, which sees all earlier successful writes, or ONE/LOCAL_ONE, which cost half as much and may be stale. On-demand tables bill one write request unit per 1 KB written and one read request unit per 4 KB read at LOCAL_QUORUM; provisioned capacity with auto scaling is the alternative. Rows are capped at 1 MB, results are paged after 1 MB read, and one connection handles up to 3,000 queries a second, so drivers need more connections than they would against Cassandra.

On top of plain CQL it adds AWS features: point-in-time recovery, TTL, encryption with KMS keys, change data capture streams that keep row images for up to 24 hours, and multi-Region keyspaces that replicate tables active-active between Regions, usually within a second, resolving concurrent updates by last writer wins. Lightweight transactions (IF NOT EXISTS) are supported at no extra cost, unlike in Cassandra. AWS launched it in preview as Amazon Managed Apache Cassandra Service in December 2019 and made it generally available as Keyspaces in April 2020.

Why teams pick it

  • Existing Cassandra drivers and CQL work, with no repair, compaction, upgrades or capacity planning to do
  • Pay per request on demand, or provisioned capacity with auto scaling, and a 99.99% availability SLA within a Region
  • Active-active multi-Region tables, point-in-time recovery and CDC streams without extra infrastructure
  • IAM, VPC endpoints and KMS encryption like other AWS services

Watch out for

  • Not Cassandra underneath: only LOCAL_QUORUM for writes, no QUORUM or EACH_QUORUM, and cell timestamps (USING TIMESTAMP, WRITETIME) are opt-in per table
  • Rows up to 1 MB and partition keys up to 2,048 bytes, with per-table throughput quotas of 40,000 read and write units by default
  • Per-request pricing gets expensive for steady, very high write rates, and multi-Region tables pay for each write in every Region
  • AWS only: no on-premises or other-cloud deployment, and Cassandra tools such as nodetool don’t apply

Good for

Data model
Wide rows: partitions of rows sorted by clustering columns, as in Cassandra
Query language
CQL
Client protocol
Cassandra CQL protocol, over TLS
Transactions
Lightweight transactions (IF NOT EXISTS), at no extra cost
Consistency
Writes at LOCAL_QUORUM only; reads at LOCAL_QUORUM or ONE/LOCAL_ONE
How it scales
Serverless: tables scale with traffic, on demand or provisioned with auto scaling
Replication
Three copies across Availability Zones
Multi-region
Multi-Region keyspaces, active-active; concurrent updates resolved by last writer wins
Ways to run it
Fully managed, AWS only
Pricing model
Per read and write request unit on demand, or provisioned capacity; plus storage

Alternatives

What all wide-column stores have in common →Compare side by side →

How it fits with other technologies

cqlsh against Keyspaces: an on-demand table with TTL and point-in-time recovery · sql

CREATE TABLE iot.readings (
  sensor_id text, day date, ts timestamp, temperature double,
  PRIMARY KEY ((sensor_id, day), ts))
WITH CUSTOM_PROPERTIES = {
    'capacity_mode': {'throughput_mode': 'PAY_PER_REQUEST'},
    'point_in_time_recovery': {'status': 'enabled'},
    'ttl': {'status': 'enabled'}}
  AND CLUSTERING ORDER BY (ts DESC)
  AND default_time_to_live = 2592000;   -- rows expire after 30 days

CONSISTENCY LOCAL_QUORUM;   -- the only write level Keyspaces accepts
INSERT INTO iot.readings (sensor_id, day, ts, temperature)
VALUES ('s-17', '2026-10-24', '2026-10-24 09:30:00+0000', 21.4);

-- copy the table as it was at an earlier moment
RESTORE TABLE iot.readings_restored FROM TABLE iot.readings
WITH restore_timestamp = '2026-10-23T09:00:00+0000';

See it in a real stack

No architecture uses Amazon Keyspaces (for Apache Cassandra) yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2019–2020

Teams running Cassandra on AWS had to manage clusters themselves: sizing nodes, running repairs, tuning compaction and the JVM, and upgrading carefully. At re:Invent in December 2019 AWS previewed Amazon Managed Apache Cassandra Service, a serverless service that implemented the Cassandra 3.11 CQL API, stored every table three times across Availability Zones and billed only for what was used.

It became generally available in April 2020 under the name Amazon Keyspaces (for Apache Cassandra), in 18 Regions, with provisioned capacity added beside on-demand. Today it also offers client-side timestamps, user-defined types, multi-Region replication and change data capture streams.

Why it’s built this way

Compatible API, not Cassandra itself
Implementing the CQL protocol on AWS’s own storage let existing drivers and code move over while AWS kept full control of replication, scaling and durability, at the cost of features that depend on Cassandra’s internals.
Always write at LOCAL_QUORUM to three zones
A fixed replication scheme across three Availability Zones gives every table the same durability and lets the service price reads by consistency level instead of exposing replication settings.
Request-based billing
Like DynamoDB, paying per read and write unit removes capacity planning for spiky or small workloads; provisioned mode is there for steady ones.

Timeline

  1. 2019

    Previewed in December as Amazon Managed Apache Cassandra Service

  2. 2020

    Generally available in April as Amazon Keyspaces, in 18 Regions

Sources8 · facts checked 24 October 2026

Improve this page on GitHub