AWS Cost Optimization: Which Recommendations Should You Ignore?

The AWS cost optimization page in your account has a savings figure on it, and that figure is the most misleading thing on the screen. The arithmetic is fine. The list underneath it includes resources a regulator requires you to keep, prices the savings as though you never bought a Savings Plan, and sizes your instances on a fortnight of CPU alone.

Our position: work the rightsizing half of that list hard, before you commit to anything. Delete nothing from the idle half until somebody who knows the DR design has read it line by line.

Why does AWS cost optimization start with a list you cannot act on?

Because the tool measures utilisation and you are measured on resilience, and nothing joins the two. Compute Optimizer is free: AWS charges nothing for it beyond "the AWS resources needed to run your applications and Amazon CloudWatch monitoring fees". It has no idea which of your instances exists only because a paragraph in a direction says it must.

Most of the list is right. The argument is about the tenth that is wrong, which in a fintech account is the tenth that costs you an audit finding.

What is Compute Optimizer actually looking at, and for how long?

Fourteen days. The documentation on metrics analysed says it reads "the specifications, such as vCPUs, memory, or storage, and the Amazon CloudWatch metrics of your running resources from a period over the last 14 days".

You can buy a longer memory. Enhanced infrastructure metrics "extends the utilization metrics analysis lookback period to up to 93 days" for EC2 instances, instances in Auto Scaling groups and RDS DB instances, at $0.0003360215 per resource per hour. AWS's own example is five instances for a 31-day month at $1.25, so a 300-instance estate pays about $75 a month to see three months instead of two weeks. Turn it on.

The idle findings use different windows again. An EBS volume counts as unattached over 32 days, and a WorkSpace is judged on 63 days of user connections. Idle is not one definition, it is eleven.

Why does a fortnight of metrics misprice a payments platform?

Because your load has a calendar and the lookback does not. Settlement, payouts, reconciliation, the invoice run: the busiest hours of the month are clustered, and a window running from the 3rd to the 17th contains none of them. The same reporting node is Over-provisioned in one fortnight and Optimized in the next, and whichever list you opened becomes the plan.

We learned this the slow way. We rightsized a batch node off a 14-day window with no quarter end in it, it held fine for six weeks, then the quarter-end job ran four hours longer than the window it had. Nothing broke. It was still a bad change, because what saved it was luck rather than anything we had checked.

The rule we use now: no downsize goes near a workload with a monthly or quarterly cycle unless the 93-day window produced it. Stateless web tiers are fine on fourteen days. Anything with a cron and a deadline is not.

Will it tell you to delete your DR standby?

Yes, with a confident savings figure attached. The idle criteria table defines an idle EC2 instance as one where "the peak CPU utilization is below 5% and your network I/O is less than 5MB/day over the 14-day lookback period", and tells you to "consider deleting this instance". Hold that against a warm standby in a second Region, which does almost nothing on 363 days a year by design. It matches that definition exactly.

The RBI's 2026 directions for NBFCs put a floor under that estate. Paragraph 129: "Periodicity of DR drills for critical information systems shall be at least on a half-yearly basis." Paragraph 131 decides the architecture, because the testing "shall involve switching over to the DR / alternate site and thus using it as the primary site for sufficiently long period where usual business operations of at least a full working day (including Beginning of Day to End of Day operations) are covered". What else that text asks of an AWS account is in our walkthrough of the 2026 direction.

AWS half-knows this. The recommended action on the NAT Gateway row reads "Check if it's part of a disaster recovery setup or serves as a backup in your network architecture." That warning appears there and nowhere else in the table.

The fix is a tag and a habit rather than a tool. Tag the DR estate, filter it out before anyone reads the list, and make that filter the first thing a new engineer inherits. Why tags alone will not carry the cost split is a longer argument about accounts or tags.

Can it size an instance it cannot see the memory of?

It will try, and it will not tell you it is guessing. Memory utilisation is analysed for two kinds of instance only: those "with the CloudWatch agent that's installed on them", and "external EC2 instances from one of the four observability products: Datadog, Dynatrace, Instana, and New Relic". Everything else is sized on CPU, network and disk. For a JVM service or a Postgres read replica that is the wrong dimension, and the recommendation is a smaller box with less of what was actually constraining it.

