# Configure read/write capacity modes in Amazon Keyspaces Amazon Keyspaces has two read/write capacity modes for processing reads and writes on your tables: + On-demand (default) + Provisioned The read/write capacity mode that you choose controls how you are charged for read and write throughput and how table throughput capacity is managed. **Topics** + [Configure on-demand capacity mode](ReadWriteCapacityMode.OnDemand.md) + [Configure provisioned capacity mode](ReadWriteCapacityMode.Provisioned.md) + [View the capacity mode of a table in Amazon Keyspaces](ReadWriteCapacityMode.ProvisionedThroughput.ManagingCapacity.md) + [Change the capacity mode of a table in Amazon Keyspaces](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md) + [Configure pre-warming for tables in Amazon Keyspaces](warm-throughput.md) # Configure on-demand capacity mode Amazon Keyspaces (for Apache Cassandra) *on-demand* capacity mode is a flexible billing option capable of serving thousands of requests per second without capacity planning. This option offers pay-per-request pricing for read and write requests so that you pay only for what you use. When you choose on-demand mode, Amazon Keyspaces can scale the throughput capacity for your table up to any previously reached traffic level instantly, and then back down when application traffic decreases. If a workload’s traffic level hits a new peak, the service adapts rapidly to increase throughput capacity for your table. You can enable on-demand capacity mode for both new and existing tables. On-demand mode is a good option if any of the following is true: + You create new tables with unknown workloads. + You have unpredictable application traffic. + You prefer the ease of paying for only what you use. To get started with on-demand mode, you can create a new table or update an existing table to use on-demand capacity mode using the console or with a few lines of Cassandra Query Language (CQL) code. For more information, see [Tables](cql.ddl.table.md). **Topics** + [Read request units and write request units](#ReadWriteCapacityMode.requests) + [Peak traffic and scaling properties](#ReadWriteCapacityMode.PeakTraffic) + [Initial throughput for on-demand capacity mode](#ReadWriteCapacityMode.InitialThroughput) ## Read request units and write request units With on-demand capacity mode tables, you don't need to specify how much read and write throughput you expect your application to use in advance. Amazon Keyspaces charges you for the reads and writes that you perform on your tables in terms of read request units (RRUs) and write request units (WRUs). + One *RRU* represents one `LOCAL_QUORUM` read request, or two` LOCAL_ONE` read requests, for a row up to 4 KB in size. If you need to read a row that is larger than 4 KB, the read operation uses additional RRUs. The total number of RRUs required depends on the row size, and whether you want to use `LOCAL_QUORUM` or `LOCAL_ONE` read consistency. For example, reading an 8 KB row requires 2 RRUs using `LOCAL_QUORUM` read consistency, and 1 RRU if you choose `LOCAL_ONE` read consistency. + One *WRU* represents one write for a row up to 1 KB in size. All writes are using `LOCAL_QUORUM` consistency, and there is no additional charge for using lightweight transactions (LWTs). If you need to write a row that is larger than 1 KB, the write operation uses additional WRUs. The total number of WRUs required depends on the row size. For example, if your row size is 2 KB, you require 2 WRUs to perform one write request. For information about supported consistency levels, see [Supported Apache Cassandra read and write consistency levels and associated costs](consistency.md). ## Peak traffic and scaling properties Amazon Keyspaces tables that use on-demand capacity mode automatically adapt to your application’s traffic volume. On-demand capacity mode instantly accommodates up to double the previous peak traffic on a table. For example, your application's traffic pattern might vary between 5,000 and 10,000 `LOCAL_QUORUM` reads per second, where 10,000 reads per second is the previous traffic peak. With this pattern, on-demand capacity mode instantly accommodates sustained traffic of up to 20,000 reads per second. If your application sustains traffic of 20,000 reads per second, that peak becomes your new previous peak, enabling subsequent traffic to reach up to 40,000 reads per second. If you need more than double your previous peak on a table, Amazon Keyspaces automatically allocates more capacity as your traffic volume increases. This helps ensure that your table has enough throughput capacity to process the additional requests. However, you might observe insufficient throughput capacity errors if you exceed double your previous peak within 30 minutes. For example, suppose that your application's traffic pattern varies between 5,000 and 10,000 strongly consistent reads per second, where 20,000 reads per second is the previously reached traffic peak. In this case, the service recommends that you space your traffic growth over at least 30 minutes before driving up to 40,000 reads per second. To learn how to estimate read and write capacity consumption of a table, see [Estimate capacity consumption of read and write throughput in Amazon Keyspaces](capacity-examples.md). To learn more about default quotas for your account and how to increase them, see [Quotas for Amazon Keyspaces (for Apache Cassandra)](quotas.md). ## Initial throughput for on-demand capacity mode If you create a new table with on-demand capacity mode enabled or switch an existing table to on-demand capacity mode for the first time, the table has the following previous peak settings, even though it hasn't served traffic previously using on-demand capacity mode: + ** Newly created table with on-demand capacity mode:** The previous peak is 2,000 WRUs and 6,000 RRUs. You can drive up to double the previous peak immediately. Doing this enables newly created on-demand tables to serve up to 4,000 WRUs and 12,000 RRUs. + **Existing table switched to on-demand capacity mode:** The previous peak is half the previous WCUs and RCUs provisioned for the table or the settings for a newly created table with on-demand capacity mode, whichever is higher. # Configure provisioned capacity mode If you choose *provisioned throughput* capacity mode, you specify the number of reads and writes per second that are required for your application. This helps you manage your Amazon Keyspaces usage to stay at or below a defined request rate to maintain predictability. To learn more about automatic scaling for provisioned throughput see [Manage throughput capacity automatically with Amazon Keyspaces auto scaling](autoscaling.md). Provisioned throughput capacity mode is a good option if any of the following is true: + You have predictable application traffic. + You run applications whose traffic is consistent or ramps up gradually. + You can forecast capacity requirements. ## Read capacity units and write capacity units For provisioned throughput capacity mode tables, you specify throughput capacity in terms of read capacity units (RCUs) and write capacity units (WCUs): + One *RCU* represents one `LOCAL_QUORUM` read per second, or two `LOCAL_ONE` reads per second, for a row up to 4 KB in size. If you need to read a row that is larger than 4 KB, the read operation uses additional RCUs. The total number of RCUs required depends on the row size, and whether you want `LOCAL_QUORUM` or `LOCAL_ONE` reads. For example, if your row size is 8 KB, you require 2 RCUs to sustain one `LOCAL_QUORUM` read per second, and 1 RCU if you choose `LOCAL_ONE` reads. + One *WCU* represents one write per second for a row up to 1 KB in size. All writes are using `LOCAL_QUORUM` consistency, and there is no additional charge for using lightweight transactions (LWTs). If you need to write a row that is larger than 1 KB, the write operation uses additional WCUs. The total number of WCUs required depends on the row size. For example, if your row size is 2 KB, you require 2 WCUs to sustain one write request per second. For more information about how to estimate read and write capacity consumption of a table, see [Estimate capacity consumption of read and write throughput in Amazon Keyspaces](capacity-examples.md). If your application reads or writes larger rows (up to the Amazon Keyspaces maximum row size of 1 MB), it consumes more capacity units. To learn more about how to estimate the row size, see [Estimate row size in Amazon Keyspaces](calculating-row-size.md). For example, suppose that you create a provisioned table with 6 RCUs and 6 WCUs. With these settings, your application could do the following: + Perform `LOCAL_QUORUM` reads of up to 24 KB per second (4 KB × 6 RCUs). + Perform `LOCAL_ONE` reads of up to 48 KB per second (twice as much read throughput). + Write up to 6 KB per second (1 KB × 6 WCUs). *Provisioned throughput* is the maximum amount of throughput capacity an application can consume from a table. If your application exceeds your provisioned throughput capacity, you might observe insufficient capacity errors. For example, a read request that doesn’t have enough throughput capacity fails with a `Read_Timeout` exception and is posted to the `ReadThrottleEvents` metric. A write request that doesn’t have enough throughput capacity fails with a `Write_Timeout` exception and is posted to the `WriteThrottleEvents` metric. You can use Amazon CloudWatch to monitor your provisioned and actual throughput metrics and insufficient capacity events. For more information about these metrics, see [Amazon Keyspaces metrics and dimensions](metrics-dimensions.md). **Note** Repeated errors due to insufficient capacity can lead to client-side driver specific exceptions, for example the DataStax Java driver fails with a `NoHostAvailableException`. To change the throughput capacity settings for tables, you can use the AWS Management Console or the `ALTER TABLE` statement using CQL, for more information see [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter). To learn more about default quotas for your account and how to increase them, see [Quotas for Amazon Keyspaces (for Apache Cassandra)](quotas.md). # View the capacity mode of a table in Amazon Keyspaces You can query the system table in the Amazon Keyspaces system keyspace to review capacity mode information about a table. You can also see whether a table is using on-demand or provisioned throughput capacity mode. If the table is configured with provisioned throughput capacity mode, you can see the throughput capacity provisioned for the table. You can also use the AWS CLI to view the capacity mode of a table. To change the provisioned throughput of a table, see [Change the capacity mode of a table in Amazon Keyspaces](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md). ------ #### [ Cassandra Query Language (CQL) ] **Example** ``` SELECT * from system_schema_mcs.tables where keyspace_name = 'mykeyspace' and table_name = 'mytable'; ``` A table configured with on-demand capacity mode returns the following. ``` { "capacity_mode":{ "last_update_to_pay_per_request_timestamp":"1579551547603", "throughput_mode":"PAY_PER_REQUEST" } } ``` A table configured with provisioned throughput capacity mode returns the following. ``` { "capacity_mode":{ "last_update_to_pay_per_request_timestamp":"1579048006000", "read_capacity_units":"5000", "throughput_mode":"PROVISIONED", "write_capacity_units":"6000" } } ``` The `last_update_to_pay_per_request_timestamp` value is measured in milliseconds. ------ #### [ CLI ] View a table's throughput capacity mode using the AWS CLI ``` aws keyspaces get-table --keyspace-name myKeyspace --table-name myTable ``` The output of the command can look similar to this for a table in provisioned capacity mode. ``` "capacitySpecification": { "throughputMode": "PROVISIONED", "readCapacityUnits": 4000, "writeCapacityUnits": 2000 } ``` The output for a table in on-demand mode looks like this. ``` "capacitySpecification": { "throughputMode": "PAY_PER_REQUEST", "lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00" } ``` ------ # Change the capacity mode of a table in Amazon Keyspaces When you switch a table from provisioned capacity mode to on-demand capacity mode, Amazon Keyspaces makes several changes to the structure of your table and partitions. This process can take several minutes. During the switching period, your table delivers throughput that is consistent with the previously provisioned WCU and RCU amounts. When you switch from on-demand capacity mode back to provisioned capacity mode, your table delivers throughput that is consistent with the previous peak reached when the table was set to on-demand capacity mode. The following waiting periods apply when you switch capacity modes: + You can switch a newly created table in on-demand mode to provisioned capacity mode at any time. However, you can only switch it back to on-demand mode 24 hours after the table’s creation timestamp. + You can switch an existing table in on-demand mode to provisioned capacity mode at any time. However, you can switch capacity modes from provisioned to on-demand only once in a 24-hour period. ------ #### [ Cassandra Query Language (CQL) ] **Change a table's throughput capacity mode using CQL** 1. To change a table's capacity mode to `PROVIOSIONED` you have to configure the read capacity and write capacity units based on your workloads expected peak values. the following statement is an example of this. You can also run this statement to adjust the read capacity or the write capacity units of the table. ``` ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 6000, 'write_capacity_units': 3000}}; ``` To configure provisioned capacity mode with auto-scaling, see [Configure automatic scaling on an existing table](autoscaling.configureTable.md). 1. To change the capacity mode of a table to on-demand mode, set the throughput mode to `PAY_PER_REQUEST`. The following statement is an example of this. ``` ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PAY_PER_REQUEST'}}; ``` 1. You can use the following statement to confirm the table's capacity mode. ``` SELECT * from system_schema_mcs.tables where keyspace_name = 'catalog' and table_name = 'book_awards'; ``` A table configured with on-demand capacity mode returns the following. ``` { "capacity_mode":{ "last_update_to_pay_per_request_timestamp":"1727952499092", "throughput_mode":"PAY_PER_REQUEST" } } ``` The `last_update_to_pay_per_request_timestamp` value is measured in milliseconds. ------ #### [ CLI ] **Change a table's throughput capacity mode using the AWS CLI** 1. To change the table's capacity mode to `PROVIOSIONED` you have to configure the read capacity and write capacity units based on the expected peak values of your workload. The following command is an example of this. You can also run this command to adjust the read capacity or the write capacity units of the table. ``` aws keyspaces update-table --keyspace-name catalog --table-name book_awards \--capacity-specification throughputMode=PROVISIONED,readCapacityUnits=6000,writeCapacityUnits=3000 ``` To configure provisioned capacity mode with auto-scaling, see [Configure automatic scaling on an existing table](autoscaling.configureTable.md). 1. To change the capacity mode of a table to on-demand mode, you set the throughput mode to `PAY_PER_REQUEST`. The following statement is an example of this. ``` aws keyspaces update-table --keyspace-name catalog --table-name book_awards \--capacity-specification throughputMode=PAY_PER_REQUEST ``` 1. You can use the following command to review the capacity mode that's configured for a table. ``` aws keyspaces get-table --keyspace-name catalog --table-name book_awards ``` The output for a table in on-demand mode looks like this. ``` "capacitySpecification": { "throughputMode": "PAY_PER_REQUEST", "lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00" } ``` ------ # Configure pre-warming for tables in Amazon Keyspaces Amazon Keyspaces automatically scales storage partitions based on on-demand or provisioned throughput, but for new tables or sudden throughput peaks, it can take longer to allocate the required storage partitions. To insure that a new or existing table has enough capacity to support anticipated peak throughput, you can manually set specific *warm throughput* values to *pre-warm* your table. *Warm throughput* refers to the number of read and write operations your Amazon Keyspaces table can instantaneously support. These values are available by default for all new and existing tables. If you are using on-demand mode, or if you update your provisioned throughput, Amazon Keyspaces ensures that your application is able to issue requests up to those values instantly. Amazon Keyspaces automatically adjusts warm throughput values as your usage increases. To adjust throughput capacity for upcoming peak events, for example when you're migrating data from another database, which may require loading terabytes of data in a short period of time, you can manually increase your tables warm throughput values. This is useful for planned peak events where request rates might increase by 10x, 100x, or more. First, assess whether the current warm throughput is sufficient to handle the expected traffic. Then, if you need to pre-warm the table for the planned peak workload, you can increase the warm throughput value manually without changing your throughput settings or [capacity mode](ReadWriteCapacityMode.md). You can pre-warm tables for read operations, write operations, or both. You can increase this value for new and existing single-Region tables and multi-Region tables and the warm throughput settings you set apply automatically to all replicas of the multi-Region tables. There is no limit to the number of Amazon Keyspaces tables you can pre-warm at any time. The time to complete pre-warming depends on the values you set and the size of the table. You can submit simultaneous pre-warm requests and these requests don't interfere with any table operations. You can pre-warm your table up to the table quota limit for your account in that Region. Use the [Service Quotas console](https://console.aws.amazon.com/servicequotas) to check your current quotas and increase them if needed. The warm throughput values that Amazon Keyspaces adjusts based on your on-demand usage or provisioned capacity are available by default for all tables without additional charges. However, if you manually increase the default warm throughput values to pre-warm tables for peak traffic events, additional charges apply. For more information, see [Amazon Keyspaces pricing](https://aws.amazon.com/keyspaces/pricing/). Here are some different scenarios and best practices you might consider when pre-warming Amazon Keyspaces tables. ## Warm throughput and uneven access patterns A table might have a warm throughput of 30,000 read units per second and 10,000 write units per second, but you could still experience capacity exceeded events on reads or writes before hitting those values. This is likely due to a hot partition. While Amazon Keyspaces can keep scaling to support virtually unlimited throughput, each individual partition is limited to 1,000 write units per second and 3,000 read units per second. If your application drives too much traffic to a small portion of the table’s partitions, capacity exceeded events can occur even before you reach the table's warm throughput values. We recommend following [Amazon Keyspaces best practices](bp-partition-key-design.md) to ensure seamless scalability and avoid hot partitions. ## Warm throughput for a provisioned table Consider a provisioned table that has a warm throughput of 30,000 read units per second and 10,000 write units per second but currently has a provisioned throughput of 4,000 RCUs and 8,000 WCUs. You can instantly scale the table's provisioned throughput up to 30,000 RCUs or 10,000 WCUs by updating your provisioned throughput settings. As you increase the provisioned throughput beyond these values, the warm throughput adjusts automatically to the new higher values, because you have established a new peak throughput. For example, if you set the provisioned throughput to 50,000 RCU, the warm throughput increases to 50,000 read units per second. ``` "ProvisionedThroughput": { "ReadCapacityUnits": 4000, "WriteCapacityUnits": 8000 } "WarmThroughput": { "ReadUnitsPerSecond": 30000, "WriteUnitsPerSecond": 10000 } ``` ## Warm throughput for an on-demand table A new on-demand table starts with a warm throughput of 12,000 read units per second and 4,000 write units per second. Your table can instantly accommodate sustained traffic up to these levels. When your requests exceed 12,000 read units per second or 4,000 write units per second, the warm throughput adjusts automatically to the higher values. ``` "WarmThroughput": { "ReadUnitsPerSecond": 12000, "WriteUnitsPerSecond": 4000 } ``` ## Best practices for pre-warming Amazon Keyspaces tables Follow these best practices when implementing pre-warming for your Amazon Keyspaces tables: Accurately estimate the required capacity Because pre-warming incurs a one-time cost, carefully calculate the throughput needed based on expected workload to avoid over-provisioning. Consider the table's schema Tables with larger rows may require more partitions for the same throughput. Factor in your average row size when estimating pre-warming requirements. Monitor table performance After pre-warming, use CloudWatch metrics to verify that your table is handling the load as expected. For more information, see [Monitor the performance of a pre-warmed table using Amazon CloudWatch](monitor-prewarming-cloudwatch.md). Manage quotas If your application requires higher throughput than the default quotas allow (40,000 RCUs/WCUs or 2,000 partitions), request quota increases well in advance of your high-traffic event. To request a quota increase, use the [Service Quotas console](https://console.aws.amazon.com/servicequotas). Optimize costs For temporary high-traffic events, consider using pre-warming instead of switching to provisioned mode with high capacity, as it may be more cost-effective for short duration events. For more information about pricing, see [Amazon Keyspaces pricing](https://aws.amazon.com/keyspaces/pricing/). **Note** Monitor your application's performance metrics during the test phase to validate that your pre-warming configuration adequately supports your workload requirements. **Topics** + [Warm throughput and uneven access patterns](#warm-throughput-scenarios-uneven) + [Warm throughput for a provisioned table](#warm-throughput-scenarios-provisioned) + [Warm throughput for an on-demand table](#warm-throughput-scenarios-ondemand) + [Best practices for pre-warming Amazon Keyspaces tables](#prewarming-best-practices) + [Create a new Amazon Keyspaces table with higher warm throughput](create-table-warm-throughput.md) + [Increase your existing Amazon Keyspaces table's warm throughput](update-warm-throughput.md) + [View warm throughput of an Amazon Keyspaces table](view-warm-throughput.md) + [Monitor the performance of a pre-warmed table using Amazon CloudWatch](monitor-prewarming-cloudwatch.md) # Create a new Amazon Keyspaces table with higher warm throughput You can adjust the warm throughput values when you create your Amazon Keyspaces table by using the console, CQL, or the AWS CLI. ------ #### [ Console ] **How to create a new table with warm-throughput settings** 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 **Tables**, and then 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**, you can choose either **On-demand** or **Provisioned**. 1. In the **Pre-warming for tables** section, you can increase the values for **Read units per second** and **Write units per second** as needed to prepare your table to handle planned peak events. The warm throughput values that Amazon Keyspaces adjusts based on your on-demand usage or provisioned capacity are available by default for all tables without additional charges. Note that if you manually increase the default warm throughput values to pre-warm the table for peak traffic events, additional charges apply. 1. Configure other optional table features as needed. Then choose **Create table**. ------ #### [ Cassandra Query Language (CQL) ] + Create a table with warm throughput using one of the following methods: + For provisioned mode, create a table and specify the expected peak capacity for reads and writes using the following CQL syntax: ``` CREATE TABLE catalog.book_awards ( year int, award text, rank int, category text, book_title text, author text, publisher text, PRIMARY KEY ((year, award), category, rank)) WITH CUSTOM_PROPERTIES = { 'capacity_mode': { 'throughput_mode': 'PROVISIONED', 'read_capacity_units': 20000, 'write_capacity_units': 10000 }, 'warm_throughput': { 'read_units_per_second': 40000, 'write_units_per_second': 20000 } }; ``` + For on-demand mode, create a table and specify the expected peak capacity for reads and writes using the following CQL syntax: ``` CREATE TABLE catalog.book_awards ( year int, award text, rank int, category text, book_title text, author text, publisher text, PRIMARY KEY ((year, award), category, rank)) WITH CUSTOM_PROPERTIES = { 'capacity_mode': { 'throughput_mode': 'PAY_PER_REQUEST' }, 'warm_throughput': { 'read_units_per_second': 40000, 'write_units_per_second': 20000 } }; ``` To confirm the capacity settings of the table, see [View warm throughput of an Amazon Keyspaces table](view-warm-throughput.md). ------ #### [ CLI ] 1. Create a table with warm throughput using one of the following methods using the AWS CLI + Create a new table in provisioned mode and specify the expected peak capacity values for reads and writes for the new table. The following statement is an example of this. ``` aws keyspaces create-table \ --keyspace-name 'catalog' \ --table-name 'book_awards' \ --schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=20000,writeCapacityUnits=10000 \ --warm-throughput-specification readUnitsPerSecond=40000,writeUnitsPerSecond=20000 ``` + Create a new table in on-demand mode and specify the expected peak capacity values for reads and writes for the new table. The following statement is an example of this. ``` aws keyspaces create-table \ --keyspace-name 'catalog' \ --table-name 'book_awards' \ --schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \ --warmThroughputSpecification readUnitsPerSecond=40000,writeUnitsPerSecond=20000 ``` 1. The output of the command returns the ARN of the table as shown in the following example. ``` { "resourceArn": "arn:aws::cassandra:us-east-1:111122223333:/keyspace/catalog/table/book_awards>" } ``` To confirm the capacity settings of the table, see [View warm throughput of an Amazon Keyspaces table](view-warm-throughput.md). ------ #### [ Java ] **Create a new table using the SDK for Java.** + Create a new table in provisioned mode and specify the expected peak capacity values for reads and writes for the new table. The following code example is an example of this. ``` import software.amazon.awssdk.services.keyspaces.KeyspacesClient; import software.amazon.awssdk.services.keyspaces.model.*; public class PreWarmingExample { public static void main(String[] args) { KeyspacesClient keyspacesClient = KeyspacesClient.builder().build(); // Define schema List columns = Arrays.asList( ColumnDefinition.builder().name("year").type("int").build(), ColumnDefinition.builder().name("award").type("text").build(), ColumnDefinition.builder().name("rank").type("int").build(), ColumnDefinition.builder().name("category").type("text").build(), ColumnDefinition.builder().name("book_title").type("text").build(), ColumnDefinition.builder().name("author").type("text").build(), ColumnDefinition.builder().name("publisher").type("text").build() ); List partitionKeys = Arrays.asList( PartitionKey.builder().name("year").build(), PartitionKey.builder().name("award").build() ); List clusteringKeys = Arrays.asList( ClusteringKey.builder().name("category").orderBy("ASC").build(), ClusteringKey.builder().name("rank").orderBy("ASC").build() ); SchemaDefinition schema = SchemaDefinition.builder() .allColumns(columns) .partitionKeys(partitionKeys) .clusteringKeys(clusteringKeys) .build(); // Define capacity specification CapacitySpecification capacitySpec = CapacitySpecification.builder() .throughputMode(ThroughputMode.PROVISIONED) .readCapacityUnits(20000) .writeCapacityUnits(10000) .build(); // Define warm throughput specification WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder() .readUnitsPerSecond(40000L) .writeUnitsPerSecond(20000L) .build(); // Create table with PreWarming CreateTableRequest request = CreateTableRequest.builder() .keyspaceName("catalog") .tableName("book_awards") .schemaDefinition(schema) .capacitySpecification(capacitySpec) .warmThroughputSpecification(warmThroughput) .build(); CreateTableResponse response = keyspacesClient.createTable(request); System.out.println("Table created with ARN: " + response.resourceArn()); } } ``` ------ # Increase your existing Amazon Keyspaces table's warm throughput You can increase your Amazon Keyspaces table's current warm throughput values using the console, CQL, or the AWS CLI. ------ #### [ Console ] **How to increase pre-warm settings of a table using 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. In the navigation pane, choose **Tables**, and then choose the table that you want to update. 1. On the **Capacity** tab of the table, continue to **Pre-warming for tables**. 1. In the **Pre-warming for tables** section, choose **Edit**. 1. On the **Edit pre-warming for tables** page, you can updated the values for **Read units per second** and for **Write units per second**. 1. Choose **Save changes**. Your table is getting updated with the specified pre-warming settings. ------ #### [ Cassandra Query Language (CQL) ] **Increase the warm throughput settings of a table using CQL** + Use the `ALTER TABLE`statement to increase warm-throughput of a table. The following statement is an example of this. ``` ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES = { 'warm_throughput': { 'read_units_per_second': 60000, 'write_units_per_second': 30000 } }; ``` To confirm the updated capacity settings of the table, see [View warm throughput of an Amazon Keyspaces table](view-warm-throughput.md). ------ #### [ CLI ] **Increase the pre-warming settings of a table using the AWS CLI** + To increase the warm-throughput of table, you can use the `update-table` command. The following statement is an example of this. ``` aws keyspaces update-table \ --keyspace-name 'catalog' \ --table-name 'book_awards' \ --warmThroughputSpecification readUnitsPerSecond=60000,writeUnitsPerSecond=30000 ``` To confirm the updated capacity settings of the table, see [View warm throughput of an Amazon Keyspaces table](view-warm-throughput.md). ------ #### [ Java ] **Update the pre-warming settings of a table using the SDK for Java.** + Update the warm-throughput settings for a table. The following code example is an example of this. ``` import software.amazon.awssdk.services.keyspaces.KeyspacesClient; import software.amazon.awssdk.services.keyspaces.model.*; public class UpdatePreWarmingExample { public static void main(String[] args) { KeyspacesClient keyspacesClient = KeyspacesClient.builder().build(); // Define new warm throughput specification WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder() .readUnitsPerSecond(60000L) .writeUnitsPerSecond(30000L) .build(); // Update table with new PreWarming settings UpdateTableRequest request = UpdateTableRequest.builder() .keyspaceName("catalog") .tableName("book_awards") .warmThroughputSpecification(warmThroughput) .build(); UpdateTableResponse response = keyspacesClient.updateTable(request); System.out.println("Table update requested: " + response.resourceArn()); } } ``` ------ # View warm throughput of an Amazon Keyspaces table You can view your Amazon Keyspaces table's current warm throughput values using the console, CQL, or the AWS CLI. ------ #### [ Console ] **How to view your table's pre-warming settings using 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. In the navigation pane, choose **Tables**, and then choose the table that you want to review. 1. On the **Capacity** tab of the table, continue to **Pre-warming for tables**. ------ #### [ Cassandra Query Language (CQL) ] **View the warm-throughput settings of a table using CQL** + To view the warm-throughput settings of a table, you can use the following CQL statement. ``` SELECT custom_properties FROM system_schema_mcs.tables WHERE keyspace_name='catalog' and table_name='book_awards'; // Output: ... custom_properties ---------------------------------------------------------------------------------- { 'warm_throughput': { 'read_units_per_second': '40000', 'write_units_per_second': '20000', 'status': 'AVAILABLE' } } ... ``` ------ #### [ CLI ] **View the warm-throughput settings of a table using the AWS CLI** + You can view the warm-throughput settings of a table using the `get-table` command as shown in the following example. ``` aws keyspaces get-table \ --keyspace-name 'catalog' \ --table-name 'book_awards' ``` The following is showing the example output of the `get-table` command for a single-Region table in provisioned mode. ``` { "keyspaceName": "catalog", "tableName": "book_awards", ... Existing Fields ..., "capacitySpecificationSummary": { "throughputMode": "PROVISIONED", "readCapacityUnits": 20000, "writeCapacityUnits": 10000 }, "warmThroughputSpecificationSummary": { "readUnitsPerSecond": 40000, "writeUnitsPerSecond": 20000, "status": "AVAILABLE" } } ``` The following is showing the example output for a single-Region table in on-demand mode. ``` { "keyspaceName": "catalog", "tableName": "book_awards_ondemand", ... Existing Fields ..., "capacitySpecification": { "throughputMode": "PAY_PER_REQUEST" }, "warmThroughputSpecificationSummary": { "readUnitsPerSecond": 40000, "writeUnitsPerSecond": 20000, "status": "AVAILABLE" } } ``` ------ #### [ Java ] **Read the pre-warming settings of a table using the SDK for Java.** + Read the warm-throughput values of a table using `get-table`. The following code example is an example of this. ``` import software.amazon.awssdk.services.keyspaces.KeyspacesClient; import software.amazon.awssdk.services.keyspaces.model.*; public class GetTableWithPreWarmingExample { public static void main(String[] args) { KeyspacesClient keyspacesClient = KeyspacesClient.builder().build(); // Get table details including PreWarming specification GetTableRequest request = GetTableRequest.builder() .keyspaceName("catalog") .tableName("book_awards") .build(); GetTableResponse response = keyspacesClient.getTable(request); // Access PreWarming details if (response.warmThroughputSpecification() != null) { WarmThroughputSpecificationSummary warmThroughputSummary = response.warmThroughputSpecification(); System.out.println("PreWarming Status: " + warmThroughputSummary.status()); System.out.println("Read Units: " + warmThroughputSummary.readUnitsPerSecond()); System.out.println("Write Units: " + warmThroughputSummary.writeUnitsPerSecond()); // Check if PreWarming is active if (warmThroughputSummary.status().equals("AVAILABLE")) { System.out.println("Table is fully pre-warmed and ready for high throughput"); } else if (warmThroughputSummary.status().equals("UPDATING")) { System.out.println("Table PreWarming is currently being updated"); } } else { System.out.println("Table does not have PreWarming enabled"); } } } ``` ------ # Monitor the performance of a pre-warmed table using Amazon CloudWatch Amazon Keyspaces pre-warming doesn't introduce new CloudWatch metrics, but you can monitor the performance of pre-warmed tables using existing Amazon Keyspaces metrics: SuccessfulRequestLatency Monitor this metric to verify that the pre-warmed table is handling requests with expected latency. WriteThrottleEvents and ReadThrottleEvents These metrics should remain low for a properly pre-warmed table. If you see insufficient capacity errors despite pre-warming, you might need to adjust your warm-throughput values. ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits These metrics show the actual consumption of capacity, which can help validate if your pre-warming configuration is appropriate. ProvisionedReadCapacityUnits and ProvisionedWriteCapacityUnits For provisioned tables, these metrics show the currently allocated capacity. These metrics can be viewed in the CloudWatch console or queried using the CloudWatch API. For more information, see [Monitoring Amazon Keyspaces with Amazon CloudWatch](monitoring-cloudwatch.md).