Why a storage bill only ever goes up
Storage is the one AWS bill category where nothing forces a conversation. An oversized EC2 instance eventually throttles a workload, and someone notices. A storage bill just grows a little every month, with no failure to flag it. EBS bills the size you provisioned, not the size you use. A volume resized up during a traffic spike stays that size unless someone remembers to size it back down.
S3 has its own version of the same problem. Versioning keeps every prior copy of an object, not just the current one. An incomplete multipart upload also keeps using storage. A failed deploy or a dropped client connection can leave one behind. It never appears in a normal object listing. Snapshots pile up on a schedule, and none has an expiry date by default. Nobody wants to delete the backup that turns out to be needed. So the safest-feeling move is to leave it all alone, and that's how a bill slowly turns into something nobody can explain.
How the calculator works
The S3 panel prices the same pool of data three ways. First, it leaves all of it in Standard. Second, it hands it to Intelligent-Tiering's three automatic tiers: Frequent Access, Infrequent Access at 30 days cold, and Archive Instant Access at 90 days cold. Third, an explicit lifecycle rule moves it to Standard-IA at 30 days cold and Glacier Instant Retrieval at 90 days cold. The two scenarios use the same two inputs and land close together, because Intelligent-Tiering's automatic tiers are priced identically to the manual classes they mirror.
What separates them is the risk, not the rate. Intelligent-Tiering charges no retrieval fee on any automatic tier and has no early-delete exposure. If you guess the access pattern wrong, you pay nothing beyond the monitoring fee. Guess wrong with a hand-written lifecycle rule and you pay retrieval charges plus an early-delete penalty. The lifecycle scenario is the only one where the calculator bills retrieval at all.
The EBS panel prices three independent fixes at once. It deletes unattached volumes, migrates the remaining gp2 to gp3, and archives the eligible snapshots. None of them depend on each other, so the total saving is always just the sum of the three, with no double-counting.