AWS Auto Scaling 完全ガイド v2.0

マルチサービス統合スケーリング・予測AI の包括的解説

ドキュメントの目的

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

初心者向け：AWS Auto Scaling とは何か、EC2 Auto Scaling との違いを学びたい方
DevOps エンジニア向け：Scaling Plans・Target Tracking・Predictive Scaling を実装したい方
インフラストラクチャ設計者向け：マルチサービス（EC2・ECS・DynamoDB・Aurora）統合管理を構築したい方
コスト最適化責任者向け：予測スケーリング・スケジュールスケーリングでコスト削減を実現したい方
エンタープライズアーキテクト向け：CloudFormation Stack 単位のスケーリング戦略を検討したい方

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

予測スケーリング（ML）の進化

機械学習による 14 日学習：過去 2 週間のトラフィックパターンから需要予測
Forecast and Scale モード：スケールアウト・スケールイン判定を予測で事前実行
複数トレンド対応：日次・週次・月次パターンの自動検出

横断スケーリング機能の拡張

Application Auto Scaling（DynamoDB・ECS・Aurora など非 EC2 リソース）との緊密統合
Karpenter との相互運用：Kubernetes（EKS）でのノードプール管理との連携

運用統合・可視化強化

CloudFormation Stack タグベース自動検出：Stack リソースの自動スケーリングプラン化
CloudWatch Insights 統合：スケーリングイベントの詳細分析
AWS Systems Manager OpsCenterとの統合：統一オペレーションダッシュボード

フリートマネージメントの最適化

Capacity Rebalancing：スポットインスタンス中断リスクの自動検知・置換
Warm Pools：起動時間高速化（コールドスタート緩和）

本質・定義
AWS Auto Scaling が解決する課題
EC2 Auto Scaling・Application Auto Scaling との関係
アーキテクチャ・スケーリング戦略
Scaling Plan の作成
ターゲット追跡スケーリング
予測スケーリング（Predictive Scaling）
スケジュールスケーリング
リソース自動検出
CloudFormation Stack 統合
主要ユースケース
設定・操作の具体例
CLI / SDK 実装例
監視・分析
Karpenter との比較
他のスケーリングサービス比較
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース・参考文献
実装例・チェックリスト
まとめ

本質・定義

AWS Auto Scaling は、「EC2 Auto Scaling・ECS・DynamoDB・Aurora・RDS・EMR など複数の AWS サービスのスケーリングを一元的な Scaling Plan で管理するサービス」。アプリケーション全体のキャパシティを最適化する上位レイヤーのスケーリング管理サービス。

簡潔な定義

「複数のAWSサービス（EC2・ECS・DynamoDB・Aurora等）のスケーリングを統合管理する Scaling Plan サービス。可用性・コスト・バランスの 3 つの最適化戦略で自動調整。」

料金：AWS Auto Scaling 自体は無料。ただし、スケーリングの対象となるリソース（EC2・DynamoDB RCU/WCU など）の実際のコストが発生。

AWS Auto Scaling が解決する課題

マルチサービスの整合性が取れない
- Web 層（EC2）・API 層（ECS）・DB 層（DynamoDB）で独立したスケーリング設定
- リソース間の依存関係・バランスが崩れる
- 解決：Scaling Plan で全体を一元管理
コスト vs 可用性のトレードオフ
- どの程度スケーリングすればよいか不明確
- 過度なプロビジョニング・キャパシティ不足
- 解決：「コスト優先」「可用性優先」「バランス」の戦略から選択
トラフィックスパイクへの事後対応
- スケールアウト指示が間に合わない
- 一時的な障害・パフォーマンス低下
- 解決：Predictive Scaling で ML 予測による事前スケール
複雑な手動スケーリング設定
- 複数リージョン・複数環境での設定の属人化
- メンテナンス・更新が煩雑
- 解決：Scaling Plan で統一的に管理
CloudFormation リソースの動的スケーリング
- Stack 内の複数リソースのスケーリング設定が分散
- 環境切り替え時のポリシー変更が面倒
- 解決：Tag / Stack ARN ベースの自動検出

