Overview

This product feature will handle upgrades of eligible ElastiCache clusters to Graviton 2 as AWS boasts that the newer version provides upto 57% better price/performance improvement over previous generation instances.

ElastiCache allows us to run managed clusters of Redis and Memcached. It is designed to store ephemeral data that needs to be accessed at low latencies, which is done using EC2 instances as nodes and storing data in memory. ElastiCache supports a subset of EC2 instance types and as new types are added (e.g. Graviton 2) and we want to take advantage of them using this upgrade process.

How does it work?

This problem will be solved by the following steps by CloudFix:

1. Collecting the required data related to the Redis Engine and Engine Version.
2. Searching for ElastiCache clusters that can be upgraded to corresponding Graviton2 instances without version upgrade.
3. Executing the Fixer to update the instance type of the cluster to Graviton2 instances.

This will work like other Finders-Fixers of the product where CloudFix will provide the recommendations from your AWS environment and you can either schedule this Fixer to run as per your schedule (eg: during a maintenance window) or set it to run on-demand.

Below are some points to consider that are related to this feature:

• CloudFix ignores clusters with versions that do not support Graviton because you might be using code that is incompatible with the latest version and this version upgrade is irreversible and hence, in case something goes wrong, the cluster would need to be recreated.
• In order to mitigate risk during cluster upgrades operation, these updates are flagged as requiring a maintenance window. This is because there should be at least 25% memory (rule of thumb) available for these upgrades to go through. If this happens during a maintenance window, then Redis would only need to dump its data into a disk without requiring any additional data in memory.
• ElastiCache supports different types of Reserved Nodes. Upgrading reserved r5 nodes to on-demand r6g ones can easily lead to losses instead of savings. Thus, CloudFix skips any nodes that are covered by reservations.
• There is a theoretical possibility that a Cluster may enter an “incompatible-network” state after an upgrade. In case this happens, CloudFix doesn’t attempt to auto-recover from this state (Related article: How do I resolve issues with an Amazon RDS database that is in an incompatible-network state?).