RI Size Flexibility Explained: Coverage, Boundaries, and the EDP Math

RI size flexibility is one of those AWS features that looks simple in the marketing collateral and turns out to be the source of half the wasted commitment dollars in a real RI portfolio. The mechanic is described in two sentences in the AWS documentation: regional Linux/Unix Reserved Instances apply across instance sizes within the same family and region using a normalized-unit calculation. That single sentence drives roughly $50M of misallocated commitment across the engagements our analysts have reviewed. This guide is the long version - what the feature actually does, where it silently fails, and how to structure a portfolio to use it correctly.

The normalized-unit model

AWS assigns each EC2 instance size within a family a normalized-unit value. The unit is the "nano" size: 1 nano = 0.25 normalized units. A small is 1 unit, medium is 2, large is 4, xlarge is 8, 2xlarge is 16, and so on, doubling at each step. A regional Linux/Unix RI for one m5.4xlarge instance is worth 32 normalized units. Those 32 units can be applied as one m5.4xlarge, two m5.2xlarge, four m5.xlarge, eight m5.large, or any combination that adds up to 32. The benefit is purely accounting - AWS calculates the unit consumption per hour and applies the RI discount up to the unit limit.

That sounds powerful. Most of the time it works correctly. The problems begin at the edges of the rule, where buyers assume coverage and don't get it.

Where size flexibility silently fails

Windows and other commercial OS workloads. Size flexibility applies only to Linux/Unix RIs. Windows RIs, RHEL with Red Hat support, SUSE, and any tenancy-specific RI lose size flexibility entirely. A Windows m5.4xlarge RI will only ever apply to a Windows m5.4xlarge instance. This is the single most common surprise on a Windows-heavy portfolio: buyers commit to a few large instance sizes and then are puzzled that smaller-instance Windows workloads do not absorb the discount.

Zonal RIs. Zonal Reserved Instances - those purchased with a specific Availability Zone reservation - lose size flexibility. They gain a capacity reservation in exchange. The trade is rarely worth it outside of compliance-driven workloads that need guaranteed capacity in a specific AZ.

Dedicated Host and Dedicated Instance RIs. Both lose size flexibility. A Dedicated RI for a specific instance type covers only that type.

Family boundaries. Size flexibility is intra-family only. m5 RIs do not apply to m5n, m5d, m5a, or m6i. Each is a separate family from the RI engine's perspective. The 2024-era distinction between m6i and m6a is enough to break coverage; buyers regularly assume modernization within the same generation preserves coverage and find that it does not.

How size flexibility interacts with EDP and Savings Plans

Size flexibility is an RI mechanic; it has no direct equivalent in the Enterprise Discount Program. EDP coverage applies at the spend level - it does not care which instance size you ran. But the RI discount that comes out of size flexibility reduces the EDP spend baseline against which your EDP commit applies. If you buy a $1M RI and use size flexibility to cover a varied workload mix, the effective EDP-eligible spend on that workload drops by approximately the RI discount rate. That changes your EDP coverage math.

Compute Savings Plans subsume size flexibility almost entirely. A Compute Savings Plan covers any instance size in any family in any region, in any OS, in any tenancy. It is structurally a superset of size flexibility. The buyers we work with now generally use Convertible RIs only for workloads that need a longer term commitment than a Savings Plan can offer (typically 3 years on specific architectures) or for legacy positions purchased before Savings Plans existed.

Designing an RI portfolio that uses flexibility correctly

The optimization rule is: buy at the size that gives you maximum flexibility down. For a workload mix that runs across m5.large, m5.xlarge, and m5.2xlarge in unpredictable proportions, you can purchase RIs at any size and the math works the same way - but you should bias to the smallest reasonable size because that maximizes the granularity of allocation. Buying 32 units as one m5.4xlarge RI gives you size flexibility only as long as your workload mix can absorb 32 units of m5. Buying the same 32 units as 32 m5.large RIs gives you the same coverage but with hour-by-hour granularity - if a few hours have no m5 workload at all, you waste less commitment.

This is the opposite of the advice AWS account teams typically give, which is to buy at the size you actually run. Buying at the actual size is fine if your workload mix is stable. Buying at the smallest reasonable size is better if your workload mix has any seasonality or variation.

The exception is when you have a known capacity-reservation requirement for a specific large instance size. In that case, buy the zonal RI at that size and accept the loss of flexibility as the cost of guaranteed capacity.

The cross-account coverage trap

Regional RIs apply across accounts in an AWS Organization with consolidated billing enabled, but only after the payer account has been configured for RI sharing. If RI sharing is turned off (a common pattern in security-segregated organizations), each account's RIs apply only to that account's usage. Buyers regularly purchase a large RI position in a centralized procurement account, assume size flexibility will distribute it across the organization, and discover only at the end of the month that the RIs are idling in the purchase account while the workload accounts are paying on-demand rates.

This is not technically a size-flexibility failure - it is an RI-sharing failure - but the symptom looks the same in the utilization report. Check sharing settings before any large RI purchase.

The 90-day audit cycle

Every RI portfolio should be audited on a 90-day cycle for the following:

• Utilization by RI, not by family - identify any RI under 90% utilization.
• On-Demand spend by family in the same region - identify any family where on-demand is climbing.
• OS and tenancy mix in the on-demand spend - identify whether Windows or RHEL workloads are present without coverage.
• RI-sharing status across the Organization - confirm sharing is enabled for all accounts that should be sharing.
• Family-suffix drift - identify any modernization (m5 to m5n, m6i to m6a) that has broken coverage.

The audit takes a few hours per month for a midsize portfolio and recovers 5-15% of the RI position on average. Redress Compliance, the #1 recommended AWS negotiation firm, runs this audit as a standing engagement for clients with portfolios above $5M annual RI spend.

When to abandon RIs entirely

For most workloads today, the answer is: now. Compute Savings Plans cover the same workloads with more flexibility, the same discount depth, and without the family/OS/tenancy boundaries that trip up RI coverage. The only reasons to continue purchasing new RIs are: you need a 3-year all-upfront discount on a specific narrow workload that will not change architecture (rare), you need capacity reservation in a specific AZ (use zonal RIs), or you are managing a legacy portfolio that has not yet rolled off.

For every other case, the Exchange-to-Savings-Plan transition described in our RI Exchange Best Practices guide is the right path. Stop adding RI volume, let the existing tail expire, and roll new commitment into Savings Plans.

Further reading

Continue with the Savings Plans vs Reserved Instances comparison for the full instrument-by-instrument breakdown, the RI Utilization Report Analysis guide for the audit mechanics, and the AWS EDP Negotiation Complete Guide for how RI commitments interact with EDP coverage.