Amazon EC2 Auto Scaling 完全ガイド v2.0

初心者から実務者向けの包括的解説

ドキュメントの目的

本ガイドは以下を対象としています：

初心者向け： EC2 Auto Scaling とは何か、なぜ必要かを学びたい方
開発者・SRE 向け： スケーリングポリシーの実装、オートメーション、本番運用を構築したい方
インフラストラクチャエンジニア向け： Karpenter などの次世代ソリューションとの比較検討
意思決定者向け： コスト削減、可用性向上のための投資判断

2026 年の EC2 Auto Scaling エコシステム

Predictive Scaling の進化：機械学習による事前スケーリングが主流（過去 14 日分の履歴から学習）
Karpenter との共存：Kubernetes クラスターではKarpenter（60秒以内の起動）、EC2ワークロードでは ASG（ECS/ALB）の使い分けが定着
Warm Pool の活用：大規模アプリケーションでコールドスタート緩和が重要化
Mixed Instances Policy の最適化：スポットインスタンスのコスト削減率が最大 70% に
Instance Refresh の拡張：ローリング更新で Blue-Green デプロイに対応
Capacity Rebalancing：スポット中断リスクを自動で検知・置換（EC2 Spot 仕様推奨）

定義

AWS 公式による定義：

「Amazon EC2 Auto Scaling は、アプリケーションの負荷に応じて EC2 インスタンス数を自動的に調整し、需要の変化に対応するマネージドサービス」

概要
このサービスを選ぶ理由
Auto Scaling が解決する課題
主な特徴
アーキテクチャ
コアコンポーネント
スケーリング戦略の詳細
主要ユースケース
設定・操作の具体例
混合インスタンスポリシー
Warm Pool
ライフサイクルフック
Instance Refresh
Karpenter・Cluster Autoscaler との比較
他の類似ツール・サービスとの比較
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例
導入ロードマップ
実装チェックリスト
まとめ
参考文献

概要

Amazon EC2 Auto Scaling は、アプリケーションの需要に応じて EC2 インスタンス数を自動的に管理するマネージドサービス です。最小・最大・目標キャパシティを指定し、スケーリングポリシー（ターゲット追跡、ステップスケーリング、スケジュール、予測）を組み合わせることで、コスト効率と高可用性を同時に実現します。

初心者向けメモ： EC2 Auto Scaling 自体は無料です。課金の対象は、起動した EC2 インスタンスと関連リソース（EBS、トラフィック等）のみです。

このサービスを選ぶ理由

課題	従来の手動管理	EC2 Auto Scaling での解決
トラフィックスパイク対応	手動でインスタンス追加（遅延あり）	秒単位で自動スケール、リアルタイム対応
オフピーク時コスト	24 時間稼働で無駄が発生	需要減でスケールイン、コスト削減
インスタンス障害時の復旧	手動で再起動・置換	ヘルスチェック失敗で自動置換
複数 AZ への分散	手動で配置管理	自動でバランス調整
スポット割引の活用	リスク回避で使わない	Mixed Instances Policy で 70% 削減

Auto Scaling が解決する課題

EC2 Auto Scaling は以下の課題に対応します：

キャパシティ計画の複雑さ：ピーク時と通常時の差を事前予測
スケーリング遅延：ALB ターゲットグループ連携で秒単位対応
不健全インスタンスの放置：ヘルスチェック失敗時に自動置換
マルチ AZ 不均衡：AZ ごとのインスタンス数を自動調整
コスト最適化：スポット・オンデマンド混在で割引適用

主な特徴

✅ 完全マネージド：インフラ管理の負担がない
✅ 自動スケーリング：CPU、メモリ、カスタムメトリクスに基づいた動的調整
✅ ターゲット追跡：目標値（CPU 60% など）を自動維持
✅ 予測スケーリング：機械学習で事前スケール（ピーク前に準備）
✅ Warm Pool：停止中のインスタンスで高速起動（コールドスタート回避）
✅ Instance Refresh：ローリング更新で Blue-Green デプロイ
✅ ライフサイクルフック：カスタムアクション（起動前・終了前処理）
✅ 混合インスタンスポリシー：スポット + オンデマンド混在
✅ ヘルスチェック：EC2 ステータス + ALB ターゲットチェック
✅ Capacity Rebalancing：スポット中断リスク自動検知・置換

