[giaour]

The pricing page is available at https://aws.amazon.com/dynamodb/pricing/on-demand/ , but it looks like it's not yet updated with the per-request rates. The blog post mentions rates in us-east-1: "in the US East (N. Virginia) region, you are charged $1.25 per million write requests units and $0.25 per million read request units, plus the usual data storage costs."

[phamilton]

My math:

Provisioned: $0.00065 per WCU. One WCU is 1 write per second for an hour = 3600 writes. So 277 WCU is 1 million writes in an hour. Cost is $0.18 per million write requests. (If you reserve this for a year it's $0.08 per million write requests.)

We generally run our tables with autoscaling set to 70% of capacity, so at $0.18 per million write requests our effective cost is $0.25 per million write requests. A good deal cheaper than on demand.

We have a few tables where we run closer to 30% of target capacity because of hot shards. There our effective cost is $0.60 per million write requests, which is still cheaper than on demand (assuming on demand doesn't have the hot shard problem).

I'm having trouble understanding when this would be beneficial.

[ksmail99]

This is actually meant for companies like ours. We have a very spiky workload (need massive throughput needs and then nothing happens for rest of the day). The current auto-scaling doesn't work since it takes time to scale up and you are limited to only few of those changes per time period. We ended up setting the throughput high to avoid that. Also people in company set up these high throughput on dynamodb and we end up paying thousands of dollars more before this is discovered. I know we can write lambda's to automate the detection and all of that but that is too much work. This feature is ideal and will drive our costs down a lot.

[kenhwang]

I'm considering using this for our staging tables since 90% of the time, we'd want to scale to 0 instead of 1. Doesn't do much for cost savings, but it does make it easier to manage.

[andrioni]

One use case where it would be beneficial is for tables that have batch-style patterns, where you (at least in my experience) need to provision a good enough baseline before autoscaling kicks in.

In some cases I've seen, autoscaling can manage going from ~500 to 10k WCU without heavy throttling (as the burst capacity can handle the five~ten minutes before autoscaling kicks in), but not with a smaller baseline. On tables with hot shards, the baseline usually has to be higher.

[arihant]

This would be beneficial for companies who have not yet figured out the math like you have. Also for companies who have 5-6X spikes in a non predictable fashion. Also, even for predictable spikes, there is a non-trivial lag for autoscaling.

Probably also useful for multi-tenant apps like web analytics. One cannot possibly predict the workload.