This inefficiency occurs when a DynamoDB table is no longer accessed by any active workload but continues to accumulate storage charges. These tables often remain after a project ends, a feature is retired, or data is migrated elsewhere. Without any read or write activity, the table provides no functional value and becomes a cost liability.
This inefficiency occurs when an RDS instance remains in the running state but is no longer actively serving application traffic. These instances may be remnants of retired applications, paused development environments, or workloads that were migrated elsewhere. If an instance shows no active connections and sustained inactivity across CPU and memory metrics, it is likely idle and generating unnecessary costs.
This inefficiency occurs when an RDS instance is consistently operating below its provisioned capacity—for example, showing low CPU, or memory utilization over an extended period. This often results from conservative initial sizing, decreased workload demand, or failure to review and adjust after deployment. Running oversized RDS instances leads to unnecessary compute and licensing costs without delivering additional value.
This inefficiency occurs when an RDS instance is allocated significantly more storage than it consumes. For example, a 2TB volume might contain only 150GB of actual data. Since RDS does not allow reducing allocated storage on existing instances, these volumes continue to incur charges based on total provisioned size—not actual usage. This often goes unnoticed in long-running databases that no longer require their original allocation.
When an RDS cluster is not upgraded in time, it can fall out of standard support and incur Extended Support charges. This often happens when upgrade cycles are delayed, blocked by compatibility issues, or deprioritized due to competing initiatives. Over time, these fees can add up significantly. Staying on an outdated version also increases operational risk and reduces access to engine improvements, performance enhancements, and security patches.
This inefficiency occurs when an RDS cluster remains provisioned but is no longer serving any workloads and has no active database connections. Unlike underutilized resources, these clusters are completely idle—showing no query activity, background processing, or usage over time. They often persist in dev, staging, or legacy environments where the workload has been retired or moved, yet the cluster remains active and continues to generate ongoing compute and storage costs.
Some ElastiCache clusters continue to run on older-generation node types that have since been replaced by newer, more cost-effective options. This can happen due to legacy templates, lack of version validation, or infrastructure that has not been reviewed in years. Newer instance families often deliver better performance at a lower hourly rate. Modernizing to newer node types can reduce compute spend without sacrificing performance, and in many cases, improve it.
Manual snapshots are often created for operational tasks like upgrades, migrations, or point-in-time backups. Unlike automated backups, which are automatically deleted after a set retention period, manual snapshots remain in place until explicitly deleted. Over time, this can lead to an accumulation of snapshots that are no longer needed but still incur monthly storage charges. This is particularly common in environments where snapshots are taken frequently but not consistently reviewed. If left unmanaged, manual snapshots can become a source of ongoing cost, especially for large databases or when snapshots are copied across regions.
Read replicas are intended to improve performance for read-heavy workloads or support cross-region redundancy. However, it's common for replicas to remain in place even after their intended purpose has passed. In some cases, they were provisioned for scaling or analytics workloads that no longer exist; in others, they are tied to live environments but not actively receiving queries. Since each replica incurs full RDS costs, retaining one that is no longer used leads to unnecessary ongoing expenses.
Many Aurora clusters default to using the Standard configuration, which charges separately for I/O operations. For workloads with frequent read and write activity, this can lead to unnecessarily high costs. Aurora I/O-Optimized eliminates I/O charges entirely and simplifies cost predictability. In environments with consistently high I/O usage, switching to I/O-Optimized often results in lower total spend.
