Three separate compute decisions, three numbers that get quoted constantly, and in all three cases the number describes something narrower or different from what people take it to mean. None of this is AWS being deceptive. The precision is right there in the documentation, in the clause immediately after the number.
1. Spot: "under 5% interruption" is a cross-region historical average
Teams avoid EC2 Spot because they picture an instance getting pulled mid-request and taking production down. AWS advertises Spot at up to 90% off On-Demand, which is a large enough number that the objection deserves examining properly.
The usual counter-argument is the Spot Instance Advisor's under-5% interruption figure. It does say that. But read the rest of the sentence: that number is the average across all Regions and all instance types, historically, and AWS immediately notes that the actual interruption rate for your workloads will depend on point-in-time available capacity.
So it is not a guarantee about your instance type in your AZ next Tuesday. It is a fleet-wide historical aggregate. Your exposure could be far lower or far higher depending on how popular your chosen pool is.
The warning is two minutes and best effort
You do get notice. The Spot interruption notice is issued two minutes before EC2 stops or terminates the instance. AWS also says interruption notices are emitted on a best effort basis, which is a meaningfully weaker promise than it first reads as.
There is a second, earlier signal: the rebalance recommendation, which flags elevated interruption risk and can arrive sooner than the two-minute notice. AWS is careful here too, saying it is not always possible to send it first. Can, not will.
If your shutdown procedure needs more than two minutes, and it might if you drain connections or finish in-flight jobs, you are designing against the best case rather than the guaranteed one.
Spread is the actual control, and it is countable
A Spot capacity pool is a set of unused EC2 instances with the same instance type and the same Availability Zone. That is the whole definition, and it is why diversification works: an interruption hits a pool, not your account.
AWS's rule of thumb is to be flexible across at least 10 instance types for each workload. Ten instance types across three Availability Zones is 30 capacity pools. That multiplication is mine, not a figure AWS publishes, but it follows directly from their definition and it is the number worth holding in your head: a workload pinned to one instance type in one AZ is sitting in exactly one pool.
The default allocation strategy is one AWS labels "not recommended"
This is the sharpest item in this post.
AWS recommends the price-capacity-optimized allocation strategy, which picks the pools with the highest capacity availability and then the lowest priced of those. Capacity first, price second.
But lowest-price is the default when using the AWS CLI, and the CreateFleet API's Spot allocation strategy defaults to lowest-price per unit. AWS labels that same strategy "(not recommended)" in its own documentation and describes it as carrying the highest risk of interruption.
So the path of least resistance, scripting a fleet without specifying a strategy, lands you on the option AWS explicitly advises against. If a team tried Spot, found the interruption rate intolerable and went back to On-Demand, this is the first thing I would check before accepting the conclusion.
Capacity Rebalancing is more conditional than the name suggests
Capacity Rebalancing sounds like a guarantee that Auto Scaling replaces an at-risk instance before you lose it. It is narrower: Auto Scaling only launches a new instance if it provides the same or better availability. Which means the existing instance can be interrupted without a proactive replacement having been launched at all.
And there is a cost-side consequence people do not plan for. While replacing at-risk instances under Capacity Rebalancing, Auto Scaling can temporarily exceed the group's maximum size by up to 10% of desired capacity.
If you have been treating max size as your spend ceiling, it is not one. It is a target that can be legitimately exceeded by a tenth during rebalancing events, which is exactly when capacity is scarce and prices are least favourable.
AWS is specific about which workloads this is for
Worth quoting the boundary, because "Spot is too risky" is genuinely the right call for some systems and AWS agrees. AWS recommends Spot for stateless, fault-tolerant and flexible applications, naming CI/CD, containerised workloads and stateless web servers, and says it is not suitable for stateful, fault-intolerant or tightly coupled workloads.
Your CI fleet is on that list. Your primary database is not. The interesting question is never "is Spot safe" but "which of my workloads is on AWS's own list", and most estates have more on it than they think.
2. Compute Optimizer: free, capable, and off
Here is a concrete case from an account I scanned, published so you can open it rather than take my word for it. Four EBS volumes attached to nothing in a single region, $180 a month between them.
- The oldest, a 300 GB gp2 volume, had been unattached for 2,451 days, billing $30.00 a month. That is just under seven years (2451 / 365.25 = 6.71).
- The next one down, a 500 GB gp2 volume, had sat for 1,790 days at $50.00 a month.
AWS detects exactly this, for free. Compute Optimizer has an Unattached criterion: a volume that is not attached to any EC2 instance over the 32-day lookback period. Its recommended action is to verify whether you need the volume, and if you do not, create a snapshot and consider deleting it. AWS's pricing page is unambiguous: there is no additional charge for AWS Compute Optimizer.
So why did seven years pass? Because it is opt-in. Before you can use the service, you must opt in or out, and it produces nothing at all before you do. The capability was sitting there, costing nothing, silent, for the entire time those volumes were billing.
That is a default doing what defaults do. Worth being precise about one thing: Cost Optimization Hub is not a second gate on the finding itself, it only changes which pricing data feeds the savings column.
The 32-day window does not shorten
One limit to know before you rely on it. You can set the lookback period for EBS volume recommendations to 14 days, but AWS states that doing so does not affect the 32-day lookback period used to determine whether a volume is unattached.
So a disk detached three weeks ago cannot surface as Unattached yet: 21 is less than 32. Scoped to that criterion only, it may still appear under the separate Idle criterion. If you are cleaning up after a migration, the volumes you just orphaned are the ones the tool cannot see.
3. EKS Auto Mode: 12% is not a percentage AWS publishes
EKS Auto Mode runs your nodes for you, and charges a management fee for every EC2 instance it launches, on top of the EC2 instance price, billed per second with a one-minute minimum. In US West (Oregon) an m5a.2xlarge carries a fee of $0.04128 per hour.
AWS publishes this as a dollar rate per instance-hour and never as a percentage of the EC2 price. Divide the published rates by the corresponding On-Demand prices, though, and they land in the same place every time:
- c6a.2xlarge: 0.03672 / 0.306 = 12%
- m5a.xlarge: 0.02064 / 0.172 = 12%
- m5a.2xlarge: 0.04128 / 0.344 = 12%
That is my arithmetic on AWS's table, not a figure AWS states. It is a useful mental model and it breaks in three specific places.
Break one: the GPU cut, which excludes Inferentia
Effective 1 July 2026, AWS reduced EKS Auto Mode management fees on G-series instances by 35%, and on P-series and AWS Trainium by 60%, with no action required from existing customers. If you priced a GPU cluster before July, your model reads too high now.
That announcement names G-series, P-series and Trainium only. It does not mention Inferentia, and inf2.xlarge remains at the full 12% of On-Demand (0.09098 / 0.7582 = 12.00%, measured against the AWS Pricing API on 2026-08-03). Accelerated does not mean discounted.
Break two: it is regional, which the percentage hides
The same m5a.2xlarge management fee is $0.04128/hr in us-east-1 and $0.06624/hr in sa-east-1. Same instance, 60% more. And af-south-1 publishes no Auto Mode rates at all.
A flat 12% assumption papers over a regional spread that materially changes multi-region cost models.
Break three: the table stops at 150 nodes
Published Auto Mode per-node pricing applies up to 150 nodes. Past that, AWS asks you to contact your account team for additional pricing information. So a growth model built on the published rate only holds to 150 nodes across your organisation, and the number beyond that is a negotiation rather than a lookup.
The part that compounds: no purchase option touches it
This is the one with the largest long-run effect. A Compute Savings Plan commits a fixed hourly spend for a one or three year term in exchange for lower rates on EC2 instance usage. AWS states plainly that the EKS Auto Mode charges are independent of the EC2 instance purchase option, in a sentence that names On Demand, one- and three-year Reserved Instances, Compute Savings Plans and Spot Instances.
So the instance gets cheaper and the fee stays exactly where it was. Which means the better your commitment coverage, the larger that fee becomes as a share of what you actually pay. 12% of On-Demand is not 12% of your bill. On a heavily committed fleet it is meaningfully more, and on Spot capacity it can be a lot more.
What to check
- Check the allocation strategy on every Spot fleet and Auto Scaling group. If it is
lowest-pricebecause nobody set one, you are on the option AWS labels not recommended. - Count your capacity pools: instance types x Availability Zones. If that number is in single digits, diversification is your cheapest reliability win.
- Confirm max size is not being used as a spend ceiling anywhere, given Capacity Rebalancing can exceed it by 10% of desired capacity.
- Opt into Compute Optimizer. It is free, and an account that never enabled it has no recommendations no matter how much is sitting idle.
- If you run EKS Auto Mode, model the fee as a dollar rate per instance-hour per region, not as 12%, and model it separately from anything a Savings Plan covers.
I build detection rules for this category for a living, and I still keep this list written down rather than trusting myself to remember it.
Sources
AWS statements are from AWS documentation and pricing pages. Percentage conversions on Auto Mode rates and the capacity pool multiplication are my arithmetic, labelled as such above. Volume ages and dollar figures come from a published scan.
- EC2 Spot best practices (pools, flexibility, suitable workloads)
- Spot Instance Advisor (interruption rate basis)
- Spot interruption notices (two minutes, best effort)
- EC2 instance rebalance recommendations
- EC2 Fleet allocation strategies (lowest-price labelled not recommended)
- Auto Scaling Capacity Rebalancing (10% overshoot)
- Compute Optimizer idle and unattached recommendations
- Compute Optimizer getting started (opt-in)
- AWS Compute Optimizer pricing (no additional charge)
- Amazon EKS pricing (Auto Mode rates, 150-node limit, purchase option independence)
- EKS Auto Mode GPU price reduction (1 July 2026)
- Published scan: the unattached volumes above