databasesSAA-C03SAP-C02DEA-C01

Amazon Keyspaces: The Serverless Cassandra Powerhouse

Fully managed, serverless Apache Cassandra-compatible database — no clusters to manage, infinite scale on demand

Updated 2026-02-21

Overview

Amazon Keyspaces (for Apache Cassandra) is a scalable, highly available, fully managed serverless database service that is compatible with Apache Cassandra. It lets you run Cassandra workloads on AWS using the same Cassandra Query Language (CQL), drivers, and developer tools you already use — without managing servers, software, or capacity. Keyspaces automatically scales tables up and down based on actual application traffic and replicates data three times across multiple Availability Zones for durability.

Migrate or build Apache Cassandra-compatible workloads on a fully managed, serverless AWS database that eliminates operational overhead while providing single-digit millisecond performance at any scale.

Use When

Migrating existing Apache Cassandra workloads to AWS without re-architecting application code or changing CQL drivers
Building high-throughput, low-latency applications such as IoT telemetry, user profile stores, product catalogs, or time-series data at massive scale
Applications requiring automatic scaling with no capacity planning — traffic spikes are absorbed without manual intervention
Scenarios requiring multi-AZ replication with 99.99% availability SLA without managing replication topology yourself

Avoid When

Relational workloads requiring complex JOINs, foreign keys, or multi-row ACID transactions — use Amazon Aurora or RDS instead
Workloads requiring strong consistency across all reads by default — Keyspaces defaults to eventual consistency and while LOCAL_QUORUM is supported, it is not a relational ACID database
Analytics or OLAP workloads requiring ad-hoc SQL queries across large datasets — use Amazon Redshift or Athena instead
Graph traversal workloads — use Amazon Neptune instead

Key Features

Serverless — no cluster management

No EC2 instances, no Cassandra ring topology to manage. AWS handles all infrastructure.

Apache Cassandra CQL compatibility

Use existing CQL drivers (v3, v4), tools, and application code with minimal changes.

On-demand capacity mode

Pay per request; automatically scales to handle any traffic level without pre-provisioning.

Provisioned capacity mode

Specify RCUs and WCUs for predictable workloads; supports auto-scaling policies.

Auto-scaling (provisioned mode)

Define min/max RCU/WCU and target utilization; Keyspaces adjusts capacity automatically.

Multi-AZ replication (3 AZs)

Data is automatically replicated across three AZs in a Region — no configuration required.

Point-in-time recovery (PITR)

Continuous backups with restore to any second in the last 35 days.

On-demand backups

Manual backups retained until explicitly deleted; no performance impact.

Encryption at rest (AWS KMS)

Default AWS-owned keys or customer-managed KMS keys (CMKs) supported.

Encryption in transit (TLS)

All data in transit is encrypted using TLS. Required by default.

TTL (Time to Live)

Column-level or row-level TTL; expired data is automatically deleted. Affects per-operation column limits.

VPC endpoints (AWS PrivateLink)

Access Keyspaces from within a VPC without traversing the public internet.

IAM authentication

Use IAM roles and policies for fine-grained access control instead of Cassandra-native auth.

AWS CloudTrail integration

All API calls logged to CloudTrail for audit and compliance.

Amazon CloudWatch metrics

Built-in metrics for read/write throughput, latency, errors, and system health.

Lightweight transactions (LWT)

Supports IF NOT EXISTS and IF conditions for conditional writes — with performance cost.

Secondary indexes

Up to 10 per table; allow queries on non-partition-key columns.

Multi-Region replication

Keyspaces does not natively support multi-Region replication like DynamoDB Global Tables. This is a key differentiator in exam scenarios.

Transactions (ACID multi-row)

No multi-row ACID transactions. Logged batches provide atomicity for a batch but are not full ACID transactions.

SQL queries / JOINs

CQL only — no SQL JOINs, subqueries, or GROUP BY aggregations across tables.

Integration Patterns

Cost Visibility and Optimization

high freq

Amazon KeyspacesAWS Cost Explorer

Use AWS Cost Explorer to analyze Keyspaces spending by capacity mode (on-demand vs provisioned), identify tables with low utilization, and right-size provisioned capacity. Tag Keyspaces tables with cost allocation tags to enable per-application cost breakdown in Cost Explorer.

Operational Best Practices and Cost Checks

high freq

Amazon KeyspacesAWS Trusted Advisor

