aws-native.dynamodb.GlobalTable

Specifies the list of replicas for your global table. The list must contain at least one element, the region where the stack defining the global table is deployed. For example, if you define your table in a stack deployed to us-east-1, you must have an entry in Replicas with the region us-east-1. You cannot remove the replica in the stack region.

Adding a replica might take a few minutes for an empty table, or up to several hours for large tables. If you want to add or remove a replica, we recommend submitting an UpdateStack operation containing only that change.

If you add or delete a replica during an update, we recommend that you don't update any other resources. If your stack fails to update and is rolled back while adding a new replica, you might need to manually delete the replica.

You can create a new global table with as many replicas as needed. You can add or remove replicas after table creation, but you can only add or remove a single replica in each update.

Specifies how you are charged for read and write throughput and how you manage capacity. Valid values are:

• PAY_PER_REQUEST
• PROVISIONED

All replicas in your global table will have the same billing mode. If you use PROVISIONED billing mode, you must provide an auto scaling configuration via the WriteProvisionedThroughputSettings property. The default value of this property is PROVISIONED .

Global secondary indexes to be created on the global table. You can create up to 20 global secondary indexes. Each replica in your global table will have the same global secondary index settings. You can only create or delete one global secondary index in a single stack operation.

Since the backfilling of an index could take a long time, CloudFormation does not wait for the index to become active. If a stack operation rolls back, CloudFormation might not delete an index that has been added. In that case, you will need to delete the index manually.

A name for the global table. If you don't specify a name, AWS CloudFormation generates a unique ID and uses that ID as the table name. For more information, see Name type .

If you specify a name, you cannot perform updates that require replacement of this resource. You can perform updates that require no or some interruption. If you must replace the resource, specify a new name.

Specifies the list of replicas for your global table. The list must contain at least one element, the region where the stack defining the global table is deployed. For example, if you define your table in a stack deployed to us-east-1, you must have an entry in Replicas with the region us-east-1. You cannot remove the replica in the stack region.

Adding a replica might take a few minutes for an empty table, or up to several hours for large tables. If you want to add or remove a replica, we recommend submitting an UpdateStack operation containing only that change.

If you add or delete a replica during an update, we recommend that you don't update any other resources. If your stack fails to update and is rolled back while adding a new replica, you might need to manually delete the replica.

You can create a new global table with as many replicas as needed. You can add or remove replicas after table creation, but you can only add or remove a single replica in each update.

Specifies how you are charged for read and write throughput and how you manage capacity. Valid values are:

• PAY_PER_REQUEST
• PROVISIONED

All replicas in your global table will have the same billing mode. If you use PROVISIONED billing mode, you must provide an auto scaling configuration via the WriteProvisionedThroughputSettings property. The default value of this property is PROVISIONED .

Global secondary indexes to be created on the global table. You can create up to 20 global secondary indexes. Each replica in your global table will have the same global secondary index settings. You can only create or delete one global secondary index in a single stack operation.

Since the backfilling of an index could take a long time, CloudFormation does not wait for the index to become active. If a stack operation rolls back, CloudFormation might not delete an index that has been added. In that case, you will need to delete the index manually.

A name for the global table. If you don't specify a name, AWS CloudFormation generates a unique ID and uses that ID as the table name. For more information, see Name type .

If you specify a name, you cannot perform updates that require replacement of this resource. You can perform updates that require no or some interruption. If you must replace the resource, specify a new name.

Specifies the list of replicas for your global table. The list must contain at least one element, the region where the stack defining the global table is deployed. For example, if you define your table in a stack deployed to us-east-1, you must have an entry in Replicas with the region us-east-1. You cannot remove the replica in the stack region.

Adding a replica might take a few minutes for an empty table, or up to several hours for large tables. If you want to add or remove a replica, we recommend submitting an UpdateStack operation containing only that change.

If you add or delete a replica during an update, we recommend that you don't update any other resources. If your stack fails to update and is rolled back while adding a new replica, you might need to manually delete the replica.

You can create a new global table with as many replicas as needed. You can add or remove replicas after table creation, but you can only add or remove a single replica in each update.

Specifies how you are charged for read and write throughput and how you manage capacity. Valid values are:

