AWS Cost Optimization & FinOps: Finding Waste Without Inflating the Number

There is no shortage of tools that will tell you your AWS bill is too high. Point one at an account and it returns a large, round, encouraging number. Then you try to act on it and discover that a third of the findings are unactionable, another third assume you'll accept a resize with no headroom, and the rest were priced with a guess. The number was never the answer — it was the marketing.

This page is about the other approach: enumerate the waste that is genuinely measurable from an account's own telemetry, price only what can be priced, and say plainly how much observation stands behind each claim. It is also a description of how InfraSync's cost analysis works, because the rules below are implemented, not aspirational.

• Where AWS money actually goes missing
• The five rules that keep a total honest
• What gets analysed, service by service
• Confidence: how long is long enough?
• Account-wide findings vs regional ones
• What it needs from your account
• What it cannot see
• Frequently asked questions

Where AWS money actually goes missing

Cloud waste is rarely one dramatic line item. It is an accumulation of small, boring, individually defensible decisions that nobody revisited. In a typical brownfield AWS account the recurring categories are:

• Compute that is larger than its workload. An instance sized for a launch that never came, or for a peak that moved elsewhere two years ago.
• Compute that is idle. Running, billing, and doing nothing measurable.
• Storage detached from anything. Unattached EBS volumes bill at full rate forever. So does the EBS attached to a stopped instance — stopping an instance stops the compute charge, not the disk.
• Volumes on last-generation types. gp2 is almost always more expensive than an equivalent gp3, and magnetic and io1 volumes usually have a cheaper modern equivalent.
• Addresses reserved and unused. An unassociated Elastic IP is billed precisely because it is idle.
• Backups nobody set an end date for. Self-owned EBS snapshots and AMIs accumulate silently; so do manual RDS snapshots and AWS Backup recovery points long past the retention anyone intended.
• Container reservations far above use. An ECS service that reserves 4 vCPU and uses 0.3 is billed on the reservation.
• Auto Scaling floors. When an ASG's MinSize is 6, the instance type is not the cost — the floor is. This is the one people miss most often, because the group looks correctly configured.
• Uncommitted steady-state spend. Predictable baseline compute running at on-demand rates while a Savings Plan would cover it.
• Object storage with no lifecycle. Buckets where nothing ever transitions or expires, because a lifecycle rule was never written — or because the objects are too small for one to work.

The five rules that keep a total honest

A savings figure is only useful if it survives contact with the person who has to approve the change. These are the constraints that make that possible. They cost us headline numbers, on purpose.

1. A claim may never exceed the data behind it

Every recommendation carries the longest observation window the metrics genuinely support, and short windows are not allowed to prescribe. Seven days of quiet does not mean an instance is oversized — it might mean you looked during a holiday. A window also needs 80% metric coverage before it may be described as covering that period at all.

2. Anything unpriceable ships at $0

This is the rule that most changes the shape of a report. An io1 → io2 change is a durability upgrade at identical price. An Auto Scaling floor, an over-reserved ECS service, a short-window observation and every S3 lifecycle warning are all real, all worth acting on, and none of them have a single defensible monthly figure. They are reported with zero savings, and the cost detail lives in the recommendation text where it informs the decision without being counted as won.

The consequence is worth stating plainly: a scan can come back with a long list of genuine findings and a small headline total. That is a correct result, not a broken one.

3. A downsize must keep headroom

The observed peak must land at or below 70% on the proposed instance. A recommendation that would run your workload at 95% of a smaller box is not a saving, it is an incident with a discount. The exception is an equal-capacity swap — an m5 → m5a AMD move reduces nothing, so it does not need the ceiling.

4. Memory is never assumed

EC2 publishes no guest memory metrics unless you have installed the CloudWatch Agent. Rather than guessing, every suggestion is capped at retaining at least half the current memory, and the report says so. If you want tighter memory recommendations, install the agent — and the honest version of that advice is to tell you why, not to quietly infer it.

5. Savings are lower bounds

