ElastiCache Serverless is a few weeks old and developers have reasons to be excited about the caching landscape. Choice in any ecosystem is a good thing. Serverless architecture from a design standpoint focuses on the assembly of components that are chosen based on performance, functionality, and cost. The idea is that you create as many two-way doors in your design as possible so that if something doesn't work quite as intended, a piece can be swapped for something more suitable.
However, some things can be known upfront such as cost. Cost in a serverless design is driven through usage and by definition, it should scale to zero when not being consumed. Let's take a look at the recently released ElastiCache Serverless service and see if that holds.
ElastiCache Serverless pricing
ElastiCache Serverless has two parts to its pricing. One part of the monthly bill is data stored and the second is based on ElastiCache Processing Units (ECPUs). On the surface this makes sense. Pay for data and pay for compute. However, there is some nuance to how this comes together when you look a little more closely.
ElastiCache Processing Units (ECPUs)
ECPUs are calculated in 1KB increments and are billed in groupings of 1 million. The exact pricing is $0.0034 per million ECPUs. Think of it this way, the size of the item cached affects the cost paid for that item to be written or fetched. The ECPUs are per 1KB of reads or writes.
Storage
Per the AWS documentation, the data stored in ElastiCache Serverless is sampled multiple times per minute to build an hourly average. That average amount is then priced at $0.125 / GB-Hr. The unfortunate part of this pricing is that it violates the scale-to-zero principle of being truly serverless by charging a 1GB minimum per hour. To put that in perspective, on a 30-day month, the minimum usage cost for ElastiCache Serverless is $90. On a 31-day month, that number goes to $93.
Pricing examples
It's important when planning a design to take cost into account early in the process. So let's take 2 examples and provide a few variations to look at what this new AWS feature will cost based on usage.
Low storage
Assume that it's early in a project's development. Data storage itself is low, even less than the 1GB minimum storage minimum ElastiCache sets. To understand how ECPUs drive cost, the below highlights a low-volume and high-volume example.
Low volume / low storage application
High volume / low storage application
Another example to look into is a high-volume application that reads from a small cached storage but is trying to improve static data lookup performance.
It takes the application 259 million requests per month to incur roughly the same amount of cost as the base monthly price on storage. ElastiCache Serverless is more than 300 times more expensive on storage than it is on compute to read or write.
High storage
When looking at how to best utilize ElastiCache Serverless, the impact of cost starts to set in when the volume of cached data increases. From the above example, ECPUs aren't that expensive when priced at $0.0034 per million units. However, data at almost $.13 per GB-hour will run up pretty quickly. Depending on how much you cache, the cost could be significant.
High volume / high storage application
Modeling a low-volume yet high-storage example doesn't make a whole lot of sense. One of the core purposes of a cache is to improve performance, which means reducing latency when accessing data. If the data is infrequently accessed, the cost to put it into the cache probably doesn't justify the cost of the infrequent access.
For a heavy storage and high read request example, assume the 10,000 requests per second from above. However, instead of 500MB of storage, this data is more customer-specific and greater volume. That total amount is 50GB.
Notes to consider
Data storage drives cost
ElastiCache Serverless becomes more expensive rapidly as the data volume stored per hour increases. When modeling costs, if a design includes this service, pay close attention to how much data will be stored per hour. Remember, it's billed by GB-hour so if there's one hour of peak usage but 23 with low storage needs, costs will still be low. But if there are large periods of the day that consume a great deal of storage, it will add up quickly.
Scaling to zero isn't possible since ElastiCache Serverless has a minimum usage amount. If the project being deployed is still early in development, this amount will stick out like a weed in a manicured garden. Lambda, SQS, EventBridge, DynamoDB and S3 will scale to zero if there is no usage or storage. If this caching service is put in the middle of that, it will not scale to zero per hour and a charge of $.125 will be applied each hour.
ECPUs are “almost free"
ElastiCache Processing Units will probably not factor into the overall cost to a significant degree. At 0.0034 per million ECPU, this is significantly cheaper than say a DynamoDB Read Capacity Units at $.25 per million. Of course, if the items read or written are extremely large and highly read, there will be a cost. But most usages of a cache are typically small payloads of around 5KB or less which won't incur a high bill, even with high read or write throughputs.
Back to choice
One of the biggest benefits of the serverless ecosystem right now is the amount of choice that Architects and Engineers have when building their systems. As seen above, ElastiCache Serverless has a nice cost profile when the data storage is low and throughput is high. However, it struggles across the entire software development lifecycle due to its inability to scale to zero and its higher charges around data storage.
Consider the impact in a Development, QA, Pre-Production, and Production type setup. With no compute consumed, the bill is $360 ($90 \* 4 environments) which on the surface might not seem like a great deal. However, for many, that is cost-prohibitive in many scenarios and isa poor use of resources. And remember, cost == sustainability.
Momento offers a compelling alternative to ElastiCache Serverless in several key scenarios when it comes to cost.
- Cost and utilization in non-production environments - Momento offers pay-as-you-go pricing which scales to zero. Pay nothing when not consuming. There is no split in data and compute.
- Low utilization with large and small payloads - With no minimum charge, Momento's pricing shines.
- High usage yet small payload size - At $.50 / GB of data transfer with the first 5GB free, the cost is driven by the amount of data transferred which is driven by the caller's design.
Working back through the examples above, take a 10, 100 and 10,000 requests / second example with 1KB payload size and the bill breaks down favorably as requests scale and payloads remain small.
Wrapping up
ElastiCache Serverless is a nice step forward in the AWS serverless ecosystem. Pricing is quite nice in terms of GB-hour and the reads and writes are extremely developer friendly. The major downside is the minimum charge of $0.125 per hour for the baseline of 1GB of storage. This inability to scale to zero is prohibitive for early-stage products and features, especially when compared to pricing around other truly serverless components like Momento's caching service.
Understanding your application's needs and usage will help shape design considerations which will have a cost impact on the feature being delivered.
If the feature is storing more than that 1GB minimum out of the gate and doesn't drop below that amount, the cost per million ECPUs is quite friendly and should fit nicely in line with other serverless costs. But that must be weighed against the total cost and its inability to scale to zero across all environments. In addition, modeling the payloads and data required could have a tremendous impact on cost as seen with Momento's pay-as-you-go pricing model.
Again, choice is a good thing. A caching decision shouldn't be a one-way door in a system's design. Choose wisely, but don't be afraid to experiment. And do include cost as a factor in the final design. Because remember, cost == sustainability.
Have a question about this post? Tweet @benjamenpyle or reach out on LinkedIn. For more insights on tech programming, AWS, and serverless, check out my blog.