• PAY_PER_REQUEST
• PROVISIONED

All replicas in your global table will have the same billing mode. If you use PROVISIONED billing mode, you must provide an auto scaling configuration via the WriteProvisionedThroughputSettings property. The default value of this property is PROVISIONED .

Global secondary indexes to be created on the global table. You can create up to 20 global secondary indexes. Each replica in your global table will have the same global secondary index settings. You can only create or delete one global secondary index in a single stack operation.

Since the backfilling of an index could take a long time, CloudFormation does not wait for the index to become active. If a stack operation rolls back, CloudFormation might not delete an index that has been added. In that case, you will need to delete the index manually.

A name for the global table. If you don't specify a name, AWS CloudFormation generates a unique ID and uses that ID as the table name. For more information, see Name type .

If you specify a name, you cannot perform updates that require replacement of this resource. You can perform updates that require no or some interruption. If you must replace the resource, specify a new name.

Specifies the list of replicas for your global table. The list must contain at least one element, the region where the stack defining the global table is deployed. For example, if you define your table in a stack deployed to us-east-1, you must have an entry in Replicas with the region us-east-1. You cannot remove the replica in the stack region.

Adding a replica might take a few minutes for an empty table, or up to several hours for large tables. If you want to add or remove a replica, we recommend submitting an UpdateStack operation containing only that change.

If you add or delete a replica during an update, we recommend that you don't update any other resources. If your stack fails to update and is rolled back while adding a new replica, you might need to manually delete the replica.

You can create a new global table with as many replicas as needed. You can add or remove replicas after table creation, but you can only add or remove a single replica in each update.

Specifies how you are charged for read and write throughput and how you manage capacity. Valid values are:

• PAY_PER_REQUEST
• PROVISIONED

All replicas in your global table will have the same billing mode. If you use PROVISIONED billing mode, you must provide an auto scaling configuration via the WriteProvisionedThroughputSettings property. The default value of this property is PROVISIONED .

Global secondary indexes to be created on the global table. You can create up to 20 global secondary indexes. Each replica in your global table will have the same global secondary index settings. You can only create or delete one global secondary index in a single stack operation.

Since the backfilling of an index could take a long time, CloudFormation does not wait for the index to become active. If a stack operation rolls back, CloudFormation might not delete an index that has been added. In that case, you will need to delete the index manually.

A name for the global table. If you don't specify a name, AWS CloudFormation generates a unique ID and uses that ID as the table name. For more information, see Name type .

If you specify a name, you cannot perform updates that require replacement of this resource. You can perform updates that require no or some interruption. If you must replace the resource, specify a new name.

Specifies the list of replicas for your global table. The list must contain at least one element, the region where the stack defining the global table is deployed. For example, if you define your table in a stack deployed to us-east-1, you must have an entry in Replicas with the region us-east-1. You cannot remove the replica in the stack region.

Adding a replica might take a few minutes for an empty table, or up to several hours for large tables. If you want to add or remove a replica, we recommend submitting an UpdateStack operation containing only that change.

If you add or delete a replica during an update, we recommend that you don't update any other resources. If your stack fails to update and is rolled back while adding a new replica, you might need to manually delete the replica.

You can create a new global table with as many replicas as needed. You can add or remove replicas after table creation, but you can only add or remove a single replica in each update.

Specifies how you are charged for read and write throughput and how you manage capacity. Valid values are:

• PAY_PER_REQUEST
• PROVISIONED

All replicas in your global table will have the same billing mode. If you use PROVISIONED billing mode, you must provide an auto scaling configuration via the WriteProvisionedThroughputSettings property. The default value of this property is PROVISIONED .

Global secondary indexes to be created on the global table. You can create up to 20 global secondary indexes. Each replica in your global table will have the same global secondary index settings. You can only create or delete one global secondary index in a single stack operation.

Since the backfilling of an index could take a long time, CloudFormation does not wait for the index to become active. If a stack operation rolls back, CloudFormation might not delete an index that has been added. In that case, you will need to delete the index manually.

A name for the global table. If you don't specify a name, AWS CloudFormation generates a unique ID and uses that ID as the table name. For more information, see Name type .