アーキテクチャ

graph TB
    subgraph ASG["Auto Scaling Group（ASG）"]
        subgraph AZ_A["Availability Zone A"]
            EC2_A1["EC2 Instance #1<br/>on-demand / gp3"]
            EC2_A2["EC2 Instance #2<br/>spot"]
        end
        subgraph AZ_B["Availability Zone B"]
            EC2_B1["EC2 Instance #3<br/>on-demand"]
            EC2_B2["EC2 Instance #4<br/>spot"]
        end
        subgraph AZ_C["Availability Zone C"]
            EC2_C1["EC2 Instance #5<br/>spot"]
        end
    end
    
    Trigger1["CPU > 70%<br/>Target Tracking"]
    Trigger2["Scheduled<br/>Time-based"]
    Trigger3["Predictive<br/>ML forecast"]
    Trigger4["Custom Metric<br/>CloudWatch"]
    
    ALB["Application Load Balancer<br/>Health Check"]
    LT["Launch Template<br/>AMI / Instance Type / SG"]
    CloudWatch["CloudWatch<br/>Metrics Aggregation"]
    
    Trigger1 --> ASG
    Trigger2 --> ASG
    Trigger3 --> ASG
    Trigger4 --> ASG
    ASG --> ALB
    LT -.provides config.-> ASG
    CloudWatch -.monitoring.-> ASG
    
    style ASG fill:#e1f5ff
    style AZ_A fill:#fff9c4
    style AZ_B fill:#fff9c4
    style AZ_C fill:#fff9c4

アーキテクチャ詳細

Auto Scaling Group（ASG）
Min / Desired / Max キャパシティを保持。複数 AZ にインスタンスを分散配置。

Launch Template
AMI、インスタンスタイプ、セキュリティグループ、IAM ロール、EBS 設定などを一元管理。

スケーリングトリガー

ターゲット追跡（CPU 60% 維持）
ステップスケーリング（段階的増減）
スケジュール（定時スケール）
予測スケーリング（ML 予測）
カスタムメトリクス

ヘルスチェック
EC2 ステータス + ALB ターゲットチェックで不健全インスタンスを検知。

コアコンポーネント

1. Auto Scaling Group（ASG）

インスタンスを論理的にグループ化する単位。

パラメータ	説明	推奨値
Min Size	最小インスタンス数	AZ 数以上（e.g., 3 AZ なら 3 以上）
Desired Capacity	目標インスタンス数	Min と Max の中間値
Max Size	最大インスタンス数	ピーク時需要 + 余裕 20%
Health Check Type	ELB / EC2	ELB（ALB/NLB 使用時）
Health Check Grace Period	起動後のチェック開始時間	300 秒（アプリ起動時間による）
Default Cooldown	スケーリング後の待機時間	300 秒（ターゲット追跡は不要）

2. Launch Template（推奨）

起動テンプレートは起動設定の後継。複数バージョン管理が可能。

必須パラメータ：

AMI ID
インスタンスタイプ
セキュリティグループ
IAM インスタンスプロファイル
EBS ボリューム設定（gp3 推奨）

セキュリティベストプラクティス：

IMDSv2 必須設定（メタデータ保護）
EBS 暗号化を有効化
ユーザーデータを Base64 エンコード

3. スケーリングポリシー

ターゲット追跡スケーリング（推奨）

目標メトリクス値を自動維持。最もシンプルで推奨。

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg-prod \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 60.0,
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }'

ステップスケーリング

閾値ごとに増減ステップ数を指定。

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg-prod \
  --policy-name step-scaling \
  --policy-type StepScaling \
  --adjustment-type ChangeInCapacity \
  --metric-aggregation-type Average \
  --step-adjustments \
    MetricIntervalLowerBound=0,MetricIntervalUpperBound=10,ScalingAdjustment=1 \
    MetricIntervalLowerBound=10,MetricIntervalUpperBound=20,ScalingAdjustment=2 \
    MetricIntervalLowerBound=20,ScalingAdjustment=3

スケジュールスケーリング

予測可能な定期負荷に対応。

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg-prod \
  --scheduled-action-name weekday-morning \
  --recurrence "0 8 * * 1-5" \
  --desired-capacity 6 \
  --min-size 4 \
  --time-zone "Asia/Tokyo"

