committed throughput charges in dynamodb table

You can take it further to check in Cost Explorer - you can filter out the CommittedThroughput in the API Operation filter, and then group your usage by "Usage Type". If the top usage type look something like "pay per request", then you will know it's a result of your table in on-demand mode. The pricing for throughput in tables in on-demand mode is often higher than the provisioned mode (depends on your usage patterns of course) - https://aws.amazon.com/dynamodb/pricing/ - depending on your actual writes/reads throughout the hour/day. With tables in the provisioned mode you are limited with the amount of WCU/RCU that you get (you can only use up to what you provision), while with the tables in on-demand mode you can use much more at a single point in time, however the trade-off will be that it will often be more expensive (again, depends on your requirements and the usage patterns).

It depends on your need, and whether your write/read patterns are known. If you know how much WCU/RCU you will need at any given time, you should try using tables in provisioned mode. A good thing to explore is to combine it with Auto-Scaling for situations when you'd need more throughput so you wouldn't run into "not enough capacity" issue https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html; Moreover, for tables in provisioned mode, you can actually reserve capacity, and save extra (around 50%) over time - check info about "reserved capacity" here https://aws.amazon.com/dynamodb/pricing/provisioned/

Though, if your usage patterns are unexpected, and you will often have these spikes in write and read requests, then on-demand mode will suit better. But you have to consider the cost.

It looks like you changed the table capacity mode from provisioned to on-demand to prevent throttling during the GSI creation. Please note that there are certain changes done to the table and partitions during these switches that can have capacity and cost implications. See here for details: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.PeakTraffic

During the switching period, your table delivers throughput that is consistent with the previously provisioned write capacity unit and read capacity unit amounts. When switching from on-demand capacity mode back to provisioned capacity mode, your table delivers throughput consistent with the previous peak reached when the table was set to on-demand capacity mode.

To avoid running into into GSI throttling errors, refer to these articles for insights: https://repost.aws/knowledge-center/on-demand-table-throttling-dynamodb https://repost.aws/knowledge-center/dynamodb-gsi-throttling-table

Hi,

I suggest you create a support ticket regarding your question (see here on how to do this: https://aws.amazon.com/contact-us/). One thing to note is that the Cost Explorer only looks at data up until the day before, see https://docs.aws.amazon.com/cost-management/latest/userguide/ce-exploring-data.html

All costs reflect your usage up to the previous day. For example, if today is December 2, the data includes your usage through December 1.