Skip to main content
rightsizing · aws

ElastiCache Multi-AZ Non-Critical

resource types
1
rule IDs covered
1
severity
low

What does ZopNight detect here?

ElastiCache replication groups with an explicit dev/test environment tag and Multi-AZ enabled carry standby replicas non-critical caches rarely need. ZopNight prices removing them as cost times replicas divided by replicas-plus-one, never the old flat 0.50. Abstains fleet-wide today because the replication-group parent row prices at $0, a known producer gap.

Signal and threshold

How ZopNight evaluates ElastiCache Multi-AZ Non-Critical.
Field Value
Rule IDsRC-053
Categoryrightsizing
Severitylow
Metricnone — pure configuration read
Sourceelasticache_multiaz.go

Why an explicit dev or test env tag is required

  • env tag (env/environment/stage/tier): authoritative and required (RC-053 HARDEN). A prod env tag is a hard veto (never strip HA from production), and firing requires an explicit dev/test env tag; concrete-or-abstain on the env signal.
  • resource.Name: not consulted. The dev/test name-substring fallback (isDevTestName) is removed (it misfired on a prod cache literally named “…test…” and is unverifiable); absent/non-env tag => abstain.
  • resource.Metadata: multi_az_enabled (bool; producer exists): applicability gate.
  • resource.Metadata: replicasPerShard (float; discoverer elasticache.go): the real removed-node fraction. Utilisation series such as those in the ElastiCache CloudWatch metric set play no part in this gate; the decision rests entirely on tags and node metadata.

Node count as the cost lever

removing the standby replica nodes (going to a single primary per shard) is the cost lever. Every node in a replication group is the same type and each one accrues its own node-hour charge, so node cost is proportional to node count: savings = cost × replicasPerShard / (replicasPerShard + 1) (the shard count cancels), capped at cost. The hardcoded 0.50 halving fraction is removed; abstains when replicasPerShard is missing or ≤ 0. PRODUCER-GAP: RC-053 is structurally dead in production until a producer surfaces a real parent-level cluster MonthlyCost (or standby-cost rollup) on the replication-group “elasticache” UID. The RG parent row carries multi_az_enabled/replicasPerShard but no InstanceType → aggregator resolves MonthlyCost 0 (no rateFallbackKeys[“elasticache”]), so the cost gate always abstains. The abstain logic is correct (emits nothing wrong); it just cannot fire until the parent cost lands. No longer a “fixed estimate”.

Removing the standby replicas

  1. Verify this is a non-production cache cluster
  2. Disable Multi-AZ first (prerequisite only, required before the last replica can be removed; this step alone removes no nodes and has no cost effect)
  3. Go to ElastiCache Console → Modify → decrease replica count to 0 (or use DecreaseReplicaCount / lower NumCacheClusters)
  4. This is the step that actually removes and stops billing for the standby replica nodes

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·