Trusted Advisor checks can surface underutilized provisioned capacity in Keyspaces tables, recommending a switch to on-demand mode or reduced provisioned throughput to reduce costs. Relevant for SAA-C03 cost-optimization domain questions.

Granular Cost Allocation and Chargeback

high freq

Amazon KeyspacesAWS Cost and Usage Reports

AWS Cost and Usage Reports (CUR) provide the most granular billing data for Keyspaces, including per-table usage broken down by storage, read units, and write units. Used by finance teams for chargeback and showback models.

Budget Alerting for Serverless Databases

high freq

Amazon KeyspacesAWS Billing

Set AWS Budgets alerts on Keyspaces service costs to prevent bill shock from unexpected traffic spikes in on-demand mode. Combine with CloudWatch alarms on ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits metrics for proactive monitoring.

Capacity Mode Recommendations

high freq

Amazon KeyspacesAWS Compute Optimizer

AWS Compute Optimizer analyzes Keyspaces table usage patterns and recommends whether to use provisioned or on-demand capacity mode, and what provisioned throughput values to set — reducing over-provisioning costs without sacrificing performance.

Serverless Event-Driven Data Processing

medium freq

Amazon KeyspacesAWS Lambda

Lambda functions triggered by EventBridge, SQS, or Kinesis write processed records into Keyspaces tables using the CQL driver over TLS. Full serverless architecture with no infrastructure to manage end-to-end.

Real-Time IoT / Telemetry Ingestion

medium freq

Amazon KeyspacesAmazon Kinesis Data Streams

Kinesis Data Streams ingests high-velocity IoT or clickstream data; Lambda consumers process and write records into Keyspaces for low-latency lookups. Common pattern for time-series data at scale.

Cassandra to Keyspaces Migration

medium freq

Amazon KeyspacesAWS Database Migration Service (DMS)

DMS supports migrating data from self-managed Apache Cassandra clusters to Amazon Keyspaces. Used in SAP-C02 workload migration scenarios — Keyspaces is the managed target, DMS handles the data movement.

Performance Monitoring and Alerting

medium freq

Amazon KeyspacesAmazon CloudWatch

CloudWatch provides built-in metrics for Keyspaces including SuccessfulRequestLatency, ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, and SystemErrors. Set alarms to detect throttling events and trigger auto-scaling or operational responses.

Private VPC Connectivity

medium freq

Amazon KeyspacesAWS PrivateLink

Use VPC endpoints powered by AWS PrivateLink to connect applications running in a VPC to Keyspaces without routing traffic through the public internet — required for compliance-sensitive workloads and a common exam scenario for security-conscious architectures.

Service Limits & Quotas

LimitValueNote

Maximum row size

1 MB per row

Candidates frequently confuse this with the 4 MB logged batch size limit. They are different limits for different constructs.

Maximum logged batch size

4 MB per logged batch statement

Do not confuse with the 1 MB static data per partition limit or the 1 MB row size limit — three separate 'MB' values exist in Keyspaces limits.

Maximum number of statements in a logged batch

100 statements per logged batch

A critical exam trap: logged batch with static columns has a lower limit of 50 statements, not 100.

Maximum statements in a logged batch with static columns

50 statements per logged batch (static columns)

This is one of the most tested sub-limits in Keyspaces. The presence of static columns cuts the batch statement limit in half.

Maximum static data per partition

1 MB per partition

Candidates swap this with the 4 MB logged batch size. Remember: 1 MB = row size AND static data per partition; 4 MB = logged batch size.

Maximum columns per INSERT or UPDATE (without TTL)

225 columns per operation

TTL changes this limit — see the TTL-enabled column limit below. Exam questions test whether you know TTL affects per-operation column counts.

Maximum columns per INSERT or UPDATE (with TTL enabled)

112 columns per operation with TTL

Many candidates assume TTL is purely a data expiration feature with no effect on operation limits. Wrong — TTL halves the per-operation column count.

Maximum keyspaces per account per Region

4,000 keyspaces

Soft limit of 4,000 keyspaces per account per Region — can be increased via Service Quotas.

Maximum tables per keyspace

4,000 tables per keyspace

Up to 4,000 tables per keyspace — same as the keyspace-per-account limit, which helps with memorization.

Maximum secondary indexes per table

10 secondary indexes per table

You can create up to 10 secondary indexes per table. Secondary indexes in Keyspaces support read isolation but come with write amplification costs.

Maximum partition key size

2 KB per partition key

