# Multi-Region replication for Amazon Keyspaces (for Apache Cassandra) You can use Amazon Keyspaces multi-Region replication to replicate your data with automated, fully managed, *active-active* replication across the AWS Regions of your choice. With active-active replication, each Region is able to perform reads and writes in isolation. You can improve both availability and resiliency from Regional degradation, while also benefiting from low-latency local reads and writes for global applications. With multi-Region replication, Amazon Keyspaces asynchronously replicates data between Regions, and data is typically propagated across Regions within a second. Also, with multi-Region replication, you no longer have the difficult work of resolving conflicts and correcting data divergence issues, so you can focus on your application. By default, Amazon Keyspaces replicates data across three [ Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) within the same AWS Region for durability and high availability. With multi-Region replication, you can create multi-Region keyspaces that replicate your tables in different geographic AWS Regions of your choice. **Topics** + [Benefits of using multi-Region replication](#mrr-benefits) + [Capacity modes and pricing](#mrr-pricing) + [How multi-Region replication works in Amazon Keyspaces](multiRegion-replication_how-it-works.md) + [Amazon Keyspaces multi-Region replication usage notes](multiRegion-replication_usage-notes.md) + [Configure multi-Region replication for Amazon Keyspaces (for Apache Cassandra)](multiRegion-replication-configure.md) ## Benefits of using multi-Region replication Multi-Region replication provides the following benefits. + **Global reads and writes with single-digit millisecond latency** – In Amazon Keyspaces, replication is active-active. You can serve both reads and writes locally from the Regions closest to your customers with single-digit millisecond latency at any scale. You can use Amazon Keyspaces multi-Region tables for global applications that need a fast response time anywhere in the world. + **Improved business continuity and protection from single-Region degradation** – With multi-Region replication, you can recover from degradation in a single AWS Region by redirecting your application to a different Region in your multi-Region keyspace. Because Amazon Keyspaces offers active-active replication, there is no impact to your reads and writes. Amazon Keyspaces keeps track of any writes that have been performed on your multi-Region keyspace but haven't been propagated to all replica Regions. After the Region comes back online, Amazon Keyspaces automatically syncs any missing changes so that you can recover without any application impact. + **High-speed replication across Regions** – Multi-Region replication uses fast, storage-based physical replication of data across Regions, with a replication lag that is typically less than 1 second. Replication in Amazon Keyspaces has little to no impact on your database queries because it doesn’t share compute resources with your application. This means that you can address high-write throughput use cases or use cases with sudden spikes or bursts in throughput without any application impact. + **Consistency and conflict resolution** – Any changes made to data in any Region are replicated to the other Regions in a multi-Region keyspace. If applications update the same data in different Regions at the same time, conflicts can arise. To help provide eventual consistency, Amazon Keyspaces uses cell-level timestamps and a *last writer wins* reconciliation between concurrent updates. Conflict resolution is fully managed and happens in the background without any application impact. For more information about supported configurations and features, see [Amazon Keyspaces multi-Region replication usage notes](multiRegion-replication_usage-notes.md). ## Capacity modes and pricing For a multi-Region keyspace, you can either use *on-demand capacity mode* or *provisioned capacity mode*. For more information, see [Configure read/write capacity modes in Amazon Keyspaces](ReadWriteCapacityMode.md). For on-demand mode, you're billed 1 write request unit (WRU) to write up to 1 KB of data per row the same way as for single-Region tables. But you're billed for writes in each Region of your multi-Region keyspace. For example, writing a row of 3 KB of data in a multi-Region keyspace with two Regions requires 6 WRUs: 3 \$1 2 = 6 WRUs. Additionally, writes that include both static and non-static data require additional write operations. For provisioned mode, you're billed 1 write capacity unit (WCU) to write up to 1 KB of data per row, the same way as for single-Region tables. But you're billed for writes in each Region of your multi-Region keyspace. For example, writing a row of 3 KB of data per second in a multi-Region keyspace with two Regions requires 6 WCUs: 3 \$1 2 = 6 WCUs. Additionally, writes that include both static and non-static data require additional write operations. For more information about pricing, see [Amazon Keyspaces (for Apache Cassandra) pricing](https://aws.amazon.com/keyspaces/pricing). # How multi-Region replication works in Amazon Keyspaces This section provides an overview of how Amazon Keyspaces multi-Region replication works. For more information about pricing, see [Amazon Keyspaces (for Apache Cassandra) pricing](https://aws.amazon.com/keyspaces/pricing). **Topics** + [How multi-Region replication works in Amazon Keyspaces](#multiRegion-replication_how-it-works-overview) + [Multi-Region replication conflict resolution](#multiRegion-replication_how-it-works-conflict-resolution) + [Multi-Region replication disaster recovery](#howitworks_disaster_recovery) + [Multi-Region replication in AWS Regions disabled by default](#howitworks_mrr_opt_in) + [Multi-Region replication and integration with point-in-time recovery (PITR)](#howitworks_mrr_pitr) + [Multi-Region replication and integration with AWS services](#howitworks_integration) ## How multi-Region replication works in Amazon Keyspaces Amazon Keyspaces multi-Region replication implements a data resiliency architecture that distributes your data across independent and geographically distributed AWS Regions. It uses *active-active replication*, which provides local low latency with each Region being able to perform reads and writes in isolation. When you create an Amazon Keyspaces multi-Region keyspace, you can select additional Regions where the data is going to be replicated to. Each table you create in a multi-Region keyspace consists of multiple replica tables (one per Region) that Amazon Keyspaces considers as a single unit. Every replica has the same table name and the same primary key schema. When an application writes data to a local table in one Region, the data is durably written using the `LOCAL_QUORUM` consistency level. Amazon Keyspaces automatically replicates the data asynchronously to the other replication Regions. The replication lag across Regions is typically less than one second and doesn't impact your application’s performance or throughput. After the data is written, you can read it from the multi-Region table in another replication Region with the `LOCAL_ONE/LOCAL_QUORUM` consistency levels. For more information about supported configurations and features, see [Amazon Keyspaces multi-Region replication usage notes](multiRegion-replication_usage-notes.md). ![\[Users are reading and writing data stored in an Amazon Keyspaces table locally in their respective AWS Region while Amazon Keyspaces asynchronously replicates writes between tables in all available Regions.\]](http://docs.aws.amazon.com/keyspaces/latest/devguide/images/keyspaces_multi_Region_replication.png) ## Multi-Region replication conflict resolution Amazon Keyspaces multi-Region replication is fully managed, which means that you don't have to perform replication tasks such as regularly running repair operations to clean-up data synchronization issues. Amazon Keyspaces monitors data consistency between tables in different AWS Regions by detecting and repairing conflicts, and synchronizes replicas automatically. Amazon Keyspaces uses the *last writer wins* method of data reconciliation. With this conflict resolution mechanism, all of the Regions in a multi-Region keyspace agree on the latest update and converge toward a state in which they all have identical data. The reconciliation process has no impact on application performance. To support conflict resolution, client-side timestamps are automatically turned on for multi-Region tables and can't be turned off. For more information, see [Client-side timestamps in Amazon Keyspaces](client-side-timestamps.md). ## Multi-Region replication disaster recovery With Amazon Keyspaces multi-Region replication, writes are replicated asynchronously across each Region. In the rare event of a single Region degradation or failure, multi-Region replication helps you to recover from disaster with little to no impact to your application. Recovery from disaster is typically measured using values for Recovery time objective (RTO) and Recovery point objective (RPO). **Recovery time objective** – The time it takes a system to return to a working state after a disaster. RTO measures the amount of downtime your workload can tolerate, measured in time. For disaster recovery plans that use multi-Region replication to fail over to an unaffected Region, the RTO can be nearly zero. The RTO is limited by how quickly your application can detect the failure condition and redirect traffic to another Region. **Recovery point objective** – The amount of data that can be lost (measured in time). For disaster recovery plans that use multi-Region replication to fail over to an unaffected Region, the RPO is typically single-digit seconds. The RPO is limited by replication latency to the failover target replica. In the event of a Regional failure or degradation, you don't need to promote a secondary Region or perform database failover procedures because replication in Amazon Keyspaces is active-active. Instead, you can use Amazon Route 53 to route your application to the nearest healthy Region. To learn more about Route 53, see [What is Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html). If a single AWS Region becomes isolated or degraded, your application can redirect traffic to a different Region using Route 53 to perform reads and writes against a different replica table. You can also apply custom business logic to determine when to redirect requests to other Regions. An example of this is making your application aware of the multiple endpoints that are available. When the Region comes back online, Amazon Keyspaces resumes propagating any pending writes from that Region to the replica tables in other Regions. It also resumes propagating writes from other replica tables to the Region that is now back online. ## Multi-Region replication in AWS Regions disabled by default Amazon Keyspaces multi-Region replication is supported in the following AWS Regions that are disabled by default: + Africa (Cape Town) Region + Middle East (UAE) Region + Asia Pacific (Hong Kong) Region + Middle East (Bahrain) Region Before you can use a Region that's disabled by default with Amazon Keyspaces multi-Region replication, you first have to enable the Region. For more information, see [ Enable or disable AWS Regions in your account](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in the [https://docs.aws.amazon.com/organizations/latest/userguide/](https://docs.aws.amazon.com/organizations/latest/userguide/). After you've enabled a Region, you can create new Amazon Keyspaces resources in the Region and add the Region to a multi-Region keyspace. When you disable a Region that is used by Amazon Keyspaces multi-Region replication, Amazon Keyspaces initiates a 24-hour grace period. During this time window, you can expect the following behavior: + Amazon Keyspaces continues to perform data manipulation language (DML) operations in enabled Regions. + Amazon Keyspaces pauses replicating data updates from enabled Regions to the disabled Region. + Amazon Keyspaces blocks all data definition language (DDL) requests in the disabled Region. If you disabled the Region in error, you can re-enable the Region within 24 hours. If you re-enable the Region during the 24-hour grace period, Amazon Keyspaces is going to take the following actions: + Automatically resume all replications to the re-enabled Region. + Replicate any data updates that took place in enabled Regions while the Region was disabled to ensure data consistency. + Continue all additional multi-Region replication operations automatically. In the case that the Region remains disabled after the 24-hour window closes, Amazon Keyspaces takes the following actions to permanently remove the Region from multi-Region replication: + Remove the disabled Region from all multi-Region replication keyspaces. + Convert multi-Region replication table replicas in the disabled Region into single-Region keyspaces and tables. + Amazon Keyspaces doesn't delete any resources from the disabled Region. After Amazon Keyspaces has permanently removed the disabled Region from the multi-Region keyspace, you can't add the disabled Region back. ## Multi-Region replication and integration with point-in-time recovery (PITR) Point-in-time recovery is supported for multi-Region tables. To successfully restore a multi-Region table with PITR, the following conditions have to be met. + The source and the target table must be configured as multi-Region tables. + The replication Regions for the keyspace of the source table and for the keyspace of the target table must be the same. + PITR has to be enabled on all replicas of the source table. You can run the restore statement from any of the Regions that the source table is available in. Amazon Keyspaces automatically restores the target table in each Region. For more information about PITR, see [How point-in-time recovery works in Amazon Keyspaces](PointInTimeRecovery_HowItWorks.md). When you create a multi-Region table, the PITR settings that you define during the creation process are automatically applied to all tables in all Regions. When you change PITR settings using `ALTER TABLE`, Amazon Keyspaces applies the update only to the local table and not to the replicas in other Regions. To enable PITR for an existing multi-Region table, you have to repeat the `ALTER TABLE` statement for all replicas. ## Multi-Region replication and integration with AWS services You can monitor replication performance between tables in different AWS Regions by using Amazon CloudWatch metrics. The following metric provides continuous monitoring of multi-Region keyspaces. + `ReplicationLatency` – This metric measures the time it took to replicate `updates`, `inserts`, or `deletes` from one replica table to another replica table in a multi-Region keyspace. For more information about how to monitor CloudWatch metrics, see [Monitoring Amazon Keyspaces with Amazon CloudWatch](monitoring-cloudwatch.md). # Amazon Keyspaces multi-Region replication usage notes Consider the following when you're using multi-Region replication with Amazon Keyspaces. + You can select any of the [available public](programmatic.endpoints.md#global_endpoints) AWS Regions. For more information about AWS Regions [that are disabled by default](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable), see [Multi-Region replication in AWS Regions disabled by default](multiRegion-replication_how-it-works.md#howitworks_mrr_opt_in). + AWS GovCloud (US) Regions and China Regions are not supported. + Consider the following workarounds until the features become available: Configure Time to Live (TTL) when creating the multi-Region table. You won't be able to enable and disable TTL, or adjust the TTL value later. For more information, see [Expire data with Time to Live (TTL) for Amazon Keyspaces (for Apache Cassandra)](TTL.md). + For encryption at rest, use an AWS owned key. Customer managed keys are currently not supported for multi-Region tables. For more information, see [Encryption at rest: How it works in Amazon Keyspaces](encryption.howitworks.md). + You can use `ALTER KEYSPACE` to add a Region to a single-Region or a multi-Region keyspace. For more information, see [Add an AWS Region to a keyspace in Amazon Keyspaces](keyspaces-multi-region-add-replica.md). + Before adding a Region to a single-Region keyspace, ensure that no tables under the keyspace are configured with customer managed keys. + Any existing tags configured for keyspaces or tables are not replicated to the new Region. + 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 [Update the provisioned capacity and auto scaling settings for a multi-Region table in Amazon Keyspaces](tables-mrr-autoscaling.md). For more information on how to estimate the write capacity throughput of provisioned multi-Region tables, see [Estimate and provision capacity for a multi-Region table in Amazon Keyspaces](tables-multi-region-capacity.md). + 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](monitoring-cloudwatch.md). 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](ReadWriteCapacityMode.OnDemand.md#ReadWriteCapacityMode.PeakTraffic). + 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 AWS 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](autoscaling.md#autoscaling.multi-region). # Configure multi-Region replication for Amazon Keyspaces (for Apache Cassandra) You can use the console, Cassandra Query Language (CQL), or the AWS Command Line Interface to create and manage multi-Region keyspaces and tables in Amazon Keyspaces. This section provides examples of how to create and manage multi-Region keyspaces and tables. All tables that you create in a multi-Region keyspace automatically inherit the multi-Region settings from the keyspace. For more information about supported configurations and features, see [Amazon Keyspaces multi-Region replication usage notes](multiRegion-replication_usage-notes.md). **Topics** + [Configure the IAM permissions required to create multi-Region keyspaces and tables](howitworks_replication_permissions.md) + [Configure the IAM permissions required to add an AWS Region to a keyspace](howitworks_replication_permissions_addReplica.md) + [Create a multi-Region keyspace in Amazon Keyspaces](keyspaces-mrr-create.md) + [Add an AWS Region to a keyspace in Amazon Keyspaces](keyspaces-multi-region-add-replica.md) + [Check the replication progress when adding a new Region to a keyspace](keyspaces-multi-region-replica-status.md) + [Create a multi-Region table with default settings in Amazon Keyspaces](tables-mrr-create-default.md) + [Create a multi-Region table in provisioned mode with auto scaling in Amazon Keyspaces](tables-mrr-create-provisioned.md) + [Update the provisioned capacity and auto scaling settings for a multi-Region table in Amazon Keyspaces](tables-mrr-autoscaling.md) + [View the provisioned capacity and auto scaling settings for a multi-Region table in Amazon Keyspaces](tables-mrr-view.md) + [Turn off auto scaling for a table in Amazon Keyspaces](tables-mrr-autoscaling-off.md) + [Set the provisioned capacity of a multi-Region table manually in Amazon Keyspaces](tables-mrr-capacity-manually.md) # Configure the IAM permissions required to create multi-Region keyspaces and tables To successfully create multi-Region keyspaces and tables, the IAM principal needs to be able to create a service-linked role. This service-linked role is a unique type of IAM role that is predefined by Amazon Keyspaces. It includes all the permissions that Amazon Keyspaces requires to perform actions on your behalf. For more information about the service-linked role, see [Using roles for Amazon Keyspaces Multi-Region Replication](using-service-linked-roles-multi-region-replication.md). To create the service-linked role required by multi-Region replication, the policy for the IAM principal requires the following elements: + `iam:CreateServiceLinkedRole` – The **action** the principal can perform. + `arn:aws:iam::*:role/aws-service-role/replication.cassandra.amazonaws.com/AWSServiceRoleForKeyspacesReplication` – The **resource** that the action can be performed on. + `iam:AWSServiceName": "replication.cassandra.amazonaws.com` – The only AWS service that this role can be attached to is Amazon Keyspaces. The following is an example of the policy that grants the minimum required permissions to a principal to create multi-Region keyspaces and tables. ``` { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/replication.cassandra.amazonaws.com/AWSServiceRoleForKeyspacesReplication", "Condition": {"StringLike": {"iam:AWSServiceName": "replication.cassandra.amazonaws.com"}} } ``` For additional IAM permissions for multi-Region keyspaces and tables, see the [Actions, resources, and condition keys for Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html) in the *Service Authorization Reference*. # Configure the IAM permissions required to add an AWS Region to a keyspace To add a Region to a keyspace, the IAM principal needs the following permissions: + `cassandra:Alter` + `cassandra:AlterMultiRegionResource` + `cassandra:Create` + `cassandra:CreateMultiRegionResource` + `cassandra:Select` + `cassandra:SelectMultiRegionResource` + `cassandra:Modify` + `cassandra:ModifyMultiRegionResource` If the table is configured in provisioned mode with auto scaling enabled, the following additional permissions are needed. + `application-autoscaling:RegisterScalableTarget` + `application-autoscaling:DeregisterScalableTarget` + `application-autoscaling:DescribeScalableTargets` + `application-autoscaling:PutScalingPolicy` + `application-autoscaling:DescribeScalingPolicies` To successfully add a Region to a single-Region keyspace, the IAM principal also needs to be able to create a service-linked role. This service-linked role is a unique type of IAM role that is predefined by Amazon Keyspaces. It includes all the permissions that Amazon Keyspaces requires to perform actions on your behalf. For more information about the service-linked role, see [Using roles for Amazon Keyspaces Multi-Region Replication](using-service-linked-roles-multi-region-replication.md). To create the service-linked role required by multi-Region replication, the policy for the IAM principal requires the following elements: + `iam:CreateServiceLinkedRole` – The **action** the principal can perform. + `arn:aws:iam::*:role/aws-service-role/replication.cassandra.amazonaws.com/AWSServiceRoleForKeyspacesReplication` – The **resource** that the action can be performed on. + `iam:AWSServiceName": "replication.cassandra.amazonaws.com` – The only AWS service that this role can be attached to is Amazon Keyspaces. The following is an example of the policy that grants the minimum required permissions to a principal to add a Region to a keyspace. ``` { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/replication.cassandra.amazonaws.com/AWSServiceRoleForKeyspacesReplication", "Condition": {"StringLike": {"iam:AWSServiceName": "replication.cassandra.amazonaws.com"}} } ``` # Create a multi-Region keyspace in Amazon Keyspaces This section provides examples of how to create a multi-Region keyspace. You can do this on the Amazon Keyspaces console, using CQL or the AWS CLI. All tables that you create in a multi-Region keyspace automatically inherit the multi-Region settings from the keyspace. **Note** When creating a multi-Region keyspace, Amazon Keyspaces creates a service-linked role with the name `AWSServiceRoleForAmazonKeyspacesReplication` in your account. This role allows Amazon Keyspaces to replicate writes to all replicas of a multi-Region table on your behalf. To learn more, see [Using roles for Amazon Keyspaces Multi-Region Replication](using-service-linked-roles-multi-region-replication.md). ------ #### [ Console ] **Create a multi-Region keyspace (console)** 1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home). 1. In the navigation pane, choose **Keyspaces**, and then choose **Create keyspace**. 1. For **Keyspace name**, enter the name for the keyspace. 1. In the **Multi-Region replication** section, you can add the additional Regions that are available in the list. 1. To finish, choose **Create keyspace**. ------ #### [ Cassandra Query Language (CQL) ] **Create a multi-Region keyspace using CQL** 1. To create a multi-Region keyspace, use `NetworkTopologyStrategy` to specify the AWS Regions that the keyspace is going to be replicated in. You must include your current Region and at least one additional Region. All tables in the keyspace inherit the replication strategy from the keyspace. You can't change the replication strategy at the table level. `NetworkTopologyStrategy` – The replication factor for each Region is three because Amazon Keyspaces replicates data across three [Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) within the same AWS Region, by default. The following CQL statement is an example of this. ``` CREATE KEYSPACE mykeyspace WITH REPLICATION = {'class':'NetworkTopologyStrategy', 'us-east-1':'3', 'ap-southeast-1':'3','eu-west-1':'3' }; ``` 1. You can use a CQL statement to query the `tables` table in the `system_multiregion_info` keyspace to programmatically list the Regions and the status of the multi-Region table that you specify. The following code is an example of this. ``` SELECT * from system_multiregion_info.tables WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable'; ``` The output of the statement looks like the following: ``` keyspace_name | table_name | region | status ----------------+----------------+----------------+-------- mykeyspace | mytable | us-east-1 | ACTIVE mykeyspace | mytable | ap-southeast-1 | ACTIVE mykeyspace | mytable | eu-west-1 | ACTIVE ``` ------ #### [ CLI ] **Create a new multi-Region keyspace using the AWS CLI** + To create a multi-Region keyspace, you can use the following CLI statement. Specify your current Region and at least one additional Region in the `regionList`. ``` aws keyspaces create-keyspace --keyspace-name mykeyspace \ --replication-specification replicationStrategy=MULTI_REGION,regionList=us-east-1,eu-west-1 ``` ------ To create a multi-Region table, see [Create a multi-Region table with default settings in Amazon Keyspaces](tables-mrr-create-default.md) and [Create a multi-Region table in provisioned mode with auto scaling in Amazon Keyspaces](tables-mrr-create-provisioned.md). # Add an AWS Region to a keyspace in Amazon Keyspaces You can add a new AWS Region to a keyspace that is either a single or a multi-Region keyspace. The new replica Region is applied to all tables in the keyspace. To change a single-Region to a multi-Region keyspace, you have to enable client-side timestamps for all tables in the keyspace. For more information, see [Client-side timestamps in Amazon Keyspaces](client-side-timestamps.md). If you're adding an additional Region to a multi-Region keyspace, Amazon Keyspaces has to replicate the existing table(s) into the new Region using a one-time cross-Region restore for each existing table. The restore charges for each table are billed per GB, for more information see [Backup and restore](https://aws.amazon.com/keyspaces/pricing/#:~:text=per%20GB-month-,Restoring%20a%20table,-Restoring%20a%20table) on the Amazon Keyspaces (for Apache Cassandra) pricing page. There's no charge for data transfer across Regions for this restore operation. In addition to data, all table properties with the exception of tags are going to be replicated to the new Region. You can use the `ALTER KEYSPACE` statement in CQL, the `update-keyspace` command with the AWS CLI, or the console to add a new Region to a single or to a multi-Region keyspace in Amazon Keyspaces. In order to run the statement successfully, the account you're using has to be located in one of the Regions where the keyspace is already available. While the replica is being added, you can't perform any other data definition language (DDL) operations on the resources that are being updated and replicated. For more information about the permissions required to add a Region, see [Configure the IAM permissions required to add an AWS Region to a keyspace](howitworks_replication_permissions_addReplica.md). **Note** When adding an additional Region to a single-Region keyspace, Amazon Keyspaces creates a service-linked role with the name `AWSServiceRoleForAmazonKeyspacesReplication` in your account. This role allows Amazon Keyspaces to replicate tables to new Regions and to replicate writes from one table to all replicas of a multi-Region table on your behalf. To learn more, see [Using roles for Amazon Keyspaces Multi-Region Replication](using-service-linked-roles-multi-region-replication.md). ------ #### [ Console ] Follow these steps to add a Region to a keyspace using the Amazon Keyspaces console. **Add a Region to a keyspace (console)** 1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home). 1. In the navigation pane, choose **Keyspaces**, and then choose a keyspace from the list. 1. Choose the **AWS Regions** tab. 1. On the **AWS Regions** tab, choose **Add Region**. 1. In the **Add Region** dialog, choose the additional Region that you want to add to the keyspace. 1. To finish, choose **Add**. ------ #### [ Cassandra Query Language (CQL) ] **Add a Region to a keyspace using CQL** + To add a new Region to a keyspace, you can use the following statement. In this example, the keyspace is already available in the US East (N. Virginia) Region and US West (Oregon) Region Regions, and the CQL statement is adding the Region US West (N. California) Region. ``` ALTER KEYSPACE my_keyspace WITH REPLICATION = { 'class': 'NetworkTopologyStrategy', 'us-east-1': '3', 'us-west-2': '3', 'us-west-1': '3' } AND CLIENT_SIDE_TIMESTAMPS = {'status': 'ENABLED'}; ``` ------ #### [ CLI ] **Add a Region to a keyspace using the AWS CLI** + To add a new Region to a keyspace using the CLI, you can use the following example. Note that the default value for `client-side-timestamps` is `DISABLED`. With the `update-keyspace` command, you must change the value to `ENABLED`. ``` aws keyspaces update-keyspace \ --keyspace-name my_keyspace \ --replication-specification '{"replicationStrategy": "MULTI_REGION", "regionList": ["us-east-1", "eu-west-1", "eu-west-3"] }' \ --client-side-timestamps '{"status": "ENABLED"}' ``` ------ # Check the replication progress when adding a new Region to a keyspace Adding a new Region to an Amazon Keyspaces keyspace is a long running operation. To track progress you can use the queries shown in this section. ------ #### [ Cassandra Query Language (CQL) ] **Using CQL to verify the add Region progress** + To verify the progress of the creation of the new table replicas in a given keyspace, you can query the `system_multiregion_info.keyspaces` table. The following CQL statement is an example of this. ``` SELECT keyspace_name, region, status, tables_replication_progress FROM system_multiregion_info.keyspaces WHERE keyspace_name = 'my_keyspace'; ``` While a replication operation is in progress, the status shows the progress of table creation in the new Region. This is an example where 5 out of 10 tables have been replicated to the new Region. ``` keyspace_name | region | status | tables_replication_progress ---------------+-----------+-----------+------------------------- my_keyspace | us-east-1 | Updating | my_keyspace | us-west-2 | Updating | my_keyspace | eu-west-1 | Creating | 50% ``` After the replication process has completed successfully, the output should look like this example. ``` keyspace_name | region | status ---------------+-----------+----------- my_keyspace | us-east-1 | Active my_keyspace | us-west-2 | Active my_keyspace | eu-west-1 | Active ``` ------ #### [ CLI ] **Using the AWS CLI to verify the add Region progress** + To confirm the status of table replica creation for a given keyspace, you can use the following example. ``` aws keyspaces get-keyspace \ --keyspace-name my_keyspace ``` The output should look similar to this example. ``` { "keyspaceName": "my_keyspace", "resourceArn": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/my_keyspace/", "replicationStrategy": "MULTI_REGION", "replicationRegions": [ "us-east-1", "eu-west-1" ] "replicationGroupStatus": [ { "RegionName": "us-east-1", "KeyspaceStatus": "Active" }, { "RegionName": "eu-west-1", "KeyspaceStatus": "Creating", "TablesReplicationProgress": "50.0%" } ] } ``` ------ # Create a multi-Region table with default settings in Amazon Keyspaces This section provides examples of how to create a multi-Region table in on-demand mode with all default settings. You can do this on the Amazon Keyspaces console, using CQL or the AWS CLI. All tables that you create in a multi-Region keyspace automatically inherit the multi-Region settings from the keyspace. To create a multi-Region keyspace, see [Create a multi-Region keyspace in Amazon Keyspaces](keyspaces-mrr-create.md). ------ #### [ Console ] **Create a multi-Region table with default settings (console)** 1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home). 1. Choose a multi-Region keyspace. 1. On the **Tables** tab, choose **Create table**. 1. For **Table name**, enter the name for the table. The AWS Regions that this table is being replicated in are shown in the info box. 1. Continue with the table schema. 1. Under **Table settings**, continue with the **Default settings** option. Note the following default settings for multi-Region tables. + **Capacity mode** – The default capacity mode is **On-demand**. For more information about configuring **provisioned** mode, see [Create a multi-Region table in provisioned mode with auto scaling in Amazon Keyspaces](tables-mrr-create-provisioned.md). + **Encryption key management** – Only the **AWS owned key** option is supported. + **Client-side timestamps** – This feature is required for multi-Region tables. + Choose **Customize settings** if you need to turn on Time to Live (TTL) for the table and all its replicas. **Note** You won't be able to change TTL settings on an existing multi-Region table. 1. To finish, choose **Create table**. ------ #### [ Cassandra Query Language (CQL) ] **Create a multi-Region table in on-demand mode with default settings** + To create a multi-Region table with default settings, you can use the following CQL statement. ``` CREATE TABLE mykeyspace.mytable(pk int, ck int, PRIMARY KEY (pk, ck)) WITH CUSTOM_PROPERTIES = { 'capacity_mode':{ 'throughput_mode':'PAY_PER_REQUEST' }, 'point_in_time_recovery':{ 'status':'enabled' }, 'encryption_specification':{ 'encryption_type':'AWS_OWNED_KMS_KEY' }, 'client_side_timestamps':{ 'status':'enabled' } }; ``` ------ #### [ CLI ] **Using the AWS CLI** 1. To create a multi-Region table with default settings, you only need to specify the schema. You can use the following example. ``` aws keyspaces create-table --keyspace-name mykeyspace --table-name mytable \ --schema-definition 'allColumns=[{name=pk,type=int}],partitionKeys={name= pk}' ``` The output of the command is: ``` { "resourceArn": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable" } ``` 1. To confirm the table's settings, you can use the following statement. ``` aws keyspaces get-table --keyspace-name mykeyspace --table-name mytable ``` The output shows all default settings of a multi-Region table. ``` { "keyspaceName": "mykeyspace", "tableName": "mytable", "resourceArn": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable", "creationTimestamp": "2023-12-19T16:50:37.639000+00:00", "status": "ACTIVE", "schemaDefinition": { "allColumns": [ { "name": "pk", "type": "int" } ], "partitionKeys": [ { "name": "pk" } ], "clusteringKeys": [], "staticColumns": [] }, "capacitySpecification": { "throughputMode": "PAY_PER_REQUEST", "lastUpdateToPayPerRequestTimestamp": "2023-12-19T16:50:37.639000+00:00" }, "encryptionSpecification": { "type": "AWS_OWNED_KMS_KEY" }, "pointInTimeRecovery": { "status": "DISABLED" }, "defaultTimeToLive": 0, "comment": { "message": "" }, "clientSideTimestamps": { "status": "ENABLED" }, "replicaSpecifications": [ { "region": "us-east-1", "status": "ACTIVE", "capacitySpecification": { "throughputMode": "PAY_PER_REQUEST", "lastUpdateToPayPerRequestTimestamp": 1702895811.469 } }, { "region": "eu-north-1", "status": "ACTIVE", "capacitySpecification": { "throughputMode": "PAY_PER_REQUEST", "lastUpdateToPayPerRequestTimestamp": 1702895811.121 } } ] } ``` ------ # Create a multi-Region table in provisioned mode with auto scaling in Amazon Keyspaces This section provides examples of how to create a multi-Region table in provisioned mode with auto scaling. You can do this on the Amazon Keyspaces console, using CQL or the AWS CLI. For more information about supported configurations and multi-Region replication features, see [Amazon Keyspaces multi-Region replication usage notes](multiRegion-replication_usage-notes.md). To create a multi-Region keyspace, see [Create a multi-Region keyspace in Amazon Keyspaces](keyspaces-mrr-create.md). When you create a new multi-Region table in provisioned mode with auto scaling settings, you can specify the general settings for the table that are valid for all AWS Regions that the table is replicated in. You can then overwrite read capacity settings and read auto scaling settings for each replica. The write capacity, however, remains synchronized between all replicas to ensure that there's enough capacity to replicate writes across all Regions. **Note** Amazon Keyspaces automatic scaling requires the presence of a service-linked role (`AWSServiceRoleForApplicationAutoScaling_CassandraTable`) that performs automatic scaling actions on your behalf. This role is created automatically for you. For more information, see [Using service-linked roles for Amazon Keyspaces](using-service-linked-roles.md). ------ #### [ Console ] **Create a new multi-Region table with automatic scaling enabled** 1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home). 1. Choose a multi-Region keyspace. 1. On the **Tables** tab, choose **Create table**. 1. On the **Create table** page in the **Table details** section, select a keyspace and provide a name for the new table. 1. In the **Columns** section, create the schema for your table. 1. In the **Primary key** section, define the primary key of the table and select optional clustering columns. 1. In the **Table settings** section, choose **Customize settings**. 1. Continue to **Read/write capacity settings**. 1. For **Capacity mode**, choose **Provisioned**. 1. In the **Read capacity** section, confirm that **Scale automatically** is selected. You can select to configure the same read capacity units for all AWS Regions that the table is replicated in. Alternatively, you can clear the check box and configure the read capacity for each Region differently. If you choose to configure each Region differently, you select the minimum and maximum read capacity units for each table replica, as well as the target utilization. + **Minimum capacity units** – Enter the value for the minimum level of throughput that the table should always be ready to support. The value must be between 1 and the maximum throughput per second quota for your account (40,000 by default). + **Maximum capacity units** – Enter the maximum amount of throughput that you want to provision for the table. The value must be between 1 and the maximum throughput per second quota for your account (40,000 by default). + **Target utilization** – Enter a target utilization rate between 20% and 90%. When traffic exceeds the defined target utilization rate, capacity is automatically scaled up. When traffic falls below the defined target, it is automatically scaled down again. + Clear the **Scale automatically** check box if you want to provision the table's read capacity manually. This setting applies to all replicas of the table. **Note** To ensure that there's enough read capacity for all replicas, we recommend Amazon Keyspaces automatic scaling for provisioned multi-Region tables. **Note** To learn more about default quotas for your account and how to increase them, see [Quotas for Amazon Keyspaces (for Apache Cassandra)](quotas.md). 1. In the **Write capacity** section, confirm that **Scale automatically** is selected. Then configure the capacity units for the table. The write capacity units stay synced across all AWS Regions to ensure that there is enough capacity to replicate write events across the Regions. + Clear **Scale automatically** if you want to provision the table's write capacity manually. This setting applies to all replicas of the table. **Note** To ensure that there's enough write capacity for all replicas, we recommend Amazon Keyspaces automatic scaling for provisioned multi-Region tables. 1. Choose **Create table**. Your table is created with the specified automatic scaling parameters. ------ #### [ Cassandra Query Language (CQL) ] **Create a multi-Region table with provisioned capacity mode and auto scaling using CQL** + To create a multi-Region table in provisioned mode with auto scaling, you must first specify the capacity mode by defining `CUSTOM_PROPERTIES` for the table. After specifying provisioned capacity mode, you can configure the auto scaling settings for the table using `AUTOSCALING_SETTINGS`. For detailed information about auto scaling settings, the target tracking policy, target value, and optional settings, see [Create a new table with automatic scaling](autoscaling.createTable.md). To define the read capacity for a table replica in a specific Region, you can configure the following parameters as part of the table's `replica_updates`: + The Region + The provisioned read capacity units (optional) + Auto scaling settings for read capacity (optional) The following example shows a `CREATE TABLE` statement for a multi-Region table in provisioned mode. The general write and read capacity auto scaling settings are the same. However, the read auto scaling settings specify additional cooldown periods of 60 seconds before scaling the table's read capacity up or down. In addition, the read capacity auto scaling settings for the Region US East (N. Virginia) are higher than those for other replicas. Also, the target value is set to 70% instead of 50%. ``` CREATE TABLE mykeyspace.mytable(pk int, ck int, PRIMARY KEY (pk, ck)) WITH CUSTOM_PROPERTIES = { 'capacity_mode': { 'throughput_mode': 'PROVISIONED', 'read_capacity_units': 5, 'write_capacity_units': 5 } } AND AUTOSCALING_SETTINGS = { 'provisioned_write_capacity_autoscaling_update': { 'maximum_units': 10, 'minimum_units': 5, 'scaling_policy': { 'target_tracking_scaling_policy_configuration': { 'target_value': 50 } } }, 'provisioned_read_capacity_autoscaling_update': { 'maximum_units': 10, 'minimum_units': 5, 'scaling_policy': { 'target_tracking_scaling_policy_configuration': { 'target_value': 50, 'scale_in_cooldown': 60, 'scale_out_cooldown': 60 } } }, 'replica_updates': { 'us-east-1': { 'provisioned_read_capacity_autoscaling_update': { 'maximum_units': 20, 'minimum_units': 5, 'scaling_policy': { 'target_tracking_scaling_policy_configuration': { 'target_value': 70 } } } } } }; ``` ------ #### [ CLI ] **Create a new multi-Region table in provisioned mode with auto scaling using the AWS CLI** + To create a multi-Region table in provisioned mode with auto scaling configuration, you can use the AWS CLI. Note that you must use the Amazon Keyspaces CLI `create-table` command to configure multi-Region auto scaling settings. This is because Application Auto Scaling, the service that Amazon Keyspaces uses to perform auto scaling on your behalf, doesn't support multiple Regions. For more information about auto scaling settings, the target tracking policy, target value, and optional settings, see [Create a new table with automatic scaling](autoscaling.createTable.md). To define the read capacity for a table replica in a specific Region, you can configure the following parameters as part of the table's `replicaSpecifications`: + The Region + The provisioned read capacity units (optional) + Auto scaling settings for read capacity (optional) When you're creating provisioned multi-Region tables with complex auto scaling settings and different configurations for table replicas, it's helpful to load the table's auto scaling settings and replica configurations from JSON files. To use the following code example, you can download the example JSON files from [auto-scaling.zip](samples/auto-scaling.zip), and extract `auto-scaling.json` and `replication.json`. Take note of the path to the files. In this example, the JSON files are located in the current directory. For different file path options, see [ How to load parameters from a file](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how). ``` aws keyspaces create-table --keyspace-name mykeyspace --table-name mytable \ --schema-definition 'allColumns=[{name=pk,type=int},{name=ck,type=int}],partitionKeys=[{name=pk},{name=ck}]' \ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1 \ --auto-scaling-specification file://auto-scaling.json \ --replica-specifications file://replication.json ``` ------ # Update the provisioned capacity and auto scaling settings for a multi-Region table in Amazon Keyspaces This section includes examples of how to use the console, CQL, and the AWS CLI to manage the Amazon Keyspaces auto scaling settings of provisioned multi-Region tables. For more information about general auto scaling configuration options and how they work, see [Manage throughput capacity automatically with Amazon Keyspaces auto scaling](autoscaling.md). Note that if you're using provisioned capacity mode for multi-Region tables, you must always use Amazon Keyspaces API calls to configure auto scaling. This is because the underlying Application Auto Scaling API operations are not Region-aware. For more information on how to estimate write capacity throughput of provisioned multi-Region tables, see [Estimate and provision capacity for a multi-Region table in Amazon Keyspaces](tables-multi-region-capacity.md). For more information about the Amazon Keyspaces API, see [https://docs.aws.amazon.com/keyspaces/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/keyspaces/latest/APIReference/Welcome.html). When you update the provisioned mode or auto scaling settings of a multi-Region table, you can update read capacity settings and the read auto scaling configuration for each replica of the table. The write capacity, however, remains synchronized between all replicas to ensure that there's enough capacity to replicate writes across all Regions. ------ #### [ Cassandra Query Language (CQL) ] **Update the provisioned capacity and auto scaling settings of a multi-Region table using CQL** + You can use `ALTER TABLE` to update the capacity mode and auto scaling settings of an existing table. If you're updating a table that is currently in on-demand capacity mode, `capacity_mode` is required. If your table is already in provisioned capacity mode, this field can be omitted. For detailed information about auto scaling settings, the target tracking policy, target value, and optional settings, see [Create a new table with automatic scaling](autoscaling.createTable.md). In the same statement, you can also update the read capacity and auto scaling settings of table replicas in specific Regions by updating the table's `replica_updates` property. The following statement is an example of this. ``` ALTER TABLE mykeyspace.mytable WITH CUSTOM_PROPERTIES = { 'capacity_mode': { 'throughput_mode': 'PROVISIONED', 'read_capacity_units': 1, 'write_capacity_units': 1 } } AND AUTOSCALING_SETTINGS = { 'provisioned_write_capacity_autoscaling_update': { 'maximum_units': 10, 'minimum_units': 5, 'scaling_policy': { 'target_tracking_scaling_policy_configuration': { 'target_value': 50 } } }, 'provisioned_read_capacity_autoscaling_update': { 'maximum_units': 10, 'minimum_units': 5, 'scaling_policy': { 'target_tracking_scaling_policy_configuration': { 'target_value': 50, 'scale_in_cooldown': 60, 'scale_out_cooldown': 60 } } }, 'replica_updates': { 'us-east-1': { 'provisioned_read_capacity_autoscaling_update': { 'maximum_units': 20, 'minimum_units': 5, 'scaling_policy': { 'target_tracking_scaling_policy_configuration': { 'target_value': 70 } } } } } }; ``` ------ #### [ CLI ] **Update the provisioned capacity and auto scaling settings of a multi-Region table using the AWS CLI** + To update the provisioned mode and auto scaling configuration of an existing table, you can use the AWS CLI `update-table` command. Note that you must use the Amazon Keyspaces CLI commands to create or modify multi-Region auto scaling settings. This is because Application Auto Scaling, the service that Amazon Keyspaces uses to perform auto scaling of table capacity on your behalf, doesn't support multiple AWS Regions. To update the read capacity for a table replica in a specific Region, you can change one of the following optional parameters of the table's `replicaSpecifications`: + The provisioned read capacity units (optional) + Auto scaling settings for read capacity (optional) When you're updating multi-Region tables with complex auto scaling settings and different configurations for table replicas, it's helpful to load the table's auto scaling settings and replica configurations from JSON files. To use the following code example, you can download the example JSON files from [auto-scaling.zip](samples/auto-scaling.zip), and extract `auto-scaling.json` and `replication.json`. Take note of the path to the files. In this example, the JSON files are located in the current directory. For different file path options, see [ How to load parameters from a file](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how). ``` aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable \ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1 \ --auto-scaling-specification file://auto-scaling.json \ --replica-specifications file://replication.json ``` ------ # View the provisioned capacity and auto scaling settings for a multi-Region table in Amazon Keyspaces You can view a multi-Region table's provisioned capacity and auto scaling settings on the Amazon Keyspaces console, using CQL, or the AWS CLI. This section provides examples of how to do this using CQL and the AWS CLI. ------ #### [ Cassandra Query Language (CQL) ] **View the provisioned capacity and auto scaling settings of a multi-Region table using CQL** + To view the auto scaling configuration of a multi-Region table, use the following command. ``` SELECT * FROM system_multiregion_info.autoscaling WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable'; ``` The output for this command looks like the following: ``` keyspace_name | table_name | region | provisioned_read_capacity_autoscaling_update | provisioned_write_capacity_autoscaling_update ----------------+------------+----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- mykeyspace | mytable | ap-southeast-1 | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 60, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 60}}} | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 0, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 0}}} mykeyspace | mytable | us-east-1 | {'minimum_units': 5, 'maximum_units': 20, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 60, 'disable_scale_in': false, 'target_value': 70, 'scale_in_cooldown': 60}}} | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 0, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 0}}} mykeyspace | mytable | eu-west-1 | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 60, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 60}}} | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 0, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 0}}} ``` ------ #### [ CLI ] **View the provisioned capacity and auto scaling settings of a multi-Region table using the AWS CLI** + To view the auto scaling configuration of a multi-Region table, you can use the `get-table-auto-scaling-settings` operation. The following CLI command is an example of this. ``` aws keyspaces get-table-auto-scaling-settings --keyspace-name mykeyspace --table-name mytable ``` You should see the following output. ``` { "keyspaceName": "mykeyspace", "tableName": "mytable", "resourceArn": "arn:aws:cassandra:us-east-1:777788889999:/keyspace/mykeyspace/table/mytable", "autoScalingSpecification": { "writeCapacityAutoScaling": { "autoScalingDisabled": false, "minimumUnits": 5, "maximumUnits": 10, "scalingPolicy": { "targetTrackingScalingPolicyConfiguration": { "disableScaleIn": false, "scaleInCooldown": 0, "scaleOutCooldown": 0, "targetValue": 50.0 } } }, "readCapacityAutoScaling": { "autoScalingDisabled": false, "minimumUnits": 5, "maximumUnits": 20, "scalingPolicy": { "targetTrackingScalingPolicyConfiguration": { "disableScaleIn": false, "scaleInCooldown": 60, "scaleOutCooldown": 60, "targetValue": 70.0 } } } }, "replicaSpecifications": [ { "region": "us-east-1", "autoScalingSpecification": { "writeCapacityAutoScaling": { "autoScalingDisabled": false, "minimumUnits": 5, "maximumUnits": 10, "scalingPolicy": { "targetTrackingScalingPolicyConfiguration": { "disableScaleIn": false, "scaleInCooldown": 0, "scaleOutCooldown": 0, "targetValue": 50.0 } } }, "readCapacityAutoScaling": { "autoScalingDisabled": false, "minimumUnits": 5, "maximumUnits": 20, "scalingPolicy": { "targetTrackingScalingPolicyConfiguration": { "disableScaleIn": false, "scaleInCooldown": 60, "scaleOutCooldown": 60, "targetValue": 70.0 } } } } }, { "region": "eu-north-1", "autoScalingSpecification": { "writeCapacityAutoScaling": { "autoScalingDisabled": false, "minimumUnits": 5, "maximumUnits": 10, "scalingPolicy": { "targetTrackingScalingPolicyConfiguration": { "disableScaleIn": false, "scaleInCooldown": 0, "scaleOutCooldown": 0, "targetValue": 50.0 } } }, "readCapacityAutoScaling": { "autoScalingDisabled": false, "minimumUnits": 5, "maximumUnits": 10, "scalingPolicy": { "targetTrackingScalingPolicyConfiguration": { "disableScaleIn": false, "scaleInCooldown": 60, "scaleOutCooldown": 60, "targetValue": 50.0 } } } } } ] } ``` ------ # Turn off auto scaling for a table in Amazon Keyspaces This section provides examples of how to turn off auto scaling for a multi-Region table in provisioned capacity mode. You can do this on the Amazon Keyspaces console, using CQL or the AWS CLI. **Important** We recommend using auto scaling for multi-Region tables that use provisioned capacity mode. For more information, see [Estimate and provision capacity for a multi-Region table in Amazon Keyspaces](tables-multi-region-capacity.md). **Note** To delete the service-linked role that Application Auto Scaling uses, you must disable automatic scaling on all tables in the account across all AWS Regions. ------ #### [ Console ] **Turn off Amazon Keyspaces automatic scaling for an existing multi-Region table on the console** 1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home). 1. Choose the table that you want to work with and choose the **Capacity** tab. 1. In the **Capacity settings** section, choose **Edit**. 1. To disable Amazon Keyspaces automatic scaling, clear the **Scale automatically** check box. Disabling automatic scaling deregisters the table as a scalable target with Application Auto Scaling. To delete the service-linked role that Application Auto Scaling uses to access your Amazon Keyspaces table, follow the steps in [Deleting a service-linked role for Amazon Keyspaces](using-service-linked-roles-app-auto-scaling.md#delete-service-linked-role-app-auto-scaling). 1. When the automatic scaling settings are defined, choose **Save**. ------ #### [ Cassandra Query Language (CQL) ] **Turn off auto scaling for a multi-Region table using CQL** + You can use `ALTER TABLE` to turn off auto scaling for an existing table. Note that you can't turn off auto scaling for an individual table replica. In the following example, auto scaling is turned off for the table's read capacity. ``` ALTER TABLE mykeyspace.mytable WITH AUTOSCALING_SETTINGS = { 'provisioned_read_capacity_autoscaling_update': { 'autoscaling_disabled': true } }; ``` ------ #### [ CLI ] **Turn off auto scaling for a multi-Region table using the AWS CLI** + You can use the AWS CLI `update-table` command to turn off auto scaling for an existing table. Note that you can't turn off auto scaling for an individual table replica. In the following example, auto scaling is turned off for the table's read capacity. ``` aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable \ --auto-scaling-specification readCapacityAutoScaling={autoScalingDisabled=true} ``` ------ # Set the provisioned capacity of a multi-Region table manually in Amazon Keyspaces If you have to turn off auto scaling for a multi-Region table, you can provision the table's read capacity for a replica table manually using CQL or the AWS CLI. **Note** We recommend using auto scaling for multi-Region tables that use provisioned capacity mode. For more information, see [Estimate and provision capacity for a multi-Region table in Amazon Keyspaces](tables-multi-region-capacity.md). ------ #### [ Cassandra Query Language (CQL) ] **Setting the provisioned capacity of a multi-Region table manually using CQL** + You can use `ALTER TABLE` to provision the table's read capacity for a replica table manually. ``` ALTER TABLE mykeyspace.mytable WITH CUSTOM_PROPERTIES = { 'capacity_mode': { 'throughput_mode': 'PROVISIONED', 'read_capacity_units': 1, 'write_capacity_units': 1 }, 'replica_updates': { 'us-east-1': { 'read_capacity_units': 2 } } }; ``` ------ #### [ CLI ] **Set the provisioned capacity of a multi-Region table manually using the AWS CLI** + If you have to turn off auto scaling for a multi-Region table, you can use `update-table` to provision the table's read capacity for a replica table manually. ``` aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable \ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1 \ --replica-specifications region="us-east-1",readCapacityUnits=5 ``` ------