OCI Object Storage buckets accrue charges based on data volume stored, even if no activity has occurred. Buckets that haven't been read from or written to in months may contain outdated data or artifacts from discontinued projects.

When a Compute instance is terminated in OCI, the associated boot volume is not deleted by default. If the termination settings don’t explicitly delete the boot volume, it persists and continues to generate storage charges. Because boot volumes are managed under the Block Volumes service, not within the Compute UI, they’re easy to overlook—especially in environments with frequent provisioning and teardown. Over time, these orphaned boot volumes can accumulate and contribute to unnecessary costs.

When replicating an EFS file system across AWS regions (e.g., for disaster recovery), the destination file system does not automatically inherit the source’s lifecycle policy. As a result, files replicated to the destination will remain in the Standard storage class unless a new lifecycle policy is explicitly configured. Over time, this can lead to significantly higher storage costs, particularly in DR environments where data is rarely accessed but still replicated in full.

EFS offers lifecycle policies that transition files from the Standard tier to Infrequent Access (IA) based on inactivity, significantly reducing storage costs for cold data. When this feature is not enabled, infrequently accessed files remain in the more expensive Standard tier indefinitely. This often occurs when the file system is initially provisioned for performance but long-term access patterns are not reevaluated.

EBS volumes often remain significantly overprovisioned compared to the actual data stored on them. Because billing is based on the total provisioned capacity—not actual usage—this creates ongoing waste when large volumes are only partially used. Overprovisioning may result from default sizing in templates, misestimated requirements, or conservative provisioning practices. Identifying and remediating these cases can lead to meaningful storage cost reductions without impacting workload performance.

EBS Snapshot Archive is a lower-cost storage tier for rarely accessed snapshots retained for compliance, regulatory, or long-term backup purposes. Archiving snapshots that do not require frequent or fast retrieval can reduce snapshot storage costs by up to 75%. Despite this, many organizations retain large volumes of snapshots in the standard tier long after their operational value has expired.

Azure Files Standard tier is cost-effective for low-traffic scenarios but imposes per-operation charges that grow rapidly with frequent access. In contrast, Premium tier provides consistent IOPS and throughput without additional transaction charges. When high-throughput or performance-sensitive workloads (e.g., real-time application data, logs, user file interactions) are placed in the Standard tier, transaction costs can significantly exceed expectations.

This inefficiency occurs when teams prioritize low storage cost without considering IOPS or throughput needs, or when workloads grow more active over time without reevaluation of their storage configuration. Unlike Blob Storage, migrating to Azure Files Premium requires creating a new storage account, making this an often-overlooked optimization.

Azure Blob Storage tiers are designed to optimize cost based on access frequency. However, when frequently accessed data is stored in the Cool or Archive tiers—either due to misconfiguration, default settings, or cost-only optimization—transaction costs can spike. These tiers impose significantly higher charges for read/write operations and metadata access compared to the Hot tier.

This misalignment is common in analytics, backup, and log-processing scenarios where large volumes of object-level operations occur regularly. While the per-GB storage rate is lower, the overall cost becomes higher due to frequent access. This inefficiency is silent but accumulates rapidly in active workloads.

Azure users may enable the SFTP feature on Storage Accounts during migration tests, integration scenarios, or experimentation. However, if left enabled after initial use, the feature continues to generate flat hourly charges — even when no SFTP traffic occurs.

Because this fee is incurred silently and independently of storage usage, it often goes unnoticed in cost reviews. When SFTP is not actively used for data ingestion or export, disabling it can eliminate unnecessary charges without impacting other access methods.

When EC2 instances within a VPC access Amazon S3 in the same region without a Gateway VPC Endpoint, traffic is routed through the public S3 endpoint and incurs standard internet egress charges — even though it remains within the AWS network. This results in unnecessary egress charges, as AWS treats this traffic as data transfer out to the internet, billed under the S3 service.

By contrast, provisioning a Gateway Endpoint for S3 allows traffic between EC2 and S3 to flow over the AWS private backbone at no additional cost. This configuration is especially important for data-intensive applications, such as analytics jobs, backups, or frequent uploads/downloads, where the cumulative data transfer can be substantial.

Because the egress cost is billed under S3, it is often misattributed or overlooked during EC2 or networking reviews, leading to silent overspend.