If you specify a name, you cannot perform updates that require replacement of this resource. You can perform updates that require no or some interruption. If you must replace the resource, specify a new name.

Specifies the list of replicas for your global table. The list must contain at least one element, the region where the stack defining the global table is deployed. For example, if you define your table in a stack deployed to us-east-1, you must have an entry in Replicas with the region us-east-1. You cannot remove the replica in the stack region.

Adding a replica might take a few minutes for an empty table, or up to several hours for large tables. If you want to add or remove a replica, we recommend submitting an UpdateStack operation containing only that change.

If you add or delete a replica during an update, we recommend that you don't update any other resources. If your stack fails to update and is rolled back while adding a new replica, you might need to manually delete the replica.

You can create a new global table with as many replicas as needed. You can add or remove replicas after table creation, but you can only add or remove a single replica in each update.

Specifies how you are charged for read and write throughput and how you manage capacity. Valid values are:

• PAY_PER_REQUEST
• PROVISIONED

All replicas in your global table will have the same billing mode. If you use PROVISIONED billing mode, you must provide an auto scaling configuration via the WriteProvisionedThroughputSettings property. The default value of this property is PROVISIONED .

Global secondary indexes to be created on the global table. You can create up to 20 global secondary indexes. Each replica in your global table will have the same global secondary index settings. You can only create or delete one global secondary index in a single stack operation.

Since the backfilling of an index could take a long time, CloudFormation does not wait for the index to become active. If a stack operation rolls back, CloudFormation might not delete an index that has been added. In that case, you will need to delete the index manually.

A name for the global table. If you don't specify a name, AWS CloudFormation generates a unique ID and uses that ID as the table name. For more information, see Name type .

If you specify a name, you cannot perform updates that require replacement of this resource. You can perform updates that require no or some interruption. If you must replace the resource, specify a new name.

The ARN of the DynamoDB stream, such as arn:aws:dynamodb:us-east-1:123456789012:table/testddbstack-myDynamoDBTable-012A1SL7SMP5Q/stream/2015-11-30T20:10:00.000 . The StreamArn returned is that of the replica in the region the stack is deployed to.

You must specify the StreamSpecification property to use this attribute.

The ARN of the DynamoDB stream, such as arn:aws:dynamodb:us-east-1:123456789012:table/testddbstack-myDynamoDBTable-012A1SL7SMP5Q/stream/2015-11-30T20:10:00.000 . The StreamArn returned is that of the replica in the region the stack is deployed to.

You must specify the StreamSpecification property to use this attribute.

The ARN of the DynamoDB stream, such as arn:aws:dynamodb:us-east-1:123456789012:table/testddbstack-myDynamoDBTable-012A1SL7SMP5Q/stream/2015-11-30T20:10:00.000 . The StreamArn returned is that of the replica in the region the stack is deployed to.

You must specify the StreamSpecification property to use this attribute.

The ARN of the DynamoDB stream, such as arn:aws:dynamodb:us-east-1:123456789012:table/testddbstack-myDynamoDBTable-012A1SL7SMP5Q/stream/2015-11-30T20:10:00.000 . The StreamArn returned is that of the replica in the region the stack is deployed to.

You must specify the StreamSpecification property to use this attribute.

The ARN of the DynamoDB stream, such as arn:aws:dynamodb:us-east-1:123456789012:table/testddbstack-myDynamoDBTable-012A1SL7SMP5Q/stream/2015-11-30T20:10:00.000 . The StreamArn returned is that of the replica in the region the stack is deployed to.

You must specify the StreamSpecification property to use this attribute.

The ARN of the DynamoDB stream, such as arn:aws:dynamodb:us-east-1:123456789012:table/testddbstack-myDynamoDBTable-012A1SL7SMP5Q/stream/2015-11-30T20:10:00.000 . The StreamArn returned is that of the replica in the region the stack is deployed to.

You must specify the StreamSpecification property to use this attribute.

• S - the attribute is of type String
• N - the attribute is of type Number
• B - the attribute is of type Binary

• S - the attribute is of type String
• N - the attribute is of type Number
• B - the attribute is of type Binary

