If backup retention settings are too high or old automated backups are unnecessarily retained, costs can accumulate rapidly. RDS backup storage is significantly more expensive than equivalent storage in S3. For long-term retention or compliance use cases, exporting backups to S3 (e.g., via snapshot export to Amazon S3 in Parquet) is often more cost-effective than retaining them in RDS-native format.
In many Databricks environments, large Delta tables are created without enabling standard optimization features like partitioning and Z-Ordering. Without these, queries scanning large datasets may read far more data than necessary, increasing execution time and compute usage. * **Partitioning** organizes data by a specified column to reduce scan scope. * **Z-Ordering** optimizes file sorting to minimize I/O during range queries or filters. * **Delta Format** enables additional optimizations like data skipping and compaction. Failing to use these features in high-volume tables often results in avoidable performance overhead and elevated spend, especially in environments with frequent exploratory queries or BI workloads.
AWS Backup does not natively support global deduplication or change block tracking across backups. As a result, even traditional incremental or differential backup strategies (e.g., daily incremental, weekly full) can accumulate redundant data. Over time, this leads to higher-than-necessary storage usage and cost — especially in environments with frequent backup schedules or large data volumes that only change minimally between snapshots. While some third-party agents can implement CBT and deduplication at the client level, AWS Backup alone offers no built-in mechanism to avoid storing unchanged data across backup generations.
When GCS object versioning is enabled, every overwrite or delete operation creates a new noncurrent version. Without a lifecycle rule to manage old versions, they persist indefinitely. Over time, this results in: * Accumulation of outdated data * Unnecessary storage costs, especially in Standard or Nearline classes * Lack of visibility into what is still needed vs. legacy debris This issue often goes unnoticed in environments with frequent data updates or automated processes (e.g., logs, models, config snapshots).
When EC2 instances are provisioned, each attached EBS volume has a `DeleteOnTermination` flag that determines whether it will be deleted when the instance is terminated. If this flag is set to `false` — often unintentionally in custom launch templates, AMIs, or older automation scripts — volumes persist after termination, resulting in orphaned storage. While detached volumes are easy to detect and clean up after the fact, proactively identifying attached volumes with `DeleteOnTermination=false` can prevent future waste before it occurs.
While moving objects to colder storage classes like Glacier or Infrequent Access (IA) can reduce storage costs, premature transitions without analyzing historical access patterns can lead to unintended expenses. Retrieval charges, restore time delays, and early delete penalties often go unaccounted for in simplistic tiering decisions. This inefficiency arises when teams default to colder tiers based solely on perceived “age” of data or storage savings—without confirming access frequency, restore time SLAs, or application requirements. Unlike inefficiencies focused on *underuse* of cold storage, this inefficiency reflects *overuse* or misalignment, resulting in higher total costs or operational friction.
Many environments continue using io1 volumes for high-performance workloads due to legacy provisioning or lack of awareness of io2 benefits. io2 volumes provide equivalent or better performance and durability with reduced cost at scale. Failing to adopt io2 where appropriate results in unnecessary spend on IOPS-heavy volumes.
When large numbers of objects are deleted from S3—such as during cleanup or lifecycle transitions—CloudTrail can log every individual delete operation if data event logging is enabled. This is especially costly when deleting millions of objects from buckets configured with CloudTrail data event logging at the object level. The resulting volume of logs can cause a significant, unexpected spike in CloudTrail charges, sometimes exceeding the cost of the underlying S3 operations themselves. This inefficiency often occurs when teams initiate bulk deletions for cleanup or cost savings without realizing that CloudTrail logs every API call, including `DeleteObject`, if data event logging is active for the bucket.
Without lifecycle policies, data in OCI Object Storage remains in the default storage tier indefinitely—even if it is rarely accessed. This can lead to growing costs from unneeded or rarely accessed data that could be expired or transitioned to lower-cost tiers like Archive Storage.
Block volumes that are not attached to any instance continue to incur charges. These often accumulate after instance deletion or reconfiguration. Unlike boot volumes, unattached data volumes may be harder to track if not labeled or tagged clearly.
