There are two type of Redis deployment in AWS ElastiCache service:

1. Standalone
2. Multi-AZ cluster

With standalone installation it is possible to turn on persistence for a Redis instance, so service can recover data after reboot. But in some cases, like underlying hardware degradation, AWS can migrate Redis to another instance and lose persistent log.

In Multi-AZ cluster installation it is not possible to enable persistence, only replication is occur. In case of failure it takes a time to promote replica to master state. Another way is to use master and slave endpoints in the application directly, which is complicated. In case of failure which cause a restart both Redis node at time it is possible to lose all data of the cluster configuration too.

So, in general, Redis doesn't provide high durability of the data, while gives you very good performance.

DynamoDB is highly available and durable storage of you data. Internally it replicates data into several availability zones, so it is highly available by default. It is also fully managed AWS service, so you don't need to care about Clusters, Nodes, Monitoring ... etc, which is considering as a right cloud way.

Dynamo DB is charging by R/W operation (on-demand or reserved capacity model) and amount of stored data. In may be really cheap for testing of the service, but much more expensive under the heavy load. You should carefully analyze you workload and calculate total service costs.

As for performance: DynamoDB is a SSD Database comparing to Redis in-memory store, but it is possible to use DAX - in-memory cache read replica for DynamoDB as accelerator on heavy load. So you won't be strictly limited with the DynamoDB performance.

Here is the link to DynamoDB pricing calculator which one of the most complicated part of service usage: https://aws.amazon.com/dynamodb/pricing/

DynamoDB is cheap. You could have a look at using the MongoDB Atlas cloud offering, which is comparable cheap as well, but that may not be much cheaper. You are trying to compare apples with oranges.

However, it looks more like a design problem. You somehow seem to be regularly do some queries based on "the last 3 days", you should look at doing those queries not too often and cache those results using ElastiCache.

Updated: If you are doing full collection scans than there is something else wrong as well. You need to avoid these. Make use of the global secondary indexes if you haven't done so yet. You could consider adding some index data only collections if you already used up the five secondaries.

In regard to MongoDB it's way more flexible for creating indexes as you can create indexes covering more than two fields(e.g. city, state and date) and you can create much more than five indexes, which would certainly ease your full scan scenarios. In addition you would be able to use the powerful aggregation framework for some of your queries. You should still consider caching those queries with ElastiCache (redis/memcached).