• S - the attribute is of type String
• N - the attribute is of type Number
• B - the attribute is of type Binary

• S - the attribute is of type String
• N - the attribute is of type Number
• B - the attribute is of type Binary

• S - the attribute is of type String
• N - the attribute is of type Number
• B - the attribute is of type Binary

• S - the attribute is of type String
• N - the attribute is of type Number
• B - the attribute is of type Binary

When switching billing mode from PAY_PER_REQUEST to PROVISIONED , DynamoDB requires you to specify read and write capacity unit values for the table and for each global secondary index. These values will be applied to all replicas. The table will use these provisioned values until CloudFormation creates the autoscaling policies you configured in your template. CloudFormation cannot determine what capacity the table and its global secondary indexes will require in this time period, since they are application-dependent.

If you want to switch a table's billing mode from PAY_PER_REQUEST to PROVISIONED , you must specify a value for this property for each autoscaled resource. If you specify different values for the same resource in different regions, CloudFormation will use the highest value found in either the SeedCapacity or ReadCapacityUnits properties. For example, if your global secondary index myGSI has a SeedCapacity of 10 in us-east-1 and a fixed ReadCapacityUnits of 20 in eu-west-1, CloudFormation will initially set the read capacity for myGSI to 20. Note that if you disable ScaleIn for myGSI in us-east-1, its read capacity units might not be set back to 10.

You must also specify a value for SeedCapacity when you plan to switch a table's billing mode from PROVISIONED to PAY_PER_REQUEST , because CloudFormation might need to roll back the operation (reverting the billing mode to PROVISIONED ) and this cannot succeed without specifying a value for SeedCapacity .

When switching billing mode from PAY_PER_REQUEST to PROVISIONED , DynamoDB requires you to specify read and write capacity unit values for the table and for each global secondary index. These values will be applied to all replicas. The table will use these provisioned values until CloudFormation creates the autoscaling policies you configured in your template. CloudFormation cannot determine what capacity the table and its global secondary indexes will require in this time period, since they are application-dependent.

If you want to switch a table's billing mode from PAY_PER_REQUEST to PROVISIONED , you must specify a value for this property for each autoscaled resource. If you specify different values for the same resource in different regions, CloudFormation will use the highest value found in either the SeedCapacity or ReadCapacityUnits properties. For example, if your global secondary index myGSI has a SeedCapacity of 10 in us-east-1 and a fixed ReadCapacityUnits of 20 in eu-west-1, CloudFormation will initially set the read capacity for myGSI to 20. Note that if you disable ScaleIn for myGSI in us-east-1, its read capacity units might not be set back to 10.

You must also specify a value for SeedCapacity when you plan to switch a table's billing mode from PROVISIONED to PAY_PER_REQUEST , because CloudFormation might need to roll back the operation (reverting the billing mode to PROVISIONED ) and this cannot succeed without specifying a value for SeedCapacity .

When switching billing mode from PAY_PER_REQUEST to PROVISIONED , DynamoDB requires you to specify read and write capacity unit values for the table and for each global secondary index. These values will be applied to all replicas. The table will use these provisioned values until CloudFormation creates the autoscaling policies you configured in your template. CloudFormation cannot determine what capacity the table and its global secondary indexes will require in this time period, since they are application-dependent.

If you want to switch a table's billing mode from PAY_PER_REQUEST to PROVISIONED , you must specify a value for this property for each autoscaled resource. If you specify different values for the same resource in different regions, CloudFormation will use the highest value found in either the SeedCapacity or ReadCapacityUnits properties. For example, if your global secondary index myGSI has a SeedCapacity of 10 in us-east-1 and a fixed ReadCapacityUnits of 20 in eu-west-1, CloudFormation will initially set the read capacity for myGSI to 20. Note that if you disable ScaleIn for myGSI in us-east-1, its read capacity units might not be set back to 10.

You must also specify a value for SeedCapacity when you plan to switch a table's billing mode from PROVISIONED to PAY_PER_REQUEST , because CloudFormation might need to roll back the operation (reverting the billing mode to PROVISIONED ) and this cannot succeed without specifying a value for SeedCapacity .

