Skip to content
Cloud Efficiency Hub

Overprovisioned Memory Allocation in Cloud Run Services

The short version

In Cloud Run, each revision is deployed with a fixed memory allocation (e.g., 512MiB, 1GiB, 2GiB, etc.).

PointFive Research

Cloud cost research at PointFive

GCP service
GCP Cloud Run
Category
Compute
Reference
CER-0179
Type
Overprovisioned Resource

Explanation

Why the waste happens and who it affects.

These settings are often overestimated during initial development or copied from templates. Unlike auto-scaling platforms that adapt instance size based on workload, Cloud Run continues to bill per the allocated amount regardless of actual memory used during execution. If a service consistently uses significantly less memory than allocated, it results in avoidable overpayment for every second of billable instance time - especially for high-throughput or long-running services. Since memory and CPU are billed together based on configured values, this inefficiency compounds quickly at scale.

Billing model

The pricing dimensions that drive this cost.

Billed based on:

  • Allocated vCPU-seconds and memory GiB-seconds of billable instance time, not per request; concurrent requests on one instance share that time
  • Billable instance time, rounded up to the nearest 100 ms: with request-based billing, while an instance is starting, shutting down, or processing at least one request; with instance-based billing, the full instance lifetime (minimum 1 minute)
  • Number of requests
  • Additional charges for egress and requests beyond free tier

How to detect

4 checks to find it in your estate.

  • Review actual memory usage per request over a representative time window
  • Identify services with consistently low memory utilization relative to their configured limits
  • Evaluate whether higher memory tiers were chosen to solve startup latency or cold start issues that no longer apply
  • Cross-reference high-throughput services where per-request efficiency has significant cost impact

How to fix

4 ways to remove the waste.

  • Reconfigure services with right-sized memory allocations aligned to observed usage patterns
  • Test progressively smaller memory configurations to find a stable baseline without introducing latency or OOM errors
  • Implement monitoring for memory pressure or failures to validate new settings
  • Use performance benchmarks and load tests in lower environments before promoting configuration changes to production

Documentation

Vendor references for pricing and configuration.