Custom metrics published to CloudWatch can be configured at two resolutions: standard (60-second intervals) or high resolution (1-second intervals). While both resolutions are priced identically for metric storage, the critical cost difference lies in the volume of API calls required to publish the data. A metric published every second generates 60 times more API calls than one published every 60 seconds. At scale — across hundreds or thousands of custom metrics in a microservices architecture — this multiplier translates into substantial and avoidable API charges that accumulate month over month.

This inefficiency commonly arises when teams default to high-resolution publishing without evaluating whether sub-minute granularity is actually needed for their monitoring use cases. Many workloads — including capacity planning, cost analysis, and non-critical service monitoring — function perfectly well with standard or even lower resolution. Compounding the issue, high-resolution metric data is only retained at its full 1-second granularity for three hours before being automatically aggregated to coarser intervals. Teams may therefore be paying a premium in API costs for resolution they cannot even query historically. Additionally, if alarms are configured to evaluate high-resolution metrics at sub-minute intervals, those alarms carry a higher per-alarm charge compared to standard-resolution alarms.

This inefficiency occurs when Azure Load Balancers remain provisioned after the backend workloads they supported have been scaled down, stopped, or decommissioned. This is common in non-production environments where virtual machines are shut down outside business hours, but the associated load balancers are left in place. Even when no meaningful traffic is flowing, the load balancer continues to incur base charges, resulting in ongoing cost without delivering value.

This inefficiency occurs when BigQuery slot reservations are sized for peak or anticipated demand but are not adjusted as workloads evolve. When actual query concurrency or complexity is lower than expected, a portion of the reserved slots remains idle. Because slot reservations are billed independently of usage, underutilized capacity results in sustained waste even while on-demand query costs elsewhere may continue.

This commonly happens when reservations are created during migrations, one-time analytical initiatives, or early scaling phases and are not revisited once usage stabilizes.

‍

This inefficiency occurs when an RDS database instance is deleted but its manual snapshots or retained backups remain. Unlike automated backups tied to a live instance, these backups persist independently and continue generating storage costs despite no longer supporting any active database. This is distinct from excessive retention on active databases and typically arises from incomplete cleanup during decommissioning.

This inefficiency occurs when analysts use SELECT * (reading more columns than needed) and/or rely on LIMIT as a cost-control mechanism. In BigQuery, projecting excess columns increases the amount of data read and can materially raise query cost, particularly on wide tables and frequently-run queries. Separately, applying LIMIT to a query does not inherently reduce bytes processed for non-clustered tables; it mainly caps the result set returned. The “LIMIT saves cost” assumption is only sometimes true on clustered tables, where BigQuery may be able to stop scanning earlier once enough clustered blocks have been read.

This inefficiency occurs when an App Service Plan is sized larger than required for the applications it hosts. Plans are often provisioned conservatively to handle anticipated peak demand and are not revisited after workloads stabilize. Because pricing is tied to the plan’s SKU rather than real-time usage, oversized plans continue to incur higher costs even when CPU and memory utilization remain consistently low.

This inefficiency occurs when an Azure Virtual WAN hub is provisioned with more capacity than required to support real network traffic. Because hub costs scale with the number of configured scale units, overprovisioned hubs continue to incur higher charges even when traffic levels remain consistently low. This commonly happens when hubs are sized for peak or anticipated demand that never materializes, or when traffic patterns change over time without corresponding capacity adjustments.

This inefficiency occurs when a function has steady, high-volume traffic (or predictable load) but continues running on default Lambda pricing, where costs scale with execution duration. Lambda Managed Instances runs Lambda on EC2 capacity managed by Lambda and supports multi-concurrent invocations within the same execution environment, which can materially improve utilization for suitable workloads (often IO-heavy services). For these steady-state patterns, shifting from duration-based billing to instance-based billing (and potentially leveraging EC2 pricing options like Savings Plans or Reserved Instances) can reduce total cost—while keeping the Lambda programming model. Savings are workload-dependent and not guaranteed.

This inefficiency occurs when Azure SQL Managed Instances continue running on legacy General Purpose or Business Critical tiers despite the availability of the next-gen General Purpose tier. The newer tier enables more granular scaling of vCPU, memory, and storage, allowing workloads to better match actual resource needs. In many cases, workloads running on Business Critical—or overprovisioned legacy General Purpose—do not require the premium performance or architecture of those tiers and could achieve equivalent outcomes at lower cost by moving to next-gen General Purpose.

This inefficiency occurs when backup data remains in a Recovery Services Vault after the original protected resource has been deleted. These orphaned backups continue to consume storage and generate cost despite no longer supporting an active workload. In addition, long-retained backups that are rarely accessed are often kept in higher-cost tiers, increasing storage spend without providing additional value.