When switching billing mode from PAY_PER_REQUEST to PROVISIONED , DynamoDB requires you to specify read and write capacity unit values for the table and for each global secondary index. These values will be applied to all replicas. The table will use these provisioned values until CloudFormation creates the autoscaling policies you configured in your template. CloudFormation cannot determine what capacity the table and its global secondary indexes will require in this time period, since they are application-dependent.

If you want to switch a table's billing mode from PAY_PER_REQUEST to PROVISIONED , you must specify a value for this property for each autoscaled resource. If you specify different values for the same resource in different regions, CloudFormation will use the highest value found in either the SeedCapacity or ReadCapacityUnits properties. For example, if your global secondary index myGSI has a SeedCapacity of 10 in us-east-1 and a fixed ReadCapacityUnits of 20 in eu-west-1, CloudFormation will initially set the read capacity for myGSI to 20. Note that if you disable ScaleIn for myGSI in us-east-1, its read capacity units might not be set back to 10.

You must also specify a value for SeedCapacity when you plan to switch a table's billing mode from PROVISIONED to PAY_PER_REQUEST , because CloudFormation might need to roll back the operation (reverting the billing mode to PROVISIONED ) and this cannot succeed without specifying a value for SeedCapacity .

When switching billing mode from PAY_PER_REQUEST to PROVISIONED , DynamoDB requires you to specify read and write capacity unit values for the table and for each global secondary index. These values will be applied to all replicas. The table will use these provisioned values until CloudFormation creates the autoscaling policies you configured in your template. CloudFormation cannot determine what capacity the table and its global secondary indexes will require in this time period, since they are application-dependent.

If you want to switch a table's billing mode from PAY_PER_REQUEST to PROVISIONED , you must specify a value for this property for each autoscaled resource. If you specify different values for the same resource in different regions, CloudFormation will use the highest value found in either the SeedCapacity or ReadCapacityUnits properties. For example, if your global secondary index myGSI has a SeedCapacity of 10 in us-east-1 and a fixed ReadCapacityUnits of 20 in eu-west-1, CloudFormation will initially set the read capacity for myGSI to 20. Note that if you disable ScaleIn for myGSI in us-east-1, its read capacity units might not be set back to 10.

You must also specify a value for SeedCapacity when you plan to switch a table's billing mode from PROVISIONED to PAY_PER_REQUEST , because CloudFormation might need to roll back the operation (reverting the billing mode to PROVISIONED ) and this cannot succeed without specifying a value for SeedCapacity .

When switching billing mode from PAY_PER_REQUEST to PROVISIONED , DynamoDB requires you to specify read and write capacity unit values for the table and for each global secondary index. These values will be applied to all replicas. The table will use these provisioned values until CloudFormation creates the autoscaling policies you configured in your template. CloudFormation cannot determine what capacity the table and its global secondary indexes will require in this time period, since they are application-dependent.

If you want to switch a table's billing mode from PAY_PER_REQUEST to PROVISIONED , you must specify a value for this property for each autoscaled resource. If you specify different values for the same resource in different regions, CloudFormation will use the highest value found in either the SeedCapacity or ReadCapacityUnits properties. For example, if your global secondary index myGSI has a SeedCapacity of 10 in us-east-1 and a fixed ReadCapacityUnits of 20 in eu-west-1, CloudFormation will initially set the read capacity for myGSI to 20. Note that if you disable ScaleIn for myGSI in us-east-1, its read capacity units might not be set back to 10.

You must also specify a value for SeedCapacity when you plan to switch a table's billing mode from PROVISIONED to PAY_PER_REQUEST , because CloudFormation might need to roll back the operation (reverting the billing mode to PROVISIONED ) and this cannot succeed without specifying a value for SeedCapacity .

The complete key schema for a global secondary index, which consists of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for a global secondary index, which consists of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for a global secondary index, which consists of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for a global secondary index, which consists of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for a global secondary index, which consists of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for a global secondary index, which consists of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The role that this key attribute will assume:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The role that this key attribute will assume:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The role that this key attribute will assume:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The role that this key attribute will assume:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The role that this key attribute will assume:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The role that this key attribute will assume:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for the local secondary index, consisting of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for the local secondary index, consisting of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for the local secondary index, consisting of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for the local secondary index, consisting of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for the local secondary index, consisting of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