予測スケーリング

機械学習で事前スケール。14 日以上の履歴が必要。

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg-prod \
  --policy-name predictive-scaling \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration '{
    "MetricSpecifications": [{
      "TargetValue": 60.0,
      "PredefinedMetricPairSpecification": {
        "PredefinedMetricType": "ASGCPUUtilization"
      }
    }],
    "Mode": "ForecastAndScale",
    "SchedulingBufferTime": 300
  }'

スケーリング戦略の詳細

ターゲット追跡 vs ステップスケーリング

項目	ターゲット追跡	ステップスケーリング
自動化	フル自動（冷却時間自動）	手動設定（段階指定）
応答性	遅い（平滑化）	速い（急激）
用途	一般的なワークロード	急変パターン
設定複雑度	低（目標値のみ）	高（複数段階設定）

推奨： ほとんどのケースでターゲット追跡を使用。ステップスケーリングは不要。

スケーリング冷却時間（Cooldown）

ターゲット追跡：自動管理（冷却時間の設定不要）
ステップスケーリング：スケールアウト 60 秒、スケールイン 300 秒
スケジュール：タイムゾーン指定必須

主要ユースケース

1. Web アプリケーション（CPU ベーススケーリング）

# ターゲット追跡でCPU 60% を維持
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 60.0
  }'

2. 予測スケーリング（周期的パターン）

営業時間中のトラフィック増加を事前予測。

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration '{
    "MetricSpecifications": [{
      "TargetValue": 60.0,
      "PredefinedMetricPairSpecification": {
        "PredefinedMetricType": "ASGCPUUtilization"
      }
    }],
    "Mode": "ForecastAndScale"
  }'

3. バッチ処理（スケジュール + 混合インスタンス）

夜間バッチ処理で安価なスポットインスタンスを活用。

# 夜 22:00 に 20 台起動
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name batch-asg \
  --scheduled-action-name night-batch-start \
  --recurrence "0 22 * * *" \
  --desired-capacity 20

# 朝 6:00 に 0 台に
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name batch-asg \
  --scheduled-action-name night-batch-end \
  --recurrence "0 6 * * *" \
  --desired-capacity 0

4. ML 推論サーバー（スポット最適化）

コスト削減が最優先。スポット中心で多機能タイプ混在。

5. API バックエンド（ALB ターゲットグループ）

ALB ベースのヘルスチェック + ターゲット追跡。

6. ECS での DynamoDB テーブルスケーリング連携

DynamoDB 自動スケーリングと連携。

7. IoT ゲートウェイ（Capacity Rebalancing）

スポット中断リスクを自動検知・置換。

8. 開発/ステージング環境（スケジュール + 停止）

コスト削減。夜間・休日は 0 台に。

9. マルチリージョン展開（リージョンごと ASG）

リージョン単位で独立した ASG。

10. Spot Fleet との組み合わせ

EC2 Fleet API 直接利用 vs ASG Mixed Instances Policy の使い分け。

設定・操作の具体例

CLI による ASG 作成（フル例）

# ステップ 1: Launch Template 作成
aws ec2 create-launch-template \
  --launch-template-name web-server-lt \
  --version-description "v1.0 with gp3 and IMDSv2" \
  --launch-template-data '{
    "ImageId": "ami-0b20f552f63953f0e",
    "InstanceType": "t3.medium",
    "KeyName": "my-keypair",
    "SecurityGroupIds": ["sg-0123456789abcdef0"],
    "IamInstanceProfile": {
      "Name": "WebServerInstanceProfile"
    },
    "MetadataOptions": {
      "HttpTokens": "required",
      "HttpEndpoint": "enabled"
    },
    "BlockDeviceMappings": [{
      "DeviceName": "/dev/xvda",
      "Ebs": {
        "VolumeSize": 30,
        "VolumeType": "gp3",
        "Iops": 3000,
        "Throughput": 125,
        "Encrypted": true,
        "DeleteOnTermination": true
      }
    }],
    "UserData": "IyEvYmluL2Jhc2gKc3lzdGVtY3RsIHN0YXJ0IGh0dHBk",
    "TagSpecifications": [{
      "ResourceType": "instance",
      "Tags": [
        {"Key": "Name", "Value": "web-server"},
        {"Key": "Environment", "Value": "prod"}
      ]
    }]
  }'

# ステップ 2: ASG 作成
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg-prod \
  --launch-template LaunchTemplateName=web-server-lt,Version='$Latest' \
  --min-size 3 \
  --max-size 10 \
  --desired-capacity 5 \
  --vpc-zone-identifier "subnet-aaa,subnet-bbb,subnet-ccc" \
  --target-group-arns "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/web-tg/abc123def456" \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --default-cooldown 300 \
  --termination-policies "Default" \
  --tags '[
    {
      "Key": "Name",
      "Value": "web-server",
      "PropagateAtLaunch": true
    },
    {
      "Key": "Environment",
      "Value": "prod",
      "PropagateAtLaunch": true
    }
  ]'

# ステップ 3: ターゲット追跡スケーリング
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg-prod \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 60.0,
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

CloudFormation による IaC

AWSTemplateFormatVersion: '2010-09-09'

Resources:
  WebServerLaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateName: web-server-lt
      LaunchTemplateData:
        ImageId: ami-0b20f552f63953f0e
        InstanceType: t3.medium
        KeyName: my-keypair
        SecurityGroupIds:
          - sg-0123456789abcdef0
        IamInstanceProfile:
          Name: WebServerInstanceProfile
        MetadataOptions:
          HttpTokens: required
          HttpEndpoint: enabled
        BlockDeviceMappings:
          - DeviceName: /dev/xvda
            Ebs:
              VolumeSize: 30
              VolumeType: gp3
              Iops: 3000
              Throughput: 125
              Encrypted: true
        UserData: !Base64 |
          #!/bin/bash
          systemctl start httpd

  WebASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AutoScalingGroupName: web-asg-prod
      LaunchTemplate:
        LaunchTemplateName: !Ref WebServerLaunchTemplate
        Version: !GetAtt WebServerLaunchTemplate.LatestVersionNumber
      MinSize: 3
      MaxSize: 10
      DesiredCapacity: 5
      VPCZoneIdentifier:
        - subnet-aaa
        - subnet-bbb
        - subnet-ccc
      TargetGroupARNs:
        - !Sub 'arn:aws:elasticloadbalancing:ap-northeast-1:${AWS::AccountId}:targetgroup/web-tg/abc123def456'
      HealthCheckType: ELB
      HealthCheckGracePeriod: 300
      TerminationPolicies:
        - Default
      Tags:
        - Key: Name
          Value: web-server
          PropagateAtLaunch: true
        - Key: Environment
          Value: prod
          PropagateAtLaunch: true

  TargetTrackingScalingPolicy:
    Type: AWS::AutoScaling::ScalingPolicy
    Properties:
      AutoScalingGroupName: !Ref WebASG
      PolicyType: TargetTrackingScaling
      TargetTrackingConfiguration:
        PredefinedMetricSpecification:
          PredefinedMetricType: ASGAverageCPUUtilization
        TargetValue: 60.0
        ScaleOutCooldown: 60
        ScaleInCooldown: 300

Terraform による IaC

resource "aws_launch_template" "web_server" {
  name_prefix = "web-server-"
  
  block_device_mappings {
    device_name = "/dev/xvda"
    ebs {
      volume_size           = 30
      volume_type           = "gp3"
      iops                  = 3000
      throughput            = 125
      encrypted             = true
      delete_on_termination = true
    }
  }

  instance_type = "t3.medium"
  image_id      = "ami-0b20f552f63953f0e"

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
  }

  iam_instance_profile {
    name = aws_iam_instance_profile.web_server.name
  }

  security_groups = [aws_security_group.web_server.id]

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "web-server"
      Environment = "prod"
    }
  }

  user_data = base64encode(file("${path.module}/user_data.sh"))
}

resource "aws_autoscaling_group" "web_asg" {
  name                = "web-asg-prod"
  launch_template {
    id      = aws_launch_template.web_server.id
    version = "$Latest"
  }

  min_size            = 3
  max_size            = 10
  desired_capacity    = 5
  vpc_zone_identifier = [
    aws_subnet.az_a.id,
    aws_subnet.az_b.id,
    aws_subnet.az_c.id
  ]

  target_group_arns       = [aws_lb_target_group.web.arn]
  health_check_type       = "ELB"
  health_check_grace_period = 300

  tag {
    key                 = "Name"
    value               = "web-server"
    propagate_at_launch = true
  }
}

resource "aws_autoscaling_policy" "target_tracking" {
  name                   = "cpu-target-tracking"
  autoscaling_group_name = aws_autoscaling_group.web_asg.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value       = 60.0
    scale_out_cooldown = 60
    scale_in_cooldown  = 300
  }
}

混合インスタンスポリシー

複数のインスタンスタイプ + スポット + オンデマンド混在で、コストと可用性を最適化。

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name batch-asg-mixed \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "batch-worker-lt",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "c6i.xlarge", "WeightedCapacity": "1"},
        {"InstanceType": "c6a.xlarge", "WeightedCapacity": "1"},
        {"InstanceType": "c5.xlarge", "WeightedCapacity": "1"},
        {"InstanceType": "m6i.xlarge", "WeightedCapacity": "1"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "capacity-optimized",
      "SpotInstancePools": 4,
      "SpotMaxPrice": ""
    }
  }' \
  --min-size 2 \
  --max-size 20 \
  --desired-capacity 8 \
  --vpc-zone-identifier "subnet-aaa,subnet-bbb,subnet-ccc"

ポイント：

OnDemandBaseCapacity：2 台 = オンデマンド最小 2 台確保
OnDemandPercentageAboveBaseCapacity：20% = 2 台超過分の 20% がオンデマンド
- 例：10 台構成なら → オンデマンド 3 台（2 + 8×20%）、スポット 7 台
SpotAllocationStrategy：capacity-optimized = スポット中断リスク最小化
複数インスタンスタイプ：可用性向上 + スポット中断時のフォールバック

Warm Pool

停止中のインスタンスを事前準備。スケールアウト時に起動済みインスタンスを即座に利用。

aws autoscaling put-warm-pool \
  --auto-scaling-group-name web-asg-prod \
  --max-group-prepared-capacity 5 \
  --pool-state Stopped \
  --min-size 2

効果：

コールドスタート時間～ 2-5 分 → 数秒に短縮
起動後即座にトラフィック受信可能

コスト考慮：

Warm Pool インスタンスは 停止状態なので EBS 代金のみ（EC2 インスタンス代不要）
ただし EBS ボリュームは保持されるため、コスト削減効果は限定的

ライフサイクルフック

スケールアウト・スケールイン時にカスタムアクションを挿入。

起動時フック（Bootstrap）

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name web-asg-prod \
  --lifecycle-hook-name startup-hook \
  --lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING \
  --default-result CONTINUE \
  --heartbeat-timeout 300 \
  --notification-target-arn arn:aws:sqs:ap-northeast-1:123456789012:asg-lifecycle \
  --role-arn arn:aws:iam::123456789012:role/AutoScalingHookRole

終了時フック（Graceful Shutdown）

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name web-asg-prod \
  --lifecycle-hook-name termination-hook \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --default-result CONTINUE \
  --heartbeat-timeout 300 \
  --notification-target-arn arn:aws:sqs:ap-northeast-1:123456789012:asg-lifecycle

Lambda で処理

import boto3

def lambda_handler(event, context):
    asg_client = boto3.client('autoscaling')
    
    for record in event['Records']:
        message = json.loads(record['Sns']['Message'])
        instance_id = message['EC2InstanceId']
        asg_name = message['AutoScalingGroupName']
        hook_name = message['LifecycleHookName']
        token = message['LifecycleActionToken']
        
        # カスタム処理（ログダウンロード、接続wait等）
        print(f"Processing {instance_id}...")
        
        # 完了シグナル送信
        asg_client.complete_lifecycle_action(
            LifecycleHookName=hook_name,
            AutoScalingGroupName=asg_name,
            LifecycleActionToken=token,
            LifecycleActionResult='CONTINUE',
            InstanceId=instance_id
        )
    
    return {'statusCode': 200}

Instance Refresh

ローリング更新で新しい AMI・設定をデプロイ。

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name web-asg-prod \
  --preferences '{
    "MinHealthyPercentage": 90,
    "InstanceWarmup": 300,
    "CheckpointPercentages": [50],
    "StepSize": 2
  }'