EC2 Auto Scaling・Application Auto Scaling との関係

3 層のスケーリングサービス

┌─────────────────────────────────────────────────────┐
│ AWS Auto Scaling（統合管理層）                      │
│ ・複数サービスのスケーリングプラン一元管理          │
│ ・Predictive Scaling（ML 予測）                     │
│ ・戦略選択：コスト優先・可用性優先・バランス        │
└─────────────────────────────────────────────────────┘
                      ↓
        ┌─────────────┬──────────────┐
        ↓              ↓               ↓
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ EC2 Auto     │  │ Application  │  │ (その他)     │
│ Scaling      │  │ Auto Scaling │  │              │
├──────────────┤  ├──────────────┤  ├──────────────┤
│ 対象：       │  │ 対象：       │  │ 対象：       │
│ EC2 ASG      │  │ ECS・DynamoDB│  │ EMR・RDS     │
│              │  │ Aurora・Lambda│  │ AppStream    │
│ スケール：   │  │ SageMaker等  │  │              │
│ インスタンス数│  │ スケール：   │  │              │
│              │  │ キャパシティ │  │              │
└──────────────┘  └──────────────┘  └──────────────┘

使い分け

サービス	用途	対象リソース	発動トリガー
AWS Auto Scaling	複数サービスの統合管理	EC2・ECS・DynamoDB・Aurora 等	戦略ベース・Predictive・Schedule
EC2 Auto Scaling	EC2 インスタンス数の管理	EC2 Auto Scaling Group	CPU・Memory・CustomMetric
Application Auto Scaling	非 EC2 キャパシティ管理	DynamoDB・ECS・Aurora・Lambda	CPU・DynamoDB 利用率・CustomMetric

アーキテクチャ・スケーリング戦略

3 つのスケーリング戦略

┌─────────────────────────────────────────────┐
│ Optimize for Availability                   │
│ （可用性優先）                              │
├─────────────────────────────────────────────┤
│ ・ターゲット追跡設定値：高い（CPU 70% など）│
│ ・常に多めのキャパシティ確保                │
│ ・スケールインが遅い                        │
│ 用途：ミッションクリティカル・金融システム  │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│ Balance Availability and Cost               │
│ （バランス）                                │
├─────────────────────────────────────────────┤
│ ・ターゲット追跡設定値：中程度（CPU 50%）  │
│ ・可用性とコストのバランス                  │
│ 用途：標準的な Web アプリケーション         │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│ Optimize for Cost                           │
│ （コスト優先）                              │
├─────────────────────────────────────────────┤
│ ・ターゲット追跡設定値：低い（CPU 30% など）│
│ ・最小限のキャパシティ確保                  │
│ ・スケールイン・アウトが頻繁                │
│ 用途：開発・テスト環境・バッチ処理          │
└─────────────────────────────────────────────┘

Predictive Scaling の仕組み

Day 1-14: トラフィッグ履歴学習
├─ 日次パターン（営業時間 vs 夜間）
├─ 週次パターン（平日 vs 週末）
└─ 月次パターン（キャンペーン・季節変動）
                 ↓
        機械学習モデル作成
                 ↓
Day 15 以降：需要予測・事前スケール
├─ 予測トラフィック に基づき先制的にスケール
├─ スケールアウト：ウォームアップ前に完了
├─ スケールイン：需要低下に対応
└─ 結果：パフォーマンス低下・過度な遅延回避

Scaling Plan の作成

CloudFormation での Scaling Plan 作成