The complete key schema for the local secondary index, consisting of one or more pairs of attribute names and key types:

• HASH - partition key
• RANGE - sort key

The partition key of an item is also known as its hash attribute . The term "hash attribute" derives from DynamoDB's usage of an internal hash function to evenly distribute data items across partitions, based on their partition key values.

The sort key of an item is also known as its range attribute . The term "range attribute" derives from the way DynamoDB stores items with the same partition key physically close together, in sorted order by the sort key value.

Represents the non-key attribute names which will be projected into the index.

For global and local secondary indexes, the total count of NonKeyAttributes summed across all of the secondary indexes, must not exceed 100. If you project the same attribute into two different indexes, this counts as two distinct attributes when determining the total. This limit only applies when you specify the ProjectionType of INCLUDE . You still can specify the ProjectionType of ALL to project all attributes from the source table, even if the table has more than 100 attributes.

The set of attributes that are projected into the index:

• KEYS_ONLY - Only the index and primary keys are projected into the index.
• INCLUDE - In addition to the attributes described in KEYS_ONLY , the secondary index will include other non-key attributes that you specify.
• ALL - All of the table attributes are projected into the index.

When using the DynamoDB console, ALL is selected by default.

Represents the non-key attribute names which will be projected into the index.

For global and local secondary indexes, the total count of NonKeyAttributes summed across all of the secondary indexes, must not exceed 100. If you project the same attribute into two different indexes, this counts as two distinct attributes when determining the total. This limit only applies when you specify the ProjectionType of INCLUDE . You still can specify the ProjectionType of ALL to project all attributes from the source table, even if the table has more than 100 attributes.

The set of attributes that are projected into the index:

• KEYS_ONLY - Only the index and primary keys are projected into the index.
• INCLUDE - In addition to the attributes described in KEYS_ONLY , the secondary index will include other non-key attributes that you specify.
• ALL - All of the table attributes are projected into the index.

When using the DynamoDB console, ALL is selected by default.

Represents the non-key attribute names which will be projected into the index.

For global and local secondary indexes, the total count of NonKeyAttributes summed across all of the secondary indexes, must not exceed 100. If you project the same attribute into two different indexes, this counts as two distinct attributes when determining the total. This limit only applies when you specify the ProjectionType of INCLUDE . You still can specify the ProjectionType of ALL to project all attributes from the source table, even if the table has more than 100 attributes.

The set of attributes that are projected into the index:

• KEYS_ONLY - Only the index and primary keys are projected into the index.
• INCLUDE - In addition to the attributes described in KEYS_ONLY , the secondary index will include other non-key attributes that you specify.
• ALL - All of the table attributes are projected into the index.

When using the DynamoDB console, ALL is selected by default.

Represents the non-key attribute names which will be projected into the index.

For global and local secondary indexes, the total count of NonKeyAttributes summed across all of the secondary indexes, must not exceed 100. If you project the same attribute into two different indexes, this counts as two distinct attributes when determining the total. This limit only applies when you specify the ProjectionType of INCLUDE . You still can specify the ProjectionType of ALL to project all attributes from the source table, even if the table has more than 100 attributes.

The set of attributes that are projected into the index:

• KEYS_ONLY - Only the index and primary keys are projected into the index.
• INCLUDE - In addition to the attributes described in KEYS_ONLY , the secondary index will include other non-key attributes that you specify.
• ALL - All of the table attributes are projected into the index.

When using the DynamoDB console, ALL is selected by default.

Represents the non-key attribute names which will be projected into the index.

For global and local secondary indexes, the total count of NonKeyAttributes summed across all of the secondary indexes, must not exceed 100. If you project the same attribute into two different indexes, this counts as two distinct attributes when determining the total. This limit only applies when you specify the ProjectionType of INCLUDE . You still can specify the ProjectionType of ALL to project all attributes from the source table, even if the table has more than 100 attributes.

The set of attributes that are projected into the index:

• KEYS_ONLY - Only the index and primary keys are projected into the index.
• INCLUDE - In addition to the attributes described in KEYS_ONLY , the secondary index will include other non-key attributes that you specify.
• ALL - All of the table attributes are projected into the index.

