Retry storms occur when a function fails and is automatically retried repeatedly due to default retry behavior for asynchronous events (e.g., SQS, EventBridge). If the error is persistent and unhandled, retries can accumulate rapidly — often invisibly — creating a large volume of billable executions with no successful outcome. This is especially costly when functions run for extended durations or have high memory allocation.
Memorystore instances that are provisioned but unused — whether due to deprecated services, orphaned environments, or development/testing phases ending — continue to incur memory and infrastructure charges. Because usage-based metrics like client connections or cache hit ratios are not tied to billing, an idle instance costs the same as a heavily used one. This makes it critical to identify and decommission inactive caches.
Cloud SQL instances are often over-provisioned or left running despite low utilization. Since billing is based on allocated vCPUs, memory, and storage — not usage — any misalignment between actual workload needs and provisioned capacity leads to unnecessary spend. Common causes include: * Initial oversizing during launch that was never revisited * Non-production environments with continuous uptime but minimal use * Databases used intermittently (e.g., for nightly reports) but kept running 24/7 Without rightsizing or scheduling strategies, these instances generate ongoing cost with limited business value.
In Cloud Run, each revision is deployed with a fixed memory allocation (e.g., 512MiB, 1GiB, 2GiB, etc.). 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 per request — 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.
Each Cloud NAT gateway provisioned in GCP incurs hourly charges for each external IP address attached, regardless of whether traffic is flowing through the gateway. In many environments, NAT configurations are created for temporary access (e.g., one-off updates, patching windows, or ephemeral resources) and are never cleaned up. If no traffic is flowing, these NAT gateways remain idle yet continue to generate charges due to reserved IPs and persistent gateway configuration. This is especially common in non-production environments or when legacy configurations are forgotten.
Cloud Memorystore instances that remain idle—i.e., not receiving read or write requests—continue to incur full costs based on provisioned size. In test environments, migration scenarios, or deprecated application components, Redis instances are often left running unintentionally. Since Redis does not autoscale or suspend, unused capacity results in 100% waste until explicitly deleted.
When GCS object versioning is enabled, every overwrite or delete operation creates a new noncurrent version. Without a lifecycle rule to manage old versions, they persist indefinitely. Over time, this results in: * Accumulation of outdated data * Unnecessary storage costs, especially in Standard or Nearline classes * Lack of visibility into what is still needed vs. legacy debris This issue often goes unnoticed in environments with frequent data updates or automated processes (e.g., logs, models, config snapshots).
Cloud Run allows users to allocate up to 8 GB of memory per container instance. If memory is overestimated — often as a buffer or based on unvalidated assumptions — customers pay for more than what the workload consumes during execution. Unlike in VM-based environments where memory might be shared or underutilized without direct cost impact, in Cloud Run, you're billed precisely for what you allocate. This inefficiency often results from: * Defaulting to high memory values for “safety” * Not using monitoring tools to assess actual memory usage * Lack of clear ownership over service tuning
Teams often adopt flat-rate pricing (slot reservations) to stabilize costs or optimize for heavy, recurring workloads. However, if query volumes drop — due to seasonal cycles, architectural shifts (e.g., workload migration), or inaccurate forecasting — those reserved slots may sit underused. This inefficiency is easy to miss, as the cost remains fixed and detached from usage volume. Unlike autoscaling models, reservations require active monitoring and manual adjustment. In some organizations, multiple projects reserve separate slot pools, exacerbating waste through fragmentation.
When EC2 instances are provisioned, each attached EBS volume has a `DeleteOnTermination` flag that determines whether it will be deleted when the instance is terminated. If this flag is set to `false` — often unintentionally in custom launch templates, AMIs, or older automation scripts — volumes persist after termination, resulting in orphaned storage. While detached volumes are easy to detect and clean up after the fact, proactively identifying attached volumes with `DeleteOnTermination=false` can prevent future waste before it occurs.