Partition keys are capped at 2 KB — important for data modeling decisions on the exam.

Maximum clustering key size

850 bytes per clustering key

Clustering keys have a tighter size limit (850 bytes) than partition keys (2 KB) — relevant for wide-row data modeling questions.

Maximum item collection size (partition)

Unlimited rows per partition

Unlike DynamoDB which has a 10 GB item collection limit, Keyspaces partitions are not bounded by a per-partition size limit for row count — though static data within a partition is still capped at 1 MB.

Default read/write throughput (on-demand mode)

40,000 RCUs / 40,000 WCUs per table (soft limit, increasable)

On-demand tables start with a default throughput ceiling that can be raised via Service Quotas — relevant for burst planning in SAP-C02 migration scenarios.

Maximum TTL value

630,720,000 seconds approximately 20 years

TTL can be set up to ~20 years. Useful for long-lived but eventually expiring data like compliance records.

Point-in-time recovery (PITR) retention window

35 days days

PITR allows restore to any second within the last 35 days — same window as DynamoDB PITR. Useful for accidental deletion recovery scenarios.

Pricing Model

Pay-per-use (on-demand) or provisioned capacity with optional auto-scaling

On-demand mode: pay per WRU (Write Request Unit) and RRU (Read Request Unit) actually consumed — no minimum fee, no idle cost
Provisioned mode: pay per provisioned RCU/WCU per hour — lower cost than on-demand for predictable, steady-state workloads
Storage: charged per GB-month for data stored in tables (separate from backup storage)
PITR backup storage: charged per GB-month for continuous backup data retained up to 35 days
On-demand backup storage: charged per GB-month until the backup is deleted
Data transfer: standard AWS data transfer rates apply for data leaving the Region
No charge for data transferred between Keyspaces and other AWS services in the same Region (e.g., Lambda, EC2)
AWS Free Tier: 25 GB of storage, 5 million WRUs, and 5 million RRUs per month for the first 12 months

Exam Tips

criticalRow size limit vs logged batch size limit

The row size limit is 1 MB — NOT 4 MB. The 4 MB limit applies to logged batches, not individual rows. These two values are intentionally confused in exam questions.

criticalLogged batch statement limits with static columns

When a logged batch contains static columns, the maximum number of statements drops from 100 to 50. If an exam question mentions 'static columns' in a batch context, the answer is 50, not 100.

criticalTTL impact on column count limits

TTL configuration directly affects per-operation column count limits. Without TTL: 225 columns max per INSERT/UPDATE. With TTL enabled: 112 columns max. This is a tested detail — do not assume TTL is only about data expiration.

critical

Row size limit = 1 MB (NOT 4 MB). The 4 MB limit is for logged batches. These two values are swapped in exam distractors — know which limit applies to which construct.

critical

Static columns in a logged batch reduce the statement limit from 100 to 50. Any exam question mentioning 'static columns' in a batch context is testing this specific sub-limit.

critical

TTL reduces the maximum columns per INSERT/UPDATE from 225 to 112. TTL is not just a data expiration feature — it directly impacts per-operation column count limits.

importantMulti-Region replication gap vs DynamoDB

Amazon Keyspaces does NOT support multi-Region replication (unlike DynamoDB Global Tables). If a question asks for a globally distributed, multi-Region, low-latency NoSQL solution with Cassandra compatibility, note this limitation and consider whether the architecture needs a workaround.

importantIAM-based authentication

Keyspaces uses IAM for authentication — NOT Cassandra's native username/password auth. In exam scenarios about securing Keyspaces access, the answer involves IAM roles and policies, not Cassandra credentials.

importantDisaster recovery and PITR

PITR (Point-in-Time Recovery) in Keyspaces has a 35-day retention window — the same as DynamoDB. If a question asks about recovering from accidental data deletion in Keyspaces within the last month, PITR is the correct answer.

importantCapacity mode selection for cost optimization

For cost optimization questions (SAA-C03 domain), remember: on-demand mode is best for unpredictable or spiky workloads; provisioned mode with auto-scaling is best for steady, predictable traffic. AWS Cost Explorer, Trusted Advisor, and Compute Optimizer all appear in Keyspaces cost-optimization exam scenarios.

importantMulti-AZ durability

Keyspaces data is automatically replicated across THREE Availability Zones within a Region. This is built-in and requires no configuration — relevant for availability and durability questions.

importantStatic data per partition limit

