This inefficiency occurs when a blob container intended for long-term or infrequently accessed data continues to store objects in higher-cost tiers like Hot or Cool, instead of using the Archive tier. This often happens when containers are created without lifecycle policies or default tier settings. Over time, storing archival data in non-archival tiers results in avoidable cost without any performance benefit, especially for compliance data, backups, or historical logs that rarely need to be accessed.
This inefficiency arises when a virtual machine is left in a stopped (deallocated) state for an extended period but continues to incur costs through attached storage and associated resources. These idle VMs are often remnants of retired workloads, temporary environments, or paused projects that were never fully cleaned up. Without clear ownership or automated cleanup, they can persist unnoticed and accumulate avoidable charges.
When an EKS cluster remains on a Kubernetes version that has reached the end of standard support, AWS begins charging an additional Extended Support fee. These charges often arise from delays in upgrade cycles, uncertainty about workload compatibility, or overlooked legacy clusters. If the workload does not require the older version, continuing to run the cluster in this state results in unnecessary cost and technical risk.
This inefficiency occurs when an EC2 instance is stopped but still has one or more attached EBS volumes. Although the compute resource is not generating charges while stopped, the attached volumes continue to incur full storage and performance-related costs. These volumes are often overlooked in cost reviews, especially if the instance is temporarily paused or has been left in a stopped state long-term. Without regular validation, these volumes may represent unused capacity that delivers no value.
This inefficiency occurs when an RDS cluster remains provisioned but is no longer serving any workloads and has no active database connections. Unlike underutilized resources, these clusters are completely idle—showing no query activity, background processing, or usage over time. They often persist in dev, staging, or legacy environments where the workload has been retired or moved, yet the cluster remains active and continues to generate ongoing compute and storage costs.
When the EC2 instance types used for EKS node groups have a memory-to-CPU ratio that doesn’t match the workload profile, the result is poor bin-packing efficiency. For example, if memory-intensive containers are scheduled on compute-optimized nodes, memory may run out first while CPU remains unused. This forces new nodes to be provisioned earlier than necessary. Over time, this mismatch can lead to higher compute costs even if the cluster appears fully utilized.
S3 buckets often persist after projects complete or when the associated workloads have been retired. If a bucket is no longer being read from or written to—and its contents are not required for compliance, backup, or retention purposes—it represents ongoing cost without delivering value. Many organizations overlook these idle buckets, especially in shared or legacy accounts, leading to unnecessary storage costs over time.
Some ElastiCache clusters continue to run on older-generation node types that have since been replaced by newer, more cost-effective options. This can happen due to legacy templates, lack of version validation, or infrastructure that has not been reviewed in years. Newer instance families often deliver better performance at a lower hourly rate. Modernizing to newer node types can reduce compute spend without sacrificing performance, and in many cases, improve it.
Workloads are sometimes deployed in specific AWS regions based on legacy decisions, developer convenience, or perceived performance requirements. However, regional EC2 pricing can vary significantly, and placing instances in a suboptimal region can lead to higher compute costs, increased data transfer charges, or both. In particular, workloads that frequently communicate with resources in other regions—or that serve a user base concentrated elsewhere—can incur unnecessary costs. Re-evaluating regional placement can reduce these costs without compromising performance or availability when done strategically.
Some architectures unintentionally route large volumes of traffic between resources that reside in different Availability Zones—such as database queries, service calls, replication, or logging. While these patterns may be functionally correct, they can lead to unnecessary data transfer charges when the traffic could be contained within a single AZ. Over time, this can become a silent cost driver, especially for chatty microservices, replicated storage layers, or high-throughput pipelines. Re-architecting for AZ-locality—when possible—can reduce these charges without affecting availability in environments where high resilience isn’t required.
