Amazon Keyspaces Multi-Region Replication usage notes - Amazon Keyspaces (for Apache Cassandra)
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Amazon Keyspaces Multi-Region Replication usage notes

Consider the following when you're using Multi-Region Replication with Amazon Keyspaces.

  • You can select up to six of the available public Amazon Web Services Regions. Amazon GovCloud (US) Regions, China Regions, and Amazon Web Services Regions that are disabled by default are not supported.

  • Select the replication Regions for the keyspace carefully because you can't add or remove them later.

  • Finalize the table schema before creating a multi-Region table because you can't add new columns later.

  • For encryption at rest, use an Amazon owned key. Customer managed keys are not supported for multi-Region tables. For more information, see

    Encryption at rest: How it works in Amazon Keyspaces.

  • When you're using provisioned capacity management with Amazon Keyspaces auto scaling, make sure to use the Amazon Keyspaces API operations to create and configure your multi-Region tables. The underlying Application Auto Scaling API operations that Amazon Keyspaces calls on your behalf don't have multi-Region capabilities.

    For more information, see How to use Multi-Region Replication. For more information on how to estimate the write capacity throughput of provisioned multi-Region tables, see Working with multi-Region tables in Amazon Keyspaces.

  • Decide if the table needs Time to Live (TTL). You won't be able to turn it on later. For more information, see Expiring data by using Amazon Keyspaces Time to Live (TTL).

  • Although data is automatically replicated across the selected Regions of a multi-Region table, when a client connects to an endpoint in one Region and queries the system.peers table, the query returns only local information. The query result appears like a single data center cluster to the client.

  • Amazon Keyspaces Multi-Region Replication is asynchronous, and it supports LOCAL_QUORUM consistency for writes. LOCAL_QUORUM consistency requires that an update to a row is durably persisted on two replicas in the local Region before returning success to the client. The propagation of writes to the replicated Region (or Regions) is then performed asynchronously.

    Amazon Keyspaces Multi-Region Replication doesn't support synchronous replication or QUORUM consistency.

  • When you create a multi-Region keyspace or table, any tags that you define during the creation process are automatically applied to all keyspaces and tables in all Regions. When you change the existing tags using ALTER KEYSPACE or ALTER TABLE, the update is only applied to the keyspace or table in the Region where you're making the change.

  • Amazon CloudWatch provides a ReplicationLatency metric for each replicated Region. It calculates this metric by tracking arriving rows, comparing their arrival time with their initial write time, and computing an average. Timings are stored within CloudWatch in the source Region. For more information, see Monitoring Amazon Keyspaces with Amazon CloudWatch.

    It can be useful to view the average and maximum timings to determine the average and worst-case replication lag. There is no SLA on this latency.

  • When using a multi-Region table in on-demand mode, you may observe an increase in latency for asynchronous replication of writes if a table replica experiences a new traffic peak. Similar to how Amazon Keyspaces automatically adapts the capacity of a single-Region on-demand table to the application traffic it receives, Amazon Keyspaces automatically adapts the capacity of a multi-Region on-demand table replica to the traffic that it receives. The increase in replication latency is transient because Amazon Keyspaces automatically allocates more capacity as your traffic volume increases. Once all replicas have adapted to your traffic volume, replication latency should return back to normal. For more information, see Peak traffic and scaling properties.

  • When using a multi-Region table in provisioned mode, if your application exceeds your provisioned throughput capacity, you may observe insufficient capacity errors and an increase in replication latency. To ensure that there's always enough read and write capacity for all table replicas in all Amazon Web Services Regions of a multi-Region table, we recommend that you configure Amazon Keyspaces auto scaling. Amazon Keyspaces auto scaling helps you provision throughput capacity efficiently for variable workloads by adjusting throughput capacity automatically in response to actual application traffic. For more information, see How auto scaling works for multi-Region tables.