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.
Storing raw JSON or CSV files in S3—especially when written frequently in small batches—leads to excessive scan costs in Athena. These formats are row-based and verbose, requiring Athena to scan and parse the full content even when only a few fields are queried. Without columnar formats, partitioning, or metadata-aware table formats, queries become inefficient and expensive, especially in high-volume environments.
An ELB with only one registered EC2 instance does not achieve its core purpose—distributing traffic across multiple backends. In this configuration, the ELB adds complexity and cost without improving availability, scalability, or fault tolerance. This setup is often the result of premature scaling design or misunderstood architecture patterns. If there's no plan to horizontally scale the application, the ELB can often be removed entirely without user impact.
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.
Photon is enabled by default on many Databricks compute configurations. While it can accelerate certain SQL and DataFrame operations, its performance benefits are workload-specific and may not justify the increased DBU cost. Many pipelines, particularly ETL jobs or simpler Spark workloads, do not benefit materially from Photon but still incur the higher DBU multiplier. Disabling Photon by default and allowing it only where proven beneficial can reduce cost without degrading performance.
