Why does provisioned capacity decide the Memorystore bill?
Memorystore is a managed cache, and like most managed memory services it bills for what you provision, not what you use. You choose a capacity in GB and a tier, and you pay per GB per hour for that capacity around the clock. An instance provisioned at sixteen GB that holds a four GB working set bills for sixteen GB regardless. The empty headroom is pure waste. So the first lever is honest sizing: measure the real working set, add headroom for growth and spikes, and provision to that, not to a comfortable round number chosen once and never revisited.
Which tier should you actually pay for?
Memorystore offers a Basic tier and a Standard tier, and the gap between them is high availability, which is also the gap in price. The Basic tier runs a single node with no replica and no automatic failover. If the node fails the cache is lost and rebuilds from source. It is the cheaper choice and it is correct for caches whose contents can be regenerated. The Standard tier adds a replica in another zone and automatic failover, which means you provision and pay for roughly double the memory. It is correct when losing the cache would hurt availability or overload the backing store. The mistake is defaulting every cache to Standard out of habit. Decide per workload whether high availability is worth doubling the capacity bill.
Where does Memorystore spend leak?
The table lists the common Memorystore cost leaks and the discipline that fixes each.
| Leak | What happens | The fix |
|---|---|---|
| Oversized instance | Provisioned memory far exceeds the working set and bills empty | Size to real working set plus headroom, revisit as it grows |
| Standard tier by default | Every cache pays for a replica it may not need | Use Basic where the cache can rebuild, Standard only for high availability |
| Unneeded read replicas | Replicas added to a workload that is not read heavy | Add replicas only when read throughput genuinely requires them |
| No eviction or time to live | Cache grows without bound, forcing a larger instance | Set an eviction policy and time to live so the working set stays bounded |
| Cross region clients | Application reads the cache across regions and pays egress | Keep cache and clients in the same region |
Each leak is a configuration choice, not an architecture problem, which is why a Memorystore review usually pays back quickly.
A worked example: tier and size together
A European SaaS company ran several Memorystore for Redis instances on the Standard tier, each provisioned well above its working set because the sizes were chosen at launch and never revisited. We measured the real working set on each, right sized the provisioned memory with sensible headroom, moved the caches that could rebuild from source to the Basic tier, removed read replicas from instances that were not read heavy, and set eviction policies so the working set stayed bounded. Provisioned GB hours fell substantially with no loss of hit rate on the workloads that mattered. Figures are verified against billing data and anonymized.
How do you keep cache cost flat as usage grows?
Caches drift upward because adding memory is the easy answer to any latency complaint. Governance keeps the discipline. Review provisioned capacity against observed working set on a regular cadence and shrink instances that run consistently empty. Require a tier decision for every new instance rather than defaulting to Standard, and record why high availability was chosen where it was. Fold the steady Memorystore baseline into your committed use discount planning where commitments apply, so you commit to a right sized baseline. Memorystore sits alongside compute and database in the wider GCP estate; the architecture level tradeoffs are in the GCP cost optimization guide linked below.
Compare provisioned memory to real working set on each Memorystore instance, and check which run on Standard tier without a high availability need. Oversized capacity and unnecessary replicas are usually the whole saving.
Frequently asked questions
How is Memorystore billed?
What is the difference between Memorystore Basic and Standard tier?
How do you reduce Memorystore cost?
Right size your managed cache spend
We help GCP teams size Memorystore to real working set, pick the tier that matches the availability the workload needs, and stop paying for idle capacity and unnecessary replicas. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.