Application Auto Scaling

Compute 以外のリソースのスケーリング基盤
概要
Application Auto Scaling が解決する課題
主な特徴
対応サービス完全リスト
アーキテクチャと基本概念
スケーリングポリシータイプ
Target Tracking Scaling 詳解
Step Scaling 詳解
Scheduled Scaling 詳解
ECS サービスのスケーリング
DynamoDB のスケーリング
Aurora のスケーリング
Lambda Provisioned Concurrency のスケーリング
SageMaker エンドポイントのスケーリング
その他サービスのスケーリング
カスタムメトリクスの活用
スケーリングポリシーの設計
EC2 Auto Scaling との比較
AWS Auto Scaling との関係
類似ツール・Karpenter との比較
ベストプラクティス
トラブルシューティング
近年の動向
学習リソース・参考文献
実装例・活用シーン
設計チェックリスト
まとめ

Compute 以外のリソースのスケーリング基盤

Application Auto Scaling は、「EC2 インスタンス以外の AWS サービス（ECS / DynamoDB / Aurora / Lambda / SageMaker / Comprehend 等）のキャパシティを自動的にスケールする統一サービス」 であり、Target Tracking Scaling / Step Scaling / Scheduled Scaling の 3 つのポリシータイプで、ECS タスク数・DynamoDB RCU/WCU・Aurora リードレプリカ・Lambda プロビジョニング済み同時実行数等を動的に管理します。EC2 Auto Scaling とは異なるサービスで、Compute 以外のマルチサービス対応のスケーリング基盤として機能します。このページでは Application Auto Scaling の概念・対応サービス・スケーリング戦略・近年の動向を体系的に整理します。

ドキュメント目的

このページでは以下を対象としています。

初心者向け： Application Auto Scaling とは何か、EC2 Auto Scaling との違いを学びたい方
開発者向け： ECS・Lambda・DynamoDB のスケーリングを実装したい方
SRE / インフラ向け： マルチサービス統合のスケーリング戦略
データエンジニア向け： DynamoDB・Aurora のプロビジョニング最適化
意思決定者向け： コスト最適化・パフォーマンス管理の効率化

2025-2026 年の Application Auto Scaling エコシステム

Predictive Scaling 拡張：ECS / DynamoDB への機械学習による予測スケーリング対応
カスタムメトリクス連携強化：CloudWatch Metrics Math / Logs Insights との統合
Karpenter 統合：ノード自動スケーリングとの連携（Fargate との棲み分け）
Step Functions Distributed Map との統合：動的スケーリング対応
リアルタイムダッシュボード：スケーリングイベントの CloudWatch ネイティブ可視化
クロスアカウントスケーリング：マルチアカウント環境でのスケーリング管理

概要

初心者向けメモ： Application Auto Scaling は「EC2 以外のマネージドサービスのスケーリング基盤」です。EC2 インスタンスをスケールするなら EC2 Auto Scaling を使いますが、ECS のタスク数・DynamoDB のキャパシティユニット・Aurora のリードレプリカ数・Lambda のプロビジョニング済み同時実行数等をスケールするには Application Auto Scaling が必要です。統一された API で複数サービスのスケーリングを一元管理できます。

Application Auto Scaling 公式定義：

「AWS サービスのリソース（ECS・DynamoDB・Aurora・Lambda 等）のスケーラブルなターゲットの容量を自動的に調整し、要求に応じてアプリケーションを拡張・縮小する」

参照：What is Application Auto Scaling

Application Auto Scaling が解決する課題

課題 1：非 EC2 リソースのスケーリングが複雑

❌ 従来の方法

ECS タスク数の調整を手動で行う（CloudWatch アラームの設定も複雑）
DynamoDB のプロビジョニング済みキャパシティを定期的に手動調整
Lambda のプロビジョニング済み同時実行数をコンソールで管理

✅ Application Auto Scaling 活用

# 統一 API でスケーリングポリシーを定義
aws application-autoscaling put-scaling-policy \
  --policy-name ecs-cpu-scaling \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    }
  }'

課題 2：EC2 Auto Scaling では対応できない

DynamoDB のスケーリングはプロビジョニングキャパシティ（RCU/WCU）で管理されており、EC2 インスタンス数とは異なるディメンションです。EC2 Auto Scaling API は EC2 インスタンスのみを対象としていますが、Application Auto Scaling はマルチサービス対応です。

課題 3：複数のスケーリング戦略を組み合わせたい

ビジネス要求により、時間帯に応じたスケーリング（スケジュール）+ 負荷応答型スケーリング（ターゲット追跡）を組み合わせたい場合があり、Application Auto Scaling で統一的に管理できます。

主な特徴

