Supported ElastiCache for Redis versions

• Redis Functions: ElastiCache for Redis 7 adds support for Redis Functions, and provides a managed experience enabling developers to execute LUA scripts with application logic stored on the ElastiCache cluster, without requiring clients to re-send the scripts to the server with every connection.

• ACL improvements: ElastiCache for Redis 7 adds support for the next version of Redis Access Control Lists (ACLs). With ElastiCache for Redis 7, clients can now specify multiple sets of permissions on specific keys or keyspaces in Redis.

• Sharded Pub/Sub: ElastiCache for Redis 7 adds support to run Redis Pub/Sub functionality in a sharded way when running ElastiCache in Cluster Mode Enabled (CME). Redis Pub/Sub capabilities enable publishers to issue messages to any number of subscribers on a channel. With Amazon ElastiCache for Redis 7, 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 Redis version 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 for Redis version 6.

• 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 commands that might cause accidental data loss, such as FLUSHALL or FLUSHDB. This is similar to the rename-command configuration in open source Redis. 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 5.0.3 parameter changes.

• Redis 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. For more information, see Introduction to Redis Streams.

• Support for a family of stream commands, such as XADD, XRANGE and XREAD. For more information, see Redis Streams Commands.

• A number of new and renamed parameters. For more information, see Redis 5.0.0 parameter changes.

• A new Redis metric, StreamBasedCmds.

• Slightly faster snapshot time for Redis nodes.

• 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.

• Redis 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. For more information, see Introduction to Redis Streams.

• Support for a family of stream commands, such as XADD, XRANGE and XREAD. For more information, see Redis Streams Commands.

• A number of new and renamed parameters. For more information, see Redis 5.0.0 parameter changes.

• A new Redis metric, StreamBasedCmds.

• Slightly faster snapshot time for Redis nodes.

• Both online cluster resizing and encryption in a single ElastiCache for Redis version. For more information, see the following:

  • Scaling clusters in Redis (Cluster Mode Enabled)

  • Online resharding and shard rebalancing for Redis (cluster mode enabled)

  • Data security in Amazon ElastiCache

• A number of new parameters. For more information, see Redis 4.0.10 parameter changes.

• Support for family of memory commands, such as MEMORY. For more information, see Redis 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 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 metric, ActiveDefragHits. For more information, see Metrics for Redis.

• Online resharding and shard rebalancing for Redis (cluster mode enabled)

• Best practices: Online cluster resizing

• ElastiCache in-transit encryption (TLS)

• At-Rest Encryption in ElastiCache for Redis

• HIPAA eligibility

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 3.2.4 introduces support for geospatial indexing via six GEO commands. For more information, see the Redis GEO* command documentation Redis Commands: GEO on the Redis Commands page (filtered for GEO).

• Replica migration

• Cluster rebalancing

• Lua debugger

• 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

• 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. 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.

• A number of critical bug fixes in replication PSYNC behavior. For more information, see Redis 2.8 release notes.

• 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 configuration variables appendonly and appendfsync are not supported on Redis 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.

• Support for HyperLogLog. For more information, see Redis new data structure: HyperLogLog.

• 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 Redis.

• 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.