Static data per partition is capped at 1 MB — the same number as the row size limit but a completely different constraint. Three separate '1 MB' limits exist: row size, static data per partition. The 4 MB limit is only for logged batches.

Good to KnowCassandra migration with DMS

In SAP-C02 migration scenarios, AWS DMS can migrate self-managed Apache Cassandra workloads to Amazon Keyspaces. Keyspaces is the recommended modernization target for Cassandra on AWS — no code changes needed if using CQL drivers.

Common Misconceptions & Traps

Common Mistake

The row size limit in Amazon Keyspaces is 4 MB

Correct

The row size limit is 1 MB. The 4 MB limit applies to logged batch statements, not individual rows.

This is the #1 most tested misconception in Keyspaces exam questions. The 4 MB number is real but belongs to a different limit (logged batch size). Always ask: is the question about a single row or a batch? Row = 1 MB; Logged batch = 4 MB.

Common Mistake

A logged batch in Keyspaces can always contain up to 100 statements regardless of column types

Correct

The 100-statement limit applies to general logged batches. If the batch involves static columns, the limit drops to 50 statements.

Exam questions deliberately introduce the phrase 'static columns' to test whether you know this sub-limit. The presence of static columns in a batch is a signal that the answer should be 50, not 100. Memorize: static columns = half the batch statement limit.

Common Mistake

Enabling TTL on an INSERT or UPDATE operation has no effect on how many columns can be included in that operation

Correct

TTL directly reduces the maximum columns per INSERT/UPDATE from 225 (without TTL) to 112 (with TTL enabled).

Candidates treat TTL as purely a data lifecycle feature and do not associate it with operational limits. On the exam, if TTL is mentioned alongside a column count question, the answer changes. Remember: TTL ≈ halves the per-operation column count (225 → 112).

Common Mistake

Amazon Keyspaces supports multi-Region replication like DynamoDB Global Tables

Correct

Keyspaces does NOT natively support multi-Region replication. Data is replicated across three AZs within a single Region only.

DynamoDB Global Tables is a frequent comparison point. If an exam question requires active-active multi-Region NoSQL, DynamoDB is the answer — not Keyspaces. This distinction is especially tested in SAP-C02 architecture design questions.

Common Mistake

The 1 MB static data per partition limit and the 1 MB row size limit are the same thing

Correct

They are two separate limits that happen to share the same value. Row size limits a single row to 1 MB. Static data per partition limits the aggregate static column data within one partition to 1 MB.

Having two different limits with the same value (1 MB) creates confusion. Exam questions may describe a scenario where one limit is hit but not the other. Understand what each limit governs: row size = one row's total data; static data per partition = aggregate static columns across all rows in a partition.

Common Mistake

Amazon Keyspaces uses Cassandra's native username/password authentication

Correct

Keyspaces uses AWS IAM for authentication. You use IAM roles, users, and policies — not Cassandra-native credentials.

Developers migrating from self-managed Cassandra expect the same auth model. On the exam, security questions about Keyspaces always point to IAM, not Cassandra credentials. This also means you can use IAM conditions, SCPs, and resource-based policies for fine-grained access control.

Memory Tricks

🧠

ROW = 1 MB, BATCH = 4 MB, STATIC BATCH = 50 stmts, GENERAL BATCH = 100 stmts — 'One Row, Four Batches, Fifty Static, Hundred General' → 1-4-50-100

🧠

TTL HALVES: Without TTL = 225 columns; With TTL = ~112 columns (half). Think: 'TTL Takes half your columns away'

🧠

Keyspaces = 3 AZs in 1 Region. DynamoDB Global Tables = Multiple Regions. 'Keyspaces stays home; DynamoDB goes global'

🧠

For cost optimization in exam questions, remember the AWS Cost Quartet: Cost Explorer + Trusted Advisor + Cost and Usage Reports + Compute Optimizer — all four appear in Keyspaces cost scenarios

CertAI Tutor · SAA-C03, SAP-C02, DEA-C01 · 2026-02-21

Ready to test your knowledge?

Practice SAA-C03, SAP-C02, DEA-C01 exam questions with AI-powered explanations — free to start.

Amazon Keyspaces: The Serverless Cassandra Powerhouse

Overview

Key Features

Integration Patterns

Service Limits & Quotas

Pricing Model

Exam Tips

Common Misconceptions & Traps

Memory Tricks

Ready to test your knowledge?

Related Cheat Sheets