S3 buckets configured with SSE-KMS but without Bucket Keys generate a separate KMS request for each object operation. This behavior results in disproportionately high KMS request costs for data-intensive workloads such as analytics, backups, or frequently accessed objects. Bucket Keys allow S3 to cache KMS data keys at the bucket level, reducing the volume of KMS calls and cutting encryption costs—often with no impact on security or performance.

Detection

• Identify S3 buckets with SSE-KMS encryption enabled

• Check if Bucket Keys are disabled or not configured

• Analyze object access frequency and KMS request volume

• Estimate potential cost savings by enabling Bucket Keys

• Prioritize buckets with high object counts or frequent read/write operations

Remediation

• Enable S3 Bucket Keys for eligible buckets using SSE-KMS

• Document any security exceptions or requirements that prevent Bucket Key use

• Note: Enabling Bucket Keys applies only to newly encrypted objects; existing objects must be re-encrypted or re-uploaded to benefit

• Track KMS request metrics before and after rollout to validate cost impact

Audit logs are often retained longer than necessary, especially in environments where the logging destination is not carefully selected. Projects that initially route SQL Audit Logs or other high-volume sources to LAW or Azure Storage may forget to revisit their retention strategy. Without policies in place, logs can accumulate unchecked—particularly problematic with SQL logs, which can generate significant volume. Lifecycle Management Policies in Azure Storage are a key tool for addressing this inefficiency but are often overlooked.

However, tier transitions are not always cost-saving. For example, in cases where log data consists of extremely large numbers of very small files (such as AKS audit logs across many pods), the transaction charges incurred when moving objects between storage tiers may exceed the potential savings from reduced storage rates. In these scenarios, it can be more cost-effective to retain logs in Hot tier until deletion, rather than moving them to lower-cost tiers first.

Detection

Identify resources with Audit Logging enabled

Determine whether logs are routed to Log Analytics Workspace or Azure Storage

Assess whether current retention aligns with compliance or operational needs

Evaluate volume and cost of logs retained beyond required periods

Review whether lifecycle policies or retention settings are currently configured

Check if any projects have a “set and forget” logging configuration that has never been reviewed

Remediation

Apply Azure Storage Lifecycle Management Policies to transition older logs to lower-cost tiers or delete them after a set retention period. Before implementing tier transitions, assess whether the additional transaction costs from moving large volumes of small log files could outweigh potential storage savings. In such cases, consider retaining logs in Hot tier until deletion if that results in lower overall cost.

For logs in Log Analytics Workspace, assess whether they can be moved to Basic tables or stored in Storage Accounts instead

Establish project-specific retention requirements with stakeholders and enforce them across all audit logging configurations

Periodically audit logging destinations and lifecycle settings to prevent silent cost creep

When file systems are launched with Provisioned Throughput, teams often overestimate future demand — especially in environments cloned from production or sized “just to be safe.” Over time, many workloads consume far less throughput than allocated, especially in dev/test environments or during periods of reduced usage. These overprovisioned settings can silently accrue substantial monthly charges that go unnoticed without intentional review.

This inefficiency is not flagged by AWS Trusted Advisor and is easy to miss. Elastic Throughput mode now offers a scalable alternative that automatically adjusts capacity — but isn’t always cheaper, depending on the workload’s sustained throughput.

S3 Storage Lens Advanced provides valuable insights into storage usage and trends, but it incurs a recurring cost. Organisations often enable it during an optimization initiative but fail to turn it off afterwards. When no active storage efficiency efforts are underway, these advanced metrics can become an unnecessary expense, especially at large scale across many buckets.

Advanced metrics include things like:

Cost optimization recommendations

Data retrieval patterns

Encryption and access control analytics

Historical trends beyond the 30-day free tier

Because the configuration is global or account-level, it’s easy to forget that these additional metrics are enabled and quietly incurring cost. This inefficiency often surfaces in organizations that over-invest in observability tooling without aligning it to an ongoing operational workflow.

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.