RDS workloads often evolve — changing engine types, rightsizing instances, or shifting to Aurora or serverless models. When these changes occur after Reserved Instances have been purchased, the existing commitments may no longer match active usage. This results in silent overspend, as underutilized RIs continue billing without offsetting usage.
Unlike Convertible EC2 RIs, RDS RIs cannot be exchanged. Selling unused RDS RIs is not supported. In rare cases, AWS Support may approve a goodwill adjustment, but this is not guaranteed. The most effective way to recover value is to steer eligible workloads back toward the reserved configuration.
Many organizations default to Intel-based EC2 instances due to familiarity or assumptions about workload compatibility. However, AWS offers AMD and Graviton-based alternatives that often deliver significantly better price-performance for general-purpose and compute-optimized workloads.
By not testing workloads across available architectures, teams may continue paying a premium for Intel instances even when no specific performance or compatibility benefit exists. Over time, this results in unnecessary compute spend across development, staging, and even production environments.
Underutilized Snowflake warehouses occur when a workload is assigned a larger warehouse size than necessary. For example, a workload that could efficiently execute on a Medium (M) warehouse may be running on a Large (L) or Extra Large (XL) warehouse.This leads to unnecessary credit consumption without a proportional benefit to performance. Underutilization is often driven by early provisioning decisions that were not later reassessed, or by a desire for marginal speed improvements that do not justify the increased operational cost.
Inefficient execution of repeated queries occurs when common query patterns are frequently executed without optimization. Even if individual executions are successful, repeated inefficiencies compound overall compute consumption and credit costs.
By analyzing Snowflake's parameterized query metrics, organizations can identify top repeated queries and optimize them for better performance, resource usage, and cost-efficiency.
Inefficient pipeline refresh scheduling occurs when data refresh operations are executed more frequently, or with more compute resources, than the actual downstream business usage requires.
Without aligning refresh frequency and resource allocation to true data consumption patterns (e.g., report access rates in Tableau or Sigma), organizations can waste substantial Snowflake credits maintaining underutilized or rarely accessed data assets.
Inefficiency arises when MVs are either underused or misused.
Proper evaluation of workload patterns and strategic use of MVs is critical to achieve a net cost benefit.
Organizations may experience unnecessary Snowflake spend due to inefficient query-to-warehouse routing, lack of dynamic warehouse scaling, or failure to consolidate workloads during low-usage periods. Third-party platforms offer solutions to address these inefficiencies:
Choosing between these solutions depends heavily on the organization's internal capabilities and desired balance between control and automation.
Excessive Auto-Clustering costs occur when tables experience frequent and large-scale modifications ("high churn"), causing Snowflake to constantly recluster data. This leads to significant and often hidden compute consumption for maintenance tasks, especially when table structures or loading patterns are not optimized. Poor clustering key choices, unordered data loads, or frequent full-table replacements are common drivers of unnecessary Auto-Clustering activity.
Retention of stale data occurs when old, no longer needed records are preserved within active Snowflake tables. Without lifecycle policies or regular purging, tables accumulate outdated data.
Because Snowflake’s compute charges are tied to how much data is scanned, retaining large volumes of inactive or irrelevant data can drive up both storage and query execution costs unnecessarily.
Ingesting a large number of small files (e.g., files smaller than 10 MB) using Snowpipe can lead to disproportionately high costs due to the per-file overhead charges. Each file, regardless of its size, incurs the same overhead fee, making the ingestion of numerous small files less cost-effective. Additionally, small files can increase the load on Snowflake's metadata and ingestion infrastructure, potentially impacting performance.
