# Engine versions and upgrading in ElastiCache This section covers the supported Valkey, Memcached, and Redis OSS engines and how to upgrade. Note that all features available with Redis OSS 7.2 are available in Valkey 7.2 and above by default. You can also upgrade from some existing ElastiCache for Redis OSS engines to a Valkey engine. # Upgrading engine versions including cross engine upgrades **Valkey and Redis OSS** With Valkey and Redis OSS, you initiate version upgrades to your cluster or replication group by modifying it using the ElastiCache console, the AWS CLI, or the ElastiCache API and specifying a newer engine version. You can also cross upgrade from Redis OSS to Valkey. For more information on cross upgrades, see [How to upgrade from Redis OSS to Valkey](#VersionManagement.HowTo.cross-engine-upgrade). **Topics** + [How to upgrade from Redis OSS to Valkey](#VersionManagement.HowTo.cross-engine-upgrade) + [Resolving blocked Valkey or Redis OSS engine upgrades](#resolving-blocked-engine-upgrades) **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html) **Memcached** With Memcached, to start version upgrades to your cluster, you modify it and specify a newer engine version. You can do this by using the ElastiCache console, the AWS CLI, or the ElastiCache API: + To use the AWS Management Console, see – [Using the ElastiCache AWS Management Console](Clusters.Modify.md#Clusters.Modify.CON). + To use the AWS CLI, see [Using the AWS CLI with ElastiCache](Clusters.Modify.md#Clusters.Modify.CLI). + To use the ElastiCache API, see [Using the ElastiCache API](Clusters.Modify.md#Clusters.Modify.API). ## How to upgrade from Redis OSS to Valkey Valkey is designed as a drop-in replacement for Redis OSS 7. You can upgrade from Redis OSS to Valkey using the Console, API, or CLI, by specifying the new engine and major engine version. The endpoint IP address and all other aspects of the application will not be changed by the upgrade. When upgrading from Redis OSS 5.0.6 and higher you will experience no downtime. **Note** **AWS CLI version requirements for Redis OSS to Valkey upgrades:** For AWSCLI v1: Minimum required version 1.35.2 (Current version: 1.40.22) For AWS CLI v2: Minimum required version 2.18.2 (Current version: 2.27.22) **Note** When upgrading from earlier Redis OSS versions than 5.0.6, you may experience a failover time of 30 to 60 seconds during the DNS propagation. To upgrade an existing Redis OSS (cluster mode disabled) single-node cluster to the Valkey engine, first follow these steps: [Creating a replication group using an existing cluster](Replication.CreatingReplGroup.ExistingCluster.md). Once the Redis OSS (cluster mode disabled) single-node cluster has been added to a replication group, you can cross-engine upgrade to Valkey. ### Upgrading a replication group from Redis OSS to Valkey If you have an existing Redis OSS replication group that is using the default cache parameter group, you can upgrade to Valkey by specifying the new engine and engine version with modify-replication-group API. For Linux, macOS, or Unix: ``` aws elasticache modify-replication-group \ --replication-group-id myReplGroup \ --engine valkey \ --engine-version 8.0 ``` For Windows: ``` aws elasticache modify-replication-group ^ --replication-group-id myReplGroup ^ --engine valkey ^ --engine-version 8.0 ``` If you have a custom cache parameter group applied to the existing Redis OSS replication group you wish to upgrade, you will need to pass a custom Valkey cache parameter group in the request as well. The input Valkey custom parameter group must have the same Redis OSS static parameter values as the existing Redis OSS custom parameter group. For Linux, macOS, or Unix: ``` aws elasticache modify-replication-group \ --replication-group-id myReplGroup \ --engine valkey \ --engine-version 8.0 \ --cache-parameter-group-name myParamGroup ``` For Windows: ``` aws elasticache modify-replication-group ^ --replication-group-id myReplGroup ^ --engine valkey ^ --engine-version 8.0 ^ --cache-parameter-group-name myParamGroup ``` ### Upgrading a Redis OSS serverless cache to Valkey with the CLI For Linux, macOS, or Unix: ``` aws elasticache modify-serverless-cache \ --serverless-cache-name myCluster \ --engine valkey \ --major-engine-version 8 ``` For Windows: ``` aws elasticache modify-serverless-cache ^ --serverless-cache-name myCluster ^ --engine valkey ^ --major-engine-version 8 ``` ### Upgrading Redis OSS to Valkey with the Console **Upgrading from Redis OSS 5 to Valkey** 1. Select the Redis OSS cache to upgrade. 1. An **Upgrade to Valkey** window should appear. Select the **Upgrade to Valkey** button. 1. Go to **Cache settings**, and then select **Engine version**. The most recent version of Valkey is recommended. 1. If this cache is serverless, then you will need to update the parameter group. Go to the **Parameter groups** area of **Cache settings**, select an appropriate parameter group such as *default.valkey8*. 1. Select **Upgrade**. This cache will now be listed in the Valkey area of the console. **Note** Upgrading directly from Redis OSS 4 or lower to Valkey may include a longer failover time of 30 to 60 seconds during the DNS propagation. ### How to downgrade from Valkey to Redis OSS If for any reason you wish to rollback your upgraded cluster, Amazon ElastiCache supports rolling back a Valkey 7.2 cache to Redis OSS 7.1. You can perform a rollback using the same console, API, or CLI steps as an engine upgrade and specifying Redis OSS 7.1 as the target engine version. Rollbacks use the same processes as an upgrade. The endpoint IP address and all other aspects of the application will not be changed by the rollback and you will experience no downtime. Additionally, you can restore a snapshot created from your Valkey 7.2 cache as a Redis OSS 7.1 cache. When you restore from a snapshot, you can specify Redis OSS 7.1 as the target engine version. When using this option, a new cache will be created from the snapshot. Restoring from a snapshot has no effect on the Valkey cache that the snapshot was created from. The following requirements and limitations apply when performing a rollback: + ElastiCache only supports rolling back from Valkey 7.2 to Redis OSS 7.1. This is true even if you upgraded to Valkey 7.2 from an earlier version than Redis OSS 7.1. + Any user group and user associated with the replication group or serverless cache being rolled back must be configured with engine type `REDIS`. ## Resolving blocked Valkey or Redis OSS engine upgrades As shown in the following table, your Valkey or Redis OSS engine upgrade operation is blocked if you have a pending scale up operation. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html) **To resolve a blocked Valkey or Redis OSS engine upgrade** + Do one of the following: + Schedule your Redis OSS or Valkey engine upgrade operation for the next maintenance window by clearing the **Apply immediately** check box. With the CLI, use `--no-apply-immediately`. With the API, use `ApplyImmediately=false`. + Wait until your next maintenance window (or after) to perform your Redis OSS engine upgrade operation. + Add the Redis OSS scale up operation to this cluster modification with the **Apply Immediately** check box chosen. With the CLI, use `--apply-immediately`. With the API, use `ApplyImmediately=true`. This approach effectively cancels the engine upgrade during the next maintenance window by performing it immediately. # ElastiCache Extended Support With ElastiCache Extended Support, you can continue running your cache on a major engine version past the end of standard support date for an additional cost. If you don't upgrade after the end of standard support date, you will be charged. Extended Support provides the following updates and technical support: + Security updates for critical and high CVEs for your cache and cache engine + Bug fixes and patches for critical issues + The ability to open support cases and receive troubleshooting help within the standard ElastiCache service level agreement This paid offering gives you more time to upgrade to a supported major engine version. For example, the ElastiCache end of standard support date for Redis OSS 4.0.10 is January 31, 2026. If you aren't ready to manually upgrade to Valkey or to Redis OSS 6 or later by that date, ElastiCache will automatically enroll your caches in Extended Support and you can continue to run Redis OSS 4.0.10. Starting the first day of the month after the standard support ends, February 1, 2026, ElastiCache automatically charges you for Extended Support. Extended Support is available for up to 3 years past the end of standard support date for a major engine version. For Elasticache for Redis OSS versions 4 and 5, that will be January 31, 2029. After this date, any caches still running Redis OSS versions 4 and 5 will be automatically upgraded to the latest version of Valkey. Once an engine’s support period ends, caches that continue to run that old version will automatically transition to Extended Support. You will be notified before the Extended Support pricing start date so you may upgrade your instance instead. You also can explicitly opt out at any time by upgrading to supported versions. For more information about the end of standard support dates and the end of Extended Support dates, see [ElastiCache versions for Redis OSS end of life schedule](engine-versions.md#deprecated-engine-versions) for Valkey, Memcached or Redis OSS. **Topics** + [ElastiCache Extended Support charges](extended-support-charges.md) + [Versions with ElastiCache Extended Support](extended-support-versions.md) + [ElastiCache and customer responsibilities with ElastiCache Extended Support](extended-support-responsibilities.md) # ElastiCache Extended Support charges You will incur charges for all engines enrolled in ElastiCache Extended Support beginning the day after the end of standard support. For the ElastiCache end of standard support date, see [Versions with ElastiCache Extended Support](extended-support-versions.md). The additional charge for ElastiCache Extended Support automatically stops when you take one of the following actions: + Upgrade to an engine version that's covered under standard support. + Delete the cache that's running a major version past the ElastiCache end of standard support date. The charges will restart if your target engine version enters Extended Support in the future. For example, let’s say ElastiCache version 4 for Redis OSS enters Extended Support on February 1, 2026, and you upgrade your caches on v4 to v6 on January 1, 2027. You will only be charged for 11 months of Extended Support, on ElastiCache version 4 for Redis OSS. If you continue running ElastiCache version 6 for Redis OSS past its end of standard support date of January 31, 2027, then those caches will again incur Extended Support charges starting on February 1, 2027. You can avoid being charged for ElastiCacheExtended Support by preventing ElastiCache from creating or restoring a cache past the ElastiCache end of standard support date. For more information, see [Amazon ElastiCache pricing](https://aws.amazon.com/elasticache/pricing/). # Versions with ElastiCache Extended Support Redis Open Source Software (OSS) versions 4 and 5 reached their community End of Life in 2020 and 2022, respectively. This means no further updates, bug fixes, or security patches are being released by the community. Standard support for ElastiCache Redis OSS versions 4 and 5 on ElastiCache will end on January 31, 2026. Continuing to use unsupported versions of Redis OSS could leave your data vulnerable to known [Common Vulnerabilities and Exposures](https://nvd.nist.gov/vuln-metrics/cvss) (CVEs). Starting on February 1, 2026, ElastiCache caches still running on Redis OSS versions 4 and 5 will be automatically enrolled in Extended Support, to provide continuous availability and security. Although Extended Support offers flexibility, we recommend treating the end of standard support as a planning milestone for your production workloads. We strongly encourage you to upgrade your Redis OSS v4 and v5 caches to ElastiCache for Valkey or Redis OSS v6 or later, before the end of standard support. The following table summarizes the Amazon ElastiCache end of standard support date and Extended Support dates. **Extended support and End of Life schedule** | Major Engine Version | End of Standard Support | Start of Extended Support Y1 Premium | Start of Extended Support Y2 Premium | Start of Extended Support Y3 Premium | End of Extended Support and version EOL | | --- | --- | --- | --- | --- | --- | | Redis OSS v4 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 | | Redis OSS v5 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 | | Redis OSS v6 | 1/31/2027 | 2/1/2027 | 2/1/2028 | 2/1/2029 | 1/31/2030 | Extended Support will only be offered for the latest supported patch version of each major Redis OSS version. When Extended Support begins on February 1, 2026, if your Redis OSS v4 and v5 clusters are not already on the latest patch versions, they will be automatically upgraded to v4.0.10 for Redis OSS v4, and v5.0.6 for Redis OSS v5, before being enrolled in Extended Support. This ensures that you receive security updates and bug fixes through Extended Support. You do not need to take any action to upgrade to these latest patch versions as part of the Extended Support transition. # ElastiCache and customer responsibilities with ElastiCache Extended Support Following are the responsibilities of Amazon ElastiCache, and your responsibilities with ElastiCache Extended Support. **Amazon ElastiCache responsibilities** After the ElastiCache end of standard support date, Amazon ElastiCache will supply patches, bug fixes, and upgrades for engines that are enrolled in ElastiCache Extended Support. This will occur for up to 3 years, or until you stop using the engines in Extended Support, whichever happens first. **Your responsibilities** You're responsible for applying the patches, bug fixes, and upgrades given for caches in ElastiCache Extended Support. Amazon ElastiCache reserves the right to change, replace, or withdraw such patches, bug fixes, and upgrades at any time. If a patch is necessary to address security or critical stability issues, Amazon ElastiCache reserves the right to update your caches with the patch, or to require that you install the patch. You're also responsible for upgrading your engine to a newer engine version before the ElastiCache end of Extended Support date. The ElastiCache end of Extended Support date is typically 3 years after the ElastiCache end of standard support date. If you don't upgrade your engine, then after the ElastiCache end of Extended Support date, Amazon ElastiCache will attempt to upgrade your engine to a newer engine version that's supported under ElastiCache standard support. If the upgrade fails, then Amazon ElastiCache reserves the right to delete the cache that's running the engine past the ElastiCache end of standard support date. However, before doing so, Amazon ElastiCache will preserve your data from that engine. # Version Management for ElastiCache Manage how you would like to update your ElastiCache caches and node-based 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. Similar to minor and patch upgrades, major version upgrades are performed without downtime to your application. ## Version management for node-based ElastiCache clusters When working with node-based ElastiCache clusters, you can control when the software powering your 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 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 node-based 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](Replication.Modify.md). **Memcached** With Memcached, to upgrade to a newer version you must modify your 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](Clusters.Modify.md). 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](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead). ## Supported engines and versions ElastiCache serverless caches support ElastiCache version 7.2 for Valkey and above, ElastiCache version 1.6 for Memcached and above, and ElastiCache 7.0 for Redis OSS and above. Node-based ElastiCache clusters support ElastiCache version 7.2 for Valkey and above, ElastiCache version 1.4.5 for Memcached and above, and ElastiCache 4.0.10 for Redis OSS and above. **Topics** + [Supported Valkey versions](#supported-engine-versions.valkey) + [Valkey 8.2](#valkey-version-8.2) + [Valkey 8.1](#valkey-version-8.1) + [Valkey 8.0](#valkey-version-8) + [ElastiCache version 7.2.6 for Valkey](#valkey-version-7.2.6) ### Supported Valkey versions Supported Valkey versions below. Note that Valkey supports most features available in ElastiCache version 7.2 for Redis OSS by default. + 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](BestPractices.Clients.redis.md) with error retries and exponential backoff and the best practices for [minimizing downtime during maintenance](BestPractices.MinimizeDowntime.md). + 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](backups-manual.md). 1. 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 node-based cluster with an externally created backup](backups-seeding-redis.md). 1. Delete the old Valkey or Redis OSS (cluster mode disabled) cluster or replication group. For more information, see [Deleting a cluster in ElastiCache](Clusters.Delete.md) or [Deleting a replication group](Replication.DeletingRepGroup.md). 1. 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 Valkey or Redis OSS (Cluster Mode Enabled) clusters](scaling-redis-cluster-mode-enabled.md) + 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](BestPractices.BGSAVE.md). 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 node-based 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. ### ElastiCache version 8.2 for Valkey Here are some of the new features introduced in Valkey 8.2 (compared to ElastiCache Valkey 8.1): + ElastiCache for Valkey v8.2 provides native support for [vector search](vector-search.md), delivering latency as low as microseconds-the lowest latency vector search with the highest throughput and best price-performance at 95%\$1 recall rate among popular vector databases on AWS. For more information on Valkey, see [Valkey](https://valkey.io/). ElastiCache version 8.2 for Valkey enhances Valkey 8.1 with vector search capabilities based on [valkey-search module](https://github.com/valkey-io/valkey-search). For more information on the Valkey 8.2 release, see [release notes](https://github.com/valkey-io/valkey-search/blob/main/00-RELEASENOTES) for valkey-search. Please note that ElastiCache v8.2 is compatible with Valkey v8.1. ### ElastiCache version 8.1 for Valkey Here are some of the new features introduced in Valkey 8.1 (compared to ElastiCache Valkey 8.0): + A [new hash table](https://valkey.io/blog/new-hash-table/) implementation that reduces memory overhead to lower memory usage by as much as 20% for common key/value patterns. + Native support for [Bloom filters](https://valkey.io/topics/bloomfilters/), a new data type allowing you to perform lookups using as much as 98% less memory compared to using the Set data type. + New command [COMMANDLOG](https://valkey.io/commands/commandlog-get/) that records slow executions, large requests, and large replies. + New conditional update support to the SET command using IFEQ argument. + Performance improvements, including up to 45% lower latency for the ZRANK command, up to 12x faster performance for PFMERGE and PFCOUNT, and up to 514% higher throughput for BITCOUNT. For more information on Valkey, see [Valkey](https://valkey.io/) For more information on the Valkey 8.1 release, see [Valkey 8.1 Release Notes](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES) ### ElastiCache version 8.0 for Valkey Here are some of the new features introduced in Valkey 8.0 (compared to ElastiCache Valkey 7.2.6): + Memory efficiency improvements, allowing users to store up to 20% more data per node without any application changes. + Newly-introduced per-slot metrics infrastructure for node-based clusters, providing detailed visibility into the performance and resource usage of individual slots. + ElastiCache Serverless for Valkey 8.0 can double the supported requests per second (RPS) every 2-3 minutes, reaching 5M RPS per cache from zero in under 13 minutes, with consistent sub-millisecond p50 read latency. For more information on Valkey, see [Valkey](https://valkey.io/) For more information on the Valkey 8 release, see [Valkey 8 Release Notes](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES) ### ElastiCache version 7.2.6 for Valkey On October 10 2024, ElastiCache version 7.2.6 for Valkey was released. Here are some of the new features introduced in 7.2 (compared to ElastiCache version 7.1 for Redis OSS): + Performance and memory optimizations for various data types: memory optimization for list and set type keys, speed optimization for sorted sets commands, performance optimization for commands with multiple keys in cluster mode, pub/sub performance improvements, performance optimization for SCAN, SSCAN, HSCAN, ZSCAN commands and numerous other smaller optimizations. + New WITHSCORE option for ZRANK and ZREVRANK commands + CLIENT NO-TOUCH for clients to run commands without affecting LRU/LFU of keys. + New command CLUSTER MYSHARDID that returns the Shard ID of the node to logically group nodes in cluster mode based on replication. For more information on Valkey, see [Valkey](https://valkey.io/) For more information on the ElastiCache version 7.2 for Valkey release, see [Redis OSS 7.2.4 Release Notes](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (ElastiCache version 7.2 for Valkey includes all changes from ElastiCache version 7.1 for Redis OSS up to ElastiCache version 7.2.4 for Redis OSS). [Valkey 7.2 release notes](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) at Valkey on GitHub. ## ElastiCache version 8.2 for Valkey Here are some of the new features introduced in Valkey 8.2 (compared to ElastiCache Valkey 8.1): + ElastiCache for Valkey v8.2 provides native support for [vector search](vector-search.md), delivering latency as low as microseconds-the lowest latency vector search with the highest throughput and best price-performance at 95%\$1 recall rate among popular vector databases on AWS. For more information on Valkey, see [Valkey.](https://valkey.io/) ElastiCache version 8.2 for Valkey enhances Valkey 8.1 with vector search capabilities based on [valkey-search module](https://github.com/valkey-io/valkey-search). For more information on the Valkey 8.2 release, see [release notes](https://github.com/valkey-io/valkey-search/blob/main/00-RELEASENOTES) for valkey-search. Please note that ElastiCache v8.2 is compatible with Valkey v8.1. ## ElastiCache version 8.1 for Valkey Here are some of the new features introduced in Valkey 8.1 (compared to ElastiCache Valkey 8.0): + A [new hash table](https://valkey.io/blog/new-hash-table/) implementation that reduces memory overhead to lower memory usage by as much as 20% for common key/value patterns. + Native support for [Bloom filters](https://valkey.io/topics/bloomfilters/), a new data type allowing you to perform lookups using as much as 98% less memory compared to using the Set data type. + New command [COMMANDLOG](https://valkey.io/commands/commandlog-get/) that records slow executions, large requests, and large replies. + New conditional update support to the SET command using IFEQ argument. + Performance improvements, including up to 45% lower latency for the ZRANK command, up to 12x faster performance for PFMERGE and PFCOUNT, and up to 514% higher throughput for BITCOUNT. For more information on Valkey, see [Valkey](https://valkey.io/) For more information on the Valkey 8.1 release, see [Valkey 8.1 Release Notes](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES) ## ElastiCache version 8.0 for Valkey Here are some of the new features introduced in Valkey 8.0 (compared to ElastiCache Valkey 7.2.6): + Memory efficiency improvements, allowing users to store up to 20% more data per node without any application changes. + Newly-introduced per-slot metrics infrastructure for node-based clusters, providing detailed visibility into the performance and resource usage of individual slots. + ElastiCache Serverless for Valkey 8.0 can double the supported requests per second (RPS) every 2-3 minutes, reaching 5M RPS per cache from zero in under 13 minutes, with consistent sub-millisecond p50 read latency. For more information on Valkey, see [Valkey](https://valkey.io/) For more information on the Valkey 8 release, see [Valkey 8 Release Notes](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES) ## ElastiCache version 7.2.6 for Valkey On October 10 2024, ElastiCache version 7.2.6 for Valkey was released. Here are some of the new features introduced in 7.2 (compared to ElastiCache version 7.1 for Redis OSS): + Performance and memory optimizations for various data types: memory optimization for list and set type keys, speed optimization for sorted sets commands, performance optimization for commands with multiple keys in cluster mode, pub/sub performance improvements, performance optimization for SCAN, SSCAN, HSCAN, ZSCAN commands and numerous other smaller optimizations. + New WITHSCORE option for ZRANK and ZREVRANK commands + CLIENT NO-TOUCH for clients to run commands without affecting LRU/LFU of keys. + New command CLUSTER MYSHARDID that returns the Shard ID of the node to logically group nodes in cluster mode based on replication. For more information on Valkey, see [Valkey](https://valkey.io/) For more information on the ElastiCache version 7.2 for Valkey release, see [Redis OSS 7.2.4 Release Notes](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (ElastiCache version 7.2 for Valkey includes all changes from ElastiCache version 7.1 for Redis OSS up to ElastiCache version 7.2.4 for Redis OSS). [Valkey 7.2 release notes](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) at Valkey on GitHub. ## Supported Redis OSS engine versions ElastiCache Serverless caches and node-based clusters support all Redis OSS versions 7.1 and before. + [ElastiCache version 7.1 for Redis OSS (enhanced)](#redis-version-7.1) **Topics** + [ElastiCache version 7.1 for Redis OSS (enhanced)](#redis-version-7.1) + [ElastiCache version 7.0 for Redis OSS (enhanced)](#redis-version-7.0) + [ElastiCache version 6.2 for Redis OSS (enhanced)](#redis-version-6.2) + [ElastiCache version 6.0 for Redis OSS (enhanced)](#redis-version-6.0) + [ElastiCache version 5.0.6 for Redis OSS (enhanced)](#redis-version-5-0.6) + [ElastiCache version 5.0.5 for Redis OSS (deprecated, use version 5.0.6)](#redis-version-5-0.5) + [ElastiCache version 5.0.4 for Redis OSS (deprecated, use version 5.0.6)](#redis-version-5-0.4) + [ElastiCache version 5.0.3 for Redis OSS (deprecated, use version 5.0.6)](#redis-version-5-0.3) + [ElastiCache version 5.0.0 for Redis OSS (deprecated, use version 5.0.6)](#redis-version-5-0) + [ElastiCache version 4.0.10 for Redis OSS (enhanced)](#redis-version-4-0-10) + [Past End of Life (EOL) versions (3.x)](#redis-version-3-2-10-scheduled-eol) + [Past End of Life (EOL) versions (2.x)](#redis-version-2-x-eol) ### ElastiCache version 7.1 for Redis OSS (enhanced) This release contains performance improvements which enable workloads to drive higher throughput and lower operation latencies. ElastiCache version 7.1 for Redis OSS introduces [two main enhancements](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/) : We extended the enhanced I/O threads functionality to also handle the presentation layer logic. By presentation layer, we mean the Enhanced I/O threads which are now not only reading client input, but also parsing the input into Redis OSS binary command format. This is then forwarded to the main thread for execution which provides performance gain. Improved Redis OSS memory access pattern. Execution steps from many data structure operations are interleaved, to ensure parallel memory access and reduced memory access latency. When running ElastiCache on Graviton3-based `R7g.4xlarge` or larger, customers can achieve over 1 million requests per second per node. With the performance improvements to ElastiCache for Redis OSS v7.1, customers can achieve up to 100% more throughput and 50% lower P99 latency relative to ElastiCache for Redis OSS v7.0. These enhancements are enabled on node sizes with at least 8 physical cores (`2xlarge` on Graviton, and `4xlarge` on x86), regardless of the CPU type and require no client changes. **Note** ElastiCache v7.1 is compatible with Redis OSS v7.0. ### ElastiCache version 7.0 for Redis OSS (enhanced) ElastiCache for Redis OSS 7.0 adds a number of improvements and support for new functionality: + [Functions](https://valkey.io/topics/functions-intro/): ElastiCache for Redis OSS 7 adds support for Redis OSS Functions, and provides a managed experience enabling developers to execute [LUA scripts](https://valkey.io/topics/eval-intro/) with application logic stored on the ElastiCache cluster, without requiring clients to re-send the scripts to the server with every connection. + [ACL improvements](https://valkey.io/topics/acl/): Valkey and Redis OSS 7 adds support for the next version of Access Control Lists (ACLs). Clients can now specify multiple sets of permissions on specific keys or keyspaces in Valkey and Redis OSS. + [Sharded Pub/Sub](https://valkey.io/topics/pubsub/): ElastiCache for Valkey and Redis OSS 7 adds support to run Pub/Sub functionality in a sharded way when running ElastiCache in Cluster Mode Enabled (CME). Pub/Sub capabilities enable publishers to issue messages to any number of subscribers on a channel. Channels are bound to a shard in the ElastiCache cluster, eliminating the need to propagate channel information across shards resulting in improved scalability. + Enhanced I/O multiplexing: ElastiCache for Valkey and Redis OSS 7 introduces enhanced I/O multiplexing, which delivers increased throughput and reduced latency for high-throughput workloads that have many concurrent client connections to an ElastiCache cluster. For example, when using a cluster of r6g.xlarge nodes and running 5200 concurrent clients, you can achieve up to 72% increased throughput (read and write operations per second) and up to 71% decreaseed P99 latency, compared with ElastiCache version 6 for Redis OSS. For more information on Valkey, see [Valkey](https://valkey.io/). For more information on the Redis OSS 7.0 release, see [Redis OSS 7.0 Release Notes](https://github.com/redis/redis/blob/7.0/00-RELEASENOTES) at Redis OSS on GitHub. ### ElastiCache version 6.2 for Redis OSS (enhanced) ElastiCache for Redis OSS 6.2 includes performance improvements for TLS-enabled clusters using x86 node types with 8 vCPUs or more or Graviton2 node types with 4 vCPUs or more. These enhancements improve throughput and reduce client connection establishment time by offloading encryption to other vCPUs. With Redis OSS 6.2, you can also manage access to Pub/Sub channels with Access Control List (ACL) rules. With this version, we also introduce support for data tiering on cluster nodes containing locally attached NVMe SSD. For more information, see [Data tiering in ElastiCache](data-tiering.md). Redis OSS engine version 6.2.6 also introduces support for native JavaScript Object Notation (JSON) format, a simple, schemaless way to encode complex datasets inside Redis OSS clusters. With JSON support, you can leverage the performance and Redis OSS APIs for applications that operate over JSON. For more information, see [Getting started with JSON](json-gs.md). Also included are JSON-related metrics, `JsonBasedCmds` and `JsonBasedCmdsLatency`, that are incorporated into CloudWatch to monitor the usage of this datatype. For more information, see [Metrics for Valkey and Redis OSS](CacheMetrics.Redis.md). You specify the engine version by using 6.2. ElastiCache will automatically invoke the preferred patch version of Redis OSS 6.2 that is available. For example, when you create/modify a cluster, you set the `--engine-version` parameter to 6.2. The cluster will be launched with the current available preferred patch version of Redis OSS 6.2 at the creation/modification time. Specifying engine version 6.x in the API will result in the latest minor version of Redis OSS 6. For existing 6.0 clusters, you can opt-in to the next auto minor version upgrade by setting the `AutoMinorVersionUpgrade` parameter to `yes` in the `CreateCacheCluster`, `ModifyCacheCluster`, `CreateReplicationGroup` or `ModifyReplicationGroup` APIs. ElastiCache will upgrade the minor version of your existing 6.0 clusters to 6.2 using self-service updates. For more information, see [Self-service updates in Amazon ElastiCache](Self-Service-Updates.md). When calling the DescribeCacheEngineVersions API, the `EngineVersion` parameter value will be set to 6.2 and the actual engine version with the patch version will be returned in the `CacheEngineVersionDescription` field. For more information on the Redis OSS 6.2 release, see [Redis OSS 6.2 Release Notes](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES) at Redis OSS on GitHub. ### ElastiCache version 6.0 for Redis OSS (enhanced) Amazon ElastiCache introduces the next version of ElastiCache for the Redis OSS engine, which includes [Authenticating Users with Role Based Access Control](Clusters.RBAC.md), client-side caching and significant operational improvements. Beginning with Redis OSS 6.0, ElastiCache will offer a single version for each Redis OSS minor release, rather than offering multiple patch versions. ElastiCache will automatically manage the patch version of your running clusters, ensuring improved performance and enhanced security. You can also opt-in to the next auto minor version upgrade by setting the `AutoMinorVersionUpgrade` parameter to `yes` and ElastiCache will manage the minor version upgrade, through self-service updates. For more information, see [Service updates in ElastiCache](Self-Service-Updates.md). You specify the engine version by using `6.0`. ElastiCache will automatically invoke the preferred patch version of Redis OSS 6.0 that is available. For example, when you create/modify a cluster, you set the `--engine-version` parameter to 6.0. The cluster will be launched with the current available preferred patch version of Redis OSS 6.0 at the creation/modification time. Any request with a specific patch version value will be rejected, an exception will be thrown and the process will fail. When calling the DescribeCacheEngineVersions API, the `EngineVersion` parameter value will be set to 6.0 and the actual engine version with the patch version will be returned in the `CacheEngineVersionDescription` field. For more information on the Redis OSS 6.0 release, see [Redis OSS 6.0 Release Notes](https://github.com/redis/redis/blob/6.0/00-RELEASENOTES) at Redis OSS on GitHub. ### ElastiCache version 5.0.6 for Redis OSS (enhanced) Amazon ElastiCache introduces the next version of ElastiCache for the Redis OSS engine, which includes bug fixes and the following cumulative updates: + Engine stability guarantee in special conditions. + Improved Hyperloglog error handling. + Enhanced handshake commands for reliable replication. + Consistent message delivery tracking via `XCLAIM` command. + Improved `LFU `field management in objects. + Enhanced transaction management when using `ZPOP`. + Ability to rename commands: A parameter called `rename-commands` that allows you to rename potentially dangerous or expensive Redis OSS commands that might cause accidental data loss, such as `FLUSHALL` or `FLUSHDB`. This is similar to the rename-command configuration in open source Redis OSS. However, ElastiCache has improved the experience by providing a fully managed workflow. The command name changes are applied immediately, and automatically propagated across all nodes in the cluster that contain the command list. There is no intervention required on your part, such as rebooting nodes. The following examples demonstrate how to modify existing parameter groups. They include the `rename-commands` parameter, which is a space-separated list of commands you want to rename: ``` aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group --parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region ``` In this example, the *rename-commands* parameter is used to rename the `flushall` command to `restrictedflushall`. To rename multiple commands, use the following: ``` aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group --parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall flushdb restrictedflushdb''" --region region ``` To revert any change, re-run the command and exclude any renamed values from the `ParameterValue` list that you want to retain, as shown following: ``` aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group --parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region ``` In this case, the `flushall` command is renamed to `restrictedflushall` and any other renamed commands revert to their original command names. **Note** When renaming commands, you are restricted to the following limitations: All renamed commands should be alphanumeric. The maximum length of new command names is 20 alphanumeric characters. When renaming commands, ensure that you update the parameter group associated with your cluster. To prevent a command's use entirely, use the keyword `blocked`, as shown following: ``` aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group --parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall blocked'" --region region ``` For more information on the parameter changes and a list of what commands are eligible for renaming, see [Redis OSS 5.0.3 parameter changes](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3). + Redis OSS Streams: This models a log data structure that allows producers to append new items in real time. It also allows consumers to consume messages either in a blocking or nonblocking fashion. Streams also allow consumer groups, which represent a group of clients to cooperatively consume different portions of the same stream of messages, similar to [Apache Kafka](https://kafka.apache.org/documentation/). For more information, see [Streams](https://valkey.io/topics/streams-intro). + Support for a family of stream commands, such as `XADD`, `XRANGE` and `XREAD`. For more information, see [Streams Commands](https://valkey.io/commands/#stream). + A number of new and renamed parameters. For more information, see [Redis OSS 5.0.0 parameter changes](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0). + A new Redis OSS metric, `StreamBasedCmds`. + Slightly faster snapshot time for Redis OSS nodes. **Important** ElastiCache has back-ported two critical bug fixes from [Redis OSS open source version 5.0.1](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES). They are listed following: RESTORE mismatch reply when certain keys have already expired. The `XCLAIM` command can potentially return a wrong entry or desynchronize the protocol. Both of these bug fixes are included in ElastiCache for Redis OSS support for Redis OSS engine version 5.0.0 and are consumed in future version updates. For more information, see [Redis OSS 5.0.6 Release Notes](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) at Redis OSS on GitHub. ### ElastiCache version 5.0.5 for Redis OSS (deprecated, use version 5.0.6) Amazon ElastiCache introduces the next version of ElastiCache for the Redis OSS engine;. It includes online configuration changes for ElastiCache of auto-failover clusters during all planned operations. You can now scale your cluster, upgrade the Redis OSS engine version and apply patches and maintenance updates while the cluster stays online and continues serving incoming requests. It also includes bug fixes. For more information, see [Redis OSS 5.0.5 Release Notes](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) at Redis OSS on GitHub. ### ElastiCache version 5.0.4 for Redis OSS (deprecated, use version 5.0.6) Amazon ElastiCache introduces the next version of the Redis OSS engine supported by ElastiCache. It includes the following enhancements: + Engine stability guarantee in special conditions. + Improved Hyperloglog error handling. + Enhanced handshake commands for reliable replication. + Consistent message delivery tracking via `XCLAIM` command. + Improved `LFU `field management in objects. + Enhanced transaction management when using `ZPOP`. For more information, see [Redis OSS 5.0.4 Release Notes](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) at Redis OSS on GitHub. ### ElastiCache version 5.0.3 for Redis OSS (deprecated, use version 5.0.6) Amazon ElastiCache introduces the next version of ElastiCache for the Redis OSS engine, which includes bug fixes. ### ElastiCache version 5.0.0 for Redis OSS (deprecated, use version 5.0.6) Amazon ElastiCache introduces the next major version of ElastiCache for the Redis OSS engine. ElastiCache version 5.0.0 for Redis OSS brings support for the following improvements: + Redis OSS Streams: This models a log data structure that allows producers to append new items in real time. It also allows consumers to consume messages either in a blocking or nonblocking fashion. Streams also allow consumer groups, which represent a group of clients to cooperatively consume different portions of the same stream of messages, similar to [Apache Kafka](https://kafka.apache.org/documentation/). For more information, see [Streams](https://valkey.io/topics/streams-intro). + Support for a family of stream commands, such as `XADD`, `XRANGE` and `XREAD`. For more information, see [Streams Commands](https://valkey.io/commands/#stream). + A number of new and renamed parameters. For more information, see [Redis OSS 5.0.0 parameter changes](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0). + A new Redis OSS metric, `StreamBasedCmds`. + Slightly faster snapshot time for Redis OSS nodes. ### ElastiCache version 4.0.10 for Redis OSS (enhanced) Amazon ElastiCache introduces the next major version of ElastiCache for the Redis OSS engine. ElastiCache version 4.0.10 for Redis OSS brings support for the following improvements: + Both online cluster resizing and encryption in a single ElastiCache version. For more information, see the following: + [Scaling Valkey or Redis OSS (Cluster Mode Enabled) clusters](scaling-redis-cluster-mode-enabled.md) + [Online resharding for Valkey or Redis OSS (cluster mode enabled)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) + [Data security in Amazon ElastiCache](encryption.md) + A number of new parameters. For more information, see [Redis OSS 4.0.10 parameter changes](ParameterGroups.Engine.md#ParameterGroups.Redis.4-0-10). + Support for family of memory commands, such as `MEMORY`. For more information, see [Commands](https://valkey.io/commands) (search on MEMO). + Support for memory defragmentation while online thus allowing more efficient memory utilization and more memory available for your data. + Support for asynchronous flushes and deletes. ElastiCache for Redis OSS supports commands like `UNLINK`, `FLUSHDB` and `FLUSHALL` to run in a different thread from the main thread. Doing this helps improve performance and response times for your applications by freeing memory asynchronously. + A new Redis OSS metric, `ActiveDefragHits`. For more information, see [Metrics for Redis OSS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CacheMetrics.Redis.html). Redis OSS (cluster mode disabled) users running ElastiCache version 3.2.10 for Redis OSS can use the console to upgrade their clusters via online upgrade. **Comparing ElastiCache cluster resizing and encryption support** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/engine-versions.html) ### Past End of Life (EOL) versions (3.x) #### ElastiCache version 3.2.10 for Redis OSS (enhanced) Amazon ElastiCache introduces the next major version of ElastiCache for the Redis OSS engine. ElastiCache version 3.2.10 for Redis OSS (enchanced) introduces online cluster resizing to add or remove shards from the cluster while it continues to serve incoming I/O requests. ElastiCache for Redis OSS 3.2.10 users have all the functionality of earlier Redis OSS versions except the ability to encrypt their data. This ability is currently available only in version 3.2.6. **Comparing ElastiCache versions 3.2.6 and 3.2.10 for Redis OSS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/engine-versions.html) For more information, see the following: + [Online resharding for Valkey or Redis OSS (cluster mode enabled)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) + [Online cluster resizing](best-practices-online-resharding.md) #### ElastiCache version 3.2.6 for Redis OSS (enhanced) Amazon ElastiCache introduces the next major version of ElastiCache for the Redis OSS engine. ElastiCache version 3.2.6 for Redis OSS users have access to all the functionality of earlier Redis OSS versions, plus the option to encrypt their data. For more information, see the following: + [ElastiCache in-transit encryption (TLS)](in-transit-encryption.md) + [At-Rest Encryption in ElastiCache](at-rest-encryption.md) + [Compliance validation for Amazon ElastiCache](elasticache-compliance.md) #### ElastiCache version 3.2.4 for Redis OSS (enhanced) Amazon ElastiCache version 3.2.4 introduces the next major version of ElastiCache for the Redis OSS engine. ElastiCache 3.2.4 users have all the functionality of earlier Redis OSS versions available to them, plus the option to run in *cluster mode* or *non-cluster mode*. The following table summarizes . **Comparing Redis OSS 3.2.4 non-cluster mode and cluster mode** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/engine-versions.html) **Notes:** + **Partitioning** – the ability to split your data across 2 to 500 node groups (shards) with replication support for each node group. + **Geospatial indexing** – Redis OSS 3.2.4 introduces support for geospatial indexing via six GEO commands. For more information, see the Redis OSS GEO\$1 command documentation [Commands: GEO](http://valkey.io/commands#geo) on the Valkey Commands page (filtered for GEO). For information about additional Redis OSS 3 features, see [Redis OSS 3.2 release notes](https://github.com/redis/redis/blob/3.2/00-RELEASENOTES) and [Redis OSS 3.0 release notes](https://github.com/redis/redis/blob/3.0/00-RELEASENOTES). Currently ElastiCache managed Valkey or Redis OSS (cluster mode enabled) does not support the following Redis OSS 3.2 features: + Replica migration + Cluster rebalancing + Lua debugger ElastiCache disables the following Redis OSS 3.2 management commands: + `cluster meet` + `cluster replicate` + `cluster flushslots` + `cluster addslots` + `cluster delslots` + `cluster setslot` + `cluster saveconfig` + `cluster forget` + `cluster failover` + `cluster bumpepoch` + `cluster set-config-epoch` + `cluster reset` For information about Redis OSS 3.2.4 parameters, see [Redis OSS 3.2.4 parameter changes](ParameterGroups.Engine.md#ParameterGroups.Redis.3-2-4). ### Past End of Life (EOL) versions (2.x) #### ElastiCache version 2.8.24 for Redis OSS (enhanced) Redis OSS improvements added since version 2.8.23 include bug fixes and logging of bad memory access addresses. For more information, see [Redis OSS 2.8 release notes](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). #### ElastiCache version 2.8.23 for Redis OSS (enhanced) Redis OSS improvements added since version 2.8.22 include bug fixes. For more information, see [Redis OSS 2.8 release notes](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). This release also includes support for the new parameter `close-on-slave-write` which, if enabled, disconnects clients who attempt to write to a read-only replica. For more information on Redis OSS 2.8.23 parameters, see [Redis OSS 2.8.23 (enhanced) added parameters](ParameterGroups.Engine.md#ParameterGroups.Redis.2-8-23) in the ElastiCache User Guide. #### ElastiCache version 2.8.22 for Redis OSS (enhanced) Redis OSS improvements added since version 2.8.21 include the following: + Support for forkless backups and synchronizations, which allows you to allocate less memory for backup overhead and more for your application. For more information, see [How synchronization and backup are implemented](Replication.Redis.Versions.md). The forkless process can impact both latency and throughput. When there is high write throughput, when a replica re-syncs, it can be unreachable for the entire time it is syncing. + If there is a failover, replication groups now recover faster because replicas perform partial syncs with the primary rather than full syncs whenever possible. Additionally, both the primary and replicas no longer use the disk during syncs, providing further speed gains. + Support for two new CloudWatch metrics. + `ReplicationBytes` – The number of bytes a replication group's primary cluster is sending to the read replicas. + `SaveInProgress` – A binary value that indicates whether or not there is a background save process running. For more information, see [Monitoring use with CloudWatch Metrics](CacheMetrics.md). + A number of critical bug fixes in replication PSYNC behavior. For more information, see [Redis OSS 2.8 release notes](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). + To maintain enhanced replication performance in Multi-AZ replication groups and for increased cluster stability, non-ElastiCache replicas are no longer supported. + To improve data consistency between the primary cluster and replicas in a replication group, the replicas no longer evict keys independent of the primary cluster. + Redis OSS configuration variables `appendonly` and `appendfsync` are not supported on Redis OSS version 2.8.22 and later. + In low-memory situations, clients with a large output buffer might be disconnected from a replica cluster. If disconnected, the client needs to reconnect. Such situations are most likely to occur for PUBSUB clients. #### ElastiCache version 2.8.21 for Redis OSS Redis OSS improvements added since version 2.8.19 include a number of bug fixes. For more information, see [Redis OSS 2.8 release notes](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). #### ElastiCache version 2.8.19 for Redis OSS Redis OSS improvements added since version 2.8.6 include the following: + Support for HyperLogLog. For more information, see [Redis OSS new data structure: HyperLogLog](http://antirez.com/news/75). + The sorted set data type now has support for lexicographic range queries with the new commands `ZRANGEBYLEX`, `ZLEXCOUNT`, and `ZREMRANGEBYLEX`. + To prevent a primary node from sending stale data to replica nodes, the master SYNC fails if a background save (`bgsave`) child process is aborted. + Support for the *HyperLogLogBasedCommands* CloudWatch metric. For more information, see [Metrics for Valkey and Redis OSS](CacheMetrics.Redis.md). #### ElastiCache version 2.8.6 for Redis OSS Redis OSS improvements added since version 2.6.13 include the following: + Improved resiliency and fault tolerance for read replicas. + Support for partial resynchronization. + Support for user-defined minimum number of read replicas that must be available at all times. + Full support for pub/sub—notifying clients of events on the server. + Automatic detection of a primary node failure and failover of your primary node to a secondary node. #### ElastiCache version 2.6.13 for Redis OSS ElastiCache version 2.6.13 for Redis OSS was the initial version of ElastiCache that supported Redis OSS. Multi-AZ is not supported on ElastiCache version 2.6.13 for Redis OSS. ## ElastiCache versions for Redis OSS end of life schedule This section defines end of life (EOL) dates for older major versions as they are announced. This allows you to make version and upgrade decisions for the future. **Note** ElastiCache versions from 5.0.0 to 5.0.5 for Redis OSS are deprecated. Use versions 5.0.6 or greater. The following table shows the schedule of [Extended Support](extended-support.md) for ElastiCache for Redis OSS engines. **Extended Support and End of Life schedule** | Major Engine Version | End of Standard Support | Start of Extended Support Y1 Premium | Start of Extended Support Y2 Premium | Start of Extended Support Y3 Premium | End of Extended Support and version EOL | | --- | --- | --- | --- | --- | --- | | Redis OSS v4 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 | | Redis OSS v5 | 1/31/2026 | 2/1/2026 | 2/1/2027 | 2/1/2028 | 1/31/2029 | | Redis OSS v6 | 1/31/2027 | 2/1/2027 | 2/1/2028 | 2/1/2029 | 1/31/2030 | The following table summarizes each version and its announced EOL date, as well as the recommended upgrade target version. **Past EOL** | Source Major Version | Source Minor Versions | Recommended Upgrade Target | EOL Date | | --- | --- | --- | --- | | Version 3 | 3.2.4, 3.2.6 and 3.2.10 | Version 6.2 or higher For US-ISO-EAST-1, US-ISO-WEST-1, and US-ISOB-EAST-1 Regions, we recommend 5.0.6 or higher. | July 31, 2023 | | Version 2 | 2.8.24, 2.8.23, 2.8.22, 2.8.21, 2.8.19, 2.8.12, 2.8.6, 2.6.13 | Version 6.2 or higher For US-ISO-EAST-1, US-ISO-WEST-1, and US-ISOB-EAST-1 Regions, we recommend 5.0.6 or higher. | January 13, 2023 | ## Supported ElastiCache for Memcached versions ElastiCache supports the following Memcached versions and upgrading to newer versions. When upgrading to a newer version, pay careful attention to the conditions that if not met cause your upgrade to fail. **Topics** + [ElastiCache version 1.6.22 for Memcached](#memcached-version-1-6-22) + [ElastiCache version 1.6.17 for Memcached](#memcached-version-1-6-17) + [ElastiCache version 1.6.12 for Memcached](#memcached-version-1-6-12) + [ElastiCache version 1.6.6 for Memcached](#memcached-version-1-6-6) + [ElastiCache version 1.5.16 for Memcached](#memcached-version-1-5-16) + [ElastiCache version 1.5.10 for Memcached](#memcached-version-1-5-10) + [ElastiCache version 1.4.34 for Memcached](#memcached-version-1-4-34) + [ElastiCache version 1.4.33 for Memcached](#memcached-version-1-4-33) + [ElastiCache version 1.4.24 for Memcached](#memcached-version-1-4-24) + [ElastiCache version 1.4.14 for Memcached](#memcached-version-1-4-14) + [ElastiCache version 1.4.5 for Memcached](#memcached-version-1-4-5) ### ElastiCache version 1.6.22 for Memcached ElastiCache for Memcached version 1.6.22 for Memcached adds support for Memcached version 1.6.22. It includes no new features, but does include bug fixes and cumulative updates from [Memcached 1.6.18](https://github.com/memcached/memcached/wiki/ReleaseNotes1618). For more information, see [ReleaseNotes1622](https://github.com/memcached/memcached/wiki/ReleaseNotes1622) at Memcached on GitHub. ### ElastiCache version 1.6.17 for Memcached ElastiCache for Memcached version 1.6.17 for Memcached adds support for Memcached engine version 1.6.17. It includes no new features, but does include bug fixes and cumulative updates from [Memcached 1.6.17](https://github.com/memcached/memcached/wiki/ReleaseNotes1617). For more information, see [ReleaseNotes1617](https://github.com/memcached/memcached/wiki/ReleaseNotes1617) at Memcached on GitHub. ### ElastiCache version 1.6.12 for Memcached ElastiCache for Memcached version 1.6.12 for Memcached adds support for Memcached engine 1.6.12 and encryption in-transit. It also includes bug fixes and cumulative updates from [Memcached 1.6.6](https://github.com/memcached/memcached/wiki/ReleaseNotes166). For more information, see [ReleaseNotes1612](https://github.com/memcached/memcached/wiki/ReleaseNotes1612) at Memcached on GitHub. ### ElastiCache version 1.6.6 for Memcached ElastiCache for Memcached version 1.6.6 for Memcached adds support for Memcached version 1.6.6. It includes no new features, but does include bug fixes and cumulative updates from [Memcached 1.5.16](https://github.com/memcached/memcached/wiki/ReleaseNotes1.5.16). ElastiCache for Memcached does not include support for [Extstore](https://memcached.org/extstore). For more information, see [ReleaseNotes166](https://github.com/memcached/memcached/wiki/ReleaseNotes166) at Memcached on GitHub. ### ElastiCache version 1.5.16 for Memcached ElastiCache version 1.5.16 for Memcached adds support for Memcached version 1.5.16. It includes no new features, but does include bug fixes and cumulative updates from [Memcached 1.5.14](https://github.com/memcached/memcached/wiki/ReleaseNotes1514) and [Memcached 1.5.15](https://github.com/memcached/memcached/wiki/ReleaseNotes1515). For more information, see [Memcached 1.5.16 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1516) at Memcached on GitHub. ### ElastiCache version 1.5.10 for Memcached ElastiCache version 1.5.10 for Memcached supports the following Memcached features: + Automated slab rebalancing. + Faster hash table lookups with `murmur3` algorithm. + Segmented LRU algorithm. + LRU crawler to background-reclaim memory. + `--enable-seccomp`: A compile-time option. It also introduces the `no_modern` and `inline_ascii_resp` parameters. For more information, see [Memcached 1.5.10 parameter changes](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-5-10). Memcached improvements added since ElastiCache version 1.4.34 for Memcached include the following: + Cumulative fixes, such as ASCII multigets, CVE-2017-9951 and limit crawls for `metadumper`. + Better connection management by closing connections at the connection limit. + Improved item-size management for item size above 1MB. + Better performance and memory-overhead improvements by reducing memory requirements per-item by a few bytes. For more information, see [Memcached 1.5.10 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1510) at Memcached on GitHub. ### ElastiCache version 1.4.34 for Memcached ElastiCache version 1.4.34 for Memcached adds no new features to version 1.4.33. Version 1.4.34 is a bug fix release that is larger than the usual such release. For more information, see [Memcached 1.4.34 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1434) at Memcached on GitHub. ### ElastiCache version 1.4.33 for Memcached Improvements added since version 1.4.24 include the following: + Ability to dump all of the metadata for a particular slab class, a list of slab classes, or all slab classes. For more information, see [Memcached 1.4.31 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1431). + Improved support for large items over the 1 megabyte default. For more information, see [Memcached 1.4.29 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1429). + Ability to specify how long a client can be idle before being asked to close. Ability to dynamically increase the amount of memory available to Memcached without having to restart the cluster. For more information, see [Memcached 1.4.27 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1427). + Logging of `fetchers`, `mutations`, and `evictions` are now supported. For more information, see [Memcached 1.4.26 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1426). + Freed memory can be reclaimed back into a global pool and reassigned to new slab classes. For more information, see [Memcached 1.4.25 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1425). + Several bug fixes. + Some new commands and parameters. For a list, see [Memcached 1.4.33 added parameters](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-33). ### ElastiCache version 1.4.24 for Memcached Improvements added since version 1.4.14 include the following: + Least recently used (LRU) management using a background process. + Added the option of using *jenkins* or *murmur3* as your hash algorithm. + Some new commands and parameters. For a list, see [Memcached 1.4.24 added parameters](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-24). + Several bug fixes. ### ElastiCache version 1.4.14 for Memcached Improvements added since version 1.4.5 include the following: + Enhanced slab rebalancing capability. + Performance and scalability improvement. + Introduced the *touch* command to update the expiration time of an existing item without fetching it. + Auto discovery—the ability for client programs to automatically determine all of the cache nodes in a cluster, and to initiate and maintain connections to all of these nodes. ### ElastiCache version 1.4.5 for Memcached ElastiCache version 1.4.5 for Memcached was the initial engine and version supported by Amazon ElastiCache for Memcached. # Major engine version behavior and compatibility differences with Valkey Valkey 7.2.6 has similar compatibility differences with previous versions of Redis OSS 7.2.4. For the most recent supported version of Valkey, see [Supported engines and versions](VersionManagement.md#supported-engine-versions). For more information on the Valkey 7.2 release, see [Redis OSS 7.2.4 Release Notes](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (Valkey 7.2 includes all changes from Redis OSS up to version 7.2.4) and [Valkey 7.2 release notes](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) at Valkey on GitHub. Here are the potentially breaking behavior changes between Valkey 7.2 and Redis OSS 7.1 (or 7.0): + Freeze time sampling occurs during command execution and in scripts. + A blocked stream command that's released when key no longer exists carries a different error code (-NOGROUP or -WRONGTYPE instead of -UNBLOCKED). + Client side tracking for scripts now tracks the keys that are read by the script, instead of the keys that are declared by the caller of EVAL / FCALL. # Major engine version behavior and compatibility differences with Redis OSS **Important** The following page is structured to signify all incompability differences between versions and inform you of any considerations you should make when upgrading to newer versions. This list is inclusive of any version incompability issues you may encounter when upgrading. You can upgrade directly from your current Redis OSS version to the latest Redis OSS version available, without the need for sequential upgrades. For example, you can upgrade directly from Redis OSS version 3.0 to version 7.0. Redis OSS versions are identified with a semantic version which comprise a major, minor, and patch component. For example, in Redis OSS 4.0.10, the major version is 4, the minor version 0, and the patch version is 10. These values are generally incremented based off the following conventions: + Major versions are for API incompatible changes + Minor versions are for new functionality added in a backwards-compatible way + Patch versions are for backwards-compatible bug fixes and non-functional changes We recommend always staying on the latest patch version within a given **major.minor** version in order to have the latest performance and stability improvements. Beginning with ElastiCache version 6.0 for Redis OSS, ElastiCache will offer a single version for each Redis OSS minor release rather than offering multiple patch versions. ElastiCache will automatically manage the patch version of your running clusters, ensuring improved performance and enhanced security. We also recommend periodically upgrading to the latest major version, since most major improvements are not back ported to older versions. As ElastiCache expands availability to a new AWS region, ElastiCache for Redis OSS supports the two most recent **major.minor** versions at that time for the new region. For example, if a new AWS region launches and the latest major.minor ElastiCache versions for Redis OSS are **7.0** and **6.2**, ElastiCache will support Redis OSS versions **7.0** and **6.2** in the new AWS region. As newer major.minor versions of ElastiCache for Redis OSS are released, ElastiCache will continue to add support for the newly released versions. To learn more about choosing regions for ElastiCache, see [Choosing regions and availability zones](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html#SupportedRegions). When doing an upgrade that spans major or minor versions, please consider the following list which includes behavior and backwards incompatible changes released with Redis OSS over time. ## Redis OSS 7.0 behavior and backwards incompatible changes For a full list of changes, see [Redis OSS 7.0 release notes](https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES). + `SCRIPT LOAD` and `SCRIPT FLUSH` are no longer propagated to replicas. If you need to have some durability for scripts, we recommend you consider using [Redis OSS functions](https://valkey.io/topics/functions-intro/). + Pubsub channels are now blocked by default for new ACL users. + `STRALGO` command was replaced with the `LCS` command. + The format for `ACL GETUSER` has changed so that all fields show the standard access string pattern. If you had automation using `ACL GETUSER`, you should verify that it will handle either format. + The ACL categories for `SELECT`, `WAIT`, `ROLE`, `LASTSAVE`, `READONLY`, `READWRITE`, and `ASKING` have changed. + The `INFO` command now shows command stats per sub-command instead of in the top level container commands. + The return values of `LPOP`, `RPOP`, `ZPOPMIN` and `ZPOPMAX` commands have changed under certain edge cases. If you use these commands, you should check the release notes and evaluate if you are impacted. + The `SORT` and `SORT_RO` commands now require access to the entire keyspace in order to use the `GET` and `BY` arguments. ## Redis OSS 6.2 behavior and backwards incompatible changes For a full list of changes, see [Redis OSS 6.2 release notes](https://raw.githubusercontent.com/redis/redis/6.2/00-RELEASENOTES). + The ACL flags of the `TIME`, `ECHO`, `ROLE`, and `LASTSAVE` commands were changed. This may cause commands that were previously allowed to be rejected and vice versa. **Note** None of these commands modify or give access to data. + When upgrading from Redis OSS 6.0, the ordering of key/value pairs returned from a map response to a lua script are changed. If your scripts use `redis.setresp()` or return a map (new in Redis OSS 6.0), consider the implications that the script may break on upgrades. ## Redis OSS 6.0 behavior and backwards incompatible changes For a full list of changes, see [Redis OSS 6.0 release notes](https://raw.githubusercontent.com/redis/redis/6.0/00-RELEASENOTES). + The maximum number of allowed databases has been decreased from 1.2 million to 10 thousand. The default value is 16, and we discourage using values much larger than this as we’ve found performance and memory concerns. + Set `AutoMinorVersionUpgrade` parameter to yes, and ElastiCache will manage the minor version upgrade through self-service updates. This will be handled through standard customer-notification channels via a self-service update campaign. For more information, see [Self-service updates in ElastiCache](Self-Service-Updates.md). ## Redis OSS 5.0 behavior and backwards incompatible changes For a full list of changes, see [Redis OSS 5.0 release notes](https://raw.githubusercontent.com/redis/redis/5.0/00-RELEASENOTES). + Scripts are by replicated by effects instead of re-executing the script on the replica. This generally improves performance but may increase the amount of data replicated between primaries and replicas. There is an option to revert back to the previous behavior that is only available in ElastiCache version 5.0 for Redis OSS. + If you are upgrading from Redis OSS 4.0, some commands in LUA scripts will return arguments in a different order than they did in earlier versions. In Redis OSS 4.0, Redis OSS would order some responses lexographically in order to make the responses deterministic, this ordering is not applied when scripts are replicated by effects. + In Redis OSS 5.0.3 and above, ElastiCache for Redis OSS will offload some IO work to background cores on instance types with more than 4 VCPUs. This may change the performance characteristics Redis OSS and change the values of some metrics. For more information, see [Which Metrics Should I Monitor?](CacheMetrics.WhichShouldIMonitor.md) to understand if you need to change which metrics you watch. ## Redis OSS 4.0 behavior and backwards incompatible changes For a full list of changes, see [Redis OSS 4.0 release notes](https://raw.githubusercontent.com/redis/redis/4.0/00-RELEASENOTES). + Slow log now logs an additional two arguments, the client name and address. This change should be backwards compatible unless you are explicitly relying on each slow log entry containing 3 values. + The `CLUSTER NODES` command now returns a slight different format, which is not backwards compatible. We recommend that clients don’t use this command for learning about the nodes present in a cluster, and instead they should use `CLUSTER SLOTS`. ## Past EOL ### Redis OSS 3.2 behavior and backwards incompatible changes For a full list of changes, see [Redis OSS 3.2 release notes](https://raw.githubusercontent.com/redis/redis/3.2/00-RELEASENOTES). + There are no compatibility changes to call out for this version. For more information, see [ElastiCache versions for Redis OSS end of life schedule](engine-versions.md#deprecated-engine-versions). ### Redis OSS 2.8 behavior and backwards incompatible changes For a full list of changes, see [Redis OSS 2.8 release notes](https://raw.githubusercontent.com/redis/redis/2.8/00-RELEASENOTES). + Starting in Redis OSS 2.8.22, Redis OSS AOF is no longer supported in ElastiCache for Redis OSS. We recommend using MemoryDB when data needs to be persisted durably. + Starting in Redis OSS 2.8.22, ElastiCache for Redis OSS no longer supports attaching replicas to primaries hosted within ElastiCache. While upgrading, external replicas will be disconnected and they will be unable to reconnect. We recommend using client-side caching, made available in Redis OSS 6.0 as an alternative to external replicas. + The `TTL` and `PTTL` commands now return -2 if the key does not exist and -1 if it exists but has no associated expire. Redis OSS 2.6 and previous versions used to return -1 for both the conditions. + `SORT` with `ALPHA` now sorts according to local collation locale if no `STORE` option is used. For more information, see [ElastiCache versions for Redis OSS end of life schedule](engine-versions.md#deprecated-engine-versions). # Upgrade considerations when working with node-based clusters **Note** The following considerations only apply when upgrading node-based clusters. They do not apply to ElastiCache Serverless. **Valkey and Redis OSS considerations** When upgrading a node-based 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](BestPractices.Clients.redis.md) with error retries and exponential backoff and the best practices for [minimizing downtime during maintenance](BestPractices.MinimizeDowntime.md). + 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](backups-manual.md). 1. 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 node-based cluster with an externally created backup](backups-seeding-redis.md). 1. Delete the old Valkey or Redis OSS (cluster mode disabled) cluster or replication group. For more information, see [Deleting a cluster in ElastiCache](Clusters.Delete.md) or [Deleting a replication group](Replication.DeletingRepGroup.md). 1. 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 Valkey or Redis OSS (Cluster Mode Enabled) clusters](scaling-redis-cluster-mode-enabled.md) + 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](BestPractices.BGSAVE.md). 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 node-based 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.