Google CloudCloud MemorystoreDatabase

`google_redis_cluster` cost estimation

A horizontally-scalable, sharded Redis Cluster on Memorystore. Priced per shard-node-hour by capacity, multiplied across shards and replicas.

A google_redis_cluster is Memorystore's cluster-mode Redis: data is sharded across nodes for horizontal scale and high throughput, unlike the single-primary google_redis_instance. Cost scales with the number of shards and the replica count, each node billed per hour by its capacity tier.

The unit is the shard node. Total nodes are shard_count multiplied by (1 + replica_count), a 3-shard cluster with 1 replica each is 6 nodes. Each node bills per hour by node type (the per-node capacity), so a highmem-XL node runs meaningfully more than a smaller tier. Memorystore Redis Cluster also has cross-zone replication traffic, billed as network data transfer for HA configurations.

c3x reads shard_count and replica_count and prices the node-hours at 730 hours/month at the node-type rate. The two levers are shard count (capacity and throughput) and replica count (availability and read scaling). Over-provisioning either multiplies the always-on node cost, so matching them to real demand is the optimization.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "google_redis_cluster" "cache" {
  name           = "app-cache"
  region         = "us-central1"
  shard_count    = 3
  replica_count  = 1
  node_type      = "REDIS_HIGHMEM_MEDIUM"

  deletion_protection_enabled = true
}

Pricing dimensions

What you actually pay for when you provision google_redis_cluster.

Dimension	Unit	What's being charged
Shard node hours	per node-hour	Per-node rate by node_type, billed across all nodes. Total = shard_count x (1 + replica_count). c3x assumes 730 hours/month. ~$0.86/node-hour for highmem-XL in us-central1
Cross-zone replication	per GB	Replication traffic between zones in HA configurations bills as network data transfer. Usage-based.

Sample C3X output

Example output from c3x estimate (3 shards x 2 nodes = 6 highmem-XL):

google_redis_cluster.cache
└─ Shard nodes (highmem-XL x 6)   4,380  node-hours    $3,758.48

OVERALL TOTAL                                         $3,758.48

Optimization tips

Common ways to reduce google_redis_cluster cost without changing the workload.

Size shard count to real capacity and throughput

Per excess shard (x replicas)

Each shard adds full node cost (times the replica factor). Provision shards for actual data size and ops/sec, not for round numbers. Scaling out later is online.

Use one replica unless you need read scaling

Per extra replica across shards

Replica_count multiplies every shard. One replica gives zonal HA; a second is only for additional read throughput. Don't over-replicate.

Use a single instance for non-sharded workloads

Cluster overhead

If your data fits one node and you don't need horizontal scale, google_redis_instance (single primary + replica) is simpler and cheaper than a cluster.

FAQ

How does c3x estimate Memorystore Redis Cluster cost?

It multiplies shard_count by (1 + replica_count) for the node count, prices each at the node_type rate at 730 hours/month, and treats cross-zone replication as usage-based data transfer.

How is this different from google_redis_instance?

google_redis_instance is single-primary (with an optional replica) and scales vertically. google_redis_cluster shards data across nodes for horizontal scale and higher throughput, so it has more nodes and a higher total cost.

What drives the node count?

Shards times (1 + replicas). A 3-shard cluster with 1 replica each is 6 billed nodes. Both shard and replica counts multiply the per-node hourly rate.

Does the node type matter much?

Yes. The capacity tier (standard-small up to highmem-XL) sets the per-node rate and the memory/throughput per node. Pick the smallest tier that holds your per-shard working set.

Can I scale shards without downtime?

Yes, Memorystore Redis Cluster supports online shard scaling. Start with the shard count you need today and scale out as data grows, rather than over-provisioning upfront.