# Memorystore for Memcached

> Memorystore for Memcached bills for the vCPUs and memory of every provisioned node 24x7, whether the cache serves traffic or sits idle. ZopNight discovers each instance through Cloud Asset Inventory and checks node utilization against its recommendation rules, since a Memcached fleet cannot be stopped, only resized or deleted.

Source: https://zop.dev/integrations/gcp/memcached
Updated: 2026-08-19

---

Memorystore for Memcached provides managed Memcached instances billed for provisioned node vCPUs and memory around the clock. Cache fleets sized for peak often run heavily under-utilized.

## Node count times node size is the Memcached invoice

Each Memcached instance is a fleet of cache nodes, and every node meters its configured vCPUs and its memory allocation continuously. Nothing in the pricing responds to traffic: a fleet answering millions of gets per second and an identical fleet answering none produce the same charge. Because capacity is chosen twice, at node size and node count, oversizing compounds: doubling both quadruples the bill. There is no serverless or usage-based option here, and no stop operation either, which is why this type is discovery-and-recommendation territory rather than a scheduling target.

## Utilization evidence ZopNight gathers on cache fleets

ZopDev discovers Memcached instances via Cloud Asset Inventory and evaluates node utilization against its recommendation rules. Redis-based caches are tracked separately as memorystore, so a mixed caching estate shows up as two distinct resource types with their own signals rather than one blurred line item.

## How Memcached fleets end up oversized

The common story is peak-day sizing that becomes permanent: a fleet dimensioned for a seasonal event keeps its node count long after the event passes. A second pattern is horizontal sprawl: adding nodes to chase hit-rate problems that were actually caused by key distribution, then never removing them. Third, non-production clones of production fleets: a staging environment rarely needs production's cache capacity, yet copies of it are provisioned in a single click and forgotten.

## What resizing involves when there is no stop button

Because the service cannot pause, recovering waste means changing the fleet: removing nodes, choosing smaller node shapes, or deleting instances whose applications have moved on. Memcached's design makes node removal a cache-warming event, not an outage. It is worth scheduling into a quiet window, but not a reason to keep paying indefinitely.

## Where Memcached fleets appear in the console

Google Cloud console → Memorystore → Memcached shows each instance with its node count and per-node vCPU and memory configuration. Multiply those columns to read the meter directly.