Cloud Provider
Service Name
Inefficiency Type
Clear filters
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Showing
1234
out of
1234
inefficiencies
Filter
:
Filter
x
Suboptimal AppStream Fleet Auto Scaling Policies
Compute
Cloud Provider
AWS
Service Name
AWS AppStream 2.0
Inefficiency Type
Inefficient Configuration

When fleet auto scaling policies maintain more active instances than are required to support current usage—particularly during off-peak hours—organizations incur unnecessary compute costs. Fleets often remain oversized due to conservative default configurations or lack of schedule-based scaling. Tuning the scaling policies to better reflect usage patterns ensures that streaming infrastructure aligns with actual demand.

Underutilized or Overprovisioned AppStream Instances
Compute
Cloud Provider
AWS
Service Name
AWS AppStream 2.0
Inefficiency Type
Underutilization

AppStream fleets often default to instance types designed for worst-case or peak usage scenarios, even when average workloads are significantly lighter. This leads to consistently low utilization of CPU, memory, or GPU resources and inflated infrastructure costs. By right-sizing AppStream instances based on actual workload needs, organizations can reduce spend without compromising user experience.

Inactive AppStream Image Builder or App Block Builder Instances
Compute
Cloud Provider
AWS
Service Name
AWS AppStream 2.0
Inefficiency Type
Unused Resource

When AppStream builder instances are left running but unused, they continue to generate compute charges without delivering any value. These instances are commonly left active after configuration or image creation is completed but can be safely stopped or terminated when not in use. Identifying and decommissioning inactive builders helps reduce unnecessary compute costs.

Unarchived Long-Term EBS Snapshots
Storage
Cloud Provider
AWS
Service Name
AWS EBS
Inefficiency Type
Suboptimal Storage Tier

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.

Missing Shared Scope Configuration for Azure Reservations
Compute
Cloud Provider
Azure
Service Name
Azure Reservations
Inefficiency Type
Suboptimal Configuration

When reservations are scoped only to a single subscription, any unused capacity cannot be applied to matching resources in other subscriptions within the same tenant. This leads to underutilization of the committed reservation and continued on-demand charges in other parts of the organization. Enabling Shared scope allows all eligible subscriptions to consume the reservation benefit, improving utilization and reducing overall spend. This is particularly impactful in environments with decentralized provisioning, such as across dev/test/prod subscriptions or multiple business units.

Underutilized Kubernetes Workload
Compute
Cloud Provider
AWS
Service Name
AWS EKS
Inefficiency Type
Underutilization

When Kubernetes workloads request more CPU and memory than they actually consume, nodes must reserve capacity that remains unused. This leads to lower node density, forcing the cluster to maintain more instances than necessary. Aligning resource requests with observed utilization improves cluster efficiency and reduces compute spend without sacrificing application performance.

Underutilized Write Capacity on a DynamoDB Table
Databases
Cloud Provider
AWS
Service Name
AWS DynamoDB
Inefficiency Type
Underutilization

Provisioned capacity mode is appropriate for workloads with consistent or predictable throughput. However, when write capacity is significantly over-provisioned relative to actual usage, it results in wasted spend. This inefficiency is especially common in dev/test environments, legacy systems, or workloads that have tapered off over time but were never adjusted.

Underuse of Serverless Compute for Jobs and Notebooks
Compute
Cloud Provider
Databricks
Service Name
Databricks Serverless Compute
Inefficiency Type
Suboptimal Execution Model

Databricks Serverless Compute is now available for jobs and notebooks, offering a simplified, autoscaled compute environment that eliminates cluster provisioning, reduces idle overhead, and improves Spot survivability. For short-running, bursty, or interactive workloads, Serverless can significantly reduce cost by billing only for execution time. However, Serverless is not universally available or compatible with all workload types and libraries. Organizations that exclusively rely on traditional clusters may be missing emerging opportunities to reduce spend and simplify operations by leveraging Serverless where appropriate.

Underutilized Read Capacity on a DynamoDB Table
Databases
Cloud Provider
AWS
Service Name
AWS DynamoDB
Inefficiency Type
Underutilization

Provisioned capacity mode is appropriate for workloads with consistent or predictable throughput. However, when read capacity is significantly over-provisioned relative to actual usage, it results in wasted spend. This inefficiency is especially common in dev/test environments, legacy systems, or workloads that have tapered off over time but were never adjusted.

Underutilized EC2 Commitment Due to Workload Drift
Compute
Cloud Provider
AWS
Service Name
AWS EC2
Inefficiency Type
Overcommitted Reservation

When EC2 usage declines, shifts to different instance families, or moves to other services (e.g., containers or serverless), organizations may find that previously purchased Standard Reserved Instances or Savings Plans no longer match current workload patterns.

This misalignment results in underutilized commitments—where costs are still incurred, but no usage is benefiting from the associated discounts. Since these commitments cannot be easily exchanged, refunded, or sold (except for eligible RIs on the RI Marketplace), the only viable path to recoup value is to steer workloads back toward the covered usage profile.

There are no inefficiency matches the current filters.