Cut ElastiCache Costs When There Is No Stop Button

Start with the constraint: the ElastiCache API has no operation to stop or pause a node-based cluster. The CLI’s command list has create, delete, modify, reboot, snapshot and failover operations, and the only “stop” is batch-stop-update-action, which stops a service update, not a cache. A running node bills until the cluster is deleted, so the choices below are about running fewer, smaller or cheaper nodes, or none at all.

1. Find caches nobody is using

Two CloudWatch metrics in the AWS/ElastiCache namespace tell you whether a Valkey or Redis OSS cluster has real clients:

• CurrConnections: client connections, excluding read replicas. ElastiCache itself uses 4 to 6 connections to monitor the cluster, so a flat line at that level means no application is connected.
• GetTypeCmds: read-only commands (get, hget, lrange and so on). A cache with connections but no reads is being written to and never read.

aws cloudwatch get-metric-statistics \
  --namespace AWS/ElastiCache --metric-name CurrConnections \
  --dimensions Name=CacheClusterId,Value=dev-sessions-001 Name=CacheNodeId,Value=0001 \
  --start-time 2026-09-10T00:00:00Z --end-time 2026-09-24T00:00:00Z \
  --period 86400 --statistics Maximum

Repeat per node. A daily maximum of 6 or less for two weeks means only ElastiCache’s own monitoring connected in that period.

2. Delete with a final snapshot, recreate when needed

For a cache that is only used during a project or a test window, the nearest thing to a stop is delete and restore. Valkey, Redis OSS and Serverless Memcached caches support snapshots; node-based Memcached clusters do not, so for those a delete means the data is gone.

aws elasticache delete-replication-group \
  --replication-group-id dev-sessions \
  --final-snapshot-identifier dev-sessions-final-2026-09-24

aws elasticache describe-snapshots --snapshot-name dev-sessions-final-2026-09-24

When the cache is needed again, create a new replication group from the snapshot, passing the same node type, subnet group (--cache-subnet-group-name) and security groups (--security-group-ids) as before:

aws elasticache create-replication-group \
  --replication-group-id dev-sessions \
  --replication-group-description "dev sessions cache" \
  --snapshot-name dev-sessions-final-2026-09-24 \
  --cache-node-type cache.t4g.small

AWS’s own advice for deleting a cache whose data matters is to take a manual backup first, confirm its status is available, and only then delete.

3. Remove replicas that only exist for failover

Every node in a replication group bills, including replicas that only exist to take over if the primary fails. For Valkey or Redis OSS with cluster mode disabled, the minimum replica count is 1 while Multi-AZ is enabled and 0 once it is disabled, so Multi-AZ has to be switched off before the last replica can go.

aws elasticache decrease-replica-count \
  --replication-group-id dev-sessions \
  --new-replica-count 0 --apply-immediately

With zero replicas there is nothing to fail over to if the primary node fails. Accept that only where losing the cache is tolerable.

4. Resize the nodes, or reserve the ones you keep

List the node types the group can move to, then resize:

aws elasticache list-allowed-node-type-modifications --replication-group-id dev-sessions
aws elasticache modify-replication-group \
  --replication-group-id dev-sessions \
  --cache-node-type cache.t4g.small --apply-immediately

Without --apply-immediately the change waits for the next maintenance window. For caches that must run all month, reserved nodes are the remaining lever. Find offerings for your node type and a one or three year term, then purchase by offering ID:

aws elasticache describe-reserved-cache-nodes-offerings \
  --cache-node-type cache.r7g.large --duration 1
aws elasticache purchase-reserved-cache-nodes-offering \
  --reserved-cache-nodes-offering-id <offering-id-from-previous-output>

Permissions

elasticache:DescribeReplicationGroups, elasticache:CreateSnapshot, elasticache:DeleteReplicationGroup, elasticache:CreateReplicationGroup, elasticache:ModifyReplicationGroup, elasticache:DecreaseReplicaCount and elasticache:PurchaseReservedCacheNodesOffering, plus cloudwatch:GetMetricStatistics for step 1.

Verify

aws elasticache describe-replication-groups --replication-group-id dev-sessions shows the node type, member clusters and status after each change. After a delete, confirm the final snapshot is still listed by describe-snapshots before you close the ticket.

ZopNight

ZopNight discovers ElastiCache replication groups and their nodes alongside the rest of an AWS account and surfaces recommendations with current cost, estimated optimized cost and the evidence behind each finding. It does not offer an ElastiCache schedule, for the same reason AWS does not offer a stop. See the ElastiCache resource page and the broader notes on idle resource detection.