Compute Optimizer idle recommendations just got a lot more useful — and a lot more dangerous for your overprovisioned infrastructure. AWS has expanded Compute Optimizer’s idle detection to six new resource types: DynamoDB, ElastiCache, MemoryDB, DocumentDB, WorkSpaces, and SageMaker endpoints. Previously, idle recommendations covered EC2, Lambda, ECS, EBS, and a handful of others. The new expansion means the service can now surface waste across a much wider slice of a typical AWS environment, including several services that have historically been overlooked in cost reviews precisely because they weren’t in scope. This post covers what “idle” means for each resource type, how to pull the recommendations via CLI, and how to act on them responsibly.
The 32-Day Lookback Window Change
Before diving into the new resource types, the lookback window expansion deserves attention. AWS also extended the lookback period for EBS and ECS service recommendations from 14 days to 32 days. This matters more than it sounds.
A 14-day window misses monthly usage patterns entirely. If a batch job runs on the last day of each month, a 14-day snapshot taken mid-month shows zero utilization and incorrectly recommends termination. A 32-day window captures at least one full monthly cycle, which is the right unit of analysis for most business workloads. Expect to see some previously flagged recommendations disappear when the longer window is applied — and trust the remaining ones more.
Pulling Idle Recommendations via CLI
The get-recommendation-summaries and get-*-recommendations commands are your primary tools. The new resource types are available under their respective recommendation resource types.
# Get a summary of all idle recommendations by resource type
aws compute-optimizer get-recommendation-summaries \
--region us-east-1 \
--query 'recommendationSummaries[?recommendationResourceType!=`null`].{Type:recommendationResourceType,Idle:currentPerformanceRiskRatings}'
# Pull idle ECS/SageMaker/DocumentDB/ElastiCache recommendations
# (Use the appropriate --resource-type flag per service)
# SageMaker endpoint idle recommendations
aws compute-optimizer get-ecs-service-recommendations \
--filters name=recommendationSourceType,values=SageMakerEndpoint \
--region us-east-1
# DynamoDB idle recommendations
aws compute-optimizer get-recommendation-summaries \
--region us-east-1 \
--query 'recommendationSummaries[?recommendationResourceType==`DynamoDbTable`]'
# WorkSpaces idle recommendations
aws compute-optimizer get-recommendation-summaries \
--region us-east-1 \
--query 'recommendationSummaries[?recommendationResourceType==`WorkSpacesWorkSpace`]'
# Pull all idle flags across new resource types in one call
aws compute-optimizer export-recommendation-preferences \
--resource-type DynamoDbTable ElastiCacheReplicationGroup MemoryDbCluster \
DocumentDbInstance WorkSpacesWorkSpace SageMakerEndpoint \
--region us-east-1
For large organizations, use the export API to push recommendations to S3 and query them with Athena — the console pagination gets tedious at scale.
# Export idle recommendations to S3 for all new resource types
aws compute-optimizer export-idle-recommendations \
--resource-types DynamoDbTable ElastiCacheReplicationGroup \
MemoryDbCluster DocumentDbInstance WorkSpacesWorkSpace SageMakerEndpoint \
--s3-destination-config bucket=your-finops-bucket,keyPrefix=compute-optimizer/ \
--region us-east-1
What “Idle” Means Per Resource Type
Each service has a different utilization signal. Compute Optimizer uses service-specific metrics, not a one-size-fits-all CPU threshold. Understanding the per-service definition helps you avoid acting on false positives.
DynamoDB
Idle is flagged when consumed read capacity units (RCUs) and write capacity units (WCUs) are near zero over the lookback period. For on-demand tables, this translates to negligible request counts. Be cautious with tables that serve as audit logs or cold-reference data — legitimate near-zero usage isn’t the same as abandoned. Check for TTL-based deletion patterns and DynamoDB Streams consumers before terminating.
ElastiCache
Idle is based on cache hit rate, connection count, and throughput metrics (GetTypeCmds, SetTypeCmds). A cluster with zero cache hits and no active connections over 32 days is definitively idle. A cluster with occasional connections but low hit rate may indicate a misconfigured application rather than an idle cluster — different remediation path.
MemoryDB
Similar to ElastiCache but also considers replication lag and keyspace statistics. MemoryDB idle recommendations will surface clusters with no active keys and no ingestion — these are strong candidates for deletion, not rightsizing. MemoryDB clusters are persistent, so verify no application is relying on the data durability guarantee before deleting.
DocumentDB
Idle detection uses database connection count, read/write operations, and CPU. A DocumentDB instance with zero connections over the lookback period is flagged. The most common cause is a decommissioned application that left the database running — check for any remaining application credentials or connection strings before terminating. Also verify no scheduled exports or replication jobs connect infrequently.
WorkSpaces
WorkSpaces idle recommendations are based on session duration and login frequency. A WorkSpace with zero sessions over the lookback window is flagged as idle — which in most cases means the user it was provisioned for has left the organization or switched to another device. This is one of the cleanest idle signals because user sessions are definitive. Verify with HR/IT before deprovisioning.
SageMaker Endpoints
Idle is flagged when an endpoint has near-zero invocations over the 32-day period. This is extremely common in ML environments where engineers spin up endpoints for experiments and forget to shut them down. SageMaker endpoint costs are significant — an ml.g4dn.xlarge endpoint running 24/7 costs roughly $400–$600/month. A cluster of idle GPU-backed endpoints discovered by Compute Optimizer can represent a four-figure monthly savings opportunity. Verify with the data science team that no scheduled inference jobs run against the endpoint before deleting.
How to Act on the Recommendations
The action for each flagged resource falls into one of three categories: terminate, rightsize, or investigate first. Use this framework:
- Terminate: WorkSpaces with no sessions (confirmed user departed), SageMaker endpoints with no invocations (confirmed no jobs), DocumentDB instances with zero connections (confirmed no app credentials)
- Rightsize: ElastiCache clusters where usage is low but real — scale down node type or reduce cluster size. DynamoDB tables where provisioned capacity is dramatically over-allocated relative to actual consumption — switch to on-demand if the table isn’t high-throughput
- Investigate first: Any resource with scheduled jobs or batch patterns that might not appear in the lookback window. Any resource where ownership is unclear. Any resource connected to a production data path you can’t trace immediately
# Example: Delete an idle SageMaker endpoint
aws sagemaker delete-endpoint \
--endpoint-name your-idle-endpoint-name \
--region us-east-1
# Example: Scale down an ElastiCache cluster
# First, modify the node type
aws elasticache modify-replication-group \
--replication-group-id your-cluster-id \
--cache-node-type cache.t4g.small \
--apply-immediately \
--region us-east-1
# Example: Delete an idle WorkSpace
aws workspaces terminate-workspaces \
--terminate-workspace-requests WorkspaceId=ws-abc12345 \
--region us-east-1
The Lookback Window’s Practical Impact
The shift to 32 days for EBS and ECS recommendations is worth revisiting with any recommendations that were previously generated under the 14-day window. If you had a batch of EBS volumes flagged as idle under the old window, re-pull those recommendations now. You may find some are no longer flagged because the longer window captured a monthly usage event. You may also find new recommendations appear for resources that showed just enough usage in a 14-day window to avoid flagging but are clearly idle over a full 32-day view.
The 32-day window is also the right default for any FinOps process that aligns to calendar-month billing cycles. Recommendations generated on a sub-monthly window are inherently less reliable for any workload with monthly cadence — finance closes, month-end reporting jobs, compliance audits, and so on. The expansion to 32 days brings Compute Optimizer’s confidence level up significantly for production environments with predictable monthly patterns.
Integration with Cost Optimization Hub
All six new resource types feed into Cost Optimization Hub’s unified recommendations view, which means the AWS FinOps Agent (preview) can surface them via natural language queries and route them to Jira automatically when they cross your savings threshold. If you’ve already configured the FinOps Agent, these new resource type recommendations will start appearing in your Jira backlog without additional configuration — they inherit whatever threshold and routing you’ve already set up.
At Enkompass (enkompass.net), this is our home turf. We’ve clawed back six figures in annual spend for clients who thought their bill was “already optimized.” If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.