Resources:
  MyScalingPlan:
    Type: AWS::AutoScalingPlans::ScalingPlan
    Properties:
      ScalingPlanName: web-app-scaling-plan
      ApplicationSource:
        CloudFormationStackARN: arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-webapp/xxxxx
      ScalingInstructions:
        # EC2 Auto Scaling Group
        - ServiceNamespace: ec2
          ResourceId: autoScalingGroup/web-asg-prod
          ScalableDimension: autoscaling:autoScalingGroup:DesiredCapacity
          MinCapacity: 2
          MaxCapacity: 20
          TargetTrackingConfigurations:
            - PredefinedScalingMetricSpecification:
                PredefinedScalingMetricType: ASGAverageCPUUtilization
              TargetValue: 60.0
              EstimatedInstanceWarmup: 300
          PredictiveScalingMaxCapacityBehavior: SetForecastCapacityToMaxCapacity
          PredictiveScalingMode: ForecastAndScale
          ScalingPolicyUpdateBehavior: ReplaceExternalPolicies
        
        # ECS Service
        - ServiceNamespace: ecs
          ResourceId: service/my-cluster/api-service
          ScalableDimension: ecs:service:DesiredCount
          MinCapacity: 2
          MaxCapacity: 30
          TargetTrackingConfigurations:
            - PredefinedScalingMetricSpecification:
                PredefinedMetricType: ECSServiceAverageCPUUtilization
              TargetValue: 70.0
              ScaleOutCooldown: 60
              ScaleInCooldown: 300
        
        # DynamoDB テーブル（Write Capacity）
        - ServiceNamespace: dynamodb
          ResourceId: table/orders-table
          ScalableDimension: dynamodb:table:WriteCapacityUnits
          MinCapacity: 5
          MaxCapacity: 1000
          TargetTrackingConfigurations:
            - PredefinedScalingMetricSpecification:
                PredefinedMetricType: DynamoDBWriteCapacityUtilization
              TargetValue: 70.0
        
        # Aurora Cluster（Read Replica）
        - ServiceNamespace: rds
          ResourceId: cluster:my-aurora-cluster
          ScalableDimension: rds:cluster:ReadReplicaCount
          MinCapacity: 1
          MaxCapacity: 15
          TargetTrackingConfigurations:
            - PredefinedScalingMetricSpecification:
                PredefinedMetricType: RDSReaderAverageCPUUtilization
              TargetValue: 60.0

CLI での Scaling Plan 作成

aws autoscaling-plans create-scaling-plan \
  --scaling-plan-name web-app-scaling-plan \
  --application-source '{
    "CloudFormationStackARN": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-webapp/xxxxx"
  }' \
  --scaling-instructions '[
    {
      "ServiceNamespace": "ec2",
      "ResourceId": "autoScalingGroup/web-asg-prod",
      "ScalableDimension": "autoscaling:autoScalingGroup:DesiredCapacity",
      "MinCapacity": 2,
      "MaxCapacity": 20,
      "TargetTrackingConfigurations": [{
        "PredefinedScalingMetricSpecification": {
          "PredefinedScalingMetricType": "ASGAverageCPUUtilization"
        },
        "TargetValue": 60.0,
        "EstimatedInstanceWarmup": 300,
        "DisableScaleIn": false
      }],
      "PredictiveScalingMaxCapacityBehavior": "SetForecastCapacityToMaxCapacity",
      "PredictiveScalingMode": "ForecastAndScale",
      "ScalingPolicyUpdateBehavior": "ReplaceExternalPolicies"
    }
  ]'

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

マネージドスケーリングメトリクス

EC2 Auto Scaling 用：

・ASGAverageCPUUtilization
・ASGAverageNetworkIn
・ASGAverageNetworkOut
・ALBRequestCountPerTarget

ECS 用：

・ECSServiceAverageCPUUtilization
・ECSServiceAverageMemoryUtilization
・ALBRequestCountPerTarget
・AppScalingECSServiceAverageCPUUtilization

DynamoDB 用：

・DynamoDBReadCapacityUtilization
・DynamoDBWriteCapacityUtilization

Aurora 用：

・RDSReaderAverageCPUUtilization
・RDSReaderAverageDatabaseConnections

カスタムメトリクスでのターゲット追跡

# CloudWatch カスタムメトリクス定義
aws cloudwatch put-metric-data \
  --namespace MyApp \
  --metric-name QueueDepth \
  --value 100

# Scaling Plan でカスタムメトリクス利用
aws autoscaling-plans update-scaling-plan \
  --scaling-plan-name web-app-scaling-plan \
  --scaling-instructions '[
    {
      "ServiceNamespace": "sqs",
      "ResourceId": "queue/my-queue",
      "TargetTrackingConfigurations": [{
        "CustomizedScalingMetricSpecification": {
          "MetricName": "QueueDepth",
          "Namespace": "MyApp",
          "Statistic": "Average",
          "Unit": "Count"
        },
        "TargetValue": 50.0
      }]
    }
  ]'

