Running an Apache Cassandra-Compatible Database on Amazon Keyspaces - Getting Started with a Serverless, Widely Distributed DB
An Apache Cassandra-compatible wide-column database is run serverlessly. This article introduces how to choose between on-demand and provisioned capacity and how to design partition keys.
Features of Keyspaces and Differences from Cassandra
Keyspaces is a managed database service compatible with Apache Cassandra. You use CQL to create tables and read and write data, and you can use existing Cassandra drivers (such as the DataStax Java Driver). However, you need to enable TLS when connecting, and if you use IAM authentication, additional configuration of the SigV4 authentication plugin is also required. The node management, patching, repair processing, and compaction tuning required to operate a Cassandra cluster become unnecessary. However, not all Cassandra features are supported, and user-defined functions (UDFs), materialized views, aggregate functions such as SUM and AVG, and others are not supported. On the other hand, conditional writes with Lightweight Transactions (LWT) are fully supported. Before migrating, you need to check the compatibility matrix and verify whether the CQL features your application uses are supported.
Capacity Modes and Partition Design
On-demand mode scales automatically according to request volume, and no capacity planning in advance is required. It is suited to cases where traffic patterns are hard to predict and to development / test environments. Provisioned mode lets you specify read/write capacity units in advance and adjust them automatically with Auto Scaling. In production environments with stable traffic, provisioned mode is more cost-efficient. Partition key design is as important as in Cassandra, and you choose a key with high cardinality that distributes access evenly. Because hot partitions cause throttling, time-series data requires measures such as combining a bucket ID with the timestamp rather than using the timestamp alone.
Security and Backups
Keyspaces has encryption at rest enabled by default, and you can choose an AWS managed key or a customer managed key (KMS). Data in transit is encrypted with TLS. Access control is managed with IAM policies, and fine-grained permission settings at the table level are possible. When you enable point-in-time recovery (PITR), you can restore a table to any second in the past 35 days. This is effective for recovering from accidental data deletion and data corruption caused by application bugs. PITR incurs additional charges, but enabling it is strongly recommended for production environments.
Keyspaces Pricing
The following are unit prices as of August 2026 / in the Tokyo Region. On-demand mode costs $0.1425 per 1 million read request units and $0.715 per 1 million write request units, and only the amount you actually read and write is billed. Provisioned mode is hourly billing for the capacity you reserve: $0.0001484/hour per read capacity unit (RCU) and $0.000742/hour per write capacity unit (WCU) (converted at 730 hours, about $0.11/month per RCU and about $0.54/month per WCU). The fact that writes cost 5 times as much per unit as reads is an element that is easy to overlook in capacity design. Storage costs $0.285 per GB per month, and enabling PITR adds $0.228 per GB per month for restore data. Automatic deletion with TTL is also billed separately at $0.315 per 1 million deletes. Compared with DynamoDB, the pricing approach is similar, and because Keyspaces is accessed with CQL, its advantage is the low migration cost (application changes) for existing Cassandra workloads. For the first 3 months, 30 million read and 30 million write request units per month and 1 GB of storage are covered by the free tier.
Data Modeling and Query Design
In a wide-column database such as Keyspaces, the approach to design differs from that of relational databases. The basic approach is "query-driven," in which you decide the query patterns first and design tables to match them. You design the partition key, which determines how data is distributed, and the clustering columns, which determine the sort order within a partition, to match the searches you expect. Denormalization, which keeps the needed data together, is often more suitable than normalization. Because it is not good at searching with arbitrary conditions later, identifying access patterns at the start and modeling around them is the prerequisite for getting performance out of it.
Balancing Consistency and Performance
Keyspaces lets you choose the consistency level for reads. You choose strong consistency when you want to reliably read the latest value at all times, and relaxed consistency when you want to tolerate some delay and prioritize performance and availability. The stronger you make consistency, the more it costs in terms of response time and load, so you use them according to the nature of the data. Conflicts when multiple processes update the same data at the same time can be prevented with conditional writes using LWT. In Cassandra, a common design was to avoid using LWT because consensus processing makes it slower, but in Keyspaces LWT has no performance penalty and can be used just like normal writes. Designing with awareness of the balance between the consistency you require and latency and throughput is the key to making effective use of a wide-column database.
Migration and Application Integration
Keyspaces is compatible with Cassandra, and you can use the query language for Cassandra (CQL) and existing drivers. The part that needs rewriting is the connection: with TLS enabled, you either add the SigV4 authentication plugin if you use IAM authentication, or issue and configure service-specific credentials. Apart from this connection setup, you may be able to migrate existing Cassandra applications without major code changes. However, because there are differences in some features and behaviors, it is important to check before migrating whether the features your application depends on are supported. Because it is operated serverlessly, a major advantage is that the effort of building / operating your own Cassandra cluster goes away. By making use of compatibility while verifying the differences in supported scope in advance, you can achieve a smooth migration and a reduced operational burden.
Operations and Monitoring
Because Keyspaces is serverless, cluster management such as adding nodes and applying patches is not required. You can choose whether capacity is adjusted automatically on demand or provisioned to match the expected load. In operations, you monitor read and write throughput and the occurrence of throttling, and check whether access to partitions is skewed. When access concentrates on a specific partition, performance hits a ceiling, so you distribute it through key design. Continuous backups let you restore to any point in time in the past, so you can prepare for operational mistakes and failures. Because management takes little effort, you can concentrate on design and monitoring.
Summary
Keyspaces is a serverless database that you can access with Cassandra-compatible CQL. It eliminates the burden of cluster management, and with on-demand capacity you are billed only for what you use. It is effective for migrating existing Cassandra workloads to AWS and for building new workloads suited to the Cassandra data model.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.