Load balancers incur charges based on provisioned bandwidth shape, even if backend traffic is minimal. If traffic is low, or if only one backend server is configured, the load balancer may be oversized or unnecessary—especially in test or staging environments.

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.

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.

OCI Compute instances incur cost based on provisioned CPU and memory, even when the instance is lightly loaded. Instances that show consistently low usage across time—such as those used only for occasional tasks, test environments, or forgotten workloads—may be overprovisioned relative to their actual needs.

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.

If an AWS WorkSpace has been provisioned but not accessed in a meaningful timeframe, it may represent waste—particularly if it is set to monthly billing. Many organizations leave WorkSpaces active for users who no longer need them or have shifted roles, leading to persistent charges without corresponding business value. Even in hourly mode, costs can accrue if WorkSpaces are left in a running state.

MemoryDB now supports Valkey, a drop-in replacement for Redis OSS offering significant cost and performance advantages. However, many deployments still default to Redis OSS, incurring higher hourly costs and unnecessary data write charges. For compatible workloads, continuing to use Redis OSS instead of Valkey represents a missed opportunity for savings and modernization.

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.