予測スケーリング（Predictive Scaling）

必要なデータ・条件

履歴データ：14 日以上
一貫したパターン：日次・週次のトラフィック変動
十分なボリューム：スパースなパターンでは精度低下

モード別設定

モード	動作	用途
ForecastAndScale	予測値に基づきスケール実行	ライブ環境推奨
ForecastOnly	予測値のみ表示・スケール未実行	評価・テスト

# Predictive Scaling 有効化
aws autoscaling-plans update-scaling-plan \
  --scaling-plan-name web-app-scaling-plan \
  --scaling-instructions '[
    {
      "ServiceNamespace": "ec2",
      "ResourceId": "autoScalingGroup/web-asg-prod",
      "PredictiveScalingMode": "ForecastAndScale",
      "PredictiveScalingMaxCapacityBehavior": "SetForecastCapacityToMaxCapacity"
    }
  ]'

予測データの確認

aws autoscaling-plans get-scaling-plan-resource-forecast-data \
  --scaling-plan-name web-app-scaling-plan \
  --scaling-plan-version 1 \
  --service-namespace ec2 \
  --resource-id autoScalingGroup/web-asg-prod \
  --scalable-dimension autoscaling:autoScalingGroup:DesiredCapacity \
  --forecast-data-type CapacityForecast \
  --start-time "2026-04-20T00:00:00Z" \
  --end-time "2026-04-26T23:59:59Z"

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

定期的なスケーリング（夜間削減等）

aws autoscaling-plans update-scaling-plan \
  --scaling-plan-name dev-environment-scaling \
  --scaling-instructions '[
    {
      "ServiceNamespace": "ec2",
      "ResourceId": "autoScalingGroup/dev-asg",
      "ScalableDimension": "autoscaling:autoScalingGroup:DesiredCapacity",
      "MinCapacity": 1,
      "MaxCapacity": 10,
      "SchedulingInstructions": [
        {
          "SchedulableDimension": "autoscaling:autoScalingGroup:DesiredCapacity",
          "Schedule": "cron(0 18 * * MON-FRI *)",
          "StartTime": "2026-04-20T18:00:00Z",
          "EndTime": "2026-04-20T09:00:00Z",
          "ScalableTargetAction": {
            "MinCapacity": 0,
            "MaxCapacity": 2
          }
        }
      ]
    }
  ]'

リソース自動検出

CloudFormation Stack タグ検出

# Stack タグに基づく自動検出
aws autoscaling-plans create-scaling-plan \
  --scaling-plan-name stack-based-scaling \
  --application-source '{
    "TagFilters": [
      {
        "Key": "Environment",
        "Values": ["production"]
      },
      {
        "Key": "AutoScaling",
        "Values": ["enabled"]
      }
    ]
  }' \
  --scaling-instructions '[
    {
      "ServiceNamespace": "ec2",
      "ResourceId": "autoScalingGroup/*",
      "ScalableDimension": "autoscaling:autoScalingGroup:DesiredCapacity",
      "MinCapacity": 2,
      "MaxCapacity": 50,
      "TargetTrackingConfigurations": [{
        "PredefinedScalingMetricSpecification": {
          "PredefinedScalingMetricType": "ASGAverageCPUUtilization"
        },
        "TargetValue": 60.0
      }]
    }
  ]'

CloudFormation Stack 統合

Stack リソースの一元スケーリング

