AWS AI Automation to Cut Costs

At Opslyft, we have run AWS Compute Optimizer across hundreds of accounts, and the gap between "recommendations generated" and "savings actually banked" is almost always wider than teams expect. Compute Optimizer surfaces good signal. It also surfaces noise, edge cases, and the occasional recommendation that would page someone at 3am if blindly applied.

We have seen teams enable Compute Optimizer, see hundreds of recommendations, and then sit on them for six months because nobody wants to be the person who downsizes the wrong instance. We have also seen teams over-trust the recommendations, downsize aggressively, and roll back within a week after their checkout service started timing out under load.

The truth is somewhere in between. Compute Optimizer is one of the best free rightsizing engines AWS provides, but it needs context, validation, and an execution workflow to actually produce savings. This article walks through how we operationalize it across client environments, where it falls short, and how to wire it into a FinOps process that produces real, repeatable savings without burning your on-call team.

What is AWS Compute Optimizer?

AWS Compute Optimizer is a free service that uses machine learning on CloudWatch metrics and resource configuration data to recommend more efficient settings for compute resources. It supports EC2, Auto Scaling groups, EBS volumes, Lambda, ECS on Fargate, RDS, and license commitments.

It analyzes 14 to 90 days of utilization data and generates recommendations like "this m5.2xlarge could run on a m5.large at 18% lower cost with no performance impact." Most recommendations include risk levels, projected cost change, and confidence ranges.

Recommendations come in three categories:

• Rightsizing: switch to a smaller or differently-shaped instance based on actual utilization.
• Modernization: move to a newer generation, often Graviton, for better price-performance.
• Idle resource flagging: detect resources that have been near-zero utilization for an extended period.

The service is genuinely useful and catches things humans miss. We routinely see 20 to 30% rightsizing potential surface from Compute Optimizer alone in audits where teams thought they had already optimized.

What it does well is one half of the picture. The other half is understanding where it falls short, because that gap is where production incidents come from.

Where AWS Compute Optimizer falls short in production

After running Compute Optimizer across a wide range of workloads, here is where we have seen it produce recommendations that need careful review before action.

It is conservative on memory but blind to bursty workloads

Compute Optimizer reads memory metrics only when the CloudWatch agent is installed. Without it, memory inferences come from CPU patterns, which is unreliable for memory-bound workloads like Java services, Postgres, or Elasticsearch.

We always install the CloudWatch agent before trusting memory recommendations. Teams that skip this step end up with recommendations that look great on paper and trigger OOMKills two days after deployment.

It does not understand application context

Compute Optimizer cannot see your SLO, your peak traffic windows, or your event-driven spikes. A recommendation that looks safe based on 60 days of metrics might miss a quarterly load test, a seasonal traffic spike, or a deployment pattern that briefly stresses memory.

We always cross-reference recommendations against application-level metrics from Datadog, Prometheus, or New Relic before acting. CPU and memory tell you part of the story. Application latency and error budgets tell you the rest.

It treats Auto Scaling Groups as static units

Compute Optimizer makes recommendations about ASG instance types based on aggregated utilization. But ASGs scale, and the right instance type at minimum capacity may be wrong at peak. We have seen teams downsize an ASG and then watch scale-out events trigger constantly during traffic peaks, increasing cost rather than reducing it.

Mixed instance policies and Spot Fleet recommendations need extra validation. Compute Optimizer is improving here but still misses nuance.

Lambda recommendations need workload context

Lambda recommendations are based on memory utilization patterns. They often miss the cost-performance tradeoff, because halving memory also halves CPU on Lambda, so a function that finishes in 200ms might take 800ms after rightsizing. Total cost can go up, not down.

For Lambda, we always model duration impact alongside the memory recommendation. If your service has a downstream timeout SLA, "memory-optimized" recommendations can break it.

Knowing where Compute Optimizer is fallible is what lets you build a workflow around it that captures savings without the breakage. That workflow is where the real work happens.

Building an automation workflow around AWS Compute Optimizer

A list of recommendations is not savings. Savings come from a closed-loop workflow that turns recommendations into validated, executed, monitored changes. Here is the structure we use.

Stage 1: Augmented data collection

Compute Optimizer's 14 to 90 day lookback is the baseline. We layer additional context on top:

• CloudWatch agent for accurate memory metrics
• Application-level metrics (Datadog, Prometheus, New Relic, CloudWatch Application Signals) for SLO context
• Tagging-based business context (which team, environment, criticality tier)
• Recent change history to avoid recommending changes to recently-modified resources

Without this layer, you are operating on partial information.

Stage 2: Recommendation enrichment and prioritization

Raw Compute Optimizer output is unsorted. We enrich it with:

• Estimated dollar savings in real currency, not just percentage
• Risk classification based on workload criticality and current utilization headroom
• Dependency mapping to flag resources that are part of larger systems
• Deduplication, because Compute Optimizer often recommends the same change in slightly different forms

Recommendations under $50/month in projected savings usually go on the back burner unless they are very low-risk. Recommendations over $1000/month get prioritized for review the same week.

