This is where item size comes into play. Each write request to DynamoDB is rounded up to the nearest 1KB. So lets first assume the items in your table is less than 1KB:
A write to the base table will consume 1 WCU and replication to a GSI will consume 1 WCU. That replicated write to the GSI will consume 1WCU regardless if you use
ALL projection, as the minimum consumption is 1 WCU.
Now consider your item size is 4KB:
A write to the base table will consume 4 WCU and replication to a GSI will consume 4 WCU if using
ALL projection. However, if you use
KEYS_ONLY you will only consume 1 WCU from your GSI which is 1/4 of the cost of using
The second factor for using
KEYS_ONLY is storage costs, only storing the keys of the item can significantly reduce storage costs as your table scales to TB's.
For example if a table with PK "id" and GSI-PK "email" would get extra WRU used or cost added when modifying the attribute "city" in the original table.
KEYS_ONLY would not consume GSI capacity in this instance, as you have made no changes to the indexed item.
How to query all items of a specific type?asked 8 months ago
Partition Projection for vpcflow logs in parquet with hive compatible prefixesasked 22 days ago
Appsync GSI not producing existing DynamoDB record by Graphql using amplifyAccepted Answerasked a year ago
Appsync composite key (GSI in dynamodb) returns Null in query responseasked 8 months ago
Hierarchical data plus condition - Table DesignAccepted Answerasked 3 years ago
Do GSI not projected attributes use WRU?Accepted Answerasked 15 days ago
DynamoDb bug on python boto3 query with GSIAccepted Answerasked 6 months ago
DynamoDB Hierarchical, Sorted QueriesAccepted Answerasked 9 months ago
AWS DynamoDB tables and GSIAccepted Answerasked 4 years ago
DynamoDB local GSI KeyConditionExpression difference from live Dynamoasked 2 years ago