Resources:
  # CloudFormation Stack（複数リソース）
  MyWebappStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/my-bucket/webapp-template.yaml
      Parameters:
        Environment: production

  # Scaling Plan（Stack 内の全スケーラブルリソース自動管理）
  ScalingPlan:
    Type: AWS::AutoScalingPlans::ScalingPlan
    DependsOn: MyWebappStack
    Properties:
      ScalingPlanName: webapp-scaling
      ApplicationSource:
        CloudFormationStackARN: !Sub "arn:aws:cloudformation:${AWS::Region}:${AWS::AccountId}:stack/${MyWebappStack}/*"
      ScalingInstructions:
        - ServiceNamespace: ec2
          ResourceId: autoScalingGroup/web-asg
          ScalableDimension: autoscaling:autoScalingGroup:DesiredCapacity
          MinCapacity: 2
          MaxCapacity: 20
          TargetTrackingConfigurations:
            - PredefinedScalingMetricSpecification:
                PredefinedScalingMetricType: ASGAverageCPUUtilization
              TargetValue: 60.0

主要ユースケース

1. マイクロサービス 3 層アーキテクチャ

構成：Web（EC2）・API（ECS）・DB（DynamoDB）

Scaling Plan で統合管理
├─ Web EC2 ASG：CPU 60% ターゲット
├─ ECS Service：CPU 70% ターゲット
└─ DynamoDB WCU：70% ターゲット

2. e-commerce サイト（トラフィックスパイク対応）

シナリオ：セール時間帯の事前スケール

Predictive Scaling（14 日学習）
├─ 過去セール パターン学習
├─ セール開始 30 分前に自動スケール開始
└─ ピーク時のパフォーマンス保証

3. 開発・テスト環境（夜間コスト削減）

シナリオ：営業時間外のリソース最小化

Scheduled Scaling
├─ 平日 18:00-09:00：最小構成
├─ 土日：ストップ
└─ 月曜 09:00 復帰

4. リアルタイム分析（スケジュール + ターゲット追跡）

構成：バッチ処理と OLAP 並行実行

Scaling Plan
├─ 営業時間：ターゲット追跡（コスト優先）
├─ 営業終了後：スケジュール スケールアウト
└─ バッチ処理完了時：スケールイン

5. マルチリージョングローバルアプリ

構成：各リージョンでローカルスケーリング

各リージョンで独立した Scaling Plan
└─ Regional CloudWatch Metrics ベース

設定・操作の具体例

Scaling Plan の確認・更新

# Scaling Plan 一覧
aws autoscaling-plans describe-scaling-plans \
  --query 'ScalingPlans[*].[ScalingPlanName, ApplicationSource, CreationTime]'

# 特定の Scaling Plan 詳細
aws autoscaling-plans get-scaling-plan \
  --scaling-plan-name web-app-scaling-plan

# Scaling Instruction 確認
aws autoscaling-plans describe-scaling-plans \
  --scaling-plan-names web-app-scaling-plan \
  --query 'ScalingPlans[0].ScalingInstructions[*].[ServiceNamespace, ResourceId, TargetTrackingConfigurations]'

# Scaling Plan 削除
aws autoscaling-plans delete-scaling-plan \
  --scaling-plan-name web-app-scaling-plan \
  --scaling-plan-version 1

CLI / SDK 実装例

Python（Boto3）での統合管理

import boto3
from datetime import datetime

asg_plans = boto3.client('autoscaling-plans')
cloudwatch = boto3.client('cloudwatch')

def create_comprehensive_scaling_plan(stack_arn, plan_name):
    """
    CloudFormation Stack 内の複数リソースを
    一つの Scaling Plan で統合管理
    """
    
    response = asg_plans.create_scaling_plan(
        ScalingPlanName=plan_name,
        ApplicationSource={
            'CloudFormationStackARN': stack_arn
        },
        ScalingInstructions=[
            {
                'ServiceNamespace': 'ec2',
                'ResourceId': 'autoScalingGroup/web-asg',
                'ScalableDimension': 'autoscaling:autoScalingGroup:DesiredCapacity',
                'MinCapacity': 2,
                'MaxCapacity': 20,
                'TargetTrackingConfigurations': [{
                    'PredefinedScalingMetricSpecification': {
                        'PredefinedScalingMetricType': 'ASGAverageCPUUtilization'
                    },
                    'TargetValue': 60.0,
                    'EstimatedInstanceWarmup': 300
                }],
                'PredictiveScalingMode': 'ForecastAndScale'
            },
            {
                'ServiceNamespace': 'ecs',
                'ResourceId': 'service/cluster/api-service',
                'ScalableDimension': 'ecs:service:DesiredCount',
                'MinCapacity': 2,
                'MaxCapacity': 30,
                'TargetTrackingConfigurations': [{
                    'PredefinedScalingMetricSpecification': {
                        'PredefinedMetricType': 'ECSServiceAverageCPUUtilization'
                    },
                    'TargetValue': 70.0
                }]
            },
            {
                'ServiceNamespace': 'dynamodb',
                'ResourceId': 'table/orders',
                'ScalableDimension': 'dynamodb:table:WriteCapacityUnits',
                'MinCapacity': 5,
                'MaxCapacity': 1000,
                'TargetTrackingConfigurations': [{
                    'PredefinedScalingMetricSpecification': {
                        'PredefinedMetricType': 'DynamoDBWriteCapacityUtilization'
                    },
                    'TargetValue': 70.0
                }]
            }
        ]
    )
    
    print(f"Scaling Plan created: {response['ScalingPlanVersion']}")
    return response

