If the only place you store data, especially data accessed extremely frequently, is a relational database, then you are missing out on all the advantages of a key-value store like Redis running on AWS Elasticache. Also, it is important to understand this is NOT a replacement for your primary database. It is more to augment your application's usage of the primary database in a more efficient way.

Caching things in Elasticache or querying things that can only be looked up via the key in Redis instead of having a relational database run expensive queries on millions of DB rows alone will decrease the load on the relational database and result in decreased CPU/Memory requirements.

Option 1 - Always on: Just like with the other resource types, “Always On” is great but can be a bit pricey. If you have a constant load and know how much you are going to be, it has that baseline cost you can’t get away from.

Option 2 -Serverless: This is a fairly new feature I have yet to try (like, released a week before I wrote this). This option is best if you have times when there will be little or no traffic on your platform or at least this feature. Just like with the database, there is a charge for data stored, but if you use expiring TTLs on your ephemeral data, that cost could drop close to zero if there is no load on the site. More on “ephemeral data” below. Key Value Store Usages: If you have not used a key-value store like Redis, here are some tips: Caution: Caching of Page HTML: Say, for example, you had a website that let you search for products. You could cache the HTML results for each page. I would NOT do this!

First of all, every character you choose to store is either a few fewer bytes you have to work with if you're on the “Always On” provisioned model or a few more bytes you have to pay for if you are using the On Demand model. So store only what is necessary. Storing JSON is better than storing the full, bloated HTML, but ideally, you would be storing the database record ID, which is much faster to look up a record in the DB than something like a text-based field.

If you really want to go wild, there is no reason you cannot also cache the full DB record in Redis with its ID as the key and just query that instead of the DB, therefore taking all load off the DB. Prebuilt Indexes: Instead of caching the full result in JSON or HTML, you can build your own indexes. So, if you wanted a list of every product on the site that was the color ‘red,’ you could create a key called ‘/products/red’ and populate it with the IDs of every red product. Then you either cache the products where the key is ‘/products/{product id}’ or you query the DB for a list of products by ID, which again is way faster than any text-based field.

There is A LOT that goes into this. Check out the advanced section on “Prebuilt Indexes.” Ephemeral Data: This is temporary data that, if it expires and needs to be recomputed, would not ruin the user's experience. A common example is session storage (which I wouldn’t recommend even having session storage these days, but that is another topic) or shopping cart data, especially if the person is not logged in and we cannot tie it back to that specific user for next time they visit the site.

Advanced Topics: There are many more advanced strategies that can save you big bucks, but they are so complex I extracted two of them to their own Sections 8 on Prebuilt Indexes and 9 on Cursors/Checkpoints.

Helpful Links: AWS Elasticache Serverless: https://aws.amazon.com/blogs/aws/amazon-elasticache-serverless-for-redis-and-memcached-now-generally-available/