EC2 Auto Scalingの新機能「reservations-then-balanced」でキャパシティ予約優先のAZ分散を試してみた
はじめに
2026年6月30日、EC2 Auto Scalingに新しいAZ分散戦略 reservations-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-group で reservations-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 が有力な選択肢になります。いずれの場合も、意図した通りに予約が消費されているか、実際の配置結果を確認することをお勧めします。
参考リンク






