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 compression is either disabled or not functioning effectively on a CloudFront distribution. Static assets such as text, JSON, JavaScript, and CSS files are compressible and benefit significantly from compression. Without compression, CloudFront transfers larger objects, leading to increased data transfer charges and slower delivery performance—without improving user experience.

This inefficiency occurs when an EBS volume has provisioned IOPS levels that consistently exceed the actual I/O requirements of the workload it supports. This can happen when performance buffers are estimated too high, usage patterns change over time, or default settings are left unadjusted. Provisioned IOPS above the included baseline generate ongoing charges that may not reflect actual utilization, resulting in avoidable cost.

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 EC2 instance remains in a running state but is not actively utilized. These instances may be remnants of past projects, forgotten development environments, or temporarily created for testing and never decommissioned. If an instance shows consistently low or no CPU, network, or disk activity—and no active connections—it likely serves no operational purpose but continues to generate ongoing compute and storage charges.

This inefficiency occurs when a VM is deallocated but its attached managed disks are still active and incurring storage charges. While compute billing stops for deallocated VMs, the disks remain provisioned and billable. These disks often persist unintentionally after a VM is paused, retired, or left unused in dev/test environments, resulting in waste if not explicitly cleaned up.

ListBucket requests are commonly used to enumerate objects in a bucket, such as by backup systems, scheduled sync jobs, data catalogs, or monitoring tools. When these operations are frequent or target buckets with large object counts, they can generate disproportionately high request charges. In many cases, real-time enumeration is not necessary and can be replaced with more efficient alternatives like S3 Inventory, which provides object metadata on a scheduled basis at lower cost.