How Does EC2 Reserved Instance Size Flexibility Work?
Amazon EC2 Reserved Instance size flexibility automatically applies the discounted rate of a Regional Linux Reserved Instance to any running instance within the same instance family and AWS Region, regardless of its specific size. Every instance size is assigned a mathematical normalization factor based on its relative resource capacity. When your instances run, AWS calculates the total normalized units consumed and matches them against the normalized units provided by your Reserved Instance commitment. This allows a single Reserved Instance to fully cover multiple smaller instances or partially discount a single larger instance without requiring manual modifications to your reservation.
Prerequisites and Eligibility Criteria
Instance size flexibility does not apply to every Reserved Instance purchase. For the billing discount to scale automatically across different sizes, your reservation and running instances must meet specific technical requirements:
- Regional Scope: The Reserved Instance must be configured as a Regional Reserved Instance rather than a Zonal Reserved Instance. Zonal reservations reserve capacity in a specific Availability Zone and lock the discount to the exact instance size purchased.
- Platform and Operating System: The instance must run on a Linux or Unix platform with default shared tenancy. Operating systems that include commercial licensing costs, such as Windows Server, Red Hat Enterprise Linux (RHEL), and SUSE Linux Enterprise Server (SLES), do not support size flexibility.
- Tenancy: Only instances with shared
(
default) tenancy qualify. Dedicated Instances and Dedicated Hosts are excluded. - Instance Family: The running instances must belong
to the exact same instance family and generation as the Reserved
Instance. For example, a reservation for the
m6ifamily can only apply to otherm6iinstances; it will not apply tom5orc6iinstances. - Amazon RDS Support: In addition to Amazon EC2, size flexibility also applies to Amazon RDS Reserved Instances across matching database engines and license-included or bring-your-own-license models where eligible.
Understanding Normalization Factors
To compare and equate different instance sizes within the same
family, AWS assigns a numerical value called a normalization factor to
each size. The normalization factor scales linearly with the size of the
instance. An xlarge instance serves as the baseline unit of
\(8\).
| Instance Size | Normalization Factor (\(N\)) | Equivalent large Units |
|---|---|---|
nano |
\(0.25\) | \(0.0625\) |
micro |
\(0.5\) | \(0.125\) |
small |
\(1\) | \(0.25\) |
medium |
\(2\) | \(0.5\) |
large |
\(4\) | \(1\) |
xlarge |
\(8\) | \(2\) |
2xlarge |
\(16\) | \(4\) |
4xlarge |
\(32\) | \(8\) |
8xlarge |
\(64\) | \(16\) |
9xlarge |
\(72\) | \(18\) |
12xlarge |
\(96\) | \(24\) |
16xlarge |
\(128\) | \(32\) |
24xlarge |
\(192\) | \(48\) |
32xlarge |
\(256\) | \(64\) |
48xlarge |
\(384\) | \(96\) |
The total discounted capacity of a reservation is calculated by multiplying the quantity of Reserved Instances (\(Q\)) by the normalization factor (\(N_{\text{RI}}\)) of the purchased size:
\[U_{\text{RI}} = Q \times N_{\text{RI}}\]
For example, purchasing one c6i.2xlarge Regional Linux
Reserved Instance provides a total of \(1
\times 16 = 16\) normalized units per hour in that region.
Applying Discounts to Smaller Instances
When you run instances that are smaller than your purchased Reserved Instance size, a single reservation can simultaneously cover multiple running instances until its pool of normalized units is exhausted.
The number of running instances (\(C\)) of a smaller target size with normalization factor (\(N_{\text{target}}\)) that a single Reserved Instance can cover is determined by:
\[C = \frac{U_{\text{RI}}}{N_{\text{target}}}\]
Suppose you own one t3.large Regional Linux Reserved
Instance (\(N_{\text{RI}} = 4\)).
Because this reservation provides \(4\)
normalized units per hour, the AWS billing engine can apply the discount
to any of the following active configurations in the same region:
- Two
t3.mediuminstances: Eachmediuminstance has a normalization factor of \(2\), consuming \(2 \times 2 = 4\) units. - Four
t3.smallinstances: Eachsmallinstance has a normalization factor of \(1\), consuming \(4 \times 1 = 4\) units. - Eight
t3.microinstances: Eachmicroinstance has a normalization factor of \(0.5\), consuming \(8 \times 0.5 = 4\) units. - Sixteen
t3.nanoinstances: Eachnanoinstance has a normalization factor of \(0.25\), consuming \(16 \times 0.25 = 4\) units. - Mixed combinations: One
t3.medium(\(2\) units), onet3.small(\(1\) unit), and twot3.microinstances (\(2 \times 0.5 = 1\) unit), which together total \(4\) units.
In all of these scenarios, 100% of the running instances are covered
by the single t3.large Reserved Instance, and no On-Demand
charges are incurred for compute usage.
Applying Discounts to Larger Instances
Instance size flexibility also works in reverse when you scale up to an instance size that is larger than your Reserved Instance. A smaller Reserved Instance will partially cover a larger running instance, reducing the On-Demand cost proportionally.
The fraction of the running instance covered by the reservation (\(F_{\text{covered}}\)) is calculated as:
\[F_{\text{covered}} = \frac{U_{\text{RI}}}{N_{\text{running}}}\]
The remaining uncovered portion is billed at the standard On-Demand hourly rate (\(R_{\text{OD}}\)) for that larger instance:
\[\text{Hourly Cost}_{\text{uncovered}} = \left(1 - F_{\text{covered}}\right) \times R_{\text{OD}}\]
For example, suppose you own one m6i.xlarge Reserved
Instance (\(N_{\text{RI}} = 8\)), and
you decide to scale your workload up to a single
m6i.2xlarge instance (\(N_{\text{running}} = 16\)) in the same
region:
- Your reservation provides \(8\) normalized units per hour.
- The running
m6i.2xlargerequires \(16\) normalized units per hour. - The coverage ratio is \(\frac{8}{16} =
0.5\), meaning 50% of the
m6i.2xlargeinstance is covered by the Reserved Instance. - You are billed at the On-Demand rate for the remaining 50% of the
m6i.2xlargeusage (equivalent to paying for \(8\) uncovered normalized units).
Alternatively, if you own two m6i.xlarge Reserved
Instances (\(2 \times 8 = 16\) units),
their normalized units combine automatically to cover 100% of the single
m6i.2xlarge instance (\(16\) units).
How AWS Billing Evaluates Usage
The application of instance size flexibility requires no manual intervention or configuration changes in the AWS Management Console. The AWS billing system evaluates usage on an hourly basis across all accounts in an AWS Organization (when consolidated billing and discount sharing are enabled) using the following order of operations:
- Account Affinity: A Reserved Instance is always applied first to matching usage within the specific AWS account that purchased the reservation.
- Smallest-to-Largest Matching: Within an instance family and region, the billing engine evaluates and applies normalized units automatically to maximize coverage across active instances.
- Organization Sharing: If any normalized units from a Regional Reserved Instance remain unused within the purchasing account during a given billing hour, those leftover fractional or whole units are automatically applied to eligible running instances in other accounts within the same AWS Organization.
Monitoring Normalized Unit Utilization
To verify how your Reserved Instances are being applied across different sizes, you can inspect your usage in AWS Cost Explorer:
- Open the AWS Cost Management console and navigate to Reservations > Utilization report.
- Filter the view by Service (EC2-Instances) and Instance Family.
- Examine the Normalized units columns, which display your Total normalized units purchased alongside the Used normalized units and Unused normalized units.
- Switch to the Coverage report to view the percentage of your running normalized units covered by Reserved Instances versus those billed at On-Demand rates, allowing you to identify if scaling up to larger instance sizes has left an uncovered gap.