def analyze_forecast_data(plan_name, days=7):
    """予測スケーリングデータの分析"""
    
    from datetime import timedelta
    
    end_time = datetime.utcnow()
    start_time = end_time - timedelta(days=days)
    
    response = asg_plans.get_scaling_plan_resource_forecast_data(
        ScalingPlanName=plan_name,
        ScalingPlanVersion=1,
        ServiceNamespace='ec2',
        ResourceId='autoScalingGroup/web-asg',
        ScalableDimension='autoscaling:autoScalingGroup:DesiredCapacity',
        ForecastDataType='CapacityForecast',
        StartTime=start_time,
        EndTime=end_time
    )
    
    # グラフ化用データ抽出
    for data_point in response['Datapoints']:
        timestamp = data_point['Timestamp']
        capacity = data_point['Value']
        print(f"{timestamp}: {capacity:.0f} instances")

# 使用例
stack_arn = "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-app/xxxxx"
create_comprehensive_scaling_plan(stack_arn, "my-app-scaling")
analyze_forecast_data("my-app-scaling")

監視・分析

CloudWatch Metrics（Scaling Plan）

監視対象メトリクス：

・GroupDesiredCapacity（目標キャパシティ）
・GroupInServiceInstances（稼働中インスタンス）
・GroupMinSize / GroupMaxSize（最小・最大）
・GroupTerminatingInstances（終了中インスタンス）

アラーム設定

# スケーリング失敗時アラーム
aws cloudwatch put-metric-alarm \
  --alarm-name scaling-plan-failure \
  --alarm-description "Alert when Scaling Plan fails" \
  --metric-name ScalingPlanFailures \
  --namespace AWS/AutoScalingPlans \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

Karpenter との比較

Kubernetes ノード管理

観点	AWS Auto Scaling	Karpenter
対象	AWS サービス（EC2・ECS・DynamoDB）	Kubernetes クラスター（EKS）
スケーリング単位	インスタンス数・キャパシティ	Pod・ノード
起動時間	~3-5 分	~10-60 秒
インスタンス型選択	ユーザー指定	Karpenter 最適化
統合管理	複数 AWS サービス	Kubernetes のみ
学習曲線	AWS 知識	Kubernetes + Karpenter

他のスケーリングサービス比較

サービス	用途	対象	スケール粒度
AWS Auto Scaling	複数サービス統合管理	EC2・ECS・DynamoDB・Aurora	サービス単位
EC2 Auto Scaling	EC2 インスタンス管理	EC2 ASG	インスタンス数
Application Auto Scaling	非 EC2 キャパシティ	ECS・DynamoDB・Aurora・Lambda	キャパシティユニット
Karpenter	Kubernetes ノード管理	EKS	Pod・ノード
Lambda 同時実行数制限	Lambda 関数スケーリング	Lambda	同時実行数

ベストプラクティス

✅ DO（推奨）

