AWS Keyspaces Table Builder

What This Tool Does

Build an Amazon Keyspaces (Cassandra-compatible) table with a Cassandra-style schema (partition keys, clustering keys with sort order, column types like map<text, text>), CapacitySpecification set to PAY_PER_REQUEST for unpredictable traffic instead of provisioned throughput, and PointInTimeRecovery for continuous backup. PartitionKeys and ClusteringKeys aren't just schema decoration, they define the actual physical data distribution and sort order Cassandra-style, a poorly-chosen partition key (low cardinality, or one that creates hot partitions under real traffic) causes the same kind of throughput and latency problems in Keyspaces that it would in genuine Apache Cassandra, and like Timestream's partition key, it's expensive to change after the fact.

Technical Details

Common Use Cases

1. 1Choosing user_id as the sole PartitionKey with session_id as a DESC-ordered ClusteringKey, so all of one user's sessions live in the same partition, sorted newest-first, matching a common 'get this user's most recent sessions' query pattern efficiently.
2. 2Setting CapacitySpecification to PAY_PER_REQUEST for a new or unpredictable-traffic table, avoiding the need to guess provisioned read/write capacity units upfront, then switching to provisioned capacity later once real traffic patterns are known and predictable, if that's more cost-effective at scale.
3. 3Enabling PointInTimeRecovery so an accidental bad write or delete can be recovered to a specific prior timestamp, rather than relying solely on periodic on-demand backups that might miss recent changes.
4. 4Setting DefaultTimeToLive (in seconds) on a session-tracking table so stale session records expire and get cleaned up automatically, instead of accumulating indefinitely and requiring a separate cleanup job.

Common Questions

Can I change a table's PartitionKeys after it has data?

No, partition key structure is fixed at table creation, exactly like in Apache Cassandra, since it determines the physical layout of data across the underlying storage. A poor initial choice that creates hot partitions or doesn't match your actual query patterns requires creating a new table with a different key and migrating data, not an in-place schema change.

What's the practical difference between PAY_PER_REQUEST and provisioned capacity?

PAY_PER_REQUEST bills per actual read/write request with no capacity planning needed, ideal for new tables, spiky, or unpredictable traffic, since there's no risk of throttling from under-provisioning or wasted cost from over-provisioning. Provisioned capacity requires estimating read/write capacity units ahead of time but can be more cost-effective for a table with steady, predictable, high-volume traffic where the per-request premium of on-demand pricing adds up. Many tables start on PAY_PER_REQUEST and migrate to provisioned once traffic patterns stabilize.

Does encrypting with a customer-managed KMS key (CUSTOMER_MANAGED_KMS_KEY) work differently from the default?

Functionally similar for read/write operations, but a customer-managed key gives you control over key rotation, access policy, and the ability to revoke access by disabling the key, whereas the AWS-owned default key gives you no such control. Choose CUSTOMER_MANAGED_KMS_KEY when compliance requirements specifically mandate customer control over encryption keys, not as a default for every table.

Expert Tips

Related Learning Guides

• S3 Storage Classes Explained24 min read
• DynamoDB Data Modeling28 min read