/amazon-keyspaces

name: amazon-keyspaces
description: >-
  Provides authoritative compatibility checks, pricing estimates, connection troubleshooting,
  pre-warming guidance, and infrastructure mutations for Amazon Keyspaces (for Apache
  Cassandra). Covers LWT/batch operations, secondary indexes, materialized views,
  capacity modes, TTL, PITR, CDC, auto-scaling, multi-region keyspaces, UDTs, nodetool
  diagnostics parsing, SQL-to-Cassandra migration, and Cassandra-to-Keyspaces migration
  scenarios. Agents frequently produce incomplete or incorrect answers about Keyspaces
  feature support without this skill loaded.
version: 1

Amazon Keyspaces

Safety guidance

This skill covers creating keyspaces and tables and modifying table-level settings (TTL, PITR, capacity mode) when the user requests it. The agent MUST confirm the action with the user before executing. Do NOT execute any create or modify operation without explicit user confirmation (e.g., "yes", "proceed", "confirmed", "go ahead"). If the user has not confirmed, present the planned action and ask for approval.

Execute these operations (after user confirmation)

• Create a keyspace: `aws keyspaces create-keyspace`
• Create a multi-region keyspace: `aws keyspaces create-keyspace --replication-specification replicationStrategy=MULTI_REGION,regionList=[{region=us-east-1},{region=eu-west-1}]`
• Create a table: `aws keyspaces create-table` (include partition-key and clustering-key design derived from the user's access patterns)
• Add column(s) to a table: `aws keyspaces update-table --add-columns '[{"name":"col_name","type":"text"}]'` — non-destructive, no downtime, no data loss. Existing rows get null for the new column.
• Create a User Defined Type (UDT): `aws keyspaces create-type --keyspace-name <ks> --type-name <name> --field-definitions '[{"name":"field1","type":"text"},...]'`
• Modify table TTL: `aws keyspaces update-table --default-time-to-live`
• Enable/disable PITR: `aws keyspaces update-table --point-in-time-recovery-specification`
• Change capacity mode: `aws keyspaces update-table --capacity-specification` (on-demand vs provisioned) — see warnings below
• Switch table encryption key: `aws keyspaces update-table --encryption-specification type=CUSTOMER_MANAGED_KMS_KEY,kmsKeyIdentifier=arn:aws:kms:...` — no downtime or availability loss. Can also switch back to AWS owned key with `type=AWS_OWNED_KMS_KEY`.
• Pre-warm table throughput: `aws keyspaces update-table --warm-throughput-specification readUnitsPerSecond=X,writeUnitsPerSecond=Y` — sets the minimum instantaneous throughput the table can handle. Use before planned traffic spikes (flash sales, migrations, batch loads). One-time cost based on the delta above natural warm throughput. Also available on `aws keyspaces create-table --warm-throughput`. Load [pre-warming.md](references/pre-warming.md) for the decision framework and sizing formulas.
• Configure auto-scaling: `aws keyspaces update-table --auto-scaling-specification` — sets target utilization percentage and min/max capacity units for reads and/or writes. **Prerequisite:** the service-linked role `AWSServiceRoleForApplicationAutoScaling_CassandraTable` must exist. If it doesn't, the agent MUST first instruct the user to run: `aws iam create-service-linked-role --aws-service-name cassandra.application-autoscaling.amazonaws.com`. The calling IAM principal also needs `application-autoscaling:RegisterScalableTarget`, `application-autoscaling:PutScalingPolicy`, `application-autoscaling:DescribeScalableTargets`, `cloudwatch:PutMetricAlarm`, `cloudwatch:DescribeAlarms`, `cloudwatch:DeleteAlarms` permissions. Scope `application-autoscaling:RegisterScalableTarget`, `application-autoscaling:PutScalingPolicy`, `application-autoscaling:DescribeScalableTargets` permissions to the target table ARN (`arn:aws:cassandra:<region>:<account>:/keyspace/<ks>/table/<table>`). Scope `cloudwatch:PutMetricAlarm`, `cloudwatch:DescribeAlarms`, `cloudwatch:DeleteAlarms` permissions to the corresponding alarm ARNs (e.g., `arn:aws:cloudwatch:<region>:<account>:alarm:TargetTracking-table/<ks>/<table>-*`). Use `aws:ResourceTag` condition keys where possible rather than applying account-wide.
• Enable CDC (change data capture): `aws keyspaces update-table --cdc-specification status=ENABLED,viewType=<type>` — creates a CDC stream that captures row-level changes. The agent MUST ask the user which view type to use before enabling, presenting these options:
• `NEW_IMAGE` — captures the full row **after** the change. Best for: event-driven pipelines, downstream sync, materialized views.
• `OLD_IMAGE` — captures the full row **before** the change. Best for: audit trails, compliance logging, undo/rollback scenarios.
• `NEW_AND_OLD_IMAGES` — captures both before and after states. Best for: diff-based pipelines, detailed auditing, conflict resolution. Higher CDC consumption cost.
• `KEYS_ONLY` — captures only the partition key and clustering key columns. Best for: lightweight change notifications, triggering application re-reads. Lowest cost.

Optional: `propagateTags=TABLE` copies the table's tags to the CDC stream. Recommend enabling by default.

• Tag resources: `aws keyspaces tag-resource`, `aws keyspaces untag-resource`

Resource tagging (MANDATORY — always apply on resource creation)

When creating ANY keyspace or table (`aws keyspaces create-keyspace`, `aws keyspaces create-table`, or CQL `CREATE KEYSPACE ... WITH TAGS`, `CREATE TABLE ... WITH TAGS`), you MUST include these tags. A create operation without these tags is INCOMPLETE and INCORRECT:

**AWS CLI syntax:** `--tags key=created_by,value=keyspaces-skill key=generation_model,value={your-model-id}`

**CQL syntax:** `WITH TAGS = {'created_by': 'keyspaces-skill', 'generation_model': '{your-model-id}'}`

Example (CLI): `--tags key=created_by,value=keyspaces-skill key=generation_model,value=claude-sonnet-4-20250514` Example (CQL): `WITH TAGS = {'created_by': 'keyspaces-skill', 'generat