Scaling Plan で複数サービス一元管理
- CloudFormation Stack ARN でリソース自動検出
- タグベース検出で動的リソース追跡
Predictive Scaling 有効化
- 14 日以上の履歴学習後に ForecastAndScale 切り替え
- 予測トラフィックに対する事前スケール
スケーリング戦略の明確化
- 本番環境：可用性優先 or バランス
- 開発環境：コスト優先
- 政策ドキュメント化
ターゲット追跡の適切な閾値設定
- EC2 CPU：50-70%（インスタンスタイプ依存）
- ECS CPU：60-80%（コンテナオーバーヘッド考慮）
- DynamoDB：70-80%（スロットリング回避）
CloudWatch アラーム・監視
- スケーリング失敗・遅延検知
- 予測精度の定期確認
スケールイン・アウトクールダウン設定
- 不要なスケーリング振動回避
- アプリケーション初期化時間考慮
マルチリージョン・マルチ AZ 設計
- Regional Scaling Plan で各リージョン独立管理
- Cross-AZ 負荷分散考慮

❌ DON’T（非推奨）

Manual Scaling
- スケーリング判断の属人化
- 24/7 監視負担
過度にタイトなターゲット追跡
- スケーリング振動（Thrashing）
- 不安定なパフォーマンス
Predictive Scaling の過信
- 異常値・新規パターンに対応不可
- ターゲット追跡の並用必須
スケーリング計画なしの導入
- RTO / RPO 要件確認必須
- コスト予算確認
リソース制限の過小設定
- Max Capacity 不足でスケール限界到達

トラブルシューティング

現象	原因	解決方法
Scaling Plan スケール不発	CloudFormation Stack ARN 誤り・リソース非検出	Stack ARN 確認・タグ設定確認
Predictive Scaling 無効	履歴データ 14 日未満・パターン不規則	待機・ForecastOnly モードで検証
スケーリング遅延	メトリクス遅延・CloudWatch 評価ラグ	アラーム評価期間確認
不要な頻繁なスケーリング	ターゲット追跡閾値高い	閾値引き上げ・スケールイン遅延設定
DynamoDB スロットリング	キャパシティ不足・Predictive 精度低	Max WCU 引き上げ・ターゲット値引き上げ
ECS タスク起動失敗	EC2 キャパシティ枯渇・IAM 権限不足	EC2 スケール・IAM ロール確認

2025-2026 最新動向

1. Predictive Scaling の進化

複数トレンド対応：日次・週次・月次パターン自動検出
異常検知：通常と異なるパターン警告
精度向上：更新頻度増加（毎日学習）

2. 横断スケーリング機能の拡張

Application Auto Scaling との緊密統合
新対象サービス：Lambda・AppStream・EMR 等

3. 運用統合

CloudFormation Stack タグベース自動検出
CloudWatch Insights でスケーリングイベント分析
AWS Systems Manager OpsCenter 統合

4. フリートマネージメント最適化

Capacity Rebalancing：スポット中断リスク自動対応
Warm Pools：コールドスタート緩和

学習リソース・参考文献

AWS 公式ドキュメント（8+）

スケーリング・最適化リソース（5+）

実装例・チェックリスト

本番環境運用チェックリスト

[ ] Scaling Plan 設計：複数サービス統合・ターゲット値決定
[ ] Predictive Scaling：14 日履歴学習後に ForecastAndScale 切り替え
[ ] ターゲット追跡設定：適切な CPU・メモリ・カスタムメトリクス選択
[ ] CloudFormation 統合：Stack ARN 指定・タグベース検出
[ ] 監視・アラーム：CloudWatch Metrics・スケーリング失敗通知
[ ] RTO / RPO 確認：スケーリング遅延・復旧時間検証
[ ] コスト見積：Max Capacity での月額推定
[ ] ドキュメント：スケーリング戦略・ポリシー・アラーム手順
[ ] テスト：トラフィックスパイク・スケールイン・Predictive モード検証
[ ] IaC 化：CloudFormation で一元管理

実装シナリオ別ガイド

シナリオ 1：E-commerce サイト（トラフィックスパイク対応）

背景：セール・キャンペーン時のトラフィック 10-50 倍

Scaling Plan 構成：

