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 マネジメントコンソール／CLI（2026年6月時点）。

この記事のポイント

・ELBがトラフィックを分散し、Auto Scalingが台数を自動調整する
・スケーリングポリシーはまずターゲット追跡を試し、段階制御が必要ならステップに切り替える
・ヘルスチェック失敗時にAuto Scalingが自動でEC2を入れ替える仕組み
・マルチAZ構成にしてはじめて単一AZ障害に耐えられる


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は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 70%など）を維持するようAWSが自動計算 ほとんどの一般的なWebシステム（最初に選ぶべき設定）
ステップスケーリング CloudWatchアラームの閾値ステップごとにスケール台数を定義 段階的に増減させたい・細かい制御が必要な場合
スケジュールスケーリング 日時・繰り返し日程を指定してキャパシティを設定 業務時間帯・セール・イベント等の定期負荷変動
ターゲット追跡スケーリング（推奨）
「CPU使用率を60%に維持する」のような目標値を設定すると、AWSが自動で台数を計算して増減します。最もシンプルで使いやすい設定です。まずこれを試し、要件を満たせない場合にステップスケーリングやスケジュールスケーリングを組み合わせるのが実務の定石です。

利用できる組み込みメトリクスは次の4つです。

・ASGAverageCPUUtilization — Auto ScalingグループのCPU使用率（平均）
・ASGAverageNetworkIn — インスタンスあたりの受信バイト数
・ASGAverageNetworkOut — インスタンスあたりの送信バイト数
・ALBRequestCountPerTarget — ALBターゲット1台あたりのリクエスト数（ALB使用時のみ）

CPU平均使用率を70%に維持する場合のCLI設定例です。

# ターゲット追跡ポリシー設定ファイルを作成
$ cat > target-tracking-config.json << 'EOF'
{
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  },
  "ScaleInCooldown": 300,
  "ScaleOutCooldown": 60
}
EOF

# Auto ScalingグループにポリシーをアタッチAdditionally
$ aws autoscaling put-scaling-policy \
    --auto-scaling-group-name my-asg \
    --policy-name cpu-target-tracking \
    --policy-type TargetTrackingScaling \
    --target-tracking-configuration file://target-tracking-config.json
ポリシーが作成されると、CloudWatchアラームが自動で2つ生成されます（スケールアウト用・スケールイン用）。これらはAWSが管理するため、手動で削除してはいけません。誤って削除するとポリシーが機能しなくなります。

デプロイ中など、スケールアウトだけを許可してスケールインは手動で制御したい場合は DisableScaleIn: true を設定します。

# スケールインを無効化（デプロイ中の意図しない縮退を防ぐ）
{
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  },
  "DisableScaleIn": true,
  "ScaleOutCooldown": 60
}
ステップスケーリング
「CPU 60～80%なら1台追加、80～90%なら3台追加、90%以上なら5台追加」というように、閾値ごとに追加台数を変えたい場合に使います。ターゲット追跡では対応しきれない急激な負荷変動パターンに有効です。

設定はCloudWatchアラームの作成とスケーリングポリシーの2段階になります。

# CPU 60%超過時に発火するCloudWatchアラームを作成（5分間の平均）
$ aws cloudwatch put-metric-alarm \
    --alarm-name my-asg-high-cpu-alarm \
    --metric-name CPUUtilization \
    --namespace AWS/EC2 \
    --statistic Average \
    --period 60 \
    --evaluation-periods 5 \
    --threshold 60 \
    --comparison-operator GreaterThanThreshold \
    --dimensions Name=AutoScalingGroupName,Value=my-asg

# ステップスケーリングポリシーを作成（閾値超過量に応じて段階的に台数を追加）
$ aws autoscaling put-scaling-policy \
    --auto-scaling-group-name my-asg \
    --policy-name step-scale-out \
    --policy-type StepScaling \
    --adjustment-type ChangeInCapacity \
    --metric-aggregation-type Average \
    --step-adjustments '[
      {"MetricIntervalLowerBound":0,"MetricIntervalUpperBound":20,"ScalingAdjustment":1},
      {"MetricIntervalLowerBound":20,"MetricIntervalUpperBound":30,"ScalingAdjustment":3},
      {"MetricIntervalLowerBound":30,"ScalingAdjustment":5}
    ]'
この設定では、アラーム閾値（60%）からの超過量に応じて動作します。

・0～20ポイント超過（CPU 60～80%） → 1台追加
・20～30ポイント超過（CPU 80～90%） → 3台追加
・30ポイント超過（CPU 90%以上） → 5台追加

スケジュールスケーリング
「毎朝9時に8台に拡張し、夜21時に2台に縮小する」といった時刻指定でのスケーリングです。トラフィックのパターンが予測可能な場合（業務時間の昼間に集中するBtoBサービスなど）に最適です。スケジュールスケーリングとターゲット追跡は組み合わせて使えます。朝に台数を先に確保しておき、そこからターゲット追跡が負荷に応じて追加調整する設計が最も実務的です。

# 平日9時（JST）に8台に拡張（cron形式はUTC基準のため9時間引く）
$ aws autoscaling put-scheduled-update-group-action \
    --auto-scaling-group-name my-asg \
    --scheduled-action-name scale-out-morning \
    --recurrence "0 0 * * 1-5" \
    --min-size 4 \
    --max-size 20 \
    --desired-capacity 8

# 平日21時（JST）に2台に縮小
$ aws autoscaling put-scheduled-update-group-action \
    --auto-scaling-group-name my-asg \
    --scheduled-action-name scale-in-night \
    --recurrence "0 12 * * 1-5" \
    --min-size 2 \
    --max-size 20 \
    --desired-capacity 2

# 設定確認
$ aws autoscaling describe-scheduled-actions \
    --auto-scaling-group-name my-asg \
    --query 'ScheduledUpdateGroupActions[*].{Name:ScheduledActionName,Recurrence:Recurrence,Desired:DesiredCapacity}'
[
    {
        "Name": "scale-out-morning",
        "Recurrence": "0 0 * * 1-5",
        "Desired": 8
    },
    {
        "Name": "scale-in-night",
        "Recurrence": "0 12 * * 1-5",
        "Desired": 2
    }
]
--recurrence はcron形式（UTC基準）で指定します。日本時間（JST）の場合は9時間引いて換算してください。平日9時JST = UTC 0時 = 0 0 * * 1-5 となります。

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秒程度に短縮できます。逆に、ファイルアップロードなど長時間接続が発生するアプリは延長してください。

4. ウォームアップとクールダウンの設定

スケーリングポリシーの選択と同じくらい重要なのが、ウォームアップとクールダウンの設定です。ここを誤ると、せっかくのスケーリング設定が機能しません。

パラメータ 意味 デフォルト値
DefaultInstanceWarmup 新規インスタンスがヘルスチェックを通過するまでの猶予時間（グループ単位） 未設定（0秒相当）
ScaleOutCooldown スケールアウト後に次のスケーリングアクションを待つ時間 300秒
ScaleInCooldown スケールイン後に次のスケーリングアクションを待つ時間 300秒
ウォームアップ時間の設定
ウォームアップ時間は実際のアプリケーション起動時間に合わせて設定するのが鉄則です。デフォルトが0秒（または設定なし）のままだと、起動直後のインスタンスがALBのヘルスチェックを通過する前にCloudWatchメトリクスに加算され、実態よりも早くスケールインしてしまうことがあります。

# デフォルトのインスタンスウォームアップを120秒に設定
$ aws autoscaling update-auto-scaling-group \
    --auto-scaling-group-name my-asg \
    --default-instance-warmup 120

# 設定を確認
$ aws autoscaling describe-auto-scaling-groups \
    --auto-scaling-group-names my-asg \
    --query 'AutoScalingGroups[0].DefaultInstanceWarmup'
120
実測値を測定するには、EC2の起動タイミングからALBのヘルスチェックが healthy になるまでの時間をCloudWatch Logsのタイムスタンプで確認します。Javaアプリのような起動の遅いアプリは180～240秒程度を見込むケースもあります。

クールダウン時間のチューニング
クールダウン時間が長すぎると、スパイク中に十分なインスタンスが追加されません。短すぎると、スケールアウトとスケールインが交互に発生して不安定になります。

・ScaleOutCooldown: ウォームアップ時間よりやや短い値に設定（例: ウォームアップ120秒ならスケールアウトクールダウン60秒）
・ScaleInCooldown: スケールアウトより長めに設定（300秒前後が一般的）。余分なインスタンスが素早く削除されないよう、コスト削減と安定性のバランスをとる

マルチ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秒）
  DefaultInstanceWarmup: 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）」を使い、最低台数はオンデマンドで確保するのがよいです。

5. スケーリングが期待通りに動かない場合のCLI調査手順

Auto Scalingを設定したのにインスタンスが増えない・減らない場合は、次の3点を順番に確認します。

（1）スケーリングアクティビティを確認する

# 最近のスケーリングアクティビティとその状態を確認
$ aws autoscaling describe-scaling-activities \
    --auto-scaling-group-name my-asg \
    --max-items 5 \
    --query 'Activities[*].{Status:StatusCode,Desc:Description,Start:StartTime}'

[
    {
        "Status": "Failed",
        "Desc": "Launching a new EC2 instance. Status Reason: The requested configuration is currently not supported.",
        "Start": "2026-09-18T09:30:00.000Z"
    }
]
StatusCode が Failed の場合は Description のメッセージに原因が書かれています。代表的なエラーと対処を示します。

・InsufficientInstanceCapacity: そのAZでは指定インスタンスタイプのキャパシティが不足しています。起動テンプレートに複数インスタンスタイプを指定（Mixed Instances Policy）するか、別のAZを追加してください。
・InstanceLimitExceeded: AWSアカウントのEC2インスタンス数上限に達しています。サービスクォータ引き上げ申請が必要です。
・クールダウン中でスケールしない: スケーリングアクティビティに理由は出ませんが、前回のアクション直後はクールダウンが終わるまで追加スケーリングが発生しません。

（2）CloudWatchアラームの状態を確認する

# スケーリングトリガーとなるアラームの状態を確認
$ aws cloudwatch describe-alarms \
    --alarm-names "TargetTracking-my-asg-AlarmHigh-a1b2c3d4" \
    --query 'MetricAlarms[*].{Name:AlarmName,State:StateValue,Reason:StateReason}'

[
    {
        "Name": "TargetTracking-my-asg-AlarmHigh-a1b2c3d4",
        "State": "OK",
        "Reason": "Threshold Crossed: 1 out of the last 1 datapoints [45.6] was not greater than the threshold (70.0)."
    }
]
アラームが ALARM 状態なのにスケーリングが発生しない場合は、Auto ScalingグループのMaxSizeにすでに達している可能性があります。

（3）ポリシーの設定内容を確認する

# グループに設定されているスケーリングポリシーを一覧表示
$ aws autoscaling describe-policies \
    --auto-scaling-group-name my-asg \
    --query 'ScalingPolicies[*].{Name:PolicyName,Type:PolicyType,Enabled:Enabled}'

[
    {
        "Name": "cpu-target-tracking",
        "Type": "TargetTrackingScaling",
        "Enabled": true
    }
]
Enabled: false になっている場合は、ポリシーが意図せず無効化されています。--no-disabled フラグでポリシーを再有効化してください。

本記事のまとめ

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

コンポーネント 役割 設計のポイント
ALB HTTPSトラフィックの分散・SSL終端 マルチAZ有効化、ヘルスチェックパスを/healthに統一
ターゲットグループ どのEC2に流すかの管理 登録解除の遅延をリクエスト最長時間に合わせる
起動テンプレート EC2の設計図（AMI・スペック・起動スクリプト） バージョン管理でロールアウト可能に
Auto Scalingグループ EC2台数の自動管理・障害時の自動復旧 Min≥2、ヘルスチェックタイプはELBに設定
スケーリングポリシー 増減タイミングのルール まずターゲット追跡（CPU 60～70%目安）を選び、段階制御が必要ならステップへ
ウォームアップ/クールダウン スケーリングのタイミング調整 DefaultInstanceWarmupをアプリ実際の起動時間に合わせて実測設定
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の実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

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

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

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

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

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

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

この記事を書いた人

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

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

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