Workloads that frequently scale up and down within the same day—whether manually, via automation, or platform-managed—can encounter hidden cost amplification under the DTU model. When a database changes tiers (e.g., S7 → S4), Azure treats each tiered segment as a separate allocation and applies full-hour rounding independently. In some cases, both tiers may be billed for the same time period due to failover, reallocation delays, or timing mismatches during transitions.
This behavior is opaque to most users because billing granularity is daily, and Azure does not explicitly surface overlapping charges. The result is unexpected overbilling where a single database may appear to consume 28 or more “hours” of DTU in a single calendar day. While technically aligned with Azure’s billing design, this creates inefficiencies when tier switches are frequent and uncoordinated.
Highly compressible datasets, such as those with repeated string fields, nested structures, or uniform rows, can benefit significantly from physical storage billing. Yet most datasets remain on logical storage by default, even when physical storage would reduce costs.
This inefficiency is common for cold or infrequently updated datasets that are no longer optimized or regularly reviewed. Because storage behavior and data characteristics evolve, failing to periodically reassess the billing model may result in persistent waste.
Bigtable automatically splits data into tablets (shards), which are distributed across provisioned nodes. However, poorly designed row key schemas or excessive shard counts (caused by high cardinality, hash-based keys, or timestamp-first designs) can result in performance bottlenecks or hot spotting. To compensate, users often scale up node counts — increasing costs — when the real issue lies in suboptimal data distribution. This leads to inflated infrastructure spend without actual workload increase.
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.
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.
