I Tried Out the New ElastiCache for Valkey Feature That Allows Changing Durability
This page has been translated by machine translation. View original
Introduction
There was an update to ElastiCache for Valkey that lets you enable and disable durability on existing node-based clusters.
Previously, the durability of a node-based cluster could be specified only at creation and could not be changed on an existing cluster.
In this article, I switched the durability of a cluster-mode-enabled Valkey 9.0 cluster between disabled, sync, and async, and checked the time required for each change, the Status during the change, and whether a failover occurred.
Prerequisites for Changes
To change the durability of an existing cluster, the following conditions must be met.
- Valkey 9.0 or later
- Cluster mode enabled
- Multi-AZ enabled, with one or more replicas per shard
- Encryption in transit (TLS) enabled
- Instance family is one of R8g, R7g, R6g, M8g, M7g, M6g, C8gn, or C7gn
- Not part of a Global Datastore
Notes on Making Changes
- A durability change cannot be made at the same time as other configuration changes.
- The change involves node replacement, and a primary switchover or automatic failover occurs for each shard. The cluster continues to process traffic during the change, but client connections may be temporarily dropped.
Test Method
Test Environment
| Item | Value |
|---|---|
| Region | ap-northeast-1 (Tokyo) |
| Engine | Valkey 9.0 |
| Node type | cache.m6g.large |
| Configuration | Cluster mode enabled, 1 shard, 1 replica (ap-northeast-1a and ap-northeast-1c) |
| Multi-AZ / Automatic failover | Enabled / Enabled |
| Encryption in transit | Enabled |
| Data | 3 or fewer test keys |
| Client that executed the changes | AWS CLI 2.38.0 on an EC2 instance in the same VPC |
Commands for Changes and Verification
I made the changes in the order disabled → sync → disabled → async → sync, waiting for each previous change to complete before making the next. Below are the command and response for the change to sync. For changes to disabled or async, I changed only the value of --durability. --query is used to check the Status, Durability, and EffectiveDurability in the response.
aws elasticache modify-replication-group \
--replication-group-id my-valkey-cluster \
--durability sync \
--apply-immediately \
--query 'ReplicationGroup.[Status,Durability,EffectiveDurability]' --output text
modifying disabled disabled
To track the state during the change, I ran the following command at intervals of about 10 seconds and recorded it with the time and the elapsed seconds since the start of the change. The output columns are, from the left, Status, Durability, EffectiveDurability, MultiAZ, number of nodes, and shard Status.
aws elasticache describe-replication-groups \
--replication-group-id my-valkey-cluster \
--query 'ReplicationGroups[0].[Status,Durability,EffectiveDurability,MultiAZ,length(MemberClusters),NodeGroups[0].Status]' \
--output text
Measurement Results
The time required is the elapsed time from the execution of the change command to the first record in which Status is available and both Durability and EffectiveDurability are the requested values (no value for disabled). It includes an error of about the recording interval (about 10 seconds), and each value is from a single measurement.
| Change | Time required | Status during change | Failover events |
|---|---|---|---|
| Disabled → sync | About 20 minutes (1226 seconds) | modifying | 1 |
| Sync → disabled | About 14.5 minutes (872 seconds) | modifying | 1 |
| Disabled → async | About 20 minutes (1195 seconds) | modifying | 1 |
| Async → sync | About 20 seconds | Remained available | None |
From the start of the first change (02:00:55) to the completion of async → sync (03:05:18), the following events were recorded for the replication group. Times are in UTC.
2026-10-28T02:15:34.565000+00:00 Failover to replica node my-valkey-cluster-0001-001 completed
2026-10-28T02:30:57.668000+00:00 Failover to replica node my-valkey-cluster-0001-001 completed
2026-10-28T02:59:09.082000+00:00 Failover to replica node my-valkey-cluster-0001-001 completed
2026-10-28T03:05:13.990000+00:00 Successfully updated the durability setting to sync.
The three failover lines correspond one each to the three changes that enabled or disabled durability, and the 03:05:13 line corresponds to the async → sync change.
In the records from immediately after the async → sync change until it became sync, the Status was available throughout.
03:04:56 +1s available async async enabled 2 available
03:05:07 +11s available async async enabled 2 available
03:05:18 +22s available sync sync enabled 2 available
Summary
I was able to change the durability of an existing cluster without recreating the cluster. The cluster continues to process traffic during the change.
Changes that enable or disable durability took about 14.5 to 20 minutes each to complete in this environment, and one failover occurred partway through. Client connections may be dropped at the moment of failover, so enabling or disabling presupposes a workload that can absorb connection drops through retries or reconnection.
The change from async to sync took about 20 seconds, with no failover.
If requirements have changed since the design stage and you need to change durability, please make use of this update.