特徴	詳細
マルチサービス対応	ECS / DynamoDB / Aurora / Lambda / SageMaker 等、複数サービスを同一 API で管理
統一スケーリング API	`register-scalable-target` / `put-scaling-policy` で統一的にスケーリング設定
3 つのスケーリングポリシー	Target Tracking（推奨）/ Step Scaling / Scheduled Scaling
カスタムメトリクス対応	CloudWatch の任意のメトリクス（SQS キュー深さ等）をトリガー可能
スケーリング冷却期間設定	スケールアウト・スケールイン後の遅延を独立制御可能
Predictive Scaling（一部対応）	機械学習による予測的スケーリング（ECS / DynamoDB）
無料サービス	スケーリング自体に費用は発生しない（対象リソースの利用料のみ）

対応サービス完全リスト

Compute

ECS サービス（Fargate / EC2 起動タイプ）：タスク数（ecs:service:DesiredCount）
Fargate Spot キャパシティプロバイダー：キャパシティ（ecs:capacityprovider:DesiredTaskCount）
AppStream 2.0 フリート：インスタンス数（appstream:fleet:DesiredCapacity）

Database

DynamoDB テーブル：読み取り（dynamodb:table:ReadCapacityUnits）/ 書き込み（dynamodb:table:WriteCapacityUnits）キャパシティユニット
DynamoDB Global Secondary Index（GSI）：読み取り / 書き込みキャパシティ
Aurora DB クラスター：リードレプリカ数（rds:cluster:ReadReplicaCount）

Serverless / Functions

Lambda 関数：プロビジョニング済み同時実行数（lambda:function:ProvisionedConcurrentExecutions）
Comprehend：エンドポイントキャパシティユニット（comprehend:document-classifier-endpoint:DesiredInferenceUnits）

Data / Analytics

EMR（Elastic MapReduce）：マネージドスケーリング対応（コアノード数）
Kinesis Data Streams：読み取り / 書き込みキャパシティユニット（kinesis:stream:DesiredWriteCapacityUnits）

ML / Inference

SageMaker エンドポイント：インスタンス数（sagemaker:variant:DesiredInstanceCount）
SageMaker Serverless エンドポイント：同時実行数（sagemaker:variant:ServerlessProvisionedConcurrentExecutions）

Search / Analytics

OpenSearch ドメイン：ウォームノード数（opensearchservice:domain:DesiredWarmNodeCount）
OpenSearch Serverless コレクション：OCU（OpenSearch Compute Units）

Message Queue

AWS MSK（Managed Streaming for Kafka）：ブローカーノード数（MSK Serverless）

Custom Resources

カスタムリソース：独自アプリケーションで Application Auto Scaling API に登録したスケーラブルターゲット

アーキテクチャと基本概念

graph LR
    A["CloudWatch メトリクス"] --> B["Application Auto Scaling"]
    C["スケーリングポリシー"] --> B
    D["スケジュール"] --> B

    B --> E["スケーリング判定"]

    E --> F["Target Tracking"]
    E --> G["Step Scaling"]
    E --> H["Scheduled"]

    F --> I["ECS / DynamoDB / Aurora / Lambda / SageMaker / ..."]
    G --> I
    H --> I

    I --> J["リソースキャパシティ変更"]

    style B fill:#e6ffe6
    style I fill:#fff3cd

Core Concepts

Scalable Target：Application Auto Scaling で管理するリソースの特定のディメンション

# 例：ECS サービスの DesiredCount（タスク数）
# resource-id: service/cluster-name/service-name
# scalable-dimension: ecs:service:DesiredCount

Scaling Policy：スケーリングを決定するルール（ターゲット値・ステップ・スケジュール）
CloudWatch Metrics：スケーリング判定に使用するメトリクス（CPU / メモリ / カスタムメトリクス）
Cooldown Period：スケーリングイベント後の待機期間（スケールアウト / スケールイン独立）
Scalable Target Attribute：最小・最大キャパシティ、スケーリング冷却期間

スケーリングポリシータイプ

1. Target Tracking Scaling（推奨）

特徴： 指定した CloudWatch メトリクスをターゲット値に保つように自動スケーリング

{
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
  },
  "ScaleOutCooldown": 60,
  "ScaleInCooldown": 300
}

メリット：

複雑なステップルール設定不要（シンプル）
自動的に適切なスケーリング速度を計算
ターゲット値に向かって段階的にスケーリング
スケールイン保護あり（突発的なスケールインを防止）

デメリット：

細かいスケーリング挙動をカスタマイズしにくい

2. Step Scaling

特徴： CloudWatch アラームの違反度合いに応じてスケーリング（複数ステップ設定可能）

{
  "AdjustmentType": "PercentChangeInCapacity",
  "StepAdjustments": [
    {
      "MetricIntervalLowerBound": 0,
      "MetricIntervalUpperBound": 10,
      "ScalingAdjustment": 10
    },
    {
      "MetricIntervalLowerBound": 10,
      "ScalingAdjustment": 30
    }
  ]
}

メリット：