パラメータ：

MinHealthyPercentage：90 = 常に 90% 以上を稼働状態に保つ
StepSize：2 = 2 台ずつ更新
CheckpointPercentages：[50] = 50% で一度停止（検証用）

Karpenter・Cluster Autoscaler との比較

項目	EC2 Auto Scaling	Karpenter	Cluster Autoscaler
対象	EC2 インスタンス（直接）	Kubernetes ノード	Kubernetes ノード
起動時間	2-5 分	60 秒以下	2-5 分
インスタンスタイプ選択	Node Group 単位	ポッド単位（最適化）	Node Group 単位
コスト削減	5-20%	20-40%（スポット活用）	5-20%
設定複雑度	低	高（Provisioner）	中
学習曲線	短	長	中
スポット対応	Mixed Instances Policy	ネイティブ	ASG 依存

使い分け

ECS on EC2：EC2 Auto Scaling（ASG）推奨
EKS：Karpenter 推奨（2025 以降主流）
セルフマネージド Kubernetes：Cluster Autoscaler

他の類似ツール・サービスとの比較

サービス	用途	特徴	コスト
EC2 Auto Scaling	EC2 インスタンス	ASG ベース、シンプル	無料 + インスタンス代
Karpenter	K8s ノード	ポッド単位最適化、高速	無料 + インスタンス代
ECS	コンテナオーケストレーション	ECS Capacity Provider 統合	無料 + インスタンス代
Fargate	サーバーレスコンテナ	完全マネージド	高（VCU ベース）
Lambda	関数実行	サーバーレス	従量課金
Spot Fleet	スポット最適化	EC2 Fleet API	インスタンス代のみ

ベストプラクティス

✅ 推奨される設定

項目	推奨	理由
起動テンプレート	Launch Template 使用	起動設定は非推奨（機能制限）
スケーリングポリシー	ターゲット追跡	自動冷却時間管理で簡潔
ヘルスチェック	ELB（ALB/NLB）	EC2 のみだと不十分
IMDSv2	必須設定	セキュリティ向上
マルチ AZ	Min Size ≥ AZ 数	可用性向上（3 AZ なら 3 以上）
スポット活用	Mixed Instances Policy	コスト 70% 削減
Warm Pool	重い起動時は有効化	コールドスタート緩和

❌ 避けるべきパターン

アンチパターン	問題	対策
起動設定の継続使用	機能制限（バージョン管理不可）	Launch Template に移行
スケジュールのみ	ピーク予測外の対応不可	ターゲット追跡と組み合わせ
スポット 100%	中断でサービス停止	オンデマンドベース確保
Desired を手動変更	スケーリングポリシー競合	ポリシーに任せる
ヘルスチェック Type = EC2	ALB が 503 返してもスケール不対応	Type = ELB に変更
クールダウン短すぎる	過剰スケール、コスト増	ターゲット追跡なら自動
予測スケーリングを新規 ASG に	履歴 14 日必要	2 週間待機後に有効化

トラブルシューティング

症状	原因	対策
スケールアウトしない	CPU が高いが増えない	ターゲット値確認、CloudWatch メトリクス確認
スケールイン遅い	スケールイン冷却が長い	冷却時間短縮（ターゲット追跡なら自動）
ヘルスチェック失敗で置換	ALB が 503 返却	アプリケーションログ確認、グレース期間延長
インスタンスが起動しない	Launch Template 参照失敗	最新バージョン確認
スポット中断で大量置換	スポット中断リスク高	Capacity Rebalancing 有効化
ライフサイクルフックタイムアウト	カスタム処理が遅い	ハートビート時間延長（最大 48 時間）
Desired を設定できない	Max Size 超過	Max Size 拡大
スケーリング通知が来ない	SNS/SQS 権限不足	IAM ロール確認

2025-2026 最新動向

1. Predictive Scaling の精度向上

機械学習モデルが進化し、ピーク 1 日前から事前スケール開始
AWS Forecast との統合が強化

2. Karpenter 主流化

Kubernetes クラスターでは Karpenter がデファクトスタンダードに
EC2 Auto Scaling は ECS・ALB ワークロード向けに特化

3. EKS Provisioned Control Plane

