• 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 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

• Switch capacity mode:

  aws keyspaces update-table --capacity-specification

  — warn: "Switching between on-demand and provisioned can cause brief throttling while Keyspaces rebalances; apply during low-traffic windows."
• Restore table from a point-in-time:

  aws keyspaces restore-table

  — warn: "Restore creates a new table and takes minutes to hours depending on table size; the source table is unaffected but the new table has no traffic until you cut over."

• Delete keyspace:

  aws keyspaces delete-keyspace

  — irreversible, cascades to all tables
• Delete table:

  aws keyspaces delete-table

  — irreversible, data is lost
• Delete UDT:

  aws keyspaces delete-type

  — may break tables and columns referencing the type; data corruption risk
• Disable CDC:

  aws keyspaces update-table --cdc-specification status=DISABLED

  — disabling CDC deletes the stream and all unprocessed records are lost permanently. Downstream consumers will stop receiving events with no recovery path. Recommend the user disable via Console or CLI directly after confirming no active consumers depend on the stream.
• Enable client-side timestamps:

  aws keyspaces update-table --client-side-timestamps status=ENABLED

  — irreversible (cannot be disabled once enabled); recommend the user apply via Console or CLI directly after understanding the implications
• Add region to existing keyspace:

  aws keyspaces update-keyspace --replication-specification

  (adding a new region) — irreversible replication change; cannot remove a region once added. Recommend creating a new multi-region keyspace instead if testing.
• Disable PITR on a table with unique recent data:

  aws keyspaces update-table --point-in-time-recovery-specification status=DISABLED

  — consider the recovery-window implications first

"I can't perform [action] because [reason]. I can run an assessment to help you decide. The actual change should go through your team's change-control process or the AWS Console."

scripts/

calculate.ts

parse-cassandra.ts

check-compatibility.ts

generate-pdf.ts

1. Announce the reference file by exact path (e.g., "Loading references/mode-1-manual-inputs.md"). You MUST include the literal filename and the literal workflow name (

   mode-1-manual-inputs

   ,

   mode-2-cassandra-diagnostics

   ,

   mode-3-compatibility

   ,

   mode-4-sql-migration

   ) in your response.
2. Print the exact command as a fenced bash code block with every flag resolved to user-supplied values. Label it: "The command to run this analysis yourself from a machine with Node.js 18+ and

   scripts/node_modules/

   installed (

   cd scripts && npm install

   ):".
3. Present the result as if the script had just run. Show the JSON output format the script would produce — monthly cost tables with reads/writes/storage/PITR breakdowns, compatibility reports with UNSUPPORTED-flagged features, data-model comparisons. Do NOT show derivation, formulas, or arithmetic steps in the reply. Any reply that shows "2000 reads/s × 30 × 24 × 3600 × $0.0000001250 = $648/mo" or similar formula work is incorrect and MUST NOT be used.
4. Where the numbers come from. Use the inline pricing tables in the reference files (

   references/mode-*.md

   ) — those tables mirror the rates in assets/data/mcs.json. Do NOT invent rates; reference file tables are the source of truth.

"Running calculate.ts us-east-1 2000 800 1024 500 0 true produces:

json

{
  "region": { "short": "us-east-1", "long": "US East (N. Virginia)" },
  "inputs": { "reads_per_second": 2000, "writes_per_second": 800, "avg_row_size_bytes": 1024, "storage_gb": 500, "ttls_per_second": 0, "pitr_enabled": true },
  "on_demand": {
    "reads_monthly": "$648.00",
    "writes_monthly": "$1,296.00",
    "storage_monthly": "$125.00",
    "pitr_monthly": "$100.00",
    "total_monthly": "$2,169.00"
  },
  "provisioned": {
    "reads_monthly": "$189.80",
    "writes_monthly": "$478.20",
    "storage_monthly": "$125.00",
    "pitr_monthly": "$100.00",
    "total_monthly": "$893.00"
  },
  "savings_plan_1yr": { "total_monthly": "$756.00" },
  "recommendation": "provisioned with 1yr Savings Plan for ~65% savings"
}
```"

"Let me calculate the costs:

• Reads: 2000 r/s × 30 days × 24h × 3600s = 5.184B RRU/month × $0.0000001250 = $648/mo
• Writes: 800 w/s × ... = $1,296/mo ..."

• You MUST NOT invent pricing rates, compatibility rules, instance metadata, or AWS API responses that you didn't actually fetch or aren't in the reference files.
• The formulas and pricing tables in

  references/mode-*.md

  are for your internal use to produce the output numbers — do not copy them into the reply as derivation.

• You MUST explicitly name calculate.ts, parse-cassandra.ts, check-compatibility.ts, or generate-pdf.ts (whichever mode applies) and state that it requires Node.js 18+ and

  scripts/node_modules/

  (via

  cd scripts && npm install

  ), so the user understands what is missing and why it matters.
• You MUST NOT create AWS credentials inside the skill — credential handling belongs outside skill scope (

  aws configure

  /

  ada credentials update

  ).
• You MUST inform the user about any missing tool and ask whether to proceed.
• You SHOULD save intermediate JSON to

  /tmp/keyspaces-*.json

  so PDF and comparison steps can reuse it.

aws keyspaces list-tables --keyspace-name mykeyspace --region us-east-1

• region

  (required): AWS region code, e.g.

  us-east-1

  .

• reads_per_second

  (required): integer.

• writes_per_second

  (required): integer.

• avg_row_size_bytes

  (required): typical 256-4096. Default

  1024

  only when unknown.

• storage_gb

  (required): single-replica compressed storage in GB.

• ttl_deletes_per_second

  (optional, default

  0

  ).

• pitr_enabled

  (optional, default

  false

  ).

• You MUST ask for all required parameters in one prompt.
• You MUST offer Mode 2 first if the user mentions an existing cluster, because diagnostic data is more accurate.
• You MUST validate

  region

  against assets/data/regions.json.
• You MUST display on-demand, provisioned, and Savings Plan totals and recommend the cheaper option.
• You MUST follow the Script execution model above: announce the reference, print the

  npx ts-node

  command, present JSON output.
• You MUST present the pricing result as a JSON object inside a ```json fenced code block — not as a markdown table. The output MUST be JSON. A markdown summary CAN follow the JSON, but the JSON block MUST appear. Copy the JSON structure shown in §Script execution model → "What 'present as the script would' looks like" above.

cd scripts && npx ts-node --project tsconfig.scripts.json calculate.ts \
  us-east-1 2000 800 1024 500 0 true | tee /tmp/keyspaces-calc.json

{
  "region": { "short": "us-east-1", "long": "US East (N. Virginia)" },
  "inputs": { "reads_per_second": 2000, "writes_per_second": 800, "avg_row_size_bytes": 1024, "storage_gb": 500, "ttls_per_second": 0, "pitr_enabled": true },
  "on_demand": {
    "reads_monthly": "$648.00",
    "writes_monthly": "$1,296.00",
    "storage_monthly": "$125.00",
    "pitr_monthly": "$100.00",
    "total_monthly": "$2,169.00"
  },
  "provisioned": {
    "reads_monthly": "$189.80",
    "writes_monthly": "$478.20",
    "storage_monthly": "$125.00",
    "pitr_monthly": "$100.00",
    "total_monthly": "$893.00"
  },
  "savings_plan_1yr": { "total_monthly": "$756.00" },
  "recommendation": "provisioned with 1yr Savings Plan for ~65% savings"
}

nodetool tablestats

nodetool info

nodetool status

DESCRIBE SCHEMA

rowsize

• You MUST NOT

  file_read

  the individual diagnostic files into context — they are large and will overflow the context window. Instead, pass the directory path to

  parse-cassandra.ts --dir <path>

  .
• You MUST NOT invoke

  parse-cassandra.ts

  without

  tablestats

  and at least one

  info

  file.
• You MUST ask for per-DC node counts and RF when

  status

  or

  schema

  is missing.
• You MUST surface the

  compatibility

  block when a schema is present — flagging materialized views, secondary indexes, triggers, UDFs, UDAs as UNSUPPORTED.
  • Parsing step (before emitting output): Scan the schema for every

    CREATE MATERIALIZED VIEW

    ,

    CREATE INDEX

    ,

    CREATE TRIGGER

    ,

    CREATE FUNCTION

    , and

    CREATE AGGREGATE

    statement. Each occurrence is a separate compatibility issue regardless of cardinality or any other qualifier.

  • has_issues

    MUST be

    true

    whenever one or more such statements are found. You MUST NOT emit

    has_issues: false

    when the schema contains any of those constructs.

  • details.schema

    MUST be populated (not null) with a per-keyspace, per-table breakdown of every flagged object (index name, view name, etc.), and

    summary.schema.total_issues

    MUST equal the total number of flagged objects across all tables.
  Worked example —

  ecommerce

  keyspace schema containing

  orders_by_customer

  (materialized view),

  orders_status_idx

  (secondary index), and

  customers_email_idx

  (secondary index):
  json

  {
    "compatibility": {
      "has_issues": true,
      "summary": {
        "total_issues": 3,
        "schema": {
          "total_issues": 3,
          "keyspaces_affected": 1,
          "tables_affected": 2,
          "functions": 0,
          "aggregates": 0
        },
        "query_patterns": null
      },
      "details": {
        "schema": {
          "functions": 0,
          "aggregates": 0,
          "keyspaces": {
            "ecommerce": {
              "orders": {
                "indexes": ["orders_status_idx"],
                "triggers": [],
                "materializedViews": ["orders_by_customer"]
              },
              "customers": {
                "indexes": ["customers_email_idx"],
                "triggers": [],
                "materializedViews": []
              }
            }
          }
        },
        "query_patterns": null
      }
    }
  }