細かいスケーリング制御が可能
複数のアラーム条件に対応
スケールアウト / スケールインで異なるルール設定可能

デメリット：

ステップ設定が複雑
Target Tracking より手動調整の負荷が高い

3. Scheduled Scaling

特徴： 指定した日時でキャパシティを固定値に変更

aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/cluster/service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name "scale-up-business-hours" \
  --schedule "cron(0 9 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=10,MaxCapacity=30

メリット：

ビジネスパターンが既知（営業時間等）の場合に効果的
定期的な需要変動に対応

デメリット：

予期しない需要スパイクに対応できない
Target Tracking と組み合わせる場合の min/max 調整が必要

Target Tracking Scaling 詳解

Predefined Metrics（事前定義メトリクス）

各サービスで推奨される標準メトリクスが提供されています。

ECS

# CPU 利用率に基づいてスケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name ecs-cpu-tracking \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

DynamoDB

# 読み取りキャパシティ利用率
aws application-autoscaling put-scaling-policy \
  --policy-name dynamo-read-tracking \
  --service-namespace dynamodb \
  --resource-id table/my-table \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 600
  }'

Custom Metrics（カスタムメトリクス）

CloudWatch にパブリッシュした任意のメトリクスをターゲットに指定可能

# SQS キューの ApproximateNumberOfMessagesVisible をベースにスケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name ecs-queue-based-scaling \
  --service-namespace ecs \
  --resource-id service/my-cluster/worker-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS",
      "Statistic": "Average",
      "Dimensions": [
        {
          "Name": "QueueName",
          "Value": "my-worker-queue"
        }
      ]
    },
    "ScaleOutCooldown": 30,
    "ScaleInCooldown": 300
  }'

ターゲット値の設定

メトリクス	推奨ターゲット値	理由
CPU 利用率	60～80%	100%に近づくと処理遅延のリスク
メモリ利用率	70～80%	メモリは予測しにくいため少し余裕
SQS キュー深さ	10～50（タスク当たり）	キューの長さ / 期待タスク数
Lambda 同時実行	0.7 倍の予約容量	予約容量に対して 70%
DynamoDB RCU/WCU	70%	利用率が高すぎると throttle のリスク

Step Scaling 詳解

Step Scaling ルールの構造

# 複数のステップを定義してきめ細かいスケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name ecs-step-scaling \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type StepScaling \
  --step-scaling-policy-configuration '{
    "AdjustmentType": "PercentChangeInCapacity",
    "MetricAggregationType": "Average",
    "Cooldown": 300,
    "StepAdjustments": [
      {
        "MetricIntervalLowerBound": 0,
        "MetricIntervalUpperBound": 10,
        "ScalingAdjustment": 10
      },
      {
        "MetricIntervalLowerBound": 10,
        "MetricIntervalUpperBound": 20,
        "ScalingAdjustment": 20
      },
      {
        "MetricIntervalLowerBound": 20,
        "ScalingAdjustment": 30
      }
    ]
  }'

MetricIntervalBound の解釈

CPU 利用率が基準値（80%）を超えた場合のステップ：

超過分 0～10%   → +10% スケール
超過分 10～20%  → +20% スケール
超過分 20%以上  → +30% スケール

# つまり CPU が 85% なら → 5% 超過 → +10% スケール
# CPU が 95% なら → 15% 超過 → +20% スケール
# CPU が 105% なら → 25% 超過 → +30% スケール

Scheduled Scaling 詳解

Cron Expression での時間指定

# 平日朝 8 時に容量を増やす
cron(0 8 ? * MON-FRI *)

# 平日夜 18 時に元に戻す
cron(0 18 ? * MON-FRI *)

# 土日は最小容量
cron(0 0 ? * SAT,SUN *)

# 毎月 1 日深夜に定期スケーリング
cron(0 2 1 * ? *)

スケジュールスケーリング設定例

# ビジネスアワーズ：容量アップ
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/cluster/web-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name "business-hours-scale-up" \
  --schedule "cron(0 8 ? * MON-FRI *)" \
  --timezone "Asia/Tokyo" \
  --scalable-target-action MinCapacity=10,MaxCapacity=50

# オフアワーズ：容量ダウン
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/cluster/web-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name "after-hours-scale-down" \
  --schedule "cron(0 20 ? * MON-FRI *)" \
  --timezone "Asia/Tokyo" \
  --scalable-target-action MinCapacity=2,MaxCapacity=10

ECS サービスのスケーリング

Fargate サービスのスケーリング完全例

#!/bin/bash

CLUSTER_NAME="production-cluster"
SERVICE_NAME="web-service"
REGION="ap-northeast-1"

# 1. スケーラブルターゲットの登録
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/$CLUSTER_NAME/$SERVICE_NAME \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 20 \
  --region $REGION

