Linuxサーバーをオンプレミスで運用してきた経験があっても、クラウドの可用性設計は勝手が違う。EC2は仮想マシンだが、ホストのハードウェア障害や計画メンテナンスで突然停止する可能性がある。
この記事では、aws ec2可用性を高めるための2本柱——マルチAZ配置設計とAuto Scalingグループの構成指針——を体系的に解説します。想定環境はAmazon Linux 2023系のEC2インスタンスで、Auto Scalingグループを使ってマルチAZにインスタンスを分散させる構成を対象にしています。VPCの基礎（サブネット・セキュリティグループ・NATゲートウェイ）を理解している方を対象としており、AWSのコンソール操作またはCLIで実際に設定できることをゴールにしています。
この記事のポイント
・マルチAZ配置でAZ障害時の影響をインスタンス単位に局所化できる
・Auto ScalingグループはAZバランスの「再分散」を自動で行う設定が重要
・ヘルスチェックはEC2タイプよりELBタイプで設定するのが実務の定番
・最小台数は「使用AZ数以上」にするのが可用性設計の基本指針
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜEC2の可用性設計にマルチAZ配置が必要なのか
AWSの各リージョンは複数のアベイラビリティゾーン（AZ）で構成されている。AZはデータセンター単位で物理的に分離されており、1つのAZで障害が発生しても他のAZには影響しない設計になっている。AWSは「マルチAZ配置を組み合わせることで高可用性を実現してください」という設計思想を明示している。1つのAZにEC2を集中させていると、AZ障害やホストメンテナンスのタイミングでサービスが停止するリスクがある。ハードウェア障害の頻度は低くても、ソフトウェア的な計画メンテナンス（インスタンスの移行・ホストリタイアなど）は定期的に発生するため、1台稼働のシステムは必ず停止を経験することになる。
マルチAZ配置の基本的な考え方は、複数のAZにインスタンスを分散させることで「障害が特定のAZに限定された場合でも、残りのAZでサービスを継続できる」状態を作ることだ。これを手動で管理するのは困難なため、Auto Scalingグループ（ASG）を使って自動化するのが現代のAWS設計の定番となっている。
マルチAZ配置の基本設計
1. VPCサブネットをAZごとに作成する
マルチAZ配置の前提として、VPC内にAZをまたいだサブネットを用意する必要がある。東京リージョン（ap-northeast-1）では3つのAZ（1a・1c・1d）が利用可能なので、それぞれにプライベートサブネットを作成するのが基本だ。# 東京リージョン（ap-northeast-1）の推奨サブネット構成（例） # プライベートサブネット（EC2インスタンス配置用） subnet-app-1a 10.0.10.0/24 ap-northeast-1a subnet-app-1c 10.0.11.0/24 ap-northeast-1c subnet-app-1d 10.0.12.0/24 ap-northeast-1d # パブリックサブネット（ALB配置用） subnet-pub-1a 10.0.1.0/24 ap-northeast-1a subnet-pub-1c 10.0.2.0/24 ap-northeast-1c subnet-pub-1d 10.0.3.0/24 ap-northeast-1d
2. Auto ScalingグループのAZ設定
Auto Scalingグループを作成する際に、インスタンスをデプロイするサブネットを選択する。ここで複数AZのサブネットを指定することで、ASGがAZ間で自動的にインスタンスを分散させるようになる。# AWS CLIでAuto Scalingグループを作成する例 aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name my-web-asg \ --launch-template LaunchTemplateId=lt-0abc1234,Version='$Latest' \ --min-size 3 \ --desired-capacity 3 \ --max-size 9 \ --vpc-zone-identifier "subnet-0abc1111,subnet-0abc2222,subnet-0abc3333"
# --vpc-zone-identifier に複数のサブネットIDをカンマ区切りで指定すると # ASGはそれぞれのAZにインスタンスを均等分散しようとする # 正常終了時は出力なし（終了コード0）
3. AZバランシング（再分散）の仕組み
ASGには「AZリバランシング（Rebalancing）」と呼ばれる機能が組み込まれている。AZ間でインスタンス数の偏りが発生した場合（AZ障害後の復帰時など）に、自動でインスタンスを再分散する仕組みだ。再分散のプロセスは以下の順序で行われる。
・不足しているAZに新しいインスタンスを先に起動する
・新インスタンスが起動完了してから、余っているAZのインスタンスを終了する
この順序により、再分散中もサービスへの影響を最小限に抑えられる。ただし、一時的にmax_sizeを超えることがあるため、max_sizeには多少の余裕を持たせておくのが実務上の注意点だ（後述）。
Auto Scalingグループの構成指針
1. 最小・希望・最大台数の設定基準
aws ec2可用性を本番環境で確保するには、最小台数（min_size）の設定が最も重要だ。一般的な指針を以下に示す。| 設定項目 | 推奨値 | 理由 |
|---|---|---|
| 最小台数（min_size） | 使用AZ数以上（3AZ構成なら3以上） | 1AZ障害時も残りのAZで最低1台確保できる |
| 希望台数（desired_capacity） | 通常負荷で必要な台数（min_size以上） | 日常運用の基準値。スケーリング時の出発点になる |
| 最大台数（max_size） | ピーク想定台数の1.5倍程度 | スパイク対応とAZリバランシング時の一時増加に対応する |
2. ヘルスチェック種別の選び方（EC2 vs ELB）
ASGのヘルスチェック種別には「EC2」と「ELB」の2つがある。デフォルトは「EC2」だが、実務ではほぼ「ELB」を選択するべきだ。・EC2ヘルスチェック：インスタンスのシステム状態（ハードウェア障害・停止）のみを検知する。アプリケーションがハングしていても検知できない
・ELBヘルスチェック：ALBがアプリケーション層（HTTP/HTTPSの応答確認）でチェックし、異常があればASGに通知する。アプリケーション障害を検知してインスタンスを自動交換できる
# AWS CLIでASGのヘルスチェックタイプをELBに変更する aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-web-asg \ --health-check-type ELB \ --health-check-grace-period 300
# 正常終了時は出力なし（終了コード0） # --health-check-grace-period はインスタンス起動から # ヘルスチェックを開始するまでの猶予時間（秒） # アプリの起動に時間がかかる場合は300～600秒程度を設定する
3. インスタンス更新ポリシー（Instance Refresh）
AMIを更新してASG内のEC2インスタンスを入れ替える際、一度に全台数を交換するとサービスが一時停止する。「Instance Refresh」機能を使うと、指定した割合の正常稼働台数を維持しながら段階的に入れ替えられる。# Instance Refreshを開始するAWS CLI例 aws autoscaling start-instance-refresh \ --auto-scaling-group-name my-web-asg \ --preferences MinHealthyPercentage=80,InstanceWarmup=300
{ "InstanceRefreshId": "ab123456-1234-abcd-1234-ab1234567890" }
AWS EC2の可用性設計をしっかり学んでAWSの本番環境を構築したい方には、AWSのAmazon Linux実践ガイドも参考にしてください。VPCの基礎から本番運用まで体系的に解説しています。
よくあるトラブルと対処法
1. AZのインスタンス分散が偏る問題
スポットインスタンスを使っている場合、特定のAZでスポット容量が枯渇すると、インスタンスが1つのAZに偏ることがある。ASGのAZリバランシングが動作するが、スポット容量が回復しないと解消されない。・対処法：オンデマンドインスタンスを最小台数分確保した上でスポットを追加する「混合インスタンスポリシー」を使い、最低限の可用性を担保する
2. 起動直後にヘルスチェックが失敗してインスタンスが終了される問題
ELBヘルスチェックを設定した直後や、アプリケーションの起動が遅いシステムで「新インスタンスが起動するたびに即終了される」トラブルが発生することがある。原因のほとんどは猶予時間（grace period）が短すぎることだ。・対処法：`health-check-grace-period` をアプリ起動時間の2倍程度に設定する。起動ログ（`/var/log/cloud-init-output.log`）を確認して実際の起動所要時間を把握してから値を決める
3. max_sizeに達してAZリバランシングが止まる問題
AZリバランシング中に一時的にmax_sizeを超えようとするが、上限に到達すると新インスタンスの起動ができず、分散が中断する。その後に古いインスタンスが残り続けるケースがある。・対処法：max_sizeをdesired_capacityの1.5倍程度に設定し、リバランシング時の一時的な増加に対応できる余裕を確保する
本記事のまとめ
AWS EC2の可用性を高める設計の要点を整理する。| 設計項目 | 推奨設定・ポイント |
|---|---|
| マルチAZ配置 | プライベートサブネットを各AZに作成し、ASGに複数AZを指定する |
| 最小台数（min_size） | 使用AZ数以上に設定（3AZ構成なら3以上） |
| ヘルスチェック種別 | EC2タイプではなくELBタイプを使う（アプリ障害も検知可能） |
| 猶予時間（grace period） | アプリ起動時間の2倍程度を設定する（デフォルト300秒は要確認） |
| max_size | desired_capacityの1.5倍程度（リバランシング余裕を確保） |
| Instance Refresh | MinHealthyPercentage=80以上でローリング更新を実施する |
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
AWSでLinuxサーバーを構築・運用するための実践知識を体系的に学べる無料マニュアルをご用意しています。VPCの基礎から本番運用のポイントまで、図解60ページでわかりやすく解説しています。
＞＞ AWSのAmazon Linux実践ガイドを無料で受け取る
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：AWSアーキテクチャ図サンプル集｜Terraform構成ファイルと対応させる読み方
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます