AWS Compute Optimizer has flagged idle EC2 instances for years. D2C engineering teams know that workflow: you get a recommendation, you check if the instance is genuinely unused or just low-traffic, you terminate or downsize. What Compute Optimizer couldn't see until now was the managed services layer — the ElastiCache cluster that served zero cache hits since December, the SageMaker endpoint left running from a Black Friday recommendation experiment, the four WorkSpaces that contractors used during Q4 setup and haven't touched since. AWS just added all six of those resource types. For D2C brands, the first audit after enabling this will be interesting.
TL;DR: Compute Optimizer now detects idle resources across DynamoDB, ElastiCache, MemoryDB, DocumentDB, WorkSpaces, and SageMaker — the exact managed services D2C brands over-provision for peak season and forget to review afterward. If you want a structured post-peak infrastructure audit before you let AWS's recommendations drive the cleanup, book a 30-min call with Dev — no SDR layer, written scope inside a week.
The Six New Resource Types and What D2C Brands Use Them For
Understanding which of the six new idle resource types is likely to show up in a D2C audit requires knowing why D2C brands provision them in the first place. The recommendations are most useful when you understand the provisioning story behind the flagged resource.
Amazon DynamoDB — Provisioned Tables
Detection window: 14 days, measuring consumed read and write capacity units. D2C brands typically provision DynamoDB tables for flash sale inventory locking — high-throughput, sub-millisecond writes during a limited-quantity release. After the event, the provisioned capacity sits idle. On-demand DynamoDB tables wouldn't get flagged here (they scale to zero); it's the provisioned mode tables with capacity units reserved whether used or not.
Amazon ElastiCache — Redis and Valkey Clusters
Detection window: 14 days, tracking new connections, CPU utilization, cache hit and miss ratios, and command types. ElastiCache Redis clusters are common in D2C stacks for session caching, cart persistence, and recommendation feature stores. Brands stand them up for peak traffic, then retain them past the point where the underlying application traffic has dropped back to levels that don't justify a dedicated cache cluster. A cluster serving zero new connections for 14 days is now flagged explicitly.
Amazon MemoryDB — Clusters
Detection window: 14 days, monitoring connections, CPU, and keyspace hit and miss rates. MemoryDB is less common in D2C stacks than ElastiCache, but it appears in brands that needed durable in-memory storage for real-time inventory counts or leaderboard mechanics during a promotion. Same idle-post-promotion pattern applies.
Amazon DocumentDB — Provisioned and Serverless Clusters
Detection window: 14 days, checking database connections. DocumentDB appears in D2C stacks most often for product catalog storage (flexible schema for variant-heavy catalogs) and B2B portal data. Both use cases generate provisioning that outlasts the project — a B2B portal that got deprioritized, a catalog migration project that switched direction. AWS's example finding from the announcement: a DocumentDB cluster running at $112.40/month with zero connections during the lookback period.
Amazon WorkSpaces — Desktops
Detection window: 63 days — two billing cycles plus a safety margin — tracking user connections. D2C brands provision WorkSpaces for seasonal contractors: Q4 content creators, customer service expansion, 3PL coordination staff. The 63-day window is intentional to avoid flagging WorkSpaces for staff who work infrequently but genuinely. An example from the announcement: a WorkSpace at $48.50/month flagged as idle. For brands that provisioned 6-8 contractor WorkSpaces in October, those are still billing in March.
Amazon SageMaker — Endpoints
Detection window: 14 days, counting invocations. SageMaker endpoints running with zero invocations for two weeks are now flagged. D2C brands provision SageMaker endpoints for recommendation models, demand forecasting inference, and personalization experiments. Holiday-season model deployments are particularly prone to this: the model serves the peak period, the promotion ends, traffic returns to the homepage recommendations backed by Shopify's native engine, and the SageMaker endpoint continues running at $680/month because no one officially decommissioned the experiment.
What a Real D2C Post-Peak Audit Found
We audited a $12M beauty brand's AWS infrastructure in February — three months after Black Friday. The EC2 layer was clean; they'd already right-sized after the post-peak period using the existing Compute Optimizer recommendations. The managed services layer was a different picture.
Three idle resources, none flagged by the old Compute Optimizer scope: a SageMaker endpoint at $680/month that had been deployed for a "personalized holiday collection" recommendation experiment in October and never decommissioned; an ElastiCache Redis cluster at $420/month that had been provisioned for a flash sale cart-locking mechanism and served zero cache hits since November 28; and four WorkSpaces at $47.50 each per month ($190 total) for contractors who had finished their engagement in early December.
Combined monthly waste: $1,290. Annualized: $15,480 — and that number assumes they would have caught it in February without an audit. Without external review, these resources often run for 6-9 months post-peak before someone notices on a cost report. All three would now be flagged by Compute Optimizer's new idle resource detection within the first 14-63 days of the engagement ending.
For the broader infrastructure picture on AWS architecture and cost management for D2C brands, the idle resource recommendations layer sits on top of the right-sizing work — our post on EC2 right-sizing for e-commerce covers the compute layer, which Compute Optimizer already handled before this update.
The managed services layer is where post-peak waste hides longest.
We run post-peak infrastructure audits for D2C brands typically in January or February. If you want a scoped review of your AWS managed services layer before letting Compute Optimizer's automated recommendations drive the cleanup, grab 30 minutes with Dev. Written scope inside a week.
How to Use These Recommendations Without Creating New Problems
Compute Optimizer's idle resource recommendations surface what's unused — they don't tell you whether it's safe to terminate. Three checks before acting on any managed service idle recommendation:
Check for Reserved Instance Coverage First
The monthly savings figure in each recommendation excludes cost already locked in via Reserved Instances, Savings Plans, or Reserved Capacity. An ElastiCache Reserved Node covering your flagged cluster means terminating the cluster doesn't recover the RI cost — you pay for unused capacity until the reservation expires. Run the RI coverage check before terminating anything that might be under commitment.
Confirm the Application Layer No Longer Depends on It
A SageMaker endpoint with zero invocations for 14 days is idle by metric — but a downstream application might still have the endpoint ARN hardcoded and simply not have been triggered. Check the application code for references to the resource's ARN or identifier before termination. Silent dependencies are common in D2C stacks where the original developer has moved on and the infrastructure was never fully documented.
Archive Data Before Destroying Storage Resources
DynamoDB tables and DocumentDB clusters flagged as idle may contain data that isn't being queried but isn't disposable. Snapshot or export before terminating any storage resource. For DynamoDB, a point-in-time export to S3 costs far less than a month of provisioned capacity and gives you a recoverable archive if the data is needed later.
For a broader view of cost reduction opportunities beyond idle resources, our post on 15 immediate AWS cost savings for e-commerce covers the structural optimizations — Savings Plans, data transfer patterns, S3 storage tiers — that idle resource cleanup should be combined with for a complete post-peak cost review.
Frequently Asked Questions
How does AWS Compute Optimizer determine a managed service resource is idle?
Compute Optimizer analyzes CloudWatch utilization metrics over a service-specific lookback window. For DynamoDB, ElastiCache, MemoryDB, DocumentDB, and SageMaker, the window is 14 days. For WorkSpaces it uses a 63-day window — two billing cycles plus a safety margin — to avoid flagging resources used infrequently but genuinely active. The metrics vary by service: ElastiCache uses new connections, CPU utilization, cache hit and miss ratios, and command counts. SageMaker uses invocation counts. DynamoDB uses consumed read and write capacity. A resource is classified as idle when these metrics fall below thresholds indicating no meaningful utilization during the lookback period.
Do Compute Optimizer idle recommendations account for Reserved Instance commitments?
No, and this matters for the decision to act. The monthly savings figure reflects the recurring cost the resource would stop incurring if terminated — but it excludes savings already locked in through Reserved Instances, Savings Plans, or Reserved Capacity. If you have an ElastiCache Reserved Node commitment covering a flagged cluster, terminating the cluster does not recover the RI cost — you pay for unused capacity until the reservation expires. Always check your RI and Savings Plan coverage before acting on an idle recommendation.
Where do these idle resource recommendations appear?
Two places: the AWS Compute Optimizer console under Idle Resources in the left navigation, and the AWS Cost Optimization Hub. Programmatic access is available through the GetIdleRecommendations and ListRecommendations APIs. If you have Compute Optimizer enabled at the organization level, recommendations appear for all member accounts — useful for D2C brands running separate accounts for production, staging, and third-party integrations. Organization-level enrollment requires opting in through your management account.
About the author
AWS Practice Lead, Braincuber Technologies
Owns AWS architecture and cloud cost optimization at Braincuber. Designs production workloads on Bedrock, SageMaker, Lambda, and EC2 for US clients — averaging $4,200/month in cost savings on right-sizing audits.