マルチAZ構成とオートスケーリング入門 可用性を高めるAWS設計パターン

「EC2を1台で動かしているけど、障害が起きたらサービスが止まる。冗長化ってどうやるの？」

オンプレミスでサーバーの冗長化やロードバランサーの導入を経験してきたエンジニアにとって、クラウドの可用性設計は馴染みのある考え方です。しかし、AWSではアベイラビリティゾーン（AZ）という独自の概念があり、オンプレの「データセンター2拠点構成」とは設計の粒度が異なります。

この記事では、AWSにおけるマルチAZ構成とオートスケーリングの仕組みを、オンプレの冗長化設計と比較しながら解説します。設計パターン、設定手順、料金の考え方、現場でよくあるトラブルまで網羅しているので、可用性の高いシステムを構築するための全体像が掴めます。

なぜマルチAZ構成が必要なのか

オンプレミスでは、1つのデータセンター内でサーバーを冗長化するのが第一段階でした。電源やネットワークの二重化、HA（High Availability）クラスタの構成、そしてコストに余裕があればDR（Disaster Recovery）用に別拠点を用意する。この段階的なアプローチが一般的だったはずです。

AWSでは、リージョン内に複数のアベイラビリティゾーン（AZ）が用意されています。東京リージョン（ap-northeast-1）には4つのAZがあり、それぞれが物理的に離れた独立のデータセンター群です。電源・冷却・ネットワークが独立しているため、1つのAZで障害が発生しても他のAZには影響しません。

ここがオンプレとの大きな違いです。オンプレでDR拠点を用意するには莫大なコストと時間がかかりましたが、AWSではAZを分散させるだけで同等以上の可用性を手に入れられます。しかもAZ間のレイテンシは1ミリ秒以下に設計されているため、同期レプリケーションも現実的です。

マルチAZ構成の基本パターン

1. ALB + EC2の2AZ分散

もっとも基本的な構成は、Application Load Balancer（ALB）の背後にEC2インスタンスを2つ以上のAZに配置するパターンです。

# 構成イメージ
#
# [インターネット]
#       |
#    [ALB] ← 複数AZにまたがって配置
#     / \
#   [EC2]  [EC2]
#   AZ-1a  AZ-1c
#     |      |
#   [RDS Primary] ← [RDS Standby]
#     AZ-1a          AZ-1c

ALBは複数のAZにまたがって動作し、ヘルスチェックに失敗したインスタンスへのトラフィックを自動的に停止します。オンプレのロードバランサー（F5 BIG-IPやNetScaler）と考え方は同じですが、ALB自体がマネージドサービスなので、ロードバランサーの冗長化を自分で考える必要がありません。

2. RDSのマルチAZ配置

Amazon RDSのマルチAZオプションを有効にすると、プライマリインスタンスとは別のAZにスタンバイインスタンスが自動的に作成されます。プライマリに障害が発生した場合、DNSのフェイルオーバーによって60〜120秒程度でスタンバイに切り替わります。

オンプレでOracle Data GuardやSQL Server Always Onを構成していた方なら、「同期レプリケーション+自動フェイルオーバー」の仕組みは理解しやすいでしょう。ただし、RDSのマルチAZではスタンバイを読み取りに使えない点に注意してください。読み取り負荷を分散させたい場合は、リードレプリカを別途作成する必要があります。

3. S3・DynamoDBは最初からマルチAZ

Amazon S3やAmazon DynamoDBは、利用者が意識しなくても自動的に複数AZにデータが分散されています。S3は最低3つのAZにオブジェクトを冗長保存し、99.999999999%（イレブンナイン）の耐久性を実現しています。

オンプレのストレージでRAIDやレプリケーションを組んでいた苦労を考えると、この自動冗長化はクラウドの大きなメリットです。

オートスケーリングの仕組み

1. Auto Scaling Groupとは

Amazon EC2 Auto Scaling の Auto Scaling Group（ASG）は、EC2インスタンスの数を負荷に応じて自動で増減させる仕組みです。オンプレでは「ピーク時に合わせてサーバーを用意しておく」のが当たり前でしたが、AWSではピーク時だけインスタンスを増やし、閑散時に減らすことでコストを最適化できます。

ASGの基本パラメータは3つです。

・最小キャパシティ: 常に維持するインスタンス数の下限
・最大キャパシティ: スケールアウト時の上限
・希望キャパシティ: 通常時に維持したいインスタンス数

2. スケーリングポリシーの種類

・ターゲット追跡スケーリング: 「CPU使用率を50%に維持する」のように目標値を指定する。もっとも簡単で推奨される方式
・ステップスケーリング: 「CPU使用率70%超で2台追加、90%超で4台追加」のように段階的に定義する
・スケジュールスケーリング: 「毎朝9時に5台、夜22時に2台」のように時間指定で変更する。トラフィックパターンが予測可能な場合に有効
・予測スケーリング: 過去のメトリクスからトラフィックパターンを機械学習し、事前にスケールアウトする

現場でもっとも使いやすいのはターゲット追跡スケーリングです。細かなしきい値の調整が不要で、AWSが自動的にインスタンスの増減を判断してくれます。

3. マルチAZとオートスケーリングの組み合わせ

ASGに複数のAZを指定すると、インスタンスがAZ間で均等に分散配置されます。たとえば希望キャパシティが4台で2つのAZを指定した場合、各AZに2台ずつ配置されます。1つのAZで障害が発生しても、残りのAZのインスタンスが稼働を続け、ASGが自動的に正常なAZに新しいインスタンスを起動します。

これはオンプレの「アクティブ-アクティブ構成+自動復旧」に相当しますが、数分で新しいサーバーが立ち上がるスピード感はクラウドならではです。

AWS CLIでの設定手順

1. 起動テンプレートの作成

# AWS CLI: 起動テンプレートの作成
aws ec2 create-launch-template \
  --launch-template-name web-server-template \
  --version-description "v1" \
  --launch-template-data '{
    "ImageId": "ami-0123456789abcdef0",
    "InstanceType": "t3.medium",
    "SecurityGroupIds": ["sg-0123456789abcdef0"],
    "UserData": "base64エンコードされた起動スクリプト"
  }'

2. Auto Scaling Groupの作成（マルチAZ）

# AWS CLI: ASGの作成（2AZ分散）
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-server-template,Version='$Latest' \
  --min-size 2 \
  --max-size 8 \
  --desired-capacity 4 \
  --vpc-zone-identifier "subnet-aaa111,subnet-bbb222" \
  --target-group-arns "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/web-tg/abc123" \
  --health-check-type ELB \
  --health-check-grace-period 300

3. ターゲット追跡スケーリングポリシーの設定

# AWS CLI: CPU使用率50%を目標に自動スケーリング
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0,
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }'

ScaleOutCooldown（スケールアウト後の待機時間）を短めに、ScaleInCooldown（スケールイン後の待機時間）を長めに設定するのが実務上のコツです。スケールアウトは素早く、スケールインは慎重にすることで、不要なインスタンスの起動・停止の繰り返し（フラッピング）を防げます。

料金の仕組み

マルチAZ構成とオートスケーリングに関連する料金を整理します（2026年3月時点）。

コストを意識するポイントは、RDSマルチAZの料金とAZ間データ転送料金です。RDSマルチAZはシングルAZの約2倍になりますが、障害時の手動復旧コスト（人件費・ダウンタイムの損失）を考えれば、本番環境では投資に見合う選択です。

AZ間データ転送は1GBあたり$0.01と少額ですが、大量のデータを同期するシステムでは積み重なります。キャッシュ層（ElastiCache）を各AZに配置して、AZ間通信量を減らす工夫が効果的です。

よくあるトラブルと対処法

1. 「スケールアウトしたのにレスポンスが改善しない」

新しいインスタンスが起動してからアプリケーションが使えるようになるまでには時間がかかります。ヘルスチェックの猶予期間（health-check-grace-period）が短すぎると、起動途中のインスタンスが異常と判定されて終了→再起動の無限ループに陥ることがあります。

アプリケーションの起動時間を計測し、余裕を持った猶予期間を設定してください。AMIにアプリケーションをプリインストールしておく（ゴールデンAMI戦略）ことで起動時間を短縮する方法も有効です。

2. 「1つのAZにインスタンスが偏る」

ASGはAZ間の均等分散を目指しますが、特定のインスタンスタイプの在庫がないAZではインスタンスが起動できず、偏りが生じることがあります。起動テンプレートで複数のインスタンスタイプを指定する「混合インスタンスポリシー」を使えば、在庫不足による偏りを軽減できます。

3. 「RDSのフェイルオーバーでアプリが切断エラーになる」

RDSマルチAZのフェイルオーバー時にはDNSが切り替わります。アプリケーション側でデータベース接続をキャッシュしていると、切り替え後も古いIPに接続しようとしてエラーが続きます。

コネクションプーリングのライブラリで接続の有効期限を設定するか、接続エラー時にリトライする実装を入れてください。DNS TTLはRDSのエンドポイントで5秒に設定されているため、アプリ側のDNSキャッシュもそれに合わせた短い値にするのがポイントです。

4. 「オートスケーリングが想定より遅い」

CloudWatchメトリクスの収集間隔はデフォルトで5分です。詳細モニタリングを有効にすると1分間隔になり、スケーリングの反応速度が向上します。詳細モニタリングの追加料金は1インスタンスあたり$2.10/月（2026年3月時点）です。

また、予測スケーリングを併用すれば、過去のパターンから事前にスケールアウトを開始できます。毎朝決まった時間にアクセスが増えるようなシステムでは効果的です。

本記事のまとめ

マルチAZ構成とオートスケーリングは、AWSで可用性の高いシステムを設計するうえで避けて通れない基本パターンです。オンプレで冗長構成を組んだ経験があれば、「AZ = 独立したデータセンター」「ASG = サーバーの自動復旧 + 自動増減」と読み替えるだけで、設計の土台はすでにできています。

大事なのは、最初から完璧な構成を目指すことではなく、まずは2AZ分散を基本に始めて、実際のトラフィックパターンやコストを見ながら調整していくことです。Auto Scalingのメトリクスとコストレポートを定期的に確認し、過剰なスケールアウトやAZ間転送コストの無駄がないかチェックする運用を習慣づけてください。

クラウド上のLinuxサーバー構築やEC2の基本操作については、姉妹サイトLinuxMaster.JPで詳しく解説しています。EC2インスタンスの初期設定やセキュリティ強化について深掘りしたい方はあわせてご覧ください。