New – Size flexibility for Amazon ElastiCache reserved nodes

Amazon ElastiCache, a fully managed, Redis OSS- and Memcached-compatible caching service, now supports size flexibility for all its reserved node offerings, enabling your reserved node discount to apply across differently sized node types beyond the size specified in your reservation. With flexible reserved nodes, you no longer need to commit to a specific node size when purchasing a reservation, reducing the overhead of capacity planning and enabling you to right-size your clusters as your workloads and capacity needs change. In this post, we explain how you can use this new size flexibility feature to leverage discounted pricing on your ElastiCache clusters.

Amazon ElastiCache helps hundreds of thousands of customers boost their applications’ performance, achieve higher scale, and optimize their costs. ElastiCache is ideal for high-performance use cases such as data caching, web, mobile apps, healthcare apps, financial apps, gaming, ad-tech, Internet of Things (IoT), media streaming, session stores, leaderboards, machine learning (ML), and microservices-based applications. Because ElastiCache is a fully managed service, it helps manage hardware provisioning, monitoring, node replacements, and software patching for your caches.

ElastiCache has two deployment options: serverless and self-designed (node-based). For self-designed clusters, you choose the node type, number of nodes, and node placement across AWS Availability Zones. You can purchase reserved nodes to reserve an ElastiCache node type for a 1- or 3-year term and receive a discount (up to 55%) compared to on-demand node pricing. ElastiCache reserved nodes are available in No Upfront, Partial Upfront, and All Upfront configurations depending on how much of an initial payment you want to make. The longer the term and the larger the upfront payment, the higher the overall discount you receive on usage for the duration of the reservation.

Previously, you needed to purchase a reservation for a specified node type (for example, cache.r7g.xlarge) and would only be eligible for a discount on the given type. If you wanted to scale your cluster up or down by changing the node size, your reserved node would no longer provide you a discount. This lack of flexibility made long-term capacity planning using reserved nodes more difficult, because you would have to commit to a specific instance type for a 1- or 3-year period. Effective October 1, 2024, all ElastiCache reserved nodes are more flexible, and now apply to all sizes of node types within a node family (for example, cache.r7g) for a given AWS Region and cache engine (Redis OSS or Memcached). The discounted rate is automatically applied to usage, so it reduces the management overhead of trying to match reserved node discounts to running cache nodes.

To calculate the discounted rate, each ElastiCache node has a normalization factor that’s measured in units. Reserved node units can be applied to any running node within the reserved node’s instance family. To see the normalization factor of any node, you can refer to the node size chart. This is a similar process to how other services, such as Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Relational Database Service (Amazon RDS), provide size flexibility for their reservations.

Scenario 1: Scaling your cluster down and out

For example, let’s say you purchased a reserved node for a cache.r7g.4xlarge node for the Memcached engine, which has a normalization factor of 32 units. This reserved node can now be used for any Memcached cache.r7g node within the Region. You can scale your node size down and run more nodes (in the same or different clusters within the account) and receive your reserved node benefit. This could be:

• Eight cache.r7g.large nodes (8 * 4 = 32 units)
• Four cache.r7g.xlarge nodes (4 * 8 = 32 units)
• Two cache.r7g.2xlarge nodes (2 * 16 = 32 units)
• One cache.r7g.4xlarge node (1 * 32 = 32 units)

Scenario 2: Mixing node sizes

The same cache.r7g.4xlarge reserved node can also be used for combinations of nodes, such as four cache.r7g.large nodes (4 * 4 = 16 units) and two cache.r7g.xlarge nodes (2 * 8 = 16 units). The reserved node price will automatically apply to any running smaller node types within the node family before being applied to larger node types. You can’t choose which specific instances receive the benefits of your reserved nodes. For example, if you’re running eight cache.r7g.large nodes (32 units) and one cache.r7g.4xlarge node (32 units), your eight cache.r7g.large nodes will be covered by the reserved node.

Scenario 3: Scaling your cluster up

If you run a node that’s larger than your reserved node, you will be charged the pro-rated, On-Demand price for the excess. For example, let’s say you have two cache.m7g.large Redis OSS reserved nodes to cover your running 2-node cache.m7g.large cluster and you want to scale your cluster up to use cache.m7g.2xlarge nodes to take advantage of its higher number of vCPUs. Your reserved nodes are worth 8 units total and will cover 50% of the new cluster (16 units), or the equivalent of one full 2xlarge node. The remaining node will be billed based on the On-Demand, per-hour price of the cache.m7g.2xlarge node. You could also purchase one additional cache.m7g.2xlarge reserved node to cover the entire cluster.

Scenario 4: Scaling your cluster down

If there aren’t enough eligible running nodes within a given hour of usage, any remaining reserved node units for the hour will be forfeited. For example, if you have a cache.t4g.medium reserved node for the Redis OSS engine and scale down your one-node Redis OSS cluster to cache.t4g.small, you will forfeit the remaining 1 unit of benefit unless you launch other Redis OSS cache.t4g nodes in the Region.

Conclusion

Node type flexibility is available now in all Regions for all ElastiCache engines and will be automatically applied to any existing and newly purchased reserved nodes from October 1 without any effort on your part. To learn more about flexible reserved nodes, visit the Amazon ElastiCache reserved node page.

About the authors

Kevin McGehee is a Principal Engineer in the Amazon In-Memory Databases team. He is passionate about building performant, maintainable systems alongside talented developers.

Goumi Viswanathan is a Senior Product Manager in the Amazon In-Memory Databases team. She has over 12 years of product experience and is focused on leading cross functional teams delivering database solutions. Outside of work, she enjoys traveling and spending time outdoors.