When using the DynamoDB console, ALL is selected by default.

Represents the non-key attribute names which will be projected into the index.

For global and local secondary indexes, the total count of NonKeyAttributes summed across all of the secondary indexes, must not exceed 100. If you project the same attribute into two different indexes, this counts as two distinct attributes when determining the total. This limit only applies when you specify the ProjectionType of INCLUDE . You still can specify the ProjectionType of ALL to project all attributes from the source table, even if the table has more than 100 attributes.

The set of attributes that are projected into the index:

• KEYS_ONLY - Only the index and primary keys are projected into the index.
• INCLUDE - In addition to the attributes described in KEYS_ONLY , the secondary index will include other non-key attributes that you specify.
• ALL - All of the table attributes are projected into the index.

When using the DynamoDB console, ALL is selected by default.

A resource-based policy document that contains permissions to add to the specified replica of a DynamoDB global table. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

An array of key-value pairs to apply to this replica.

For more information, see Tag .

A resource-based policy document that contains permissions to add to the specified replica of a DynamoDB global table. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

An array of key-value pairs to apply to this replica.

For more information, see Tag .

A resource-based policy document that contains permissions to add to the specified replica of a DynamoDB global table. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

An array of key-value pairs to apply to this replica.

For more information, see Tag .

A resource-based policy document that contains permissions to add to the specified replica of a DynamoDB global table. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

An array of key-value pairs to apply to this replica.

For more information, see Tag .

A resource-based policy document that contains permissions to add to the specified replica of a DynamoDB global table. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

An array of key-value pairs to apply to this replica.

For more information, see Tag .

A resource-based policy document that contains permissions to add to the specified replica of a DynamoDB global table. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

An array of key-value pairs to apply to this replica.

For more information, see Tag .

A resource-based policy document that contains the permissions for the specified stream of a DynamoDB global table replica. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

You can update the ResourcePolicy property if you've specified more than one table using the AWS ::DynamoDB::GlobalTable resource.

A resource-based policy document that contains the permissions for the specified stream of a DynamoDB global table replica. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

You can update the ResourcePolicy property if you've specified more than one table using the AWS ::DynamoDB::GlobalTable resource.

A resource-based policy document that contains the permissions for the specified stream of a DynamoDB global table replica. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

You can update the ResourcePolicy property if you've specified more than one table using the AWS ::DynamoDB::GlobalTable resource.

A resource-based policy document that contains the permissions for the specified stream of a DynamoDB global table replica. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

You can update the ResourcePolicy property if you've specified more than one table using the AWS ::DynamoDB::GlobalTable resource.

A resource-based policy document that contains the permissions for the specified stream of a DynamoDB global table replica. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

You can update the ResourcePolicy property if you've specified more than one table using the AWS ::DynamoDB::GlobalTable resource.

A resource-based policy document that contains the permissions for the specified stream of a DynamoDB global table replica. Resource-based policies let you define access permissions by specifying who has access to each resource, and the actions they are allowed to perform on each resource.

In a CloudFormation template, you can provide the policy in JSON or YAML format because CloudFormation converts YAML to JSON before submitting it to DynamoDB . For more information about resource-based policies, see Using resource-based policies for DynamoDB and Resource-based policy examples .

You can update the ResourcePolicy property if you've specified more than one table using the AWS ::DynamoDB::GlobalTable resource.

• KMS - Server-side encryption that uses AWS Key Management Service . The key is stored in your account and is managed by AWS KMS ( AWS KMS charges apply).

• KMS - Server-side encryption that uses AWS Key Management Service . The key is stored in your account and is managed by AWS KMS ( AWS KMS charges apply).

• KMS - Server-side encryption that uses AWS Key Management Service . The key is stored in your account and is managed by AWS KMS ( AWS KMS charges apply).

• KMS - Server-side encryption that uses AWS Key Management Service . The key is stored in your account and is managed by AWS KMS ( AWS KMS charges apply).

• KMS - Server-side encryption that uses AWS Key Management Service . The key is stored in your account and is managed by AWS KMS ( AWS KMS charges apply).

• KMS - Server-side encryption that uses AWS Key Management Service . The key is stored in your account and is managed by AWS KMS ( AWS KMS charges apply).

• KEYS_ONLY - Only the key attributes of the modified item are written to the stream.
• NEW_IMAGE - The entire item, as it appears after it was modified, is written to the stream.
• OLD_IMAGE - The entire item, as it appeared before it was modified, is written to the stream.
• NEW_AND_OLD_IMAGES - Both the new and the old item images of the item are written to the stream.

• KEYS_ONLY - Only the key attributes of the modified item are written to the stream.
• NEW_IMAGE - The entire item, as it appears after it was modified, is written to the stream.
• OLD_IMAGE - The entire item, as it appeared before it was modified, is written to the stream.
• NEW_AND_OLD_IMAGES - Both the new and the old item images of the item are written to the stream.

• KEYS_ONLY - Only the key attributes of the modified item are written to the stream.
• NEW_IMAGE - The entire item, as it appears after it was modified, is written to the stream.
• OLD_IMAGE - The entire item, as it appeared before it was modified, is written to the stream.
• NEW_AND_OLD_IMAGES - Both the new and the old item images of the item are written to the stream.

• KEYS_ONLY - Only the key attributes of the modified item are written to the stream.
• NEW_IMAGE - The entire item, as it appears after it was modified, is written to the stream.
• OLD_IMAGE - The entire item, as it appeared before it was modified, is written to the stream.
• NEW_AND_OLD_IMAGES - Both the new and the old item images of the item are written to the stream.

• KEYS_ONLY - Only the key attributes of the modified item are written to the stream.
• NEW_IMAGE - The entire item, as it appears after it was modified, is written to the stream.
• OLD_IMAGE - The entire item, as it appeared before it was modified, is written to the stream.
• NEW_AND_OLD_IMAGES - Both the new and the old item images of the item are written to the stream.

• KEYS_ONLY - Only the key attributes of the modified item are written to the stream.
• NEW_IMAGE - The entire item, as it appears after it was modified, is written to the stream.
• OLD_IMAGE - The entire item, as it appeared before it was modified, is written to the stream.
• NEW_AND_OLD_IMAGES - Both the new and the old item images of the item are written to the stream.

The name of the attribute used to store the expiration time for items in the table.

Currently, you cannot directly change the attribute name used to evaluate time to live. In order to do so, you must first disable time to live, and then re-enable it with the new attribute name. It can take up to one hour for changes to time to live to take effect. If you attempt to modify time to live within that time window, your stack operation might be delayed.

The name of the attribute used to store the expiration time for items in the table.

Currently, you cannot directly change the attribute name used to evaluate time to live. In order to do so, you must first disable time to live, and then re-enable it with the new attribute name. It can take up to one hour for changes to time to live to take effect. If you attempt to modify time to live within that time window, your stack operation might be delayed.

The name of the attribute used to store the expiration time for items in the table.

Currently, you cannot directly change the attribute name used to evaluate time to live. In order to do so, you must first disable time to live, and then re-enable it with the new attribute name. It can take up to one hour for changes to time to live to take effect. If you attempt to modify time to live within that time window, your stack operation might be delayed.

The name of the attribute used to store the expiration time for items in the table.

Currently, you cannot directly change the attribute name used to evaluate time to live. In order to do so, you must first disable time to live, and then re-enable it with the new attribute name. It can take up to one hour for changes to time to live to take effect. If you attempt to modify time to live within that time window, your stack operation might be delayed.

The name of the attribute used to store the expiration time for items in the table.

Currently, you cannot directly change the attribute name used to evaluate time to live. In order to do so, you must first disable time to live, and then re-enable it with the new attribute name. It can take up to one hour for changes to time to live to take effect. If you attempt to modify time to live within that time window, your stack operation might be delayed.

The name of the attribute used to store the expiration time for items in the table.

Currently, you cannot directly change the attribute name used to evaluate time to live. In order to do so, you must first disable time to live, and then re-enable it with the new attribute name. It can take up to one hour for changes to time to live to take effect. If you attempt to modify time to live within that time window, your stack operation might be delayed.