New – Size flexibility for Amazon ElastiCache reserved nodes

Amazon ElastiCache, a fully managed, Valkey-, Memcached-, and Redis OSS-compatible caching service, now supports size flexibility for all its reserved node offerings, enabling your reserved node discount to apply to all node types in the node family 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: self-designed (node-based), and serverless. 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. Customers asked for more flexibility to make their long-term capacity planning easier, and so they did not 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 (Valkey, Memcached, or Redis OSS). Additionally, with the launch of Valkey in ElastiCache, customers with Redis OSS reserved nodes can now apply this reserved node discount to the Valkey engine, making it easy for Redis OSS customers with existing contracts to upgrade to Valkey while still benefitting from their reservation. 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 and engine combination 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 for a given engine. Redis OSS reserved nodes can additionally apply across engines to cover running Valkey nodes. Because Valkey is priced at a discount relative to Redis OSS and Memcached, its units for a given instance type are lower, which allows a Redis OSS reserved node to cover more Valkey nodes (see Scenario 5). 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.

Scenario 5: Upgrading from Redis OSS to Valkey

With Redis OSS reserved nodes, in addition to being able to apply your benefits within the cache node family and engine, you can also choose to upgrade to the Valkey engine and receive more incremental value. Valkey is priced at a 20% discount relative to Redis OSS, and with reserved node flexibility, you can use your Redis OSS reserved nodes to cover 20% more running Valkey nodes. Let’s say you have purchased a reserved node for a cache.r7g.4xlarge for the Redis OSS engine (32 units) and are running one cache.r7g.4xlarge Redis OSS node (32 units). If you upgrade the node to Valkey, the normalization factor of the running node drops to 25.6 units, and your existing reserved node provides you with an additional 6.4 units to use against any other running Valkey or Redis OSS node within the cache.r7g family in the Region. You could use this to cover 25% of another cache.r7g.4xlarge Valkey node in the account (25.6 units), or 100% of a cache.r7g.xlarge Valkey node (6.4 units).

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.