サービスを本番運用し始めると、必ず突き当たる壁です。
AWSのマルチAZ冗長構成は、単に「複数のAZに同じサーバーを並べる」だけでは成立しません。VPCのサブネット設計、ロードバランサー、RDSやElastiCache側のフェイルオーバー設定まで、一連のパーツが噛み合って初めて「止まらないシステム」が実現できます。
この記事では、AWSマルチAZ冗長構成の設計パターンと実装上の注意点を解説します。
コマンド単体の使い方ではなく、「なぜそう設計するのか」「どこが落とし穴か」という設計思想から掘り下げていきます。
この記事のポイント
・マルチAZはVPCサブネット設計から始まる
・ALB＋Auto Scalingで自動復旧するWeb層を作る
・RDSのマルチAZはプライマリ障害時に自動昇格する
・設計の落とし穴はセッション管理とDNS TTLにある
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
マルチAZとは何か？AWSアベイラビリティゾーンの仕組み
AWSのリージョン（例：ap-northeast-1 東京）は、物理的に独立した複数のデータセンター群——アベイラビリティゾーン（AZ）——で構成されています。東京リージョンであれば ap-northeast-1a / 1c / 1d の3つのAZがあります。
各AZは独立した電力・ネットワーク・冷却設備を持ち、AZ間はAWS専用の低遅延ネットワークで繋がっています。
つまり、あるAZで電源障害が発生しても、別のAZには影響が及ばないように設計されています。
マルチAZ冗長構成とは、このAZの独立性を活かして、複数のAZにシステムコンポーネントを分散配置することです。
1つのAZが完全に停止しても、別のAZで処理を継続できる状態を作ります。
シングルAZ構成との違い
・シングルAZ：安価だが、AZ障害でシステム全停止
・マルチAZ：コストは増えるが、AZ障害でも自動継続
AWSのSLA（サービス品質保証）でもマルチAZ構成を前提としたものが多く、本番サービスではマルチAZが事実上の標準です。
VPCとサブネット設計｜マルチAZ冗長の基盤
マルチAZ構成はVPC（Virtual Private Cloud）のサブネット設計から始まります。ここを正しく設計しておかないと、後からどれだけサービスを追加しても冗長構成は成り立ちません。1. 基本的なVPCサブネット構成パターン
標準的な3層構成（Web層・アプリ層・DB層）でのサブネット設計例です。# VPC全体（例） VPC CIDR: 10.0.0.0/16 # AZ-a のサブネット Public Subnet-a: 10.0.1.0/24 （Web層・ALB配置） Private Subnet-a: 10.0.11.0/24 （アプリ層・EC2配置） DB Subnet-a: 10.0.21.0/24 （DB層・RDS配置） # AZ-c のサブネット Public Subnet-c: 10.0.2.0/24 （Web層・ALB配置） Private Subnet-c: 10.0.12.0/24 （アプリ層・EC2配置） DB Subnet-c: 10.0.22.0/24 （DB層・RDS配置）
Web層のサブネットをAZ-aだけに作ってしまうと、そのAZが停止した瞬間にWebへのアクセスが途絶えます。
2. パブリック・プライベートの使い分け
インターネットから直接アクセスを受けるリソース（ALBなど）はパブリックサブネットに配置します。EC2インスタンスやRDSは原則プライベートサブネットに置き、直接外部に露出させないのが基本です。
・パブリックサブネット：インターネットゲートウェイへのルートを持つ
・プライベートサブネット：NATゲートウェイ経由でアウトバウンドのみインターネット接続
・DB専用サブネット：アウトバウンドも不要な場合はルートなしで完全分離
3. Nat Gatewayのマルチ配置
コスト削減のためにNATゲートウェイを1つのAZにだけ置くケースをよく見かけますが、これは冗長設計の落とし穴です。AZ-aにあるNATゲートウェイが停止すると、AZ-cのプライベートサブネットからのアウトバウンド通信も止まります。
本番環境では各AZに1つずつNATゲートウェイを配置してください。コストは増えますが、AZ障害時の影響を最小化できます。
Web層の冗長設計｜ALBとAuto Scaling
Web層の冗長化は、ALB（Application Load Balancer）とAuto Scalingグループの組み合わせが定番パターンです。1. ALBのマルチAZ設定
ALBを作成する際、複数のAZのサブネットを登録することで、ALB自体がマルチAZ対応になります。ALBはDNSベースで負荷分散するため、特定のAZが停止してもエンドポイントURLは変わりません。
# AWS CLIでALBのサブネット確認例 aws elbv2 describe-load-balancers \ --names my-alb \ --query 'LoadBalancers[].AvailabilityZones[].SubnetId' \ --output text # 出力例（AZ-aとAZ-cのサブネットが登録されていることを確認） subnet-0a1b2c3d4e5f subnet-9z8y7x6w5v4u
2. Auto Scalingグループのマルチ配置
Auto ScalingグループにプライベートサブネットのAZ-a・AZ-c両方を指定します。EC2インスタンスを2台起動する設定であれば、理想的には各AZに1台ずつ配置されます。
# Auto ScalingグループのAZ配置確認 aws autoscaling describe-auto-scaling-groups \ --auto-scaling-group-names my-asg \ --query 'AutoScalingGroups[].AvailabilityZones' \ --output text # 出力例 ap-northeast-1a ap-northeast-1c
この自動復旧をヘルスチェックが検知してから実行するまでの時間（通常3分～10分）がRPO（目標復旧時点）の目安になります。
3. セッション管理の落とし穴
マルチAZでALBが複数のEC2に振り分けると、ユーザーのセッション情報が別のEC2に保存されている問題が起きます。解決策は2つです。
・スティッキーセッション（ALBのターゲットグループ設定）：同じユーザーを同じEC2に固定する。簡単だが、EC2停止時にセッションが消える
・外部セッションストア（ElastiCache Redis等）：セッション情報をEC2の外に保存する。EC2が変わってもセッションが維持される
本番運用では、後者のElastiCacheを使った外部セッションストアが推奨です。
DB層の冗長設計｜RDSマルチAZの仕組み
RDS（Relational Database Service）のマルチAZ機能は、AWS側が自動的に別AZにスタンバイレプリカを管理してくれる仕組みです。1. RDSマルチAZの自動フェイルオーバー
RDSマルチAZ構成では、プライマリDBとスタンバイDBが常に同期レプリケーション（Synchronous Replication）されています。プライマリDBが停止すると、通常60秒～2分でスタンバイがプライマリに昇格し、接続エンドポイント（DNSが指すIPアドレス）が自動で切り替わります。
# RDSマルチAZ設定の確認 aws rds describe-db-instances \ --db-instance-identifier mydb \ --query 'DBInstances[].[MultiAZ,AvailabilityZone,SecondaryAvailabilityZone]' \ --output text # 出力例（マルチAZ有効時） True ap-northeast-1a ap-northeast-1c
2. RDSフェイルオーバー時のDNS TTL問題
フェイルオーバー時にDNSのIPアドレスが切り替わりますが、アプリケーション側でDNSのTTLを長く設定していると、古いIPに接続し続けてしまいます。・RDSエンドポイントのTTL：5秒（AWSが設定）
・アプリ側JDBCやpg接続設定のconnectTimeout：できるだけ短く設定する
・接続プールの設定：接続失敗時に自動再接続する設定を入れる
RDSエンドポイントのTTLは短いですが、OSやJVMのDNSキャッシュが長い場合は切り替えが遅れます。
JavaアプリはJVMの`networkaddress.cache.ttl`を60秒以下に設定することを推奨します。
Linux DNS 設定の基本も参考にしてください。
3. ElastiCacheのマルチAZ設定
ElastiCache（RedisやMemcached）もマルチAZで配置できます。Redisではクラスターモードを有効にし、レプリケーショングループを複数AZに分散することで、AZ障害時でもキャッシュが継続します。
セッションストアやキャッシュ層がダウンすると、全リクエストがDBに直撃してDBが過負荷になる「キャッシュスタンピード」が発生します。
ElastiCacheもDB同様にマルチAZで冗長化してください。
実際の障害シナリオで確認する設計チェックリスト
設計が正しいかどうかは、障害シナリオを想定してチェックするのが一番確実です。1. AZ-a全停止シナリオ
AZ-aが停止した場合、以下が自動で起きることを確認します。・ALB：AZ-aへのルーティングを自動停止し、AZ-cのEC2だけに振り分ける → ALBが複数AZのサブネットを設定しているか確認
・Auto Scaling：AZ-aのEC2が停止したことをヘルスチェックで検知し、AZ-cに新しいEC2を起動する → ASGの最小台数と希望台数を確認
・RDS：プライマリがAZ-aにあった場合、AZ-cのスタンバイが昇格する → マルチAZが有効になっているか確認
・ElastiCache：プライマリノードがAZ-aにあった場合、AZ-cのレプリカが昇格する → レプリケーショングループが別AZに存在するか確認
2. 落とし穴のある設計パターン
以下のパターンは一見マルチAZに見えても、障害時に問題が発生します。| 落とし穴 | 具体的な問題 | 対策 |
|---|---|---|
| NATゲートウェイを1つのAZのみに配置 | そのAZが停止すると全プライベートサブネットのアウトバウンドが止まる | 各AZにNATゲートウェイを1つずつ配置する |
| EC2インスタンスを1台のみ運用 | ヘルスチェック失敗からASGが新EC2を起動するまでの数分間サービス停止 | 常時2台以上（各AZに1台）を維持する |
| RDSのマルチAZを有効にしていない | EC2はマルチAZでも、DBが単一障害点になる | 本番RDSは必ずマルチAZを有効化する |
| セッションをEC2のローカルに保存 | ALBがEC2を切り替えるたびにセッションが消える | ElastiCacheなどの外部セッションストアを使う |
| 接続プールでDNSキャッシュが長い | RDSフェイルオーバー後も旧プライマリへ接続し続ける | JVM/アプリのDNSキャッシュTTLを60秒以下に設定 |
AWS冗長構成のコスト試算と段階的な導入方針
マルチAZ構成はシングルAZより確実にコストが上がります。具体的には以下のコストが増加します。
・EC2インスタンス：最低2倍（各AZに1台）
・RDSマルチAZ：約2倍（スタンバイレプリカ分）
・NATゲートウェイ：AZ数分（東京リージョンなら2～3個）
・ElastiCacheレプリカ：レプリカ数に応じて追加
コスト最適化のための段階的な導入例を紹介します。
・ステージ1（最小マルチAZ）：ALB＋EC2×2台（各AZ1台）＋RDSマルチAZ。NATゲートウェイは1つに留める。コスト優先の初期構成
・ステージ2（推奨構成）：NATゲートウェイをAZごとに配置。ElastiCacheをマルチAZ化。セッションを外部ストアへ移行
・ステージ3（高可用性構成）：Auto Scalingの最小台数をAZ数の倍数に設定。Multi-AZ Readerで読み取り性能も強化
まずステージ1でRDSのマルチAZを確保し、サービスが安定してきたらステージ2へ移行するのが現実的です。
トラブルシュート｜マルチAZ構成でよくある問題
1. フェイルオーバーが起きたのにアプリが復旧しない
RDSのフェイルオーバーが完了しているのにアプリが接続できない場合、原因の多くはDNSキャッシュです。# RDSエンドポイントのIPアドレスを確認する host mydb.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com # 古いIPが返ってくる場合は接続プールの再起動を試みる # アプリケーションサーバー上での確認例 dig mydb.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com +short
IPが変わっているのにアプリが繋がらない場合は、JVMやOSのDNSキャッシュが原因です。アプリを再起動することで接続が回復します。
Linuxサーバー上でのポート疎通確認はLinux ポート確認の全コマンドも参考にしてください。
2. Auto ScalingがAZ-aにしかEC2を起動しない
Auto ScalingグループにAZ-cのサブネットが登録されていないケースです。# ASGのサブネット設定を確認する aws autoscaling describe-auto-scaling-groups \ --auto-scaling-group-names my-asg \ --query 'AutoScalingGroups[].VPCZoneIdentifier' \ --output text # 複数のサブネットIDがカンマ区切りで出力されることを確認 # 例: subnet-0a1b2c3d,subnet-9z8y7x6w
3. ALBがAZ-aのEC2にだけ負荷を集中させる
ALBのクロスゾーン負荷分散が無効の場合、各AZへのリクエスト量が偏ることがあります。ALBはデフォルトでクロスゾーン負荷分散が有効ですが、NLBやGateway LBではデフォルト無効なので注意してください。
# ALBのクロスゾーン負荷分散設定を確認する aws elbv2 describe-load-balancer-attributes \ --load-balancer-arn arn:aws:elasticloadbalancing:... \ --query 'Attributes[?Key==`load_balancing.cross_zone.enabled`]' # 出力例（有効時） [{"Key": "load_balancing.cross_zone.enabled", "Value": "true"}]
本記事のまとめ
AWSでマルチAZ冗長構成を設計する際の要点をまとめます。| レイヤー | 冗長化の方法 | 注意点 |
|---|---|---|
| VPC・サブネット | 各AZに同じ役割のサブネットを作成 | NATゲートウェイも各AZに1つずつ配置する |
| Web層（EC2） | ALB＋Auto Scalingで各AZにEC2を分散 | セッションは外部ストア（ElastiCache）に保存する |
| DB層（RDS） | マルチAZを有効化してスタンバイを別AZに配置 | アプリ側のDNSキャッシュTTLを短く設定する |
| キャッシュ層（ElastiCache） | レプリケーショングループを別AZに配置 | 障害時は自動昇格まで一時的にキャッシュが失われる |
| ネットワーク（NATゲートウェイ） | AZごとに1つずつ配置 | 1つのAZに集約するとAZ障害で全プライベートサブネットのアウトバウンドが止まる |
設計段階で各レイヤーの単一障害点（SPOF）を潰し、定期的に障害シミュレーション（AWS FISやカオスエンジニアリング）で実際の動作を確認することが大切です。
AWSのより詳しい設計・実践については、AWS冗長構成の設計実践ガイドもあわせてご覧ください。
AWS上でLinuxサーバーを動かすための基礎から学びたい方は、AWSでLinuxサーバーを構築する入門講座からどうぞ。
Linux無料マニュアルを受け取る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：AWS VPC設計入門｜サブネット・セキュリティグループ・NATの基礎ハンズオン
- 前のページへ：AWS用語解説
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます