This inefficiency occurs when small files are stored in S3 storage classes that impose a minimum object size charge, resulting in unnecessary costs. Small files under 128 KB stored in Glacier Instant Retrieval, Standard-IA, or One Zone-IA are billed as if they were 128 KB. If these small files are accessed frequently, S3 Standard may be a better fit. For infrequently accessed small files, transitioning them to archival storage classes like Glacier Flexible Retrieval or Deep Archive can optimize storage spend. Poorly tuned lifecycle policies often allow small files to remain in suboptimal storage classes indefinitely.

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 arises when snapshots are retained long after they’ve served their purpose. Snapshots may have been created for backups, migrations, or disaster recovery plans but were never deleted—even after the related workload or volume was decommissioned. Over time, these unused snapshots accumulate, continuing to incur storage costs without providing operational value.

This inefficiency occurs when an RDS instance uses a high-cost storage type such as io1 or io2 but does not require the performance benefits it provides. In many cases, provisioned IOPS are set at or below the free baseline included with gp3 (3,000 IOPS and 125 MB/s). In such scenarios, continuing to use provisioned IOPS storage results in elevated cost with no functional advantage. These misconfigurations often persist due to legacy templates, default settings, or a lack of periodic review.

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 a table remains in the default Standard storage class despite having minimal or infrequent access. In these cases, switching to Standard-IA can significantly reduce monthly storage costs, especially for archival tables, compliance data, or legacy systems that are still retained but rarely queried.

This inefficiency occurs when legacy volume types such as gp2 or io1 remain in use, even though AWS has released newer types—like gp3 and io2—that offer better performance at lower cost. Gp3 allows users to configure IOPS and throughput independently of volume size, while io2 provides higher durability and more predictable performance than io1. These newer volumes are generally more cost-effective and can be adopted without re-architecting workloads. Many teams continue using outdated types due to default AMIs, automation templates, or simple oversight.

Multipart upload allows large files to be uploaded in segments. Each part is stored individually until the upload is finalized by a “CompleteMultipartUpload” request. If this final request is never issued—due to a timeout, crash, failed job, or misconfiguration—the parts remain stored but are effectively useless: they do not form a valid object and cannot be retrieved. Without a lifecycle policy in place to clean up these incomplete uploads, the orphaned parts persist and continue to incur storage charges indefinitely.

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.