Version Management for ElastiCache

Manage how you would like to update your ElastiCache caches and self-designed clusters updated for the Valkey, Memcached, and Redis OSS engines.

Version management for ElastiCache Serverless Cache

Manage if and when the ElastiCache Serverless cache is upgraded and perform version upgrades on your own terms and timelines.

ElastiCache Serverless automatically applies the latest MINOR and PATCH software version to your cache, without any impact or downtime to your application. No action is required on your end.

When a new MAJOR version is available, ElastiCache Serverless will send you a notification in the console and an event in EventBridge. You can choose to upgrade your cache to the latest major version by modifying your cache using the Console, CLI, or API and selecting the latest engine version.

Version management for self-designed ElastiCache clusters

When working with self-designed ElastiCache clusters, you can control when the software powering your cache cluster is upgraded to new versions that are supported by ElastiCache. You can control when to upgrade your cache to the latest available MAJOR, MINOR, and PATCH versions. You initiate engine version upgrades to your cluster or replication group by modifying it and specifying a new engine version.

You can control if and when the protocol-compliant software powering your cache cluster is upgraded to new versions that are supported by ElastiCache. This level of control enables you to maintain compatibility with specific versions, test new versions with your application before deploying in production, and perform version upgrades on your own terms and timelines.

Because version upgrades might involve some compatibility risk, they don't occur automatically. You must initiate them.

Valkey and Redis OSS clusters

Note

• If a Valkey or Redis OSS cluster is replicated across one or more Regions, the engine version is upgraded for secondary Regions and then for the primary Region.

• ElastiCache for Redis OSS versions are identified with a semantic version which comprise a MAJOR and MINOR component. For example, in Redis OSS 6.2, the major version is 6, and the minor version 2. When operating self-designed clusters, ElastiCache for Redis OSS also exposes the PATCH component, e.g. Redis OSS 6.2.1, and the patch version is 1.

  MAJOR versions are for API incompatible changes and MINOR versions are for new functionality added in a backwards-compatible way. PATCH versions are for backwards-compatible bug fixes and non-functional changes.

With Valkey and Redis OSS, you initiate engine version upgrades to your cluster or replication group by modifying it and specifying a new engine version. For more information, see Modifying a replication group.

Memcached

With Memcached, to upgrade to a newer version you must modify your cache cluster and specify the new engine version you want to use. Upgrading to a newer Memcached version is a destructive process – you lose your data and start with a cold cache. For more information, see Modifying an ElastiCache cluster.

You should be aware of the following requirements when upgrading from an older version of Memcached to Memcached version 1.4.33 or newer. CreateCacheCluster and ModifyCacheCluster fails under the following conditions:

• If slab_chunk_max > max_item_size.

• If max_item_size modulo slab_chunk_max != 0.

• If max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).

  The value (max_cache_memory - memcached_connections_overhead) is the node's memory useable for data. For more information, see Memcached connection overhead.

Upgrade considerations when working with self-designed clusters

Note

The following considerations only apply when upgrading self-designed clusters. They do not apply to ElastiCache Serverless.

Valkey and Redis OSS considerations

When upgrading a self-designed Valkey or Redis OSS cluster, consider the following.

• Engine version management is designed so that you can have as much control as possible over how patching occurs. However, ElastiCache reserves the right to patch your cluster on your behalf in the unlikely event of a critical security vulnerability in the system or cache software.

• Beginning with ElastiCache version 7.2 for Valkey and ElastiCache version 6.0 for Redis OSS, ElastiCache will offer a single version for each minor release, rather than offering multiple patch versions.

• Starting with Redis OSS engine version 5.0.6, you can upgrade your cluster version with minimal downtime. The cluster is available for reads during the entire upgrade and is available for writes for most of the upgrade duration, except during the failover operation which lasts a few seconds.

• You can also upgrade your ElastiCache clusters with versions earlier than 5.0.6. The process involved is the same but may incur longer failover time during DNS propagation (30s-1m).

• Beginning with Redis OSS 7, ElastiCache supports switching between Valkey or Redis OSS (cluster mode disabled) and Valkey or Redis OSS (cluster mode enabled).

• The Amazon ElastiCache for Redis OSS engine upgrade process is designed to make a best effort to retain your existing data and requires successful Redis OSS replication.

• When upgrading the engine, ElastiCache will terminate existing client connections. To minimize downtime during engine upgrades, we recommend you implement best practices for Redis OSS clients with error retries and exponential backoff and the best practices for minimizing downtime during maintenance.

• You can't upgrade directly from Valkey or Redis OSS (cluster mode disabled) to Valkey or Redis OSS (cluster mode enabled) when you upgrade your engine. The following procedure shows you how to upgrade from Valkey or Redis OSS (cluster mode disabled) to Valkey or Redis OSS (cluster mode enabled).

  To upgrade from a Valkey or Redis OSS (cluster mode disabled) to Valkey or Redis OSS (cluster mode enabled) engine version

  1. Make a backup of your Valkey or Redis OSS (cluster mode disabled) cluster or replication group. For more information, see Taking manual backups.

  2. Use the backup to create and seed a Valkey or Redis OSS (cluster mode enabled) cluster with one shard (node group). Specify the new engine version and enable cluster mode when creating the cluster or replication group. For more information, see Tutorial: Seeding a new self-designed cluster with an externally created backup.

  3. Delete the old Valkey or Redis OSS (cluster mode disabled) cluster or replication group. For more information, see Deleting a cluster in ElastiCache or Deleting a replication group.

  4. Scale the new Valkey or Redis OSS (cluster mode enabled) cluster or replication group to the number of shards (node groups) that you need. For more information, see Scaling clusters in Valkey or Redis OSS (Cluster Mode Enabled)

• When upgrading major engine versions, for example from 5.0.6 to 6.0, you need to also choose a new parameter group that is compatible with the new engine version.

• For single Redis OSS clusters and clusters with Multi-AZ disabled, we recommend that sufficient memory be made available to Redis OSS as described in Ensuring you have enough memory to make a Valkey or Redis OSS snapshot. In these cases, the primary is unavailable to service requests during the upgrade process.

• For Redis OSS clusters with Multi-AZ enabled, we also recommend that you schedule engine upgrades during periods of low incoming write traffic. When upgrading to Redis OSS 5.0.6 or above, the primary cluster continues to be available to service requests during the upgrade process.

  Clusters and replication groups with multiple shards are processed and patched as follows:

  • All shards are processed in parallel. Only one upgrade operation is performed on a shard at any time.

  • In each shard, all replicas are processed before the primary is processed. If there are fewer replicas in a shard, the primary in that shard might be processed before the replicas in other shards are finished processing.

  • Across all the shards, primary nodes are processed in series. Only one primary node is upgraded at a time.

• If encryption is enabled on your current cluster or replication group, you cannot upgrade to an engine version that does not support encryption, such as from 3.2.6 to 3.2.10.

Memcached considerations

When upgrading a self-designed Memcached cluster, consider the following.

• Engine version management is designed so that you can have as much control as possible over how patching occurs. However, ElastiCache reserves the right to patch your cluster on your behalf in the unlikely event of a critical security vulnerability in the system or cache software.

• Because the Memcached engine does not support persistence, Memcached engine version upgrades are always a disruptive process that clears all cache data in the cluster.