# 2. CPU ターゲット追跡ポリシー
aws application-autoscaling put-scaling-policy \
  --policy-name "${SERVICE_NAME}-cpu-tracking" \
  --service-namespace ecs \
  --resource-id service/$CLUSTER_NAME/$SERVICE_NAME \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }' \
  --region $REGION

# 3. メモリ利用率ポリシー（オプション）
aws application-autoscaling put-scaling-policy \
  --policy-name "${SERVICE_NAME}-memory-tracking" \
  --service-namespace ecs \
  --resource-id service/$CLUSTER_NAME/$SERVICE_NAME \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 80.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageMemoryUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }' \
  --region $REGION

# 4. スケジュールスケーリング：営業時間帯
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/$CLUSTER_NAME/$SERVICE_NAME \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name "business-hours" \
  --schedule "cron(0 9 ? * MON-FRI *)" \
  --timezone "Asia/Tokyo" \
  --scalable-target-action MinCapacity=10,MaxCapacity=30 \
  --region $REGION

# 5. スケジュールスケーリング：オフアワーズ
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/$CLUSTER_NAME/$SERVICE_NAME \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name "off-hours" \
  --schedule "cron(0 18 ? * MON-FRI *)" \
  --timezone "Asia/Tokyo" \
  --scalable-target-action MinCapacity=2,MaxCapacity=5 \
  --region $REGION

スケーリングポリシーの確認・削除

# スケーリングポリシー一覧確認
aws application-autoscaling describe-scaling-policies \
  --service-namespace ecs \
  --query 'ScalingPolicies[?ResourceId==`service/production-cluster/web-service`]'

# スケーリングポリシー削除
aws application-autoscaling delete-scaling-policy \
  --policy-name "web-service-cpu-tracking" \
  --service-namespace ecs \
  --resource-id service/production-cluster/web-service \
  --scalable-dimension ecs:service:DesiredCount

DynamoDB のスケーリング

DynamoDB 読み取りスケーリング設定

#!/bin/bash

TABLE_NAME="orders-table"

# 1. スケーラブルターゲット登録
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/$TABLE_NAME \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --min-capacity 10 \
  --max-capacity 40000

# 2. 読み取りキャパシティのターゲット追跡スケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name "${TABLE_NAME}-read-scaling" \
  --service-namespace dynamodb \
  --resource-id table/$TABLE_NAME \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 600
  }'

# 3. 読み取り用スケジュールスケーリング（夜間に最小化）
aws application-autoscaling put-scheduled-action \
  --service-namespace dynamodb \
  --resource-id table/$TABLE_NAME \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --scheduled-action-name "reduce-read-capacity-night" \
  --schedule "cron(0 22 ? * * *)" \
  --timezone "Asia/Tokyo" \
  --scalable-target-action MinCapacity=10,MaxCapacity=100

# 4. 夜明けに容量復帰
aws application-autoscaling put-scheduled-action \
  --service-namespace dynamodb \
  --resource-id table/$TABLE_NAME \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --scheduled-action-name "restore-read-capacity-morning" \
  --schedule "cron(0 6 ? * * *)" \
  --timezone "Asia/Tokyo" \
  --scalable-target-action MinCapacity=100,MaxCapacity=40000

DynamoDB Global Secondary Index (GSI) のスケーリング

# GSI の読み取りキャパシティをスケーリング
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/orders-table/index/gsi-by-customer \
  --scalable-dimension dynamodb:index:ReadCapacityUnits \
  --min-capacity 10 \
  --max-capacity 40000

aws application-autoscaling put-scaling-policy \
  --policy-name "orders-gsi-read-scaling" \
  --service-namespace dynamodb \
  --resource-id table/orders-table/index/gsi-by-customer \
  --scalable-dimension dynamodb:index:ReadCapacityUnits \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
    }
  }'

Aurora のスケーリング

Aurora Read Replica のスケーリング

#!/bin/bash

DB_CLUSTER_IDENTIFIER="production-aurora-cluster"

# 1. リードレプリカ数のスケーラブルターゲット登録
aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --resource-id cluster:$DB_CLUSTER_IDENTIFIER \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 1 \
  --max-capacity 15

# 2. CPU 利用率に基づいてリードレプリカを自動増減
aws application-autoscaling put-scaling-policy \
  --policy-name "${DB_CLUSTER_IDENTIFIER}-read-replica-scaling" \
  --service-namespace rds \
  --resource-id cluster:$DB_CLUSTER_IDENTIFIER \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "RDSReaderAverageCPUUtilization"
    },
    "ScaleOutCooldown": 300,
    "ScaleInCooldown": 600
  }'

Aurora Serverless v2 の ACU（Aurora Capacity Units）自動スケーリング

Aurora Serverless v2 では、Application Auto Scaling により ACU を自動的に調整できます。

# Aurora Serverless v2 のスケーラブルターゲット登録
aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --resource-id cluster:serverless-v2-cluster \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 0.5 \
  --max-capacity 32

