EC2 Auto Scalingの新機能「reservations-then-balanced」でキャパシティ予約優先のAZ分散を試してみた

EC2 Auto Scalingの新機能「reservations-then-balanced」でキャパシティ予約優先のAZ分散を試してみた

EC2 Auto Scalingに新しいAZ分散戦略reservations-then-balancedが追加されました。キャパシティ予約を優先的に消費しつつ残りのインスタンスをAZ間で分散する動作を、従来のbalanced-best-effortとの比較で検証しました。
2026.07.03

はじめに

2026年6月30日、EC2 Auto Scalingに新しいAZ分散戦略 reservations-then-balanced が追加されました。

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

従来の balanced-best-effort では、AZ均等分散が優先されるため、予約がAZ間で偏っている場合に予約を活用できないことがありました。reservations-then-balanced では、キャパシティ予約を優先的に消費し、予約枠を超えた分をAZ間で分散配置する運用が可能になります。

項目 balanced-best-effort reservations-then-balanced
スケールアウト時の優先度 AZ 均等分散 キャパシティ予約の消費 → AZ 分散
スケールイン時の削除順 AZ バランス重視 予約外インスタンスが優先的に削除(今回の検証結果)
予約利用率(AZ-a に予約3台、3AZ構成、今回の検証) Desired=3 で 1/3 Desired=3 で 1/3、Desired=5 で 2/3 まで確認

検証環境

  • リージョン: ap-northeast-1
  • ODCR: t4g.nano × 3台、ap-northeast-1a、targeted
  • Auto Scaling Group(ASG): ap-northeast-1a / 1c / 1dの3AZ構成、Max=5

検証

ODCR の作成

ap-northeast-1aにt4g.nano × 3台のtargeted ODCRを作成しました。

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"
}

ASG の作成(CloudFormation)

以下のCloudFormationテンプレートでASGを作成しました。初回は balanced-best-effort(デフォルト)でデプロイし、後から reservations-then-balanced に切り替えます。

CloudFormationテンプレート(クリックで展開)
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
  • CapacityReservationSpecification でODCRをターゲット指定(capacity-reservations-first + ODCR ID)
  • AvailabilityZoneDistribution は初回 balanced-best-effort で作成し、後からAPIで reservations-then-balanced に切り替え

Before: balanced-best-effort でのスケールアウト

Desired Capacityを3に設定した結果です。

AZ インスタンスID CR Preference LifecycleState
ap-northeast-1a i-0ea798b6xxxxxxxx open InService
ap-northeast-1c i-07479a5fxxxxxxxx open InService
ap-northeast-1d i-07391cc3xxxxxxxx open InService
{
    "Total": 3,
    "Available": 2
}

3AZに均等分散(a:1, c:1, d:1)された結果、AZ-aの予約は1台しか消費されず、残り2台分が未使用です。

After: reservations-then-balanced でのスケールアウト

update-auto-scaling-groupreservations-then-balanced に切り替えます。今回の検証では、この変更による既存インスタンスの即時置き換えは発生しませんでした。

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

0台 → 3台

初回スケールアウトではAZバランスも同時に考慮されるため、今回の検証では balanced-best-effort と同様に予約消費は1台(1/3)にとどまりました。差が明確に出たのは次のスケールアウトからです。

AZ-aの1台が予約へ配置され(capacity-reservations-only)、残り2台はc, dに分散されました。

AZ インスタンスID CR Preference Capacity Reservation
ap-northeast-1a i-08fcce94xxxxxxxx capacity-reservations-only cr-xxxxxxxxxxxxxxxxx
ap-northeast-1c i-0ef98d3axxxxxxxx open
ap-northeast-1d i-015bca4cxxxxxxxx open

ODCR残: 2/3(Available: 2)

3台 → 5台

追加の2台のうち1台がAZ-aに配置され予約を消費し、もう1台はAZ-cに配置されました。ODCRの消費は2/3に増加しています。

AZ インスタンスID CR Preference Capacity Reservation
ap-northeast-1a i-08fcce94xxxxxxxx capacity-reservations-only cr-xxxxxxxxxxxxxxxxx
ap-northeast-1a i-085d201exxxxxxxx capacity-reservations-only cr-xxxxxxxxxxxxxxxxx
ap-northeast-1c i-0ef98d3axxxxxxxx open
ap-northeast-1c i-00cb22cfxxxxxxxx open
ap-northeast-1d i-015bca4cxxxxxxxx open

ODCR残: 1/3(Available: 1)

スケールイン: 予約利用インスタンスが残ることの確認

Desired Capacityを5から3に減らしました。予約外のインスタンスが先に削除され、予約を使用しているインスタンスは残りました。

削除されたインスタンス:

インスタンスID AZ CR Preference
i-015bca4cxxxxxxxx ap-northeast-1d open
i-00cb22cfxxxxxxxx ap-northeast-1c open

残ったインスタンス:

AZ インスタンスID CR Preference Capacity Reservation
ap-northeast-1a i-08fcce94xxxxxxxx capacity-reservations-only cr-xxxxxxxxxxxxxxxxx
ap-northeast-1a i-085d201exxxxxxxx capacity-reservations-only cr-xxxxxxxxxxxxxxxxx
ap-northeast-1c i-0ef98d3axxxxxxxx open

結果としてAZ配置はa:2, c:1と偏りが生じていますが、予約利用率は維持されています(ODCR残: 1/3)。

まとめ

reservations-then-balanced は、AZ間で偏りのあるキャパシティ予約を持つ構成で有効なAZ分散戦略です。

今回の検証では、1つのAZに3台分のODCRが偏っている状態で、balanced-best-effort ではDesired=3時点で1台分のみ予約が消費されました。一方、reservations-then-balanced ではDesired=3から5へのスケールアウトで予約消費が2/3まで進み、スケールイン時にも予約を使用しているインスタンスが残ることを確認できました。

予約をAZ間で均等に配置できる場合は、従来の balanced-best-effort でもAZ均等分散と予約消費が噛み合いやすくなります。予約が特定AZに偏る場合は、reservations-then-balanced が有力な選択肢になります。いずれの場合も、意図した通りに予約が消費されているか、実際の配置結果を確認することをお勧めします。

参考リンク

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

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事