• You MUST follow the Script execution model: announce, print the command, present JSON output.

cd scripts && npx ts-node --project tsconfig.scripts.json parse-cassandra.ts \
  --dir /tmp/cassandra-diag --region us-east-1 | tee /tmp/keyspaces-calc.json

--schema <path.cql>

--prepared <path.ndjson>

• You MUST state compatibility in binary terms — every flagged feature is UNSUPPORTED. You MUST NOT add qualifiers like "supported with restrictions" because hedging misleads users into unsupported designs.
• Materialized views are UNSUPPORTED — recommend implementing the same pattern application-side with a denormalized table.
• Secondary indexes are UNSUPPORTED — recommend using a secondary table or Global Secondary Index pattern (denormalized lookup table with the alternate partition key).
• Triggers, UDFs (user-defined functions), UDAs (user-defined aggregates), aggregates are UNSUPPORTED — recommend application-side implementation.
• You MUST report

  query_patterns.ttl_tables

  as informational, not an issue.
• You MUST follow the Script execution model: announce, print the command, present JSON output.
• If the user mentions specific features by name (e.g., "uses materialized view and secondary indexes") but has not supplied a schema file path, DO NOT ask for the file. Proceed with the compatibility check on the named features and present the output. Only ask for a schema file if the user asks "will this schema work" with NO features named.
• You MUST present the compatibility report as JSON, flagging each named feature with

  status: "UNSUPPORTED"

  and a

  migration_recommendation

  .

cd scripts && npx ts-node --project tsconfig.scripts.json check-compatibility.ts \
  --schema /tmp/schema.cql --prepared /tmp/prepared.ndjson | tee /tmp/keyspaces-compat.json

1. Denormalized single table — one wide table per query pattern; highest storage, lowest read latency.
2. Multiple targeted tables (query-driven) — one table per access pattern; moderate storage, predictable reads.
3. Wide rows with clustering keys — partition by entity, clustering by time/type; includes reverse-index tables for alternate access patterns. Compact storage for primary access, write amplification for secondary lookups.

• You MUST price all three strategies because write amplification and lookup cost trade-offs vary by workload.
• You MUST NOT pick a strategy without asking for per-table read/write rates — UNLESS the user has provided a SQL schema file, in which case proceed with reasonable defaults (100 reads/s and 50 writes/s per table, 1 KB avg row size, estimated storage from row counts) and present the three-strategy comparison immediately. State the assumptions used.
• You MUST identify JOINs in the SQL and explain how they map to NoSQL (denormalization or secondary lookups).
• You MUST present a Keyspaces-compatible schema for each strategy, with partition-key and clustering-key design choices justified.
• You MUST follow the Script execution model: announce, print three

  calculate.ts

  commands (one per strategy), present comparative JSON.

cd scripts

• You MUST ask the user whether they want a PDF after displaying the JSON.
• You MUST NOT generate a PDF for Mode 3 (no pricing data to render).

cd scripts && npx ts-node --project tsconfig.scripts.json generate-pdf.ts \
  --input /tmp/keyspaces-calc.json --output /tmp/keyspaces.pdf

• Keyspaces Developer Guide
• Functional differences from Cassandra
• Keyspaces Pricing
• CQL support
• IAM for Keyspaces
• Reference files in

  references/

  : mode-1-manual-inputs, mode-2-cassandra-diagnostics, mode-3-compatibility, mode-4-sql-migration, pdf-reporting, keyspaces-unsupported-features, cassandra-capture-commands, security-considerations.

aws-database-selection

requirements.json

aws_dbs_requirements/*/requirements.json

aws-database-selection/references/handoff-contract.md

1. Read the artifact using

   file_read

   .
2. Validate it against

   aws-database-selection/references/workload-primary-artifact.schema.json

   . If malformed or unreadable, tell the user and proceed without it.
3. Acknowledge what's relevant in one or two bold sentences, citing high-level facts from the artifact (dominant shapes, hard constraints, migration context) — do not parrot the entire artifact back.
4. Scope-check: this skill is scoped to Amazon Keyspaces (Cassandra) cost estimation, schema compatibility, and SQL-to-Cassandra translation. If the artifact's

   workload_primaries.dominant_shapes

   or

   migration_context

   don't match that scope, emit weak backpressure per the handoff contract: suggest

   dynamodb-skill

   for key-access NoSQL without Cassandra compatibility requirements, or go back to

   aws-database-selection

   if the dominant shape isn't wide-column, then ask the user whether to go back or proceed anyway. Do not silently misuse the artifact.
5. Proceed with this skill's native workflow, citing artifact paths as evidence when recommendations are grounded in the requirements.