Amazon ElastiCache Global Datastore
Does ZopNight manage Amazon ElastiCache Global Datastore?
ElastiCache Global Datastore runs a complete, continuously billed replica cluster in every secondary region, so 2 secondaries triple the node-hour spend of the primary cache. ZopNight discovers global datastores via a dedicated provider on the 6-hour cycle, attributes cost per region, and flags secondaries no application reads from.
Rules that fire on Amazon ElastiCache Global Datastore
No active rule family targets Amazon ElastiCache Global Datastore today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
An ElastiCache Global Datastore replicates a Redis cluster across AWS regions for disaster recovery and local reads. Every secondary region runs a full, continuously billed replica cluster, so unused secondaries double or triple cache spend.
Cache replication at cluster prices
Global Datastore has no meter of its own; its cost is that every member is a full ElastiCache cluster billing node-hours at its instance sizes, all day, in its own region, plus cross-region data transfer for the replication stream. Caches amplify the multiplication in a way databases do not: cache clusters are typically sized for throughput headroom, so each secondary inherits a generous node configuration whose entire purpose in the secondary region may be to sit warm awaiting a failover that has never been rehearsed.
Regional replicas, individually accounted
A dedicated provider discovers global datastores on the 6-hour cycle, and cross-region cost attribution splits the spend per member cluster. That per-region view is the finding: a secondary whose local applications hold no connections and issue no reads is pure standby cost, and the recommendation asks whether the failover requirement justifies a same-sized cluster, a smaller one, or none. Re-creating a cache from a warm primary is often acceptable for workloads whose cache is genuinely a cache rather than a datastore.
Standby caches that never serve
The common shapes: a secondary added during a multi-region initiative that shipped only its database tier, leaving the cache replica readerless; geo-local read replicas for a user base that never materialized in that geography; and DR postures where the application tier fails over to a region whose cache exists but whose connection strings were never wired, meaning the replica would not even be used in the disaster it exists for. Each bills node-hours continuously.
Where to inspect a global datastore
The ElastiCache console’s Global datastores view lists each datastore with its primary and secondary clusters, regions, and node configurations. Per-secondary CloudWatch connection and hit metrics answer the only question that matters (does anything read from this region), and the failover runbook, if one exists, answers whether anything ever could.