Memorystore for Redis
Does ZopNight manage Memorystore for Redis?
Memorystore for Redis bills per GB-hour of provisioned capacity, and each Standard-tier replica adds a full copy of that charge. ZopNight tracks memory utilization over a 42-day window and scales replica counts down on schedule during quiet hours, keeping the primary node serving while standby replicas stop billing.
Rules that fire on Memorystore for Redis
At a glance
| Field | Value |
|---|---|
| Scheduling notes | scales the replica count down to reduce billing during quiet hours, restoring replicas on resume |
Memorystore for Redis provides managed Redis instances billed by capacity tier and provisioned GB per hour. Standard-tier replicas double the cost of every instance, so replica counts on non-production caches deserve scrutiny.
GB-hours by capacity tier, multiplied by replicas
The meter is provisioned memory: an instance bills for every GB it was created with, per hour, at a rate set by its capacity tier. Actual cache hit rates and key counts never appear on the invoice. The multiplier is the tier choice. A Basic-tier instance is a single node; a Standard-tier instance adds high availability through replication, and every read replica attached to it bills as one more full copy of the provisioned capacity. A cache provisioned generously and then replicated for availability pays that generosity several times over, around the clock.
Trimming replicas on schedule without dropping the cache
Memorystore cannot be stopped, but its replica count can move. ZopNight scales the replica count down to reduce billing during quiet hours and restores the saved replica configuration on resume. The primary node stays available throughout, because scheduling removes standby replicas rather than the cache itself, so applications keep their connection string and their data while the overnight bill shrinks to a single node’s capacity charge.
Discovery and the 42-day memory picture
ZopDev discovers Redis instances via Cloud Asset Inventory, tracks memory utilization over 42 days, and can scale replicas down on schedule. That utilization history is what separates a cache that genuinely needs its provisioned headroom from one that has never crossed half of it.
Redis spending habits worth breaking
Three patterns dominate. Development caches created at Standard tier out of habit, paying the availability premium for an environment nobody would page over. Provisioned capacity sized for a launch spike that has long passed; memory cannot be consumed-billed, so the headroom is a permanent charge. And replica counts copied from production into staging, where a read replica serves no read traffic at all.
Locating Memorystore instances in the Cloud console
Google Cloud console → Memorystore → Redis lists every instance with its tier, capacity, and replica count: the three fields that, multiplied together, are the bill.