Lambda Provisioned Concurrency のスケーリング

#!/bin/bash

FUNCTION_NAME="payment-processor"
FUNCTION_ARN="arn:aws:lambda:ap-northeast-1:123456789012:function:$FUNCTION_NAME"

# 1. プロビジョニング済み同時実行数のスケーラブルターゲット登録
aws application-autoscaling register-scalable-target \
  --service-namespace lambda \
  --resource-id "$FUNCTION_ARN:provisioned" \
  --scalable-dimension lambda:function:ProvisionedConcurrentExecutions \
  --min-capacity 10 \
  --max-capacity 1000

# 2. Lambda の Invocations per Second に基づいてスケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name "${FUNCTION_NAME}-provisioned-concurrency" \
  --service-namespace lambda \
  --resource-id "$FUNCTION_ARN:provisioned" \
  --scalable-dimension lambda:function:ProvisionedConcurrentExecutions \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 0.7,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

SageMaker エンドポイントのスケーリング

#!/bin/bash

ENDPOINT_NAME="recommendation-model-prod"
VARIANT_NAME="AllTraffic"

# 1. エンドポイントバリアントのスケーラブルターゲット登録
aws application-autoscaling register-scalable-target \
  --service-namespace sagemaker \
  --resource-id "endpoint/$ENDPOINT_NAME/variant/$VARIANT_NAME" \
  --scalable-dimension sagemaker:variant:DesiredInstanceCount \
  --min-capacity 1 \
  --max-capacity 10

# 2. 推論リクエストレートに基づいてスケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name "${ENDPOINT_NAME}-instance-scaling" \
  --service-namespace sagemaker \
  --resource-id "endpoint/$ENDPOINT_NAME/variant/$VARIANT_NAME" \
  --scalable-dimension sagemaker:variant:DesiredInstanceCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 1000.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 600
  }'

その他サービスのスケーリング

AppStream 2.0 フリートのスケーリング

aws application-autoscaling register-scalable-target \
  --service-namespace appstream \
  --resource-id fleet/graphics-fleet \
  --scalable-dimension appstream:fleet:DesiredCapacity \
  --min-capacity 2 \
  --max-capacity 100

aws application-autoscaling put-scaling-policy \
  --policy-name "appstream-fleet-scaling" \
  --service-namespace appstream \
  --resource-id fleet/graphics-fleet \
  --scalable-dimension appstream:fleet:DesiredCapacity \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 75.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "AppStreamAverageCapacityUtilization"
    }
  }'

OpenSearch Serverless コレクションのスケーリング

OpenSearch Serverless は自動的にスケーリングされ、Application Auto Scaling による追加設定は不要です。OCU（OpenSearch Compute Units）が自動に調整されます。

Kinesis Data Streams のスケーリング

aws application-autoscaling register-scalable-target \
  --service-namespace kinesis \
  --resource-id stream/event-stream \
  --scalable-dimension kinesis:stream:DesiredWriteCapacityUnits \
  --min-capacity 10 \
  --max-capacity 4000

aws application-autoscaling put-scaling-policy \
  --policy-name "kinesis-write-scaling" \
  --service-namespace kinesis \
  --resource-id stream/event-stream \
  --scalable-dimension kinesis:stream:DesiredWriteCapacityUnits \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "KinesisStreamDesiredWriteCapacityUtilization"
    }
  }'

カスタムメトリクスの活用

SQS キュー深さに基づくスケーリング

# CloudWatch カスタムメトリクスを使用した ECS スケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name "ecs-sqs-depth-scaling" \
  --service-namespace ecs \
  --resource-id service/cluster/worker \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS",
      "Statistic": "Average",
      "Dimensions": [
        {
          "Name": "QueueName",
          "Value": "task-queue"
        }
      ]
    },
    "ScaleOutCooldown": 30,
    "ScaleInCooldown": 300
  }'

ビジネスメトリクスに基づくスケーリング

# アプリケーションから CloudWatch にカスタムメトリクスをパブリッシュ
aws cloudwatch put-metric-data \
  --namespace "CustomApp" \
  --metric-name "OrdersPerSecond" \
  --value 150 \
  --unit Count

# このメトリクスをベースにスケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name "custom-orders-scaling" \
  --service-namespace ecs \
  --resource-id service/cluster/order-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 100.0,
    "CustomizedMetricSpecification": {
      "MetricName": "OrdersPerSecond",
      "Namespace": "CustomApp",
      "Statistic": "Average"
    }
  }'

スケーリングポリシーの設計

設計の 7 つのステップ

リソースとディメンション特定：ECS / DynamoDB など、何をスケールするか
最小・最大キャパシティ決定：ビジネス要件・コスト制約から決定
スケーリング戦略選択：Target Tracking / Step / Scheduled のいずれか
ターゲット値設定：リソースタイプごとの推奨値から開始
冷却期間設定：スケールアウト < スケールインで安定性重視
テストと監視：本番投入前に非本番環境で検証
継続的改善：CloudWatch メトリクスから調整

冷却期間（Cooldown）の設定

# 推奨ガイドライン
ECS: ScaleOutCooldown=60秒, ScaleInCooldown=300秒
DynamoDB: ScaleOutCooldown=60秒, ScaleInCooldown=600秒
Lambda: ScaleOutCooldown=60秒, ScaleInCooldown=300秒

# 理由：スケールイン冷却を長く設定して、スパイク後の段階的な縮小を防止

EC2 Auto Scaling との比較

観点	EC2 Auto Scaling	Application Auto Scaling
対象	EC2 インスタンス	ECS / DynamoDB / Aurora / Lambda 等
スケーリング単位	インスタンス数	タスク数 / RCU/WCU / ACU 等
API 名前空間	`autoscaling`	`application-autoscaling`
主要用途	仮想マシンのスケーリング	マネージドサービスの容量管理
Predictive Scaling	✅対応	✅一部対応（ECS / DynamoDB）
ターゲット追跡	✅対応	✅対応（推奨）
スケジュールスケーリング	✅対応	✅対応
スケーリングポリシー上限	ASG 当たり 50	1 リソース当たり複数可能

AWS Auto Scaling との関係

AWS Auto Scaling は Application Auto Scaling 上位のサービスで、複数リソース・複数サービスのスケーリングを一元管理します。

# AWS Auto Scaling で複数の Application Auto Scaling ポリシーを一括管理
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name "multi-resource-group" \
  --resources "ecs-service,dynamodb-table" \
  --scaling-instruction '{
    "ServiceNamespace": "ecs",
    "TargetTrackingConfiguration": {...}
  }'

類似ツール・Karpenter との比較

ツール	対象	用途	特徴
EC2 Auto Scaling	EC2 インスタンス	インスタンス数の自動調整	AWS ネイティブ、信頼性高
Application Auto Scaling	非 EC2 リソース	マネージドサービスの容量管理	統一 API、カスタムメトリクス対応
Karpenter	EKS ノード	K8s クラスタのノード自動スケーリング	高速、コスト最適化、Spot 対応
KEDA（Kubernetes Event Driven Autoscaling）	K8s Pod	イベント駆動の Pod スケーリング	K8s 標準、外部メトリクス対応
HPA（Horizontal Pod Autoscaler）	K8s Pod	CPU / メモリに基づく Pod スケーリング	K8s 標準、基本機能

Karpenter vs Application Auto Scaling

EKS クラスタの場合：

Application Auto Scaling：
  → ECS on Fargate の場合はこちら
  → ノードではなくタスク数をスケール

Karpenter：
  → EKS の EC2 ノードをスケール
  → Pod 数ではなくノード容量を確保
  → Spot インスタンス活用で大幅コスト削減

ベストプラクティス

✅ やるべきこと

Target Tracking Scaling から開始

# Step Scaling より簡単で効果的
PredefinedMetricType で事前定義メトリクスを使用

冷却期間はスケールイン > スケールアウト

# スケールアウト：60秒
# スケールイン：300～600秒（スパイク後の安定待機）

最大キャパシティにはビジネスバッファを含める

# 想定最大需要 × 1.2～1.5
# 予期しないスパイクに対応可能

CloudWatch ダッシュボードで常時監視

# スケーリングイベントの頻度
# ターゲット値との乖離
# 冷却期間中のイベント

定期的にターゲット値を見直し

# 3～6 ヶ月ごとに実績データを分析
# CPU 70% が妥当か、80% でいいか確認

❌ やってはいけないこと

Step Scaling を複雑に設定しすぎ

# ステップが 5 個以上になったら設計を見直す
# Target Tracking に置き換えることを検討

スケールイン冷却を短すぎるに設定

# 30秒でスケールインすると、スパイク直後に急縮小
# ユーザーエクスペリエンス低下

最小キャパシティを動的に変更

# 最小値は固定にして、スケジュールスケーリングで min/max を調整

複数のスケーリングポリシーを混在させすぎ

# Target Tracking + Scheduled + Step を同時設定すると予測不可
# 基本は Target Tracking + Scheduled の組み合わせ

アラーム設定なしでのデプロイ

# CloudWatch アラーム（スケーリング異常・スケール失敗）を必ず設定

トラブルシューティング

Issue 1：スケーリングが起動しない

# 原因確認
1. スケーラブルターゲットが正しく登録されているか
aws application-autoscaling describe-scalable-targets \
  --service-namespace ecs \
  --query 'ScalableTargets[?ResourceId==`service/cluster/service`]'

2. スケーリングポリシーが存在するか
aws application-autoscaling describe-scaling-policies \
  --service-namespace ecs

3. IAM ロール権限
# AWS::ApplicationAutoScaling::Role が作成されているか確認
aws iam get-role --role-name ApplicationAutoscalingECSRole

4. CloudWatch メトリクスが到着しているか
aws cloudwatch get-metric-statistics \
  --namespace AWS/ECS \
  --metric-name CPUUtilization \
  --dimensions Name=ServiceName,Value=my-service

Issue 2：スケールインが激しすぎる

# 原因と対策
1. スケールイン冷却期間を延長
   ScaleInCooldown: 300秒 → 600秒

2. ターゲット値を下げる（スケールインまでの時間短縮）
   TargetValue: 70% → 80%

3. Step Scaling を使用して段階的な縮小
   最小削減幅を 10% に設定

Issue 3：ターゲット値に到達しない

# 原因確認
1. 最大キャパシティに達しているか
aws application-autoscaling describe-scalable-targets \
  --service-namespace ecs \
  --query 'ScalableTargets[0].{Current:CurrentCapacity,Max:MaxCapacity}'

2. スケールアウト冷却期間中か
   CloudWatch で ScalingActivity イベントを確認
   https://console.aws.amazon.com/cloudwatch → Logs

3. リソース側の制限
   ECS タスク：クラスター内のキャパシティ不足
   DynamoDB：パーティション限界
   Lambda：リージョンの同時実行数上限

Issue 4：意図しないスケーリングが発生

# 原因確認
1. スケジュールスケーリングがアクティブか
aws application-autoscaling describe-scheduled-actions \
  --service-namespace ecs

2. Predictive Scaling が有効か
aws application-autoscaling describe-scaling-policies \
  --service-namespace ecs \
  --query 'ScalingPolicies[?PredictiveScalingPolicyConfiguration]'

3. タイムゾーン設定が正確か
   Asia/Tokyo（UTC+9）で設定しているか確認

4. CloudWatch アラーム設定を確認
   誤った Threshold で アラームが起動していないか

Issue 5：コスト削減効果が見られない

# 確認ポイント
1. 実際のスケーリングが発生しているか
   CloudWatch Logs に ScaleOutActivities / ScaleInActivities が記録されているか

2. スケールイン冷却期間が長すぎないか
   600秒（10分）以上の冷却で、スケールインが稀に

3. 最小キャパシティが高すぎないか
   min_capacity を下げて、非ピーク時に 1～2 に設定

4. ターゲット値設定が妥当か
   CPU 70% では常に高めの状態
   → CPU 80% に上げると、より低く維持される場合もある

# スケーリング履歴から実績を分析
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationAutoScaling \
  --metric-name GroupDesiredCapacity \
  --dimensions Name=AutoScalingGroupName,Value=my-resource \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-31T23:59:59Z \
  --period 86400 \
  --statistics Average

近年の動向

1. Predictive Scaling の拡張

AWS は機械学習により、過去 14 日間のメトリクスから需要を予測し、事前にスケーリングする Predictive Scaling を ECS / DynamoDB に展開。

# Predictive Scaling の有効化（2025）
aws application-autoscaling put-scaling-policy \
  --policy-name "predictive-ecs-scaling" \
  --service-namespace ecs \
  --resource-id service/cluster/service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "PredictiveScalingMaxCapacityBehavior": "SetMaxCapacityAboveMaxCapacity"
  }'

2. カスタムメトリクス機械学習フィルター

CloudWatch Logs Insights から自動抽出したメトリクスを Application Auto Scaling に統合

3. Karpenter との統合

Karpenter で EKS ノードをスケーリング、ECS on Fargate で Application Auto Scaling を使用する統一デザインパターンが確立

4. クロスアカウントスケーリング

AWS Organizations 経由でマルチアカウント環境での一元的なスケーリング管理

学習リソース・参考文献

AWS 公式資料

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

サードパーティ・OSS

実装例・活用シーン

シーン 1：E-Commerce 注文処理システム

# 時間帯別スケーリング + 負荷応答スケーリング

# 業務時間：最小 20、最大 100 タスク
# 営業時間帯：最小 10、最大 50 タスク
# オフアワーズ：最小 2、最大 10 タスク

# 加えて CPU 70% で自動スケーリング

シーン 2：リアルタイムデータ分析

# Kinesis Data Streams + DynamoDB

# 書き込み容量を自動スケーリング
# 予期しない需要スパイクに対応
# スケールイン冷却を長めに設定（データ一貫性重視）

シーン 3：機械学習推論エンドポイント

# SageMaker エンドポイント
# リクエストレート（Invocations Per Instance）を監視
# スケールアウト：60秒（モデル初期化）
# スケールイン：600秒（突発需要への対応）

設計チェックリスト

[ ] 対象リソース・ディメンションが正しく特定されているか
[ ] 最小・最大キャパシティがビジネス・技術要件に合致しているか
[ ] スケーリングポリシータイプ（Target / Step / Scheduled）が適切か
[ ] ターゲット値が各リソースタイプの推奨値か（CPU 70%、メモリ 75% 等）
[ ] スケールアウト冷却 < スケールイン冷却で設定されているか
[ ] CloudWatch メトリクス・ダッシュボードが設定済みか
[ ] アラーム（スケーリング失敗・異常スケーリング）が設定済みか
[ ] 非本番環境で十分なテストが実施されたか
[ ] IAM ロール（ApplicationAutoscalingECSRole 等）が作成されているか
[ ] 定期的な見直し（3～6 ヶ月）スケジュール設定済みか
[ ] 緊急時のスケーリング手動介入手順が文書化されているか
[ ] コスト監視メトリクス（利用キャパシティ vs 費用）が設定済みか

まとめ

Application Auto Scaling は 「EC2 以外の AWS マネージドサービスのキャパシティを統一 API で自動管理するサービス」。ECS タスク数・DynamoDB RCU/WCU・Aurora リードレプリカ・Lambda プロビジョニング済み同時実行数等を、Target Tracking / Step / Scheduled の 3 つのポリシータイプで動的に調整します。

採用メリット：

複数リソース・複数サービスの統一管理
カスタムメトリクスによる柔軟なスケーリング
ビジネス要件（スケジュール）+ 技術要件（負荷）の両立
コスト最適化（非利用時間帯の自動縮小）
予測的スケーリング（機械学習）による先制対応

設計のコツ：

Target Tracking Scaling からスタート（簡潔）
スケールイン冷却をスケールアウトより長く設定（安定性）
ターゲット値を各サービスの推奨値から開始（CPU 70% など）
CloudWatch ダッシュボードで常時監視（改善ループ）
3～6 ヶ月ごとに実績データから調整

Application Auto Scaling は、サーバーレス・マネージドサービス中心のモダンアーキテクチャで必須のコンポーネント。EC2 Auto Scaling と組み合わせることで、エンタープライズ級のマルチレイヤースケーリング基盤が実現できます。

Application Auto Scaling

目次

Compute 以外のリソースのスケーリング基盤

ドキュメント目的

2025-2026 年の Application Auto Scaling エコシステム

概要

Application Auto Scaling が解決する課題

課題 1：非 EC2 リソースのスケーリングが複雑

課題 2：EC2 Auto Scaling では対応できない

課題 3：複数のスケーリング戦略を組み合わせたい

主な特徴

対応サービス完全リスト

Compute

Database

Serverless / Functions

Data / Analytics

ML / Inference

Search / Analytics

Message Queue

Custom Resources

アーキテクチャと基本概念

Core Concepts

スケーリングポリシータイプ

1. Target Tracking Scaling（推奨）

2. Step Scaling

3. Scheduled Scaling

Target Tracking Scaling 詳解

Predefined Metrics（事前定義メトリクス）

ECS

DynamoDB

Custom Metrics（カスタムメトリクス）

ターゲット値の設定

Step Scaling 詳解

Step Scaling ルールの構造

MetricIntervalBound の解釈

Scheduled Scaling 詳解

Cron Expression での時間指定

スケジュールスケーリング設定例

ECS サービスのスケーリング

Fargate サービスのスケーリング完全例

スケーリングポリシーの確認・削除

DynamoDB のスケーリング

DynamoDB 読み取りスケーリング設定

DynamoDB Global Secondary Index (GSI) のスケーリング

Aurora のスケーリング

Aurora Read Replica のスケーリング

Aurora Serverless v2 の ACU（Aurora Capacity Units）自動スケーリング

Lambda Provisioned Concurrency のスケーリング

SageMaker エンドポイントのスケーリング

その他サービスのスケーリング

AppStream 2.0 フリートのスケーリング

OpenSearch Serverless コレクションのスケーリング

Kinesis Data Streams のスケーリング

カスタムメトリクスの活用

SQS キュー深さに基づくスケーリング

ビジネスメトリクスに基づくスケーリング

スケーリングポリシーの設計

設計の 7 つのステップ

冷却期間（Cooldown）の設定

EC2 Auto Scaling との比較

AWS Auto Scaling との関係

類似ツール・Karpenter との比較

Karpenter vs Application Auto Scaling

ベストプラクティス

✅ やるべきこと

❌ やってはいけないこと

トラブルシューティング

Issue 1：スケーリングが起動しない

Issue 2：スケールインが激しすぎる

Issue 3：ターゲット値に到達しない

Issue 4：意図しないスケーリングが発生

Issue 5：コスト削減効果が見られない

近年の動向

1. Predictive Scaling の拡張

2. カスタムメトリクス機械学習フィルター

3. Karpenter との統合

4. クロスアカウントスケーリング

学習リソース・参考文献

AWS 公式資料

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