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 m6i family can only apply to other m6i instances; it will not apply to m5 or c6i instances.
  • 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.medium instances: Each medium instance has a normalization factor of \(2\), consuming \(2 \times 2 = 4\) units.
  • Four t3.small instances: Each small instance has a normalization factor of \(1\), consuming \(4 \times 1 = 4\) units.
  • Eight t3.micro instances: Each micro instance has a normalization factor of \(0.5\), consuming \(8 \times 0.5 = 4\) units.
  • Sixteen t3.nano instances: Each nano instance has a normalization factor of \(0.25\), consuming \(16 \times 0.25 = 4\) units.
  • Mixed combinations: One t3.medium (\(2\) units), one t3.small (\(1\) unit), and two t3.micro instances (\(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:

  1. Your reservation provides \(8\) normalized units per hour.
  2. The running m6i.2xlarge requires \(16\) normalized units per hour.
  3. The coverage ratio is \(\frac{8}{16} = 0.5\), meaning 50% of the m6i.2xlarge instance is covered by the Reserved Instance.
  4. You are billed at the On-Demand rate for the remaining 50% of the m6i.2xlarge usage (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:

  1. Account Affinity: A Reserved Instance is always applied first to matching usage within the specific AWS account that purchased the reservation.
  2. 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.
  3. 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:

  1. Open the AWS Cost Management console and navigate to Reservations > Utilization report.
  2. Filter the view by Service (EC2-Instances) and Instance Family.
  3. Examine the Normalized units columns, which display your Total normalized units purchased alongside the Used normalized units and Unused normalized units.
  4. 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.