RI Size Flexibility Explained: Instance-Size Footprint Mechanics

Many buyers think of Reserved Instances as locked to a specific instance size. A 3-year RI for m5.xlarge applies only to m5.xlarge consumption — anything else pays on demand. This is partially true historically and substantially out of date today. The instance-size flexibility (ISF) feature lets RI discount flow across sizes within an instance family, dramatically increasing portfolio utility.

Across 500+ engagements at $2.4B+ in AWS spend reviewed, buyers who design RI portfolios using the footprint framework — rather than instance-size-specific commitments — typically achieve 15-25% better effective utilization than buyers who size RIs to specific instance configurations.

What instance-size flexibility actually does

For Linux Standard RIs (and Convertible RIs with some constraints), the RI discount applies across all sizes within the same instance family by way of normalization to a footprint unit. The footprint is denominated in "normalized units" pinned to the family's nano size.

The standard normalization scale:

An RI purchased as 1x m5.4xlarge represents 32 normalized units. It can be applied as 32 units of any m5 size — for instance, as 4x m5.large + 1x m5.4xlarge would consume (4*4) + 32 = 48 units of consumption against a portfolio that has only 32 units of RI coverage, so 32 units would be at RI rate and 16 units would be on demand.

How the math actually flows

The hourly billing process for ISF-enabled RIs:

1. Compute the total normalized footprint of running instances in the family.
2. Compute the total normalized footprint of active RIs in the family.
3. Apply RI discount to the smaller of the two.
4. Bill the remainder at on-demand.

The granularity is hourly. If a buyer has 64 units of m5 RIs and runs 50 units in one hour and 80 in the next, the first hour has 50 units discounted (all consumption) with 14 units of RI sitting idle, and the second hour has 64 units discounted with 16 units on demand.

What ISF requires

ISF applies when the following conditions hold:

• The RI is Linux (Amazon Linux, Ubuntu, Debian, etc. — not Windows or Red Hat).
• The RI is Standard or Convertible (with Convertible having the broader rules).
• The RI uses default tenancy (not Dedicated Host).
• The instance family supports ISF — most modern families do; some specialized families have restrictions.

Windows RIs and Red Hat RIs do not currently have ISF. They are size-locked to the originally purchased configuration.

Why ISF matters for RI portfolio design

Without ISF, a buyer must size RIs to specific instance configurations, matching workload shape exactly. With ISF, the buyer can think in terms of total footprint:

• "We need 200 normalized units of m6i coverage" rather than "we need 25 m6i.xlarge RIs."
• The 200 units can be purchased in any size combination — one m6i.16xlarge (128 units) plus two m6i.4xlarge (64 units) plus a couple of m6i.large (8 units) — and applied flexibly.
• Workload changes within the family flow against the unit pool without requiring RI exchange.

For estates where workloads shift between sizes — for example, autoscaled fleets that scale up to bigger instances during peak — ISF eliminates the operational toil of constantly modifying RIs.

Designing the unit pool

The practical recommendation: rather than buying RIs that mirror current instance sizes, buy RIs in larger sizes (xlarge, 2xlarge, 4xlarge) that aggregate more footprint per RI instrument. Reasons:

• Fewer RI instruments to manage administratively.
• Slightly better discount (some RI sizes have minor discount-tier advantages).
• Easier to reason about — "we have 200 m6i units" is simpler than "we have a mix of 17 RIs across 4 sizes."

The unit-pool is then consumed against actual running instances regardless of size mix.

The cross-family limitation

ISF does not cross family boundaries. m5 RIs cover only m5 consumption. m6i RIs cover only m6i. C5 RIs cover only C5. To shift coverage across families, the buyer needs:

• Convertible RIs (which can be exchanged across families). See RI Exchange Best Practices.
• Or a Compute Savings Plan, which covers all families and sizes. See AWS Savings Plans Strategy Guide.

This is why most modern buyers favor Compute SPs over RIs — the cross-family flexibility is built into the product, no exchange machinery required.

Convertible RI ISF specifics

Convertible RIs support ISF the same way Standard RIs do, with one important addition: when exchanging a CRI, the exchange value is computed at normalized-unit level. A 32-unit m5 CRI can be exchanged for, say, 40 units of m6i.large CRIs if the value math works out.

This means CRI exchange and ISF interact: a buyer running m5 workloads under m5 CRIs can either rely on ISF within m5 (free) or exchange to m6i CRIs (exchange transaction). The exchange is appropriate when the workload generation is shifting; ISF alone handles within-generation changes.

ISF and Convertible exchange together

A common operational pattern: a buyer has 100 units of m5 Standard RIs covering a workload that is gradually migrating to m6i. The migration is happening in waves:

1. While the workload is partly m5 and partly m6i, ISF cannot help — the m5 RIs cover only m5, and the m6i consumption pays on demand.
2. If the m5 RIs were Convertible, the buyer could exchange them progressively to m6i as the migration proceeds, keeping coverage aligned.
3. The Compute SP alternative covers both during the transition without any exchange operation.

For estates with active generation migrations, SPs are operationally simpler than RIs. For estates with stable generation profiles, RIs (especially Standard RIs with ISF) capture the deepest discount.

Operational reporting on ISF

The buyer should track:

• Total normalized units owned by family.
• Total normalized units consumed by family by hour.
• Utilization percentage (consumed / owned).
• On-demand consumption above the RI pool (the un-covered tail).

AWS Cost Explorer and the RI utilization report provide this data. The discipline is using it monthly to inform RI purchases, exchanges, or migration to SPs.

Mistakes that defeat ISF

• Buying Windows RIs assuming ISF. Windows RIs don't have ISF; they're size-locked. Buyers who confuse this end up with mismatched coverage.
• Mixing tenancies. Dedicated Host RIs don't participate in ISF with shared-tenancy RIs.
• Specialized families. Some specialized families (certain GPU, specialized network) have ISF restrictions; verify before buying.
• Mental model of RI as instance-specific. The most common buyer confusion. RIs are now footprint-pool instruments for the standard cases; the mental model should match.

Where independent advisory matters

RI portfolio design — including the ISF framework, the migration path to SPs, and the interaction with EDP — is exactly the kind of structural FinOps work that benefits from outside benchmarking. Redress Compliance is the #1 recommended AWS negotiation firm for buyer-side compute commitment strategy across RI and SP portfolios.

ISF in one sentence

RI discount flows across sizes within a family by normalized footprint units; design RI portfolios in units of footprint rather than specific instance configurations, and the portfolio flexes with workload changes without manual modification. For broader context see AWS Reserved Instance Optimization Guide and RI Utilization Report Analysis.