For a structured FinOps approach to this layer, our breakdown of AWS cost optimization with FinOps best practices and tools covers the broader operational context.

Stage 3: Risk assessment and approval gates

Not every recommendation should be auto-applied. We classify into three tiers:

• Tier 1, low risk, auto-actionable: idle resources, dev/staging instances, EBS gp2 to gp3 conversions. These can move through automated workflows with minimal oversight.
• Tier 2, medium risk, ticket-based: production EC2 rightsizing, ASG changes, Lambda memory shifts. These create approval tickets with full context, projected impact, and rollback steps.
• Tier 3, high risk, manual only: database instance changes, anything tagged as a system of record, anything with a hard SLO. These never auto-execute.

The Service Control Policies and IAM boundaries that enforce this tiering are non-negotiable. We have seen teams skip them and regret it within a quarter.

Stage 4: Controlled execution

Even Tier 1 changes go out during defined maintenance windows when possible. We use AWS Systems Manager and Step Functions for orchestrated rollouts, with built-in pre-checks (latest backup, dependency status) and post-checks (CloudWatch alarms green for 30 minutes).

For Auto Scaling Groups and Kubernetes node groups, blue-green or rolling replacement avoids any service interruption. Our Kubernetes cost optimization guide covers the equivalent patterns for EKS environments where Compute Optimizer is one input among several.

Stage 5: Continuous monitoring and rollback readiness

Every change is monitored for at least 7 days before being marked successful. If application metrics drift outside acceptable ranges, automatic rollback triggers. The rollback window matters because subtle issues like increased GC pauses, slightly higher latency, or higher error rates take time to surface.

This closed loop is what turns Compute Optimizer from an inbox of suggestions into a predictable savings engine.

Comparing automation approaches around Compute Optimizer

Different teams take different approaches to operationalizing Compute Optimizer. This is how we frame the tradeoffs.

Our consistent observation: the difference between "5% savings" and "25% savings" is rarely the tool. It is whether the workflow has approval gates, monitoring, and rollback automation that engineers actually trust.

Real production patterns we have seen

A few specific patterns surface repeatedly across the AWS environments we audit. Worth checking against your own.

The 25 to 30% headroom on EC2 fleets where teams "already rightsized" two years ago. Workloads change. Yesterday's rightsizing is today's overprovisioning.

EBS gp2 to gp3 conversion is one of the easiest wins. We see 20% storage cost reduction with no performance impact, and Compute Optimizer flags it cleanly. Yet teams skip it because nobody owns "boring" optimizations.

ARM/Graviton recommendations are increasingly accurate, but require image and dependency compatibility checks. We always pilot Graviton on stateless services first before broader rollout.

Lambda over-allocation is endemic. We frequently see functions with 1024MB memory configured running at 200MB peak. Compute Optimizer catches it, but the duration tradeoff often gets missed in execution.

For broader cost-awareness across AWS, our common AWS cost management mistakes guide covers the patterns Compute Optimizer alone cannot catch.

All of this requires Compute Optimizer to actually be set up correctly first. Most environments we see have at least one configuration gap that limits accuracy.

Getting started with AWS Compute Optimizer the right way

If you are setting this up from scratch or auditing an existing setup, here is the sequence we follow.

Enable at the management account level

For multi-account organizations, enable Compute Optimizer at the AWS Organizations management account. This unifies recommendations across linked accounts and is required for org-wide rightsizing.

Install the CloudWatch agent

Without the agent, memory metrics are inferred, not measured. This single step often shifts recommendation quality from "directionally correct" to "actually trustworthy" for memory-bound workloads.

Wait for sufficient data

Compute Optimizer needs 14 days of metrics minimum, 60+ days for high confidence. New environments produce noisy recommendations. Hold execution decisions until the data window is mature.

Layer in scaling context

Compute Optimizer does not know about your traffic patterns directly. Pair it with AWS Auto Scaling policies tuned to your actual workload curves so rightsizing decisions account for both peak and trough conditions.

Start with non-production

Validate your workflow on dev and staging before touching production. The first production rightsizing pass should be small, monitored, and reversible.

Establish baselines before changing anything

Use AWS Cost Explorer and the Cost and Usage Report to capture pre-change spend by service and team. Without baselines, you cannot prove savings, and "I think we saved money" is not a FinOps outcome.

For the broader strategic context around this layer, our overview of the AWS Cost Optimization Hub covers how Compute Optimizer fits with other optimization signals AWS now surfaces.

Conclusion

AWS Compute Optimizer is one of the most underused free services AWS offers. The recommendations are good. The problem is almost never the data, it is the gap between recommendation and execution that quietly costs teams millions every year.

The teams that turn Compute Optimizer into real savings are the ones who treat it as an input to a workflow, not an answer. They install the CloudWatch agent. They classify recommendations by risk. They build approval gates and monitoring around execution. They measure savings against a baseline and adjust quarterly.

If your AWS environment has Compute Optimizer enabled but the savings are not landing, the bottleneck is almost always operational, not technical. The team at Opslyft helps engineering and finance leaders close that execution gap, but the patterns above will get most teams meaningful results regardless of tooling choice.