Stop Paying for Idle Redis: How We Cut Our GCP Bill by $35/Month With Serverless Caching

Redis is one of those infrastructure pieces you add early and never think about again. It sits in the background handling caching, rate limiting, session storage — reliably, invisibly, and (if you are using Google Cloud Memorystore) expensively, regardless of whether anything is using it.

This is the story of how a travel content tool we built in 2026 accumulated a $35/month Redis bill with virtually zero active users — and how a one-line configuration change fixed it.

---

The Project Context

We had a RAG-backed travel blog tool running on Google Cloud Run (we wrote about the Cloud Run min-instances cost trap separately). The service used Redis for:

• Rate limiting — preventing abuse of the generation API
• Response caching — storing generated content to avoid redundant LLM calls
• Session state — tracking user generation quotas

The natural GCP choice was Cloud Memorystore — managed Redis, same network as Cloud Run, easy setup.

---

What Cloud Memorystore Actually Charges

Here is the pricing model that caught us:

Cloud Memorystore billing:
──────────────────────────
Charged by: Instance uptime (GB-hours)
            NOT by commands
            NOT by connections
            NOT by data stored

Minimum tier (M1 — 1 GB):
  Rate:    ~$0.049/GB-hour
  Monthly: ~$35/month

This runs whether you have:
  - 0 requests/day   ──► $35
  - 100 requests/day ──► $35
  - 10,000 req/day   ──► $35 + egress

There is no scale-to-zero. The instance exists, it bills. That is the contract.

For a production service with steady traffic, this is fine — the cost amortises across actual usage. For a low-traffic tool in early development or with intermittent use, it is pure waste.

---

The Symptom: $35/Month for a Quiet Service

The GCP bill showed Cloud Memorystore as the second largest line item after Cloud Run. The service had been running for six weeks. Traffic: effectively zero — we were the only users.

Weekly Redis commands (typical week):
  Mon:  12 commands
  Tue:   8 commands
  Wed:  15 commands
  Thu:   3 commands
  Fri:   6 commands
  Total: 44 commands/week

Cost that week: $8.75
Cost per command: $0.20

Twenty cents per Redis command. We were essentially paying a standing army to occasionally carry one envelope.

---

The Alternative: Upstash Serverless Redis

Upstash is a serverless Redis service that bills per command:

Upstash pricing:
────────────────
Free tier:   10,000 commands/day   ──► $0
Pay-as-you:  $0.2 per 100K commands

Same week as above:
  44 commands ──► Free tier (well under 10,000/day)
  Cost: $0.00

At 10x traffic:
  440 commands/week ──► still free tier
  Cost: $0.00

At 100x traffic:
  4,400 commands/week ──► still free tier
  Cost: $0.00

For our low-traffic phase, the cost difference is dramatic. For a high-traffic production service, Upstash becomes cost-comparable to Memorystore only above roughly 20 million commands/month.

---

The Migration: What Changed

The connection string changed. That is nearly the entire migration.

Architecture before:

Cloud Run Service
      │
      └──► Cloud Memorystore
              redis://10.x.x.x:6379
              (private VPC, no TLS)

Architecture after:

Cloud Run Service
      │
      └──► Upstash Redis
              rediss://default:••••@host.upstash.io:6379
              (public endpoint, TLS required)

The one code change needed was handling Upstash’s mandatory TLS. Memorystore on a private VPC doesn’t use TLS. Upstash requires it.

The pattern (pseudocode):

function createRedisClient(redisUrl):
    options = { decode_responses: true }
    
    if redisUrl starts with "rediss://":
        // Upstash uses TLS with a self-signed cert
        // We need to disable strict cert verification
        options.ssl_cert_reqs = None
    
    return Redis.from_url(redisUrl, options)

That conditional covers both Memorystore (no TLS) and Upstash (TLS with relaxed cert check) from a single code path. The rest of the codebase — rate limiting, caching, session storage — did not change at all.

---

What the Migration Looked Like End-to-End

Step 1: Create Upstash Redis database
─────────────────────────────────────
  Upstash console → New Database
  Region: ap-southeast-1 (Singapore, closest to Australia)
  Plan: Free / Pay-as-you-go
  
  Output: Connection string + REST API endpoint

