AWS Idle ElastiCache Cluster Detector
Locate provisioned Amazon ElastiCache Redis and Memcached clusters with zero client connections burning expensive memory cache hours.
1. Detection Scope & Operational Boundaries
Every ArthaOps detector enforces strict epistemic honesty. We clearly separate what can be mathematically proven via agentless telemetry from what requires contextual human judgement.
What This Detector Identifies
- Amazon ElastiCache Redis and Memcached clusters with CurrConnections == 0 across 14 consecutive days.
- Clusters where NetworkBytesIn is < 1 MB/day indicating zero application cache traffic.
- Non-production cache clusters operating 24/7 with zero active client workloads.
What It Cannot Establish Alone
- Whether the cluster is maintained as a warm standby cache for an upcoming launch or disaster recovery (DR) failover target.
- Whether a batch job connects only on monthly or quarterly reconciliation cycles (e.g. payroll, ledger reconciliations).
- Whether the cluster acts as a warm cross-region or cross-AZ DR replica awaiting primary failover.
2. Telemetry & Evidence Requirements
ArthaOps operates strictly via Plane 1 (Read-Only Discovery). The following CloudFormation / IAM permissions and CloudWatch metrics are evaluated:
AWS::ElastiCache::CacheClusterVerification Protocol: Tested against simulated Redis cluster fixtures with CurrConnections == 0 across 14-day rolling windows.
Validation Context: Validated in customer staging and testing environments discovering forgotten Redis clusters left running post-sprint.
3. Reproducible AWS CLI Verification Recipe
Query CloudWatch for 14-day client connection metrics for target ElastiCache cluster.
# Check 14-day connections on target Redis cluster
aws cloudwatch get-metric-statistics \
--region ap-south-1 \
--namespace AWS/ElastiCache \
--metric-name CurrConnections \
--dimensions Name=CacheClusterId,Value=staging-redis-cluster-001 \
--start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 86400 \
--statistics Average Maximum \
--output table-----------------------------------------------------------------------
| GetMetricStatistics |
+--------------------------+---------------------+--------------------+
| Average | Maximum | Timestamp |
+--------------------------+---------------------+--------------------+
| 0.0 | 0.0 | 2026-10-10T00:00Z |
+--------------------------+---------------------+--------------------+💡 Zero concurrent connections over 14 days proves that no application workload is connected to the cache.
4. Transparent Economic Model
- 730 operational hours per standard calendar month.
- Primary + replica 2-node cluster configuration.
- Backup storage fees for snapshots up to 100% of cluster size are free.
5. False-Positive Scenarios & Operational Risks
Never delete or terminate cloud resources blindly. These validated architectural scenarios must be reviewed before initiating remediation:
Documented False-Positive Scenarios
- Warm Disaster Recovery (DR) Replica: Inactive Redis cluster primed via asynchronous data replication to accept traffic immediately in an emergency failover scenario.
- Infrequent Batch Reconciliations: Memory clusters utilized exclusively by month-end or quarter-end cron jobs that exhibit zero connections across 14-day standard sampling windows.
Blast Radius & Remediation Risks
- Cache Miss Stampede: If applications suddenly start and expect cache connectivity, absence of the cluster may cause connection timeouts or high database load.
6. Remediation Procedure & Rollback Runbook
Follow this ordered sequence of verified AWS CLI actions to remediate the resource with complete rollback availability:
Capture Pre-Deletion ElastiCache Snapshot
Create a manual snapshot to preserve cluster data.
aws elasticache create-snapshot --region ap-south-1 --cache-cluster-id staging-redis-cluster-001 --snapshot-name pre-delete-backup-staging-redisDelete the Idle Cache Cluster
Delete the cluster once snapshot reaches available.
aws elasticache delete-cache-cluster --region ap-south-1 --cache-cluster-id staging-redis-cluster-001Forensic Rollback Procedure
To restore, execute `aws elasticache create-cache-cluster --snapshot-name pre-delete-backup-staging-redis`. The cluster will be fully restored within 5–10 minutes.
🔒 ArthaOps Assurance: ArthaOps requires snapshot creation before issuing any ElastiCache deletion command.
Cluster endpoint URL will change if restored under a different cluster identifier. Ensure DNS CNAME is updated.
How This Appears in the ArthaOps Control Plane
2-node cache.m6g.large Redis cluster has 0 active connections for 32 consecutive days.
Test Your Infrastructure in 180 Seconds
Explore our zero-setup interactive sample report covering real Mumbai findings, or launch a 100% read-only agentless scan across your AWS environment.