API スロットリング削除で大規模バースト対応向上
Karpenter + Provisioned Control Plane で超高速スケール

4. Capacity Rebalancing の強化

スポット中断予測の精度が向上
実装の容易性向上

5. ハイブリッド環境対応

AWS Outposts での Auto Scaling サポート拡大
オンプレ + AWS の統一スケーリングポリシー

学習リソース

公式ドキュメント

ブログ・ホワイトペーパー

セミナー・Workshop

実装例

シナリオ 1: 小規模 Web アプリケーション

# Terraform
resource "aws_launch_template" "web" {
  name_prefix = "web-"
  image_id    = data.aws_ami.al2.id
  instance_type = "t3.small"
  
  metadata_options {
    http_tokens = "required"
  }
}

resource "aws_autoscaling_group" "web" {
  min_size            = 2
  max_size            = 5
  desired_capacity    = 2
  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }
  vpc_zone_identifier = var.subnets
  target_group_arns   = [aws_lb_target_group.web.arn]
  health_check_type   = "ELB"
}

resource "aws_autoscaling_policy" "scale" {
  autoscaling_group_name = aws_autoscaling_group.web.name
  policy_type            = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 70.0
  }
}

シナリオ 2: 中規模バッチ処理（スポット最適化）

resource "aws_launch_template" "batch" {
  name_prefix = "batch-"
  image_id    = data.aws_ami.batch_image.id
  instance_type = "c6i.xlarge"
}

resource "aws_autoscaling_group" "batch" {
  min_size     = 1
  max_size     = 100
  launch_template {
    id      = aws_launch_template.batch.id
    version = "$Latest"
  }
  mixed_instances_policy {
    launch_template {
      overrides = [
        { instance_type = "c6i.xlarge" },
        { instance_type = "c6a.xlarge" },
        { instance_type = "m6i.xlarge" },
        { instance_type = "m6a.xlarge" }
      ]
    }
    instances_distribution {
      on_demand_base_capacity                  = 1
      on_demand_percentage_above_base_capacity = 10
      spot_allocation_strategy                 = "capacity-optimized"
    }
  }
}

シナリオ 3: 大規模本番環境（Warm Pool + 予測スケーリング）

resource "aws_autoscaling_group" "prod" {
  min_size         = 10
  max_size         = 200
  desired_capacity = 50
  launch_template {
    id      = aws_launch_template.prod.id
    version = "$Latest"
  }
  
  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group_warm_pool" "prod" {
  autoscaling_group_name = aws_autoscaling_group.prod.name
  max_group_prepared_capacity = 20
  pool_state = "Stopped"
}

resource "aws_autoscaling_policy" "predictive" {
  autoscaling_group_name = aws_autoscaling_group.prod.name
  policy_type            = "PredictiveScaling"
  predictive_scaling_configuration {
    metric_specification {
      target_value = 60.0
      predefined_metric_pair_specification {
        predefined_metric_type = "ASGCPUUtilization"
      }
    }
    mode = "ForecastAndScale"
  }
}

導入ロードマップ

フェーズ 1: 基本設定（1-2 週間）

Launch Template 作成
最小構成 ASG（min=2, max=5）
ターゲット追跡スケーリング（CPU 70%）
ALB + ターゲットグループ統合

フェーズ 2: 最適化（2-4 週間）

スケーリング動作の監視（CloudWatch）
ターゲット値調整（CPU 50-70%）
ヘルスチェックグレース期間最適化
冷却時間の検証

フェーズ 3: 高度な機能（1 ヶ月）

Warm Pool 導入（コールドスタート時間測定）
Mixed Instances Policy でスポット活用
Predictive Scaling 有効化（14 日データ待機）
ライフサイクルフック実装（カスタム処理）

フェーズ 4: 本番運用（継続）

CloudWatch アラーム監視
月次コスト分析
スケーリングポリシー見直し
ドキュメント・Runbook 更新

実装チェックリスト

設定チェック

[ ] Launch Template を使用（起動設定は非推奨）
[ ] IMDSv2 を有効化（メタデータ保護）
[ ] EBS 暗号化を有効化
[ ] マルチ AZ（min-size ≥ AZ 数）
[ ] ヘルスチェック = ELB（ECS/ALB 使用時）
[ ] グレース期間 = アプリ起動時間 + 100 秒

