TL

Cloud Service

AWS Auto Scaling (EC2 Auto Scaling Plans)

複数の AWS リソースを1つの計画でまとめてスケーリング。予測スケーリングで先回りも可能。EC2 や ECS、DynamoDB などを横断して可用性とコストを両立する管理レイヤー。

中級SAA-C03SOA-C02SAP-C02信頼性パフォーマンス効率コスト最適化
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.EC2 Auto Scaling グループや ECS、DynamoDB などを横断して、1つのスケーリング計画でまとめて管理できる
  • 2.目標追跡を中心に、需要を見越して先に台数を増やす予測スケーリングも選べる
  • 3.個別リソースのスケーリング機能の上位に立つ管理レイヤーで、サービス自体に追加料金はかからない

AWS Auto Scaling は、複数の AWS リソースのスケーリングを1つの「スケーリング計画(Scaling Plan)」としてまとめて構成・管理できるサービスです。EC2 Auto Scaling グループだけでなく、ECS サービスや DynamoDB のテーブル、Aurora のリードレプリカ、Spot フリートなどを横断的に対象にできます。

解決する課題

アプリケーションは多くの場合、複数の AWS リソースが連動して動いています。Web 層の EC2、コンテナの ECS、バックエンドの DynamoDB といった具合に、それぞれが独自のスケーリング設定を持つため、リソースごとに個別に設定・調整するとスケーリングポリシーが分散し、全体像を把握しづらくなります。

AWS Auto Scaling は、これらをアプリケーション単位の1つの計画として束ねることで、横断的にスケーリングを設計・適用できるようにします。各リソースに対して「可用性重視」「コスト重視」「バランス」といった戦略を一括で指定でき、目標追跡ポリシーを自動生成します。さらに、過去のメトリクス傾向から将来の負荷を見越してあらかじめ容量を確保する予測スケーリングを使えば、起動に時間のかかるリソースでも反応遅れを抑えられます。

主要概念と用語

  • スケーリング計画(Scaling Plan): スケーリング対象のリソース群とその戦略をまとめた構成単位。AWS Auto Scaling の中心となる概念。
  • スケーラブルリソース: 計画の対象にできるリソース。EC2 Auto Scaling グループ、ECS サービス、DynamoDB テーブルやインデックス、Aurora リードレプリカ、Spot フリートなどが含まれる。
  • リソースの検出: CloudFormation スタックや EC2 のタグを起点に、関連するスケーラブルリソースを自動で見つけ出す仕組み。
  • スケーリング戦略: 各リソースに適用する方針。可用性を優先するか、コストを優先するか、その中間(バランス)かを選ぶと、対応する目標追跡の目標値が設定される。
  • 目標追跡スケーリング: 指定したメトリクス(CPU 使用率やリクエスト数など)を目標値に近づけるように容量を自動調整する方式。AWS Auto Scaling が生成するポリシーの基本。
  • 予測スケーリング(Predictive Scaling): 過去のメトリクス傾向から将来の需要を予測し、先回りして容量を増やす機能。日次や週次など周期性のある負荷に向く。
  • Application Auto Scaling: EC2 以外の個別サービス(ECS、DynamoDB、Aurora など)をスケーリングする下位の仕組み。AWS Auto Scaling はこれらを束ねる上位レイヤーに位置づけられる。

仕様・制限・クォータ

AWS Auto Scaling はリージョン単位のサービスで、1 つのスケーリング計画に複数の異なる種類のリソースを含められます。対象リソースは、CloudFormation スタックや EC2 インスタンスのタグを使って自動検出するか、明示的に指定します。

スケーリング計画は、対象リソースごとに目標追跡ポリシーを生成します。可用性・コスト・バランスといった事前定義された戦略を選ぶと、それに対応する目標値が設定され、必要に応じて手動で目標値を上書きすることもできます。予測スケーリングは EC2 Auto Scaling グループに対して利用でき、一定期間のメトリクス履歴を学習材料として将来の容量を見積もります。

計画やリソースの数にはアカウント・リージョンごとのクォータが設定されています。実際の上限値や対応リソースの範囲は変動しうるため、最新の情報は AWS の公式ドキュメントとアカウントの Service Quotas で確認してください。なお、AWS Auto Scaling 自体に追加料金はかからず、課金対象は実際に起動・利用されたリソースです。

EC2 Auto Scaling との混同に注意

名前が似ていますが、EC2 Auto Scaling は EC2 インスタンス台数を制御する個別機能、AWS Auto Scaling はそれを含む複数リソースを横断して束ねる管理レイヤーです。役割の階層が異なる点を押さえてください。

内部の仕組み

AWS Auto Scaling は、スケーリング計画に含まれる各リソースに対して、内部的に目標追跡スケーリングポリシーと CloudWatch アラームを生成します。EC2 Auto Scaling グループには EC2 Auto Scaling のポリシーが、ECS や DynamoDB などには Application Auto Scaling のポリシーが適用される形で、対象ごとに適切な下位の仕組みへ設定が展開されます。

戦略として可用性・コスト・バランスのいずれかを選ぶと、その方針に応じた目標値が各リソースのポリシーに反映されます。たとえば可用性重視ではメトリクスの目標値を低めに設定して余裕を持たせ、コスト重視では高めに設定して稼働率を上げます。

予測スケーリングでは、一定期間分のメトリクス履歴を分析して周期的なパターンを学習し、将来の需要を予測して将来時刻の容量計画を作成します。これにより、需要が立ち上がる前にあらかじめ容量を確保でき、起動に時間がかかるリソースでも負荷の急増に追随しやすくなります。予測スケーリングは、リアルタイムの目標追跡と組み合わせて、予測と実測の両面から容量を調整できます。

設計パターン / ベストプラクティス

アプリケーションを構成するリソースを1つのスケーリング計画にまとめ、戦略を統一して適用するのが基本です。CloudFormation スタックやタグでリソースを検出させると、関連リソースを漏れなく対象に含めやすくなります。

予測可能な周期性のある負荷(平日昼にピークが来るなど)には予測スケーリングが有効で、需要の立ち上がりに先回りして容量を確保できます。一方、突発的で予測しにくいスパイクにはリアルタイムの目標追跡が向くため、両者を併用して定常的な波と突発的な変動の双方に対応させます。

まずは目標追跡から始める

最初は可用性とコストのバランス戦略による目標追跡から始め、運用しながらメトリクスの推移を見て目標値を調整するのが扱いやすい進め方です。周期性が確認できたら予測スケーリングの追加を検討します。

対象リソースはステートレスに設計し、状態は外部のデータストアやキャッシュに逃がしておくことが重要です。スケールインでリソースが縮小されても、ユーザー体験に影響しないようにします。

運用・監視

スケーリング計画ごとに、各リソースの実際の容量と予測容量、目標追跡の推移を CloudWatch メトリクスで監視できます。予測スケーリングを有効にする前に「予測のみ(forecast only)」のモードで一定期間運用し、予測が実際の需要とどの程度合っているかを確認してから本適用すると安全です。

スケーリングが頻繁に発生して容量が振動する場合は、目標値の見直しや、対象リソース側のウォームアップ・クールダウン設定の調整を行います。各リソースのスケーリング履歴は、EC2 Auto Scaling のアクティビティ履歴や Application Auto Scaling のスケーリングアクティビティから追跡できます。

予測は履歴に依存する

予測スケーリングは過去のメトリクス傾向を学習材料にするため、履歴が十分にない初期段階や、過去と傾向が大きく変わった場合は予測精度が下がります。導入直後は予測のみモードで挙動を見極めてください。

コスト

AWS Auto Scaling の利用そのものに追加料金は発生せず、課金対象は実際に起動・利用された EC2 インスタンスや ECS タスク、DynamoDB のキャパシティといったリソースです。したがって、需要に応じてリソースを過不足なく調整すること自体が、そのままコスト最適化につながります。

戦略としてコスト重視を選べば、稼働率を高めに保って無駄を減らせます。一方で可用性重視は余裕を持たせる分コストが上がるため、ワークロードの重要度に応じて戦略を使い分けます。具体的な料金は対象リソースの種類・購入オプション・リージョンによって変動するため、断定的な金額は示せません。最新の料金は各リソースの公式料金ページで確認してください。

セキュリティ

AWS Auto Scaling の操作は IAM ポリシーで制御し、スケーリング計画の作成・変更・削除を権限のある主体のみに限定します。AWS Auto Scaling は各リソースのスケーリングを設定するために、サービスにリンクされたロールを通じて EC2 Auto Scaling や Application Auto Scaling、CloudWatch などへアクセスします。

最小権限の原則に従い、計画を管理する主体には必要な操作だけを許可します。対象リソース自体のセキュリティ(EC2 のインスタンスプロファイル、ECS のタスクロール、ネットワーク構成など)は、それぞれのリソース側の設定で適切に保護します。

関連サービス・比較

最も比較されるのは、EC2 インスタンス単位のスケーリングを担う Amazon EC2 Auto Scaling です。AWS Auto Scaling はその上位に立ち、EC2 を含む複数リソースを横断して束ねる点が異なります。

観点AWS Auto ScalingEC2 Auto Scaling
対象EC2 や ECS、DynamoDB など複数サービス横断EC2 インスタンスと Spot フリート
設定単位アプリケーション単位のスケーリング計画Auto Scaling グループごと
予測スケーリング計画から横断的に設定できるグループ単位で個別に設定
位置づけ横断的なスケーリングの管理レイヤー個別サービスのスケーリング機能

ハンズオン / CLI例

CloudFormation スタックや EC2 のタグを起点にスケーラブルリソースを検出し、戦略を指定してスケーリング計画を作成する例です。リソースの種類ごとに目標追跡の設定を含めます。

# タグでリソースを検出し、目標追跡を含むスケーリング計画を作成する
aws autoscaling-plans create-scaling-plan \
  --scaling-plan-name web-app-plan \
  --application-source 'TagFilters=[{Key=app,Values=[web]}]' \
  --scaling-instructions '[
    {
      "ServiceNamespace": "autoscaling",
      "ResourceId": "autoScalingGroup/web-asg",
      "ScalableDimension": "autoscaling:autoScalingGroup:DesiredCapacity",
      "MinCapacity": 2,
      "MaxCapacity": 10,
      "TargetTrackingConfigurations": [
        {
          "PredefinedScalingMetricSpecification": {
            "PredefinedScalingMetricType": "ASGAverageCPUUtilization"
          },
          "TargetValue": 50.0
        }
      ],
      "PredictiveScalingMode": "ForecastOnly"
    }
  ]'

# 作成したスケーリング計画の状態を確認する
aws autoscaling-plans describe-scaling-plans \
  --scaling-plan-names web-app-plan

AWS Service

AWS Auto Scaling (EC2 Auto Scaling Plans)を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

コンピューティング

比較で見る軸

クラウド: AWS / カテゴリ: コンピューティング / 難易度: intermediate

導入後に効く点

目標追跡を中心に、需要を見越して先に台数を増やす予測スケーリングも選べる

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
コンピューティング
難易度
intermediate
関連資格
SAA-C03 / SOA-C02 / SAP-C02
設計柱
reliability / performance / cost

判断チェックリスト

  • 自社の用途が「コンピューティング / reliability」に近いか確認する。
  • 強みである「EC2 Auto Scaling グループや ECS、DynamoDB などを横断して、1つのスケーリング計画でまとめて管理できる」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

コンピューティングreliabilityperformancecostSAA-C03