The two instruments bind different things, and that is the whole mechanism. A Reserved Instance binds a configuration: family, and depending on the type, size, region, OS and tenancy [3]. A Savings Plan binds a number: you commit to a dollar amount of usage per hour, say $10/hour of compute, and AWS applies the discounted rate to whatever matching usage you actually run [4]. Same one- or three-year term either way, same trade against On-Demand [17].
The comparison worth making is what each instrument forgives, not simply which discount is bigger. The Compute Savings Plan carries the commitment across instance families, regions, Fargate and Lambda [5], at the Convertible RI's ceiling, with no exchange step [7]. A Convertible RI reaches a different family, OS or tenancy only through a manual exchange [10]. AWS's own documentation now recommends Savings Plans over Reserved Instances for compute, according to the pages the dev.to post cites [6].
One tier up is where you pay for the rate. An EC2 Instance Savings Plan reaches up to 72%, matching a Standard RI, and keeps size, OS and tenancy flexible inside the family you committed to [8]. Subtract the ceilings: 72 minus 66 is six points, and the price of those six points is that your commitment stops travelling between families and regions [18].
Both figures are ceilings measured against somebody else's instance mix. For 66% to be your number, the committed dollars per hour have to be matched by running usage in the hours you committed them, and the post routes that arithmetic elsewhere: how the commitment gets applied, the billing-hour math, the queue order against On-Demand all live in a separate piece [16]. Read the ceilings as the shape of the trade rather than a forecast of the invoice. The AWS citations in the post are stamped as accessed June 2026, which is the only date attached to those rates.
One asymmetry still favours the older instrument, and the post mentions it in passing: an unused Standard RI can be listed on the Reserved Instance Marketplace [9]. No equivalent exit for a Savings Plan appears anywhere in the piece.
The part that actually moved is databases. Before December 2025, RDS, Aurora, ElastiCache, Redshift and OpenSearch had no Savings Plan at all, and the post identifies that gap as the single biggest reason teams still carried large RI portfolios [11][15]. Redshift still discounts through Reserved Nodes, OpenSearch Service through Reserved Instances, and neither falls under any Savings Plan today [13]. Take the difference between those two lists and the December 2025 launch [12] accounts for RDS, Aurora and ElastiCache [14].
That leaves the RI as a two-service instrument for anyone not running those engines. What's left to pay for is process, not rate: exchange workflows and marketplace listings for EC2, node reservations for Redshift, maintained for whatever share of the bill two services represent. If that share is small, the RI skill set is overhead you keep for a rounding error, and the post's default of buying the Savings Plan is the cheaper place to put the team's attention [1].