Where a range is possible, the conservative end is reported. S3 eligible volume, for instance, is min(size now, size 90 days ago) — data demonstrably stored throughout the window, not the peak.

What gets analysed, service by service

Two data sources are used deliberately, because they disagree and they cover different things. AWS Compute Optimizer contributes its own recommendations; direct CloudWatch analysis does the utilization arithmetic independently. Findings are then de-duplicated on (resource type, resource id, region), keeping the larger saving, so the same volume found twice is never counted twice.

Confidence: how long is long enough?

Every finding derived from utilization states the window it is based on, and the window governs whether it is allowed to prescribe an action at all.

Below 30 days you get an observation — "this instance looked quiet over 15 days" — and never an instruction. This is the difference between a report you can hand to an engineer and one they'll argue with.

Account-wide findings vs regional ones

Region is a property of a finding's scope, not a label on it. A finding about an unattached volume in ap-south-1 belongs to that region. A Savings Plans recommendation belongs to the account and lists every region that was scanned as its coverage.

This matters when filtering. A region filter that treats account-wide findings as regional will silently hide your largest single recommendation the moment someone narrows the view — and hiding a finding looks exactly like not having one.

What it needs from your account

Cost analysis is entirely read-only. Beyond the permissions a normal infrastructure scan needs, it uses:

ec2:DescribeInstances
ec2:DescribeInstanceTypes
cloudwatch:GetMetricData
cloudwatch:ListMetrics
autoscaling:DescribeAutoScalingGroups
ecs:ListClusters
ecs:ListServices
compute-optimizer:Get*
ce:GetSavingsPlansPurchaseRecommendation
s3:GetBucketLifecycleConfiguration
s3:GetBucketVersioning
s3:ListBucket

Every action in that list is a describe or a get. A missing permission degrades to a note rather than failing the run — you get the findings the granted permissions support, plus an explicit note about what could not be examined. Read the full setup in how to create a read-only IAM role for safe AWS scanning, or connect an account with a cross-account role.

What it cannot see

A page about honest numbers should be honest about its own gaps.

• No memory metrics without the CloudWatch Agent. AWS does not publish guest memory, which caps every right-sizing recommendation to retaining half the current memory.
• No per-prefix S3 analysis. A bucket average cannot distinguish 20,000 uniformly tiny objects from 19,000 tiny plus 100 large, and those two deserve opposite advice. S3 Inventory would resolve it; its absence is itself reported rather than papered over.
• Reserved Instance modelling beyond Savings Plans recommendations is not covered.
• Nothing about application efficiency. A perfectly sized instance running an inefficient query is not a cost finding, and pretending otherwise would be guesswork.

Frequently asked questions

What is FinOps for AWS?

FinOps is the practice of giving engineering teams visibility and accountability for what they run, rather than treating the bill as a finance problem discovered a month later. Practically, it means knowing which specific resources are wasteful, what changing them would actually save, and how much confidence stands behind that number.

Does a cost scan need write access to my account?

No. Every permission listed above is a describe or a get — read verbs, not write ones.

Why do some findings show zero savings?

Because they are real problems that cannot be honestly priced, and a guess would make the headline total meaningless. See rule 2.

How is this different from AWS Cost Explorer?

Cost Explorer tells you what you spent and where. It does not tell you which specific volume is unattached, which ECS service reserves ten times what it uses, or whether an instance has enough headroom to be safely downsized. The two answer different questions, and Cost Explorer's Savings Plans recommendations are used here as one input among several.

Can I see the findings before connecting a payment method?

Yes — a free scan returns the findings and the headline figure. Start a free scan.

The point of all this

A cost report is a request for someone's time. Every finding you include that turns out to be unactionable, unpriceable-but-priced, or based on a week of data spends a little of the credibility you need for the findings that matter. Reporting less, and standing behind it, is what makes the next report get read.

If you want to see what your account looks like under these rules, run a free scan — it is read-only, and takes about as long as reading this page.