スケーリング設定

[ ] ターゲット追跡を使用（ステップスケーリング不要）
[ ] CPU ターゲット値 = 60-70%（アプリに応じて調整）
[ ] スケールアウト冷却 = 60 秒
[ ] スケールイン冷却 = 300 秒
[ ] 予測スケーリング有効化（14 日後）

セキュリティ

[ ] IAM インスタンスプロファイル設定
[ ] セキュリティグループ最小権限
[ ] ユーザーデータの Base64 エンコード
[ ] SNS/SQS 通知権限確認

運用監視

[ ] CloudWatch ダッシュボード作成
[ ] スケーリングアラーム設定
[ ] 月次コストレビュー
[ ] ドキュメント・Runbook 整備

まとめ

EC2 Auto Scaling は AWS における EC2 インスタンスの自動キャパシティ管理の最適解 です。

主要なポイント：

ターゲット追跡スケーリングが大多数のユースケースに対応
混合インスタンスポリシーでスポット活用により最大 70% コスト削減
Warm Pool でコールドスタート緩和
予測スケーリングで周期的パターンを事前対応
Kubernetes環境では Karpenter が新標準（2025 以降）

正しく設定すれば、コストと可用性の両立が実現可能。段階的な導入で、まずは基本設定から開始し、監視結果をもとに最適化を進めることを推奨します。

参考文献

AWS 公式ドキュメント

OSS・関連プロジェクト

ブログ・ホワイトペーパー

最終更新：2026-04-26
バージョン：v2.0

目次

Amazon EC2 Auto Scaling 完全ガイド v2.0

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の EC2 Auto Scaling エコシステム

定義

目次

概要

このサービスを選ぶ理由

Auto Scaling が解決する課題

主な特徴

アーキテクチャ

アーキテクチャ詳細

コアコンポーネント

1. Auto Scaling Group（ASG）

2. Launch Template（推奨）

3. スケーリングポリシー

ターゲット追跡スケーリング（推奨）

ステップスケーリング

スケジュールスケーリング

予測スケーリング

スケーリング戦略の詳細

ターゲット追跡 vs ステップスケーリング

スケーリング冷却時間（Cooldown）

主要ユースケース

1. Web アプリケーション（CPU ベーススケーリング）

2. 予測スケーリング（周期的パターン）

3. バッチ処理（スケジュール + 混合インスタンス）

4. ML 推論サーバー（スポット最適化）

5. API バックエンド（ALB ターゲットグループ）

6. ECS での DynamoDB テーブルスケーリング連携

7. IoT ゲートウェイ（Capacity Rebalancing）

8. 開発/ステージング環境（スケジュール + 停止）

9. マルチリージョン展開（リージョンごと ASG）

10. Spot Fleet との組み合わせ

設定・操作の具体例

CLI による ASG 作成（フル例）

CloudFormation による IaC

Terraform による IaC

混合インスタンスポリシー

Warm Pool

ライフサイクルフック

起動時フック（Bootstrap）

終了時フック（Graceful Shutdown）

Lambda で処理

Instance Refresh

Karpenter・Cluster Autoscaler との比較

使い分け

他の類似ツール・サービスとの比較

ベストプラクティス

✅ 推奨される設定

❌ 避けるべきパターン

トラブルシューティング

2025-2026 最新動向

1. Predictive Scaling の精度向上

2. Karpenter 主流化

3. EKS Provisioned Control Plane

4. Capacity Rebalancing の強化

5. ハイブリッド環境対応

学習リソース

公式ドキュメント

ブログ・ホワイトペーパー

セミナー・Workshop

実装例

シナリオ 1: 小規模 Web アプリケーション

シナリオ 2: 中規模バッチ処理（スポット最適化）

シナリオ 3: 大規模本番環境（Warm Pool + 予測スケーリング）

導入ロードマップ

フェーズ 1: 基本設定（1-2 週間）

フェーズ 2: 最適化（2-4 週間）

フェーズ 3: 高度な機能（1 ヶ月）

フェーズ 4: 本番運用（継続）

実装チェックリスト

設定チェック

スケーリング設定

セキュリティ

運用監視

まとめ

参考文献

AWS 公式ドキュメント