Installing the agent is not enough either, which cost us a day. "The namespace must contain the InstanceId dimension. If the InstanceId dimension is missing or you overwrite it with a custom dimension name, Compute Optimizer can't collect memory utilization data for your instance." Plenty of configs append a hostname instead, the graphs look perfect in CloudWatch, and Compute Optimizer sees nothing.

A self-hosted Prometheus and Grafana stack is not one of those four, so with it you run the CloudWatch agent as well or accept CPU-only sizing. That sits beside the per-unit billing argument in the comparison of what each tool counts.

Which recommendations are safe to apply without a conversation?

A shorter list than the console implies. From the same criteria table, five findings are usually leftovers rather than decisions:

• EBS volumes unattached for 32 days. Snapshot, then delete. Root volumes are excluded.
• NAT Gateways with no route table association and no packets either way. If nothing routes to it, no DR plan is using it.
• Provisioned DynamoDB tables with zero consumed capacity at table and every GSI level over 14 days. On-demand mode is often the landing place rather than deletion.
• SageMaker endpoints with zero invocations over 14 days. The most expensive forgotten thing in most AI-adjacent accounts.
• Always On WorkSpaces nobody has connected to in 63 days. Auto Stop and Standby are excluded, so you see the expensive mode only.

AWS added DynamoDB, WorkSpaces, SageMaker endpoints and three more on 8 June 2026, so an account reviewed last year has a category nobody has seen.

One correction before you believe any figure on that page. If Cost Optimization Hub is not enabled, "Compute Optimizer uses Cost Explorer data and On-Demand pricing information", so every saving is quoted at On-Demand against capacity you may already have discounted. Enable the Hub, then read the numbers. How much of that capacity to commit to is the argument we made about Savings Plans.

What can you run on Monday?

Two things, both under an hour. First, pull the idle list with the lookback window beside each finding, so the resource and the window that judged it arrive together.

aws compute-optimizer get-idle-recommendations \
  --region ap-south-1 \
  --query 'idleRecommendations[].[resourceType,resourceId,finding,lookBackPeriodInDays,savingsOpportunity.estimatedMonthlySavings.value]' \
  --output table

Read the lookBackPeriodInDays column before the savings column. Anything on 14 days belonging to a workload with a monthly cycle goes back in the queue, not into a change ticket.

Second, find how many instances are being sized with no memory data at all.

aws ec2 describe-instances --region ap-south-1 \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].InstanceId' \
  --output text | tr '\t' '\n' | sort > running.txt

aws cloudwatch list-metrics --region ap-south-1 \
  --namespace CWAgent --metric-name mem_used_percent \
  --query "Metrics[].Dimensions[?Name=='InstanceId'].Value" \
  --output text | tr '\t' '\n' | sort -u > with-memory.txt

comm -23 running.txt with-memory.txt

Every instance that prints is one whose sizing recommendation is CPU-only. On the accounts we have run this against it is usually most of them, and never zero. If that list is long, installing the agent saves more than anything on the console page, because it changes what the page is allowed to say.

When is the recommendation right and you wrong?

More often than this post makes it sound. With no second Region, no monthly peak and nothing memory-bound, the list is a work queue and you should empty it this week. Under about forty instances, skip the tooling argument too: one engineer reading the console for an hour a quarter beats any automation, including ours, because they know which box is the one from the migration that nobody dares turn off.

When you do overrule a recommendation on resilience grounds, write the reason where an auditor can read it. An exception with a paragraph number beside it is a control. An exception in somebody's head is a finding.

The short version

Turn on enhanced infrastructure metrics this week and leave it on. At roughly $0.25 per resource per month it is the cheapest change here, and it moves your sizing from a fortnight of history to three months.

Tag the DR estate and exclude it from the idle view before anyone reads that view, then apply the five safe findings and route the rest through whoever owns the architecture.

Run the memory check, then go back to the commitment question, because the floor you commit to should be the floor after this work rather than before it. Which of the remaining line items a regulator actually requires is in what a fintech can cut without failing an audit.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.