Step 2: Update environment variable
────────────────────────────────────
  Remove from GCP Secret Manager:
    REDIS_URL=redis://10.x.x.x:6379

  Add to GCP Secret Manager:
    REDIS_URL=rediss://default:TOKEN@host.upstash.io:6379

Step 3: Update connection code
──────────────────────────────
  Add TLS conditional (see pattern above)
  No other changes

Step 4: Delete Memorystore instance
────────────────────────────────────
  GCP Console → Memorystore → Delete
  Savings take effect immediately on next billing cycle

Step 5: Verify in production
─────────────────────────────
  Run a few cached requests → confirm cache hits
  Check Upstash dashboard → confirm commands recorded
  Wait one billing cycle → confirm $35 line item gone

Total migration time: about 45 minutes, including testing.

---

When Each Option Makes Sense

This is not a “Upstash is always better” argument. Memorystore wins in specific situations:

Choose Cloud Memorystore when:
───────────────────────────────
✓ High command volume (20M+ commands/month)
✓ Latency is critical (<1ms matters to you)
  (Upstash adds ~5–15ms over Memorystore on same GCP region)
✓ You need Redis clustering or large datasets (>10 GB)
✓ Data residency must stay within GCP VPC
✓ You are already paying for VPC networking

Choose Upstash when:
──────────────────────
✓ Low-to-medium traffic (<1M commands/day)
✓ Development / staging environments
✓ Early-stage product (cost predictability matters)
✓ Multi-cloud or non-GCP environments
✓ You want zero ops overhead (no instance to manage)
✓ Budget is tight (Australian startup / SMB)

---

The Bigger Picture: Idle Infrastructure Adds Up

The Memorystore cost was $35/month. The Cloud Run min-instances cost was $150/month. Together, that was $185/month in idle infrastructure for a product with near-zero traffic — before a single user generated any value.

Across a twelve-month development and early-traction phase, that would have been $2,220 spent on infrastructure that was not serving customers.

The pattern that caused both:

Build phase decision
        │
        ▼
"This setting makes sense now"
  (min-instances for dev demos)
  (Memorystore for easy GCP integration)
        │
        ▼
Ship and move on
        │
        ▼
Settings carried forward unchanged
        │
        ▼
Billing runs in the background
        │
        ▼
Invoice arrives 6–8 weeks later

The fix is not to avoid these services. It is to review infrastructure choices at each phase change: development → staging → low traffic → growth → scale.

---

What We Do Now

Every deployment in our team now goes through a phase-appropriate infrastructure checklist:

Low-traffic / development phase:
  □ min-instances = 0 (scale-to-zero)
  □ Redis = Upstash (pay-per-request)
  □ Cloud SQL = paused when not in use
  □ Budget alert set at 150% of expected spend

Growth phase (1k+ daily active users):
  □ Revisit min-instances for latency budget
  □ Benchmark Upstash latency vs Memorystore
  □ Right-size based on observed memory usage
  □ Compare costs at actual command volume

Small decisions made in the right context cost almost nothing. The same decisions made in the wrong context cost hundreds of dollars a month.

---

The Result

Before (Cloud Memorystore M1):
  Monthly cost:      $35.28
  Commands handled:  ~200/month
  Cost per command:  $0.18

After (Upstash free tier):
  Monthly cost:      $0.00
  Commands handled:  ~200/month
  Cost per command:  $0.00

Annual saving:       $423

If you are running Cloud Memorystore for a low-traffic service and want to assess whether Upstash makes sense for your workload, reach out to our Cloud Geeks team — we have migrated several Sydney-based businesses off idle managed Redis and can give you a realistic cost projection before you make any changes.

---

This is the second post in our GCP cost optimisation series. The first covers the Cloud Run min-instances trap that cost us $150/month.

Pairing cloud infrastructure with a professional website amplifies your online presence. Cosmos Web Tech builds high-performance sites that make the most of solid hosting foundations.

Part of the Ganda Tech Services family, Cloud Geeks delivers specialist IT and cloud solutions for Australian small and medium businesses.