Trying Out the New EC2 Auto Scaling Feature "reservations-then-balanced" for AZ Distribution That Prioritizes Capacity Reservations

Introduction

On June 30, 2026, a new AZ distribution strategy, reservations-then-balanced, was added to EC2 Auto Scaling.

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/ec2-auto-scaling-res-then-balanced/

With the conventional balanced-best-effort, even distribution across AZs takes priority, so reservations sometimes could not be used when they were unevenly distributed across AZs. With reservations-then-balanced, you can operate in a way that consumes capacity reservations first and distributes instances beyond the reserved capacity across AZs.

Verification Environment

• Region: ap-northeast-1
• ODCR: t4g.nano × 3, ap-northeast-1a, targeted
• Auto Scaling Group (ASG): 3-AZ configuration of ap-northeast-1a / 1c / 1d, Max=5

Verification

Creating the ODCR

I created a targeted ODCR for t4g.nano × 3 in ap-northeast-1a.

aws ec2 create-capacity-reservation \
  --availability-zone ap-northeast-1a \
  --instance-type t4g.nano \
  --instance-platform "Linux/UNIX" \
  --instance-count 3 \
  --end-date-type unlimited \
  --instance-match-criteria targeted

{
    "CapacityReservationId": "cr-xxxxxxxxxxxxxxxxx",
    "InstanceType": "t4g.nano",
    "AvailabilityZone": "ap-northeast-1a",
    "TotalInstanceCount": 3,
    "AvailableInstanceCount": 3,
    "State": "active",
    "InstanceMatchCriteria": "targeted"
}

Creating the ASG (CloudFormation)

I created the ASG with the following CloudFormation template. It is first deployed with balanced-best-effort (the default) and later switched to reservations-then-balanced.

AWSTemplateFormatVersion: "2010-09-09"
Description: >
  ASG with reservations-then-balanced strategy.
  t4g.nano instances with ODCR priority in AZ-a, then balanced across AZs.

Parameters:
  CapacityReservationId:
    Type: String
    Description: "ODCR ID (e.g., cr-0123456789abcdef0) created by create-odcr.sh"

  SubnetAZa:
    Type: AWS::EC2::Subnet::Id
    Description: "Subnet in ap-northeast-1a"

  SubnetAZb:
    Type: AWS::EC2::Subnet::Id
    Description: "Subnet in ap-northeast-1c"

  SubnetAZc:
    Type: AWS::EC2::Subnet::Id
    Description: "Subnet in ap-northeast-1d"

  AmiId:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64
    Description: "AMI ID (default: latest Amazon Linux 2023 ARM64)"

  DesiredCapacity:
    Type: Number
    Default: 3

  MinSize:
    Type: Number
    Default: 0

  MaxSize:
    Type: Number
    Default: 5

Resources:
  LaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateName: !Sub "${AWS::StackName}-lt"
      LaunchTemplateData:
        ImageId: !Ref AmiId
        InstanceType: t4g.nano
        TagSpecifications:
          - ResourceType: instance
            Tags:
              - Key: Name
                Value: !Sub "${AWS::StackName}-instance"

  AutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AutoScalingGroupName: !Sub "${AWS::StackName}-asg"
      LaunchTemplate:
        LaunchTemplateId: !Ref LaunchTemplate
        Version: !GetAtt LaunchTemplate.LatestVersionNumber
      VPCZoneIdentifier:
        - !Ref SubnetAZa
        - !Ref SubnetAZb
        - !Ref SubnetAZc
      MinSize: !Ref MinSize
      MaxSize: !Ref MaxSize
      DesiredCapacity: !Ref DesiredCapacity
      AvailabilityZoneDistribution:
        CapacityDistributionStrategy: balanced-best-effort
      CapacityReservationSpecification:
        CapacityReservationPreference: capacity-reservations-first
        CapacityReservationTarget:
          CapacityReservationIds:
            - !Ref CapacityReservationId

• Target the ODCR with CapacityReservationSpecification (capacity-reservations-first + ODCR ID)
• AvailabilityZoneDistribution is created with balanced-best-effort initially, and later switched to reservations-then-balanced via the API

Before: Scale-out with balanced-best-effort

These are the results after setting Desired Capacity to 3.

{
    "Total": 3,
    "Available": 2
}

As a result of even distribution across the 3 AZs (a:1, c:1, d:1), only 1 instance of the AZ-a reservation was consumed, and the remaining 2 are unused.

After: Scale-out with reservations-then-balanced

Switch to reservations-then-balanced with update-auto-scaling-group. In this verification, this change did not cause existing instances to be replaced immediately.

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name reservations-balanced-demo-asg \
  --availability-zone-distribution '{"CapacityDistributionStrategy":"reservations-then-balanced"}'

0 → 3 instances

Because AZ balance is also considered during the initial scale-out, reservation consumption in this verification stayed at 1 instance (1/3), the same as with balanced-best-effort. The difference became clear from the next scale-out.

One instance in AZ-a was placed in the reservation (capacity-reservations-only), and the remaining 2 were distributed to c and d.

ODCR remaining: 2/3 (Available: 2)

3 → 5 instances

Of the 2 additional instances, one was placed in AZ-a and consumed a reservation, and the other was placed in AZ-c. ODCR consumption increased to 2/3.

ODCR remaining: 1/3 (Available: 1)

Scale-in: Confirming that instances using reservations remain

I reduced Desired Capacity from 5 to 3. Instances outside the reservation were terminated first, and the instances using the reservation remained.

Terminated instances:

Remaining instances:

As a result, the AZ placement is skewed to a:2, c:1, but the reservation utilization is maintained (ODCR remaining: 1/3).

Summary

reservations-then-balanced is an effective AZ distribution strategy for configurations with capacity reservations that are unevenly distributed across AZs.

In this verification, with 3 instances' worth of ODCR concentrated in a single AZ, balanced-best-effort consumed the reservation for only 1 instance at Desired=3. On the other hand, with reservations-then-balanced, reservation consumption advanced to 2/3 when scaling out from Desired=3 to 5, and I was able to confirm that instances using the reservation remained during scale-in.

If reservations can be placed evenly across AZs, even the conventional balanced-best-effort makes it easier for even AZ distribution and reservation consumption to line up. If reservations are concentrated in a specific AZ, reservations-then-balanced becomes a strong option. In either case, I recommend checking the actual placement results to confirm that reservations are being consumed as intended.

Reference Links

https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-availability-zone-balanced.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html