ApplicationSource: CloudFormation Stack
├─ ScalingInstruction: EC2 ASG
│  ├─ TargetTracking: CPU 60%
│  ├─ PredictiveScaling: ForecastAndScale
│  │  └─ 14 日パターン学習 → セール 30 分前スケール
│  └─ Min: 2, Max: 100
├─ ScalingInstruction: ECS Service
│  ├─ TargetTracking: CPU 70%
│  └─ Min: 2, Max: 50
├─ ScalingInstruction: DynamoDB (Orders)
│  ├─ TargetTracking: WCU 70%
│  └─ Min: 100, Max: 10000
└─ ScalingInstruction: Aurora (Read Replica)
   ├─ TargetTracking: CPU 60%
   └─ Min: 1, Max: 10

効果：

Predictive Scaling：ピーク 30 分前にスケール開始
パフォーマンス維持：ウォームアップ待ちなし
コスト最適化：通常時は最小構成

シナリオ 2：SaaS サービス（複数テナント・多環境）

背景：顧客ごとに異なるリソース要件

マルチテナント Scaling Plan：

タグベース自動検出：
├─ 企業 A（Premium）
│  └─ Scaling Plan: CPU 70% ターゲット（可用性重視）
├─ 企業 B（Standard）
│  └─ Scaling Plan: CPU 50% ターゲット（バランス）
└─ 企業 C（Economy）
   └─ Scaling Plan: CPU 30% ターゲット（コスト重視）

CloudFormation Stack タグ：
─ Environment: production
─ Tier: premium / standard / economy
└─ AutoScaling: enabled

運用メリット：

タグに基づいて自動検出・スケーリング
ポリシー一元管理
顧客ティア別に最適化

シナリオ 3：バッチ処理・分析ワークロード（時間帯別スケーリング）

背景：営業終了後の大量データ処理

スケジュール + ターゲット追跡統合：

営業時間（8:00-18:00）
├─ EC2 ASG: Min 5, Max 20, CPU 50%
├─ ECS Service: Min 5, Max 30, CPU 60%
└─ DynamoDB WCU: 100-2000 ターゲット追跡

営業終了後（18:00-翌 8:00）
├─ EC2 ASG: Min 20 → Max 200（スケール アウト）
├─ ECS Service: Min 50 → Max 500（並列処理）
└─ DynamoDB WCU: 2000-10000（バッチ処理）

翌朝（8:00）
└─ 自動スケールイン → 通常構成

コスト削減：

オフピーク時に効率化（計算の集約）
ピーク時に完全リソース活用
年間 30-40% コスト削減

シナリオ 4：リアルタイムストリーミング分析

背景：常時トラフィック変動（IoT・ログ）

カスタムメトリクスターゲット追跡：

CloudWatch Custom Metric: KinesisRecordCount
├─ EC2 Kinesis Consumer: CPU + RecordCount 複合
├─ ECS Processor: RecordCount 50/秒 ターゲット
└─ DynamoDB: RecordCount 1000/秒 ターゲット

オートスケーリング：
├─ RecordCount 増加 → リアルタイムスケール
├─ Lag 減少 → 目標達成
└─ RecordCount 低下 → スケールイン

効果：

レイテンシ一定維持
リアルタイムデータ処理
予測不可能なトラフィク対応

まとめ

AWS Auto Scaling は 「複数 AWS サービスのスケーリングを統合管理する Scaling Plan サービス」。

主な特徴：

複数サービス（EC2・ECS・DynamoDB・Aurora）一元管理
3 つの最適化戦略（可用性・コスト・バランス）
Predictive Scaling で ML 予測スケーリング
CloudFormation Stack タグベース自動検出

2026 年の進化：

Predictive Scaling の精度向上（複数トレンド・異常検知）
Application Auto Scaling とのシームレス統合
CloudWatch Insights・Systems Manager との連携

推奨アーキテクチャ：

CloudFormation Stack → Scaling Plan（統合管理）
├─ EC2 ASG（CPU ターゲット追跡 + Predictive）
├─ ECS Service（CPU ターゲット追跡）
├─ DynamoDB（WCU ターゲット追跡 + Scheduled）
└─ Aurora（Read Replicas ターゲット追跡）

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

目次