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.
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.
If a table is not partitioned by a relevant column (typically a timestamp), every query scans the entire dataset, even if filtering by date. This leads to: * High costs per query * Long execution times * Inefficient use of resources when querying recent or small subsets of data This inefficiency is especially common in: * Event or log data stored in raw, unpartitioned form Historical data migrations without schema optimization * Workloads developed without awareness of BigQuery’s scanning model
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.
Non-production OpenSearch domains often inherit Multi-AZ configurations from production setups without clear justification. This leads to redundant replica shards across AZs, inflating both compute and storage costs. Unless strict uptime or fault tolerance requirements exist, most dev/test workloads do not benefit from Multi-AZ redundancy.
In non-production environments, enabling Multi-AZ Redis clusters introduces redundant replicas that may not deliver meaningful business value. These replicas are often kept in sync across Availability Zones, incurring both compute and inter-AZ data transfer costs. For development or test clusters that can tolerate occasional downtime or data loss, a single-AZ deployment is typically sufficient and significantly less expensive.
RDS Multi-AZ deployments are designed for production-grade fault tolerance. In non-production environments, this configuration doubles the cost of database instances and storage with little added value. Unless explicitly required for high-availability testing, Multi-AZ in dev, staging, or test environments typically results in avoidable expense.
RDS reader nodes are intended to handle read-only workloads, allowing for traffic offloading from the primary (writer) node. However, in many environments, services are misconfigured or hardcoded to send all traffic—including reads—to the writer node. This results in underutilized reader nodes that still incur full hourly charges, while the writer node becomes a performance bottleneck and may require upsizing to handle unnecessary load. This inefficiency reduces cost-effectiveness and resilience, especially in high-throughput or scalable architectures.
MemoryDB now supports Valkey, a drop-in replacement for Redis OSS offering significant cost and performance advantages. However, many deployments still default to Redis OSS, incurring higher hourly costs and unnecessary data write charges. For compatible workloads, continuing to use Redis OSS instead of Valkey represents a missed opportunity for savings and modernization.
Provisioned capacity mode is appropriate for workloads with consistent or predictable throughput. However, when write capacity is significantly over-provisioned relative to actual usage, it results in wasted spend. This inefficiency is especially common in dev/test environments, legacy systems, or workloads that have tapered off over time but were never adjusted.
