▪️目的
AWSでWebサービスを運用していると、アクセス数やサーバーへの負荷が常に一定とは限りません。
例えば、普段はアクセスが少ないものの、キャンペーンやイベントなどによって一時的にアクセスが急増することがあります。
このような場合、サーバーを人の手で追加するのではなく、負荷や状況に応じてサーバーの台数を自動的に増減させる仕組みがあります。
それが「Auto Scaling」です。
この記事では、AWS初心者向けにAuto Scalingの基本的な仕組みやメリット、EC2やELBとの関係について解説します。
この記事を読むことで、以下の内容が分かるようになります。
- Auto Scalingとは何か
- なぜAuto Scalingが必要なのか
- スケールアウトとスケールイン
- Auto Scaling Groupとは何か
- EC2とAuto Scalingの関係
- ELB・ターゲットグループとの関係
- Auto Scalingの基本的な構成
▪️Auto Scalingとは？
Auto Scalingとは、AWSのリソースを状況に応じて自動的に増減させる仕組みです。
Webサービスでは、アクセス数や処理量によって必要なサーバーの台数が変化します。
例えば、普段はEC2を2台で運用していたとしても、アクセスが急増すると2台では処理しきれなくなる可能性があります。
そこで、
通常時
EC2 × 2台
から、
負荷増加
EC2 × 4台
のように、必要に応じてサーバーを増やします。
逆にアクセスが減少した場合は、
EC2 × 4台
↓
EC2 × 2台
のように台数を減らすこともできます。
このように、システムの負荷や状況に応じてリソースを自動的に調整するのがAuto Scalingです。
▪️なぜAuto Scalingが必要なのか？
例えば、EC2を1台だけ使ってWebサービスを運用しているとします。
ユーザー
↓
EC2
普段は問題なく動作していても、突然アクセスが増えると、
ユーザー
↓↓↓↓↓↓↓↓↓
EC2
となり、CPU使用率やメモリ使用量などが増加して、処理性能が低下する可能性があります。
最悪の場合、サーバーが処理しきれずサービスに影響が出ることもあります。
そこで、複数のEC2を用意して負荷を分散させます。
┌─ EC2
ユーザー → ├─ EC2
└─ EC2
さらに、アクセス量に応じてEC2の台数を自動的に増減できるようにすると、より柔軟にシステムを運用できます。
▪️スケールアウトとスケールイン
Auto Scalingを理解するうえで重要なのが、
スケールアウトとスケールインです。
♦︎スケールアウト
スケールアウトとは、サーバーなどのリソースを横方向に増やすことです。
例えば、
EC2 × 2台
から、
EC2 × 4台
へ増やします。
イメージとしては、
┌─ EC2
├─ EC2
ALB ────┼─ EC2
└─ EC2
のように、処理を担当するサーバーを増やします。
アクセスが急増したときなどに利用されます。
♦︎スケールイン
スケールインとは、サーバーなどのリソースを横方向に減らすことです。
例えば、
EC2 × 4台
から、
EC2 × 2台
へ減らします。
アクセスが少なくなったときなどに、不要なEC2を減らすことで、リソースを効率的に利用できます。
▪️スケールアップとスケールダウンとの違い
似た言葉に「スケールアップ」「スケールダウン」があります。
スケールアウト・スケールインは、台数を増減する方法です。
一方、スケールアップ・スケールダウンは、1台あたりの性能を変更する方法です。
例えば、
スケールアウト
EC2
↓
EC2 + EC2
のように台数を増やします。
一方、
スケールアップ
小さいEC2
↓
大きいEC2
のように、EC2インスタンス自体の性能を高くします。
Auto Scalingでは、複数のEC2を利用することでスケールアウト・スケールインを実現する構成がよく使われます。
▪️Auto Scaling Groupとは？
EC2のAuto Scalingで重要になるのが、**Auto Scaling Group（ASG）**です。
Auto Scaling Groupとは、Auto Scalingによって管理するEC2インスタンスのグループです。
例えば、
Auto Scaling Group
┌──────────────────┐
│ EC2-1 │
│ EC2-2 │
│ EC2-3 │
└──────────────────┘
のように、複数のEC2をまとめて管理します。
Auto Scaling Groupでは、例えば、
- 最小台数
- 希望台数
- 最大台数
などを設定します。
例えば、
最小台数：2
希望台数：2
最大台数：5
と設定した場合、通常は2台程度で運用しながら、必要に応じて最大5台まで増やせるようにできます。
▪️最小台数・希望台数・最大台数
Auto Scaling Groupでは、EC2の台数を管理するために以下のような設定があります。
最小台数
Auto Scaling Groupが維持するEC2の最低台数です。
例えば、
最小台数：2
なら、基本的に2台以上を維持するようにします。
希望台数
Auto Scaling Groupが通常維持したい希望する台数です。
例えば、
希望台数：2
なら、通常時は2台を維持するようにします。
最大台数
Auto Scaling Groupが増やせるEC2の最大台数です。
例えば、
最大台数：5
なら、Auto Scalingによって5台を超えてEC2を増やすことはありません。
これらを設定することで、
最低2台
通常2台
最大5台
といった運用ができます。
▪️何を基準にEC2を増減させるのか？
では、Auto Scalingは何を見てEC2を増やしたり減らしたりするのでしょうか？
代表的なものとして、CloudWatchのメトリクスがあります。
例えば、
EC2のCPU使用率
を監視して、CPU使用率が高くなったらEC2を追加する、といった設定ができます。
例えば、
CPU使用率が70%を超える
↓
EC2を追加
↓
負荷を分散
という流れです。
逆に、
CPU使用率が20%まで低下
↓
EC2を減らす
といった制御もできます。
このように、CloudWatchなどで取得したメトリクスを利用して、Auto Scalingの動作を制御できます。
▪️Auto ScalingとELBを組み合わせる
Auto Scalingは、ELBと組み合わせることでより効果を発揮します。
例えば、
ユーザー
↓
ALB
↓
Target Group
↓
EC2 × 2台
という構成があるとします。
アクセスが増えるとAuto Scalingによって、
EC2 × 2台
↓
EC2 × 4台
に増やします。
すると、
┌─ EC2
├─ EC2
ユーザー → ALB ┼─ EC2
└─ EC2
のように、ALBから複数のEC2へ通信を分散できます。
Auto ScalingとELBを組み合わせることで、
「アクセスが増えたらサーバーを増やし、増えたサーバーへ通信を分散する」
という仕組みを作ることができます。
▪️Auto Scalingとターゲットグループ
ここで、前回の記事で紹介したターゲットグループも登場します。
例えば、
ユーザー
↓
ALB
↓
Target Group
↓
EC2
という構成です。
Auto ScalingによってEC2が追加されると、そのEC2をロードバランサーからの通信先として利用できるよう、Auto Scaling Groupとターゲットグループを連携させる構成がよく使われます。
イメージすると、
Auto Scaling Group
┌───────────────┐
│ EC2-1 │
│ EC2-2 │
│ EC2-3 │
└───────┬───────┘
│
↓
Target Group
↑
│
ALB
↑
│
User
となります。
EC2の台数が変化しても、ロードバランサー側から利用できるターゲットを連携して管理できます。
▪️Auto Scalingと可用性
Auto Scalingには、単に性能を向上させるだけではなく、可用性を高めるという目的もあります。
例えば、EC2を1台だけ配置していると、
EC2-1
↓
障害
↓
サービス停止
となる可能性があります。
一方、複数のEC2を利用していれば、
EC2-1 → 障害
EC2-2 → 正常
EC2-3 → 正常
という状態にすることができます。
さらにELBのヘルスチェックと組み合わせることで、正常なターゲットへ通信を振り分けることができます。
そのため、
Auto Scalingは「負荷に応じて台数を変える仕組み」であると同時に、複数インスタンスによる可用性向上にもつながる
という点も覚えておきましょう。
▪️複数のAZにEC2を配置する
本番環境では、複数のAvailability Zone（AZ）にEC2を配置する構成もよく利用されます。
例えば、
ALB
/ \
/ \
AZ-A AZ-C
│ │
EC2 EC2
EC2 EC2
のような構成です。
1つのAZで障害が発生しても、別のAZで稼働しているEC2によってサービスを継続できる可能性があります。
Auto Scaling Groupでは、複数のAZをまたいでEC2を管理する構成も可能です。
そのため、Auto Scalingは単純な「サーバー台数の自動変更」だけではなく、可用性を考えたインフラ構成でも重要な役割を持っています。
▪️Auto Scalingの基本的な流れ
ここまでの内容を一つにつなげてみましょう。
ユーザー
↓
ALB
↓
Target Group
↓
EC2
↓
CloudWatchでメトリクス監視
↓
負荷が上昇
↓
Auto Scaling
↓
EC2を追加
↓
Target Groupと連携
↓
ALBが新しいEC2へ通信を分散
逆に負荷が低下した場合は、
負荷が低下
↓
Auto Scaling
↓
EC2を減らす
↓
必要な台数に調整
という流れになります。
この仕組みによって、アクセス量に応じてサーバー台数を柔軟に変更できます。
▪️Auto Scalingのメリット
Auto Scalingには、主に以下のようなメリットがあります。
① 負荷に応じて自動でリソースを調整できる
アクセスが増えた場合にEC2を追加し、アクセスが減った場合にはEC2を減らせます。
② 可用性を高められる
複数のEC2を利用することで、1台の障害がサービス全体へ与える影響を小さくできます。
③ コストを最適化できる
必要以上にEC2を起動し続けるのではなく、負荷が低いときには台数を減らすことで、無駄なリソースを減らせます。
④ 手動作業を減らせる
アクセスが急増するたびに人間がEC2を追加する必要がなくなります。
自動化することで、運用負担を軽減できます。
▪️Auto Scalingを利用するときの注意点
便利なAuto Scalingですが、設定すればすべて解決するわけではありません。
例えば、
- どのメトリクスを基準にするか
- 何台まで増やすか
- 何台まで減らすか
- スケールアウトする条件
- スケールインする条件
- EC2起動後にアプリケーションが正常に起動するか
- 複数AZへ配置するか
- ELBのヘルスチェックをどう設定するか
などを考える必要があります。
特に、「とりあえずCPU使用率70%で増やす」だけではなく、実際のアプリケーションの特性に合わせて設計することが重要です。
▪️ECSとの関係
AWSではEC2だけでなく、ECSでもスケーリングという考え方が登場します。
ECSでは、EC2インスタンスそのものではなく、コンテナ化されたタスクの数を増減させるという考え方があります。
例えば、
通常時
ECS Task × 2
から、
負荷増加
ECS Task × 4
のように増やします。
そして、
ALB
↓
Target Group
↓
ECS Tasks
という形で通信を分散します。
このように、Auto Scalingで学んだ
「負荷に応じて処理単位を増減させる」
という考え方は、ECSを理解するときにも非常に重要になります。
▪️まとめ
今回はAWSのAuto Scalingについて解説しました。
Auto Scalingとは、システムの負荷や状況に応じてAWSリソースを自動的に増減させる仕組みです。
EC2では、Auto Scaling Groupを利用して複数のEC2インスタンスを管理し、スケールアウト・スケールインを行うことができます。
また、
CloudWatch
↓
Auto Scaling
↓
EC2の台数を調整
↓
Target Group
↓
ALB
というように、AWSの複数のサービスを組み合わせることで、負荷に応じて柔軟に対応できるWebシステムを構築できます。
さらに、複数のAZへEC2を配置することで、可用性を高める構成にもできます。
AWSでWebシステムを設計・運用するうえで、Auto Scalingは非常に重要な仕組みです。
次の記事では「Route53」について解説します。
「Route53」の記事はこちら
→「https://lovelabengineer.com/2026/10/09/awsのroute-53とは？dnsの仕組みとドメイン名からwebサイトへ/」
No responses yet