Always On Vs Just In Time Databases

This post is one in a series of posts that are sample chapters from my FREE eBook 20 Things You Can DoTo Save Money On Your Amazon Web Services Bill Today. Feel free to download the full eBook for free if you want the whole thing.

Databases

This resource type is slightly different from the previous mainly because, besides paying for CPU and RAM Memory, there is the additional cost of storing data on a disc somewhere. So, the baseline cost for this type of resource will likely never be zero, even on an “On Demand” solution when there is no traffic on your platform. The good news is that storage is almost always cheaper than compute power.

Option 1 - Always on:

With an “Always On” solution like AWS RDS, you are always paying for the compute/memory resources even if there is no load on the DB. If traffic is sporadic, then, just like with the workers, you are paying for compute resources you do not need. If traffic is consistent, this could be your best option.

Auto Scaling:

Most “Always On” databases have some type of auto-scaling solution based on CPU or Memory usage. It is pretty intuitive, so I will not go into too much detail here, but be sure to check out Section 12, called “Horizontally Scaling Via Partitioning/Sharding,” for the more advanced options.

Option 2 - Serverless:

DynamoDB: The first product that comes to mind when talking about an On Demand Database is AWS DynamoDB which was designed from the ground up for this type of application.

A Word Of Warning: Watch your I/O with this. Reads are way cheaper than writes, but if you are sending a ton of traffic back and forth, it can get a bit pricey, and you may want to consider option 1. That or consider something like Redis on AWS Elasticache, which is optimized for a lot of fast transactions.

Aurora Serverless:

I have NOT used this in production, but if you need to run MySQL in a serverless On Demand way, somehow AWS made that possible with Aurora Serverless. It doesn’t seem quite as native as DynamoDB, but it still could do the trick in a pinch, especially if you are stuck with SQL or Postgres and migrating away is not an option. That is totally understandable.

Helpful Links: