AWS Auto ScalingとELBで作る高可用性アーキテクチャ｜EC2自動スケーリングとロードバランサーの設計パターン入門

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWS Auto ScalingとELBで作る高可用性アーキテクチャ｜EC2自動スケーリングとロードバランサーの設計パターン入門
「AWSにEC2を立てたはいいが、負荷が増えたり1台が落ちたりしたらどうなるんだろう」
クラウドを使い始めたLinuxエンジニアが必ずぶつかる壁です。

この記事では、AWS Auto ScalingとELB（Elastic Load Balancing）を組み合わせて高可用性アーキテクチャを設計する方法を、構成設計の考え方から順を追って解説します。
単なる「操作手順」ではなく、「なぜこの構成にするのか」という設計の文脈ごと理解することを目指します。
動作確認環境: AWS マネジメントコンソール（2026年6月時点）。

この記事のポイント

・ELBがトラフィックを分散し、Auto Scalingが台数を自動調整する
・起動テンプレート＋Auto Scalingグループ＋ALBの3点セットが基本構成
・ヘルスチェック失敗時にAuto Scalingが自動でEC2を入れ替える仕組み
・マルチAZ構成にしてはじめて単一AZ障害に耐えられる


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

高可用性に必要な2つの問題を理解する

AWSで「落ちないシステム」を作るには、2つの問題を別々に解決する必要があります。

1つ目は「トラフィックの偏り」です。EC2が1台しかなければ、その1台に全てのアクセスが集中します。負荷が増えれば応答が遅くなり、最悪の場合はサービスが停止します。

2つ目は「障害による停止」です。EC2インスタンスや、インスタンスが乗っているアベイラビリティゾーン（AZ）自体が障害を起こすことがあります。予備機がなければそのまま全停止です。

ELBはこの「1つ目の問題（トラフィック分散）」を解決します。Auto Scalingは「2つ目の問題（障害時の自動復旧）」と「負荷増加時のスケールアウト」を解決します。
この2つを組み合わせて、はじめて実用的な高可用性アーキテクチャになります。

ELB（Elastic Load Balancing）の役割と種類

ELBはAWSが提供するマネージドのロードバランサーサービスです。自前でNginxやHAProxyをロードバランサーとして構築するのとは異なり、AWSが可用性・スケーリングを管理してくれるため、ロードバランサー自体が単一障害点にならないのが最大の利点です。

1. ALB（Application Load Balancer）—— WebアプリはこれでOK

ALBはHTTP/HTTPSのL7（アプリケーション層）でトラフィックを分散します。パスベースのルーティング（例: /api/* は別のターゲットグループへ）や、ホストベースのルーティング（ドメイン名で振り分け）が可能です。

Webアプリケーション、REST API、マイクロサービスのフロントエンドには迷わずALBを選択してください。

2. NLB（Network Load Balancer）—— 超低遅延が必要な場面

NLBはTCP/UDP/TLSのL4で動作し、1秒間に数百万リクエストをさばける超低遅延のロードバランサーです。IPアドレスを固定したい場合（Elastic IP割り当て可能）にも使います。

ゲームサーバー、IoTバックエンド、VPN終端など、プロトコルレベルの制御が必要な場面で使います。Webアプリには必要ないほどの性能なので、用途の違いを理解しておきましょう。

3. CLB（Classic Load Balancer）—— レガシー、新規では使わない

旧来のEC2-Classic環境向けのロードバランサーです。VPC環境での新規構築には使いません。既存システムのリプレイス時に名前を見かけることがある程度です。

Auto Scalingの3つのコンポーネント

Auto Scalingを設定するには、3つのコンポーネントを理解する必要があります。

1. 起動テンプレート（Launch Template）—— EC2の設計図

Auto Scalingが新しいEC2を起動するときの設計図です。以下の情報を定義します。

・AMI ID：どのマシンイメージから起動するか（Webアプリが入ったゴールデンイメージを使うのが定石）
・インスタンスタイプ：t3.micro、c5.large など
・セキュリティグループ：どのポートを開けるか
・ユーザーデータ：起動後に自動実行するシェルスクリプト（Nginxの起動コマンドなど）
・IAMインスタンスプロファイル：EC2に付与するIAMロール

起動テンプレートはバージョン管理ができるため、設定変更の際は新バージョンを作成して段階的にロールアウトできます。以前使われていた「起動設定（Launch Configuration）」はバージョン管理ができず、現在は非推奨です。

2. Auto Scalingグループ（ASG）—— インスタンス数の管理者

ASGが実際にEC2の台数を管理します。設定項目は以下の通りです。

・最小台数（Min）：常時稼働させる最低台数。障害時の自動復旧の基準値
・最大台数（Max）：スケールアウトの上限。コスト暴走を防ぐ安全弁
・希望台数（Desired）：通常時の稼働台数
・AZの指定：どのAZにEC2を分散させるか

たとえば Min=2、Max=10、Desired=2 に設定した場合、通常は2台が稼働します。CPUが高騰すれば最大10台まで自動で追加され、負荷が下がれば2台まで縮退します。1台が落ちてもASGが自動で新しいEC2を起動して2台を維持します。

3. スケーリングポリシー —— いつ増やすか・減らすかのルール

代表的なスケーリングポリシーは3種類あります。

・ターゲット追跡スケーリング（推奨）：「CPU使用率を60%に維持する」のような目標値を設定すると、AWSが自動で台数を計算して増減します。最もシンプルで使いやすい設定です。
・ステップスケーリング：CPU 70%以上で+2台、90%以上で+4台のような段階的なルールを定義します。急激な負荷増加に対して素早く反応させたい場合に使います。
・スケジュールスケーリング：毎朝9時に6台に増やし、夜22時に2台に戻すといった時刻指定でのスケーリングです。トラフィックのパターンが予測可能な場合（業務時間の昼間に集中するBtoBサービスなど）に最適です。

ALB＋Auto Scalingの組み合わせ設計パターン

実際のWebアプリケーション構成では、ALBとASGを次のように組み合わせます。

1. ターゲットグループの設計

ALBのターゲットグループは「どのEC2群にトラフィックを流すか」を定義するコンテナです。ASGをターゲットグループに紐づけると、ASGがEC2を追加・削除するたびに自動的にターゲットグループも更新されます。手動でEC2を登録・削除する必要はありません。


# ALBのトラフィックフロー（概念図）

インターネット
    ↓
[ALB] ← ヘルスチェック（/health に GET）
    ↓         ↓
[EC2-1]    [EC2-2]    ← Auto Scalingグループ（Min=2, Max=10）
(ap-northeast-1a)  (ap-northeast-1c)  ← AZを分散配置

2. ヘルスチェックの二重構造を理解する

ALB+Auto Scalingの構成では、ヘルスチェックが2段階あります。

・ALBのヘルスチェック：ALBが定期的に各EC2の特定パス（例: /health）にHTTPリクエストを送り、200 OKが返るかを確認します。失敗したEC2はトラフィックの配信先から外されます（drain処理）。
・EC2のヘルスチェック（ASG）：ASGがEC2インスタンス自体のステータスを確認します。デフォルトはEC2ステータスチェックですが、「ELBヘルスチェックを使う」設定に変更することを強く推奨します。これにより、「EC2は起動しているがアプリがクラッシュしている」ような状態でも、ASGがEC2を入れ替えてくれます。


# ASGのヘルスチェックタイプをELBに変更（CLIの場合）
$ aws autoscaling update-auto-scaling-group \
    --auto-scaling-group-name my-web-asg \
    --health-check-type ELB \
    --health-check-grace-period 300

# health-check-grace-period: 新しいEC2が起動してからヘルスチェックを
# 開始するまでの猶予時間（秒）。アプリの起動に時間がかかる場合は長めに設定

3. コネクションドレイニング（登録解除の遅延）

スケールイン（台数縮小）やEC2の入れ替え時、ALBはすぐにトラフィックの転送を止めるのではなく、既存の接続が終了するまで待機します。この仕組みをコネクションドレイニングといいます。

デフォルトは300秒ですが、APIサーバーなど短命なリクエストが多い場合は30秒程度に短縮できます。逆に、ファイルアップロードなど長時間接続が発生するアプリは延長してください。

マルチAZ配置の重要性と設計上の注意

どれほど良い設計でも、1つのAZにEC2を集中させると、そのAZの障害でサービスが全停止します。

AWS東京リージョン（ap-northeast-1）には現在4つのAZがあります（ap-northeast-1a/1c/1d/1e）。最低でも2つのAZ（ap-northeast-1aとap-northeast-1c）に分散させるのが鉄則です。

1. AZ分散の設計ルール

・Min=2 ならAZ=2以上：1台ずつ別のAZに置くことで、片方のAZ障害時も残り1台でサービスを継続できます。
・台数は奇数を避ける：Min=3をAZ=2に置くと、1aに2台・1cに1台のように偏ります。Min=4のほうが均等に分散できます。ただし、実際にはASGが「バランスを保つ」モードで動作するため、ある程度自動調整されます。
・スポットインスタンスを使う場合は3AZ以上：スポットインスタンスはAZ・インスタンスタイプ別に中断リスクが異なります。3AZ以上に分散することで、特定のスポットプールが枯渇しても他のAZでカバーできます。

2. ALBはマルチAZ対応が自動

ALB自体はマルチAZ構成が自動で有効になっています（無効化することも可能ですが推奨しません）。ALBに複数のAZを指定すると、ALB自体もそれぞれのAZにノードが配置され、AZ障害時でも継続してトラフィックを処理できます。

実際の構成例：最小構成の高可用性Webアプリ

以下は、本番環境の最小構成として現場でよく使われるパターンです。

# 構成要素一覧

[Route 53] → DNSでALBのDNS名に向ける

[ALB]
  リスナー: HTTP 80 → HTTPS 443にリダイレクト
  リスナー: HTTPS 443 → ターゲットグループ(web-tg)に転送
  ACM証明書: ALBにアタッチ（SSL終端をALBで行う）

[ターゲットグループ: web-tg]
  ヘルスチェック: GET /health, 200 OK
  登録解除の遅延: 60秒

[Auto Scalingグループ: web-asg]
  起動テンプレート: web-lt（Nginx + アプリ入りAMI）
  Min: 2 / Desired: 2 / Max: 10
  AZ: ap-northeast-1a, ap-northeast-1c
  ヘルスチェック: ELB（猶予時間 120秒）
  スケーリングポリシー: ターゲット追跡（CPU 60%）

1. 起動テンプレートのユーザーデータ（例）

EC2起動後に自動でアプリを起動させるためのユーザーデータです。

#!/bin/bash
# EC2起動直後に自動実行されるスクリプト

# 最新パッケージに更新
dnf update -y

# Nginxを起動・自動起動設定
systemctl start nginx
systemctl enable nginx

# アプリプロセスを起動（例: Node.jsアプリ）
cd /opt/myapp
npm start &

# ヘルスチェック用エンドポイントの確認
# /health に GET すると 200 OK が返ることを確認してから起動完了とする

2. 実サーバーでのALBヘルスチェック確認

ALBのターゲットグループ画面で、各EC2インスタンスのヘルスチェック状態を確認できます。CLIでも確認可能です。

# ターゲットグループのヘルスチェック状態を確認
$ aws elbv2 describe-target-health \
    --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/web-tg/abcdef1234567890

# 出力例（2台がhealthy状態）
{
    "TargetHealthDescriptions": [
        {
            "Target": {
                "Id": "i-0a1b2c3d4e5f67890",
                "Port": 80
            },
            "HealthCheckPort": "80",
            "TargetHealth": {
                "State": "healthy"
            }
        },
        {
            "Target": {
                "Id": "i-0f9e8d7c6b5a43210",
                "Port": 80
            },
            "HealthCheckPort": "80",
            "TargetHealth": {
                "State": "healthy"
            }
        }
    ]
}

よくある設計ミスとトラブルシュート

1. 新しいEC2が immediately unhealthy になる

Auto Scalingで新しいEC2が追加されてもすぐにヘルスチェック失敗になる場合、多くはヘルスチェックの猶予時間（grace period）が短すぎることが原因です。

アプリの起動に60秒かかるのに猶予時間が30秒だと、起動完了前にヘルスチェックが始まり失敗します。「初回ヘルスチェックが通るまでにどれくらい時間がかかるか」を実測して猶予時間を設定してください。

2. スケールイン後に接続が切れる

コネクションドレイニングの時間が短すぎると、通信中のセッションが強制切断されます。「登録解除の遅延」をアプリの最長リクエスト処理時間よりも長く設定してください。

3. AZが1つしか指定されていない

構築時にAZを1つしか選ばないと、ASGのインスタンスが全て同じAZに集中します。後からAZを追加することはできますが、既存インスタンスの再分散は自動では行われません（インスタンスリバランシング機能を使って再均等化する必要があります）。設計初期からマルチAZを設定してください。

4. スポットインスタンス中断時に台数が急減する

コスト削減でスポットインスタンスを使う場合、スポットインスタンスが中断されるとASGが新しいインスタンスを起動しようとしますが、スポットプールに空きがなければ起動に時間がかかります。本番環境では「オンデマンド＋スポットの混在設定（Mixed Instances Policy）」を使い、最低台数はオンデマンドで確保するのがよいです。

本記事のまとめ

ALBとAuto Scalingを組み合わせた高可用性アーキテクチャのポイントをまとめます。

コンポーネント 役割 設計のポイント
ALB HTTPSトラフィックの分散・SSL終端 マルチAZ有効化、ヘルスチェックパスを/healthに統一
ターゲットグループ どのEC2に流すかの管理 登録解除の遅延をリクエスト最長時間に合わせる
起動テンプレート EC2の設計図（AMI・スペック・起動スクリプト） バージョン管理でロールアウト可能に
Auto Scalingグループ EC2台数の自動管理・障害時の自動復旧 Min≥2、ヘルスチェックタイプはELBに設定
スケーリングポリシー 増減タイミングのルール 通常はターゲット追跡（CPU 60～70%目安）
AZ設計 障害域の分離 最低2AZ、台数はAZ数の倍数が均等分散しやすい

AWSの構成設計は「設定画面で何をポチるか」より「なぜこの設定にするか」の設計思想のほうが重要です。
今回解説したALB＋Auto Scalingの組み合わせは、AWSで高可用性を実現するための最も基本的なパターンです。まずこのパターンを自分の手で組んで理解してから、次のステップ（ECSへの移行、CloudFront+ALBの組み合わせ、マルチリージョン構成など）に進んでください。

AWSのより深い実践については、以下の記事も参考にしてください。
・Linux DNS設定の基本（resolv.conf・nmcli）
・Linuxポート確認の全コマンド（ss・lsof）

Linuxの実践力を体系的に身につけたい方は、以下のセミナーLP・AWSコース紹介ページもご覧ください。

＞＞ AWSの設計・構築を体系的に学ぶ（上級LPはこちら）

＞＞ AWSをはじめて学ぶ方はこちら（入門LP）

AWSの高可用性設計を「実機で動かして理解する」習慣は、Linuxサーバー構築の「型」から生まれます

Auto ScalingやELBはマネジメントコンソールで設定できても、「なぜこの設計にするか」を説明できるかどうかで現場での信頼が変わります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。