オンプレでサーバーの冗長化設計をやってきたエンジニアなら、「アクティブ-アクティブ」と「アクティブ-パッシブ」という言葉は何度も使ってきたはずだ。しかしクラウドに移行すると、この2つの概念が各サービスによって異なる形で実装されているため、どのサービスがどちらに該当するのかがわかりにくくなる場面が増える。
たとえばAmazon RDSのマルチAZ構成はアクティブ-パッシブだ。一方、ALBにぶら下がるEC2 Auto Scalingグループはアクティブ-アクティブになる。どちらも「マルチAZ構成」と呼ばれるが、フェールオーバー時の挙動もRTOまったく異なる。ここを理解していないと、「マルチAZにしたから大丈夫」という誤った安心感で設計を終えてしまう。
この記事では、アクティブ-アクティブとアクティブ-パッシブの本質的な違いを整理し、AWS・Azureの主要サービスでどちらが採用されているかを具体的に解説する。設計判断の根拠として使えるよう、コストとRTOのトレードオフも含めて説明する。
なぜクラウドでこの区別が重要になるのか
オンプレの時代、HAクラスタやActive/Standbyの切り替えは自分たちで設計し、フェールオーバー時間も実測で把握していた。ところがクラウドでは、マネージドサービスの内部実装が隠蔽されている。
「マルチAZを有効にした」という事実だけでは、そのサービスがアクティブ-アクティブなのかアクティブ-パッシブなのかわからない。これは特に以下の場面で問題になる。
・SLA・SLOの設計時: RTOの見積もりが正確でないと、サービスレベル目標を達成できない
・コスト計算時: スタンバイノードにも課金されるかどうかで月額費用が大きく変わる
・性能設計時: アクティブ-アクティブなら全ノードが負荷分散に寄与するが、アクティブ-パッシブではスタンバイは性能に貢献しない
・障害訓練の計画時: フェールオーバーの実動作を理解していないと、訓練でも本番でも予期しない挙動が起きる
SLA・SLO・SLIの設計を行う際には、このクラウドサービスがどちらの構成なのかを把握した上でRTOを設定する必要がある。
アクティブ-アクティブ構成の仕組みと特徴
アクティブ-アクティブ構成では、複数のノード（サーバー・インスタンス・コンテナ等）が同時に稼働し、全てが実際のトラフィックを処理する。
典型的な構成は、ロードバランサーが複数のバックエンドノードにリクエストを均等に振り分けるモデルだ。オンプレで言えば、F5やNetScalerで複数の実サーバーにトラフィックを分散している状態がこれに近い。
アクティブ-アクティブの主な特性
・フェールオーバー速度: あるノードが障害を起こしても、ロードバランサーがそのノードへの振り分けを止めるだけで、他のノードはすでに稼働中なのでRTOは数秒以内になることが多い
・リソース効率: 全ノードが常時トラフィックを処理するため、スタンバイを「遊ばせる」コストがない
・水平スケーリングとの親和性: ノードを追加するだけでキャパシティが線形に増える
・状態管理の複雑さ: セッション情報やDBへの書き込みが複数ノードに分散するため、整合性の維持が設計上の課題になる
アクティブ-アクティブが向くケース
ステートレスなWebアプリケーション層やAPIサーバー層は、アクティブ-アクティブに最も向いている。リクエストごとに状態を持たないので、どのノードがリクエストを処理しても結果が変わらないためだ。
一方で、単一書き込みノードが必要なDBの書き込み層には向かない。複数ノードが同時に同じデータを書き込もうとすると、競合や整合性の破壊が起きやすくなる。
アクティブ-パッシブ構成の仕組みと特徴
アクティブ-パッシブ構成では、プライマリが通常の処理を担い、セカンダリはスタンバイ状態で待機する。セカンダリは通常のトラフィックを処理せず（あるいはリードオンリーのみ）、プライマリが障害を起こしたときにのみ昇格して処理を引き継ぐ。
オンプレで言えば、WindowsのFailover ClusteringやLinuxのPacemakerによるActive/Standby構成がこれに相当する。
アクティブ-パッシブの主な特性
・フェールオーバー速度: スタンバイからプライマリへの切り替えに数十秒から数分かかる場合がある。これがRTOの下限値になる
・データ整合性: プライマリ1台のみが書き込みを担当するため、整合性の維持が比較的容易
・リソースコスト: スタンバイも同等のリソースを確保しておく必要があるため、実質2倍のインフラコストになりやすい
・スタンバイの活用: サービスによってはスタンバイをリードレプリカとして活用できるが、フェールオーバーによる昇格中はリードも一時停止する
アクティブ-パッシブが向くケース
DBの書き込み層、認証サーバー、ジョブスケジューラーなど、同時に複数のノードが同じ処理を実行すると問題が起きるコンポーネントに向いている。
また、コストよりも設計のシンプルさを優先したい場面や、フェールオーバー後の状態確認を人手で行うような運用モデルにも適している。
2つの構成の違いを一覧で整理する
| 比較軸 | アクティブ-アクティブ | アクティブ-パッシブ |
|---|---|---|
| 通常時の処理 | 全ノードがトラフィックを処理 | プライマリのみが処理、スタンバイは待機 |
| 障害時の挙動 | 障害ノードへの振り分けを停止、即時継続 | スタンバイをプライマリに昇格して引き継ぎ |
| RTO（目安） | 数秒以内（ヘルスチェック間隔依存） | 数十秒～数分（サービス・設定依存） |
| リソース効率 | 高い（全ノードが有効稼働） | 低い（スタンバイ分のコストが発生） |
| 書き込み整合性 | 複雑（複数ノード間の調整が必要） | 単純（プライマリ1台が書き込みを担当） |
| スケーラビリティ | ノード追加で水平スケール可能 | 基本的にノード数固定（2台構成が多い） |
| 向くコンポーネント | ステートレスなWebアプリ・APIサーバー | DBの書き込み層・ジョブスケジューラー |
AWSサービス別 実装パターン一覧
AWSの主要マネージドサービスが、内部でどちらの構成を採用しているかを整理する。「マルチAZ対応」というラベルだけでは判断できないため、ここで把握しておきたい。
アクティブ-アクティブを採用するAWSサービス
・ALB（Application Load Balancer）+ EC2 Auto Scaling: 複数AZにEC2インスタンスを分散配置し、ALBがヘルスチェックに基づいてリクエストを振り分ける。障害インスタンスはターゲットグループから自動除外され、残存インスタンスが処理を継続する。フェールオーバー時間は実質ゼロに近い
・Amazon ECS / EKS（マルチAZ構成）: タスクやPodを複数AZに分散配置した場合、特定AZの障害時も他AZのタスクが処理を継続する。ECS Service Connectや、EKSのKubernetes Serviceがロードバランシングを担う
・Amazon ElastiCache for Redis（クラスターモード有効）: データをシャーディングして複数ノードに分散する。各シャードがそれぞれのデータセットを処理するアクティブ-アクティブ型の分散構成
・AWS Global Accelerator（複数エンドポイント）: 複数リージョンのエンドポイントを同時に有効化し、最も近いリージョンにルーティングする。あるリージョンが障害時は他リージョンへ自動フェールオーバー
アクティブ-パッシブを採用するAWSサービス
・Amazon RDS マルチAZ（シングルスタンバイ）: これが最も誤解されやすいポイントだ。マルチAZを有効にすると別AZにスタンバイインスタンスが自動作成されるが、このスタンバイは通常のトラフィックを一切処理しない。プライマリ障害時（通常60～120秒程度）のみ自動フェールオーバーが発生し、スタンバイが新プライマリになる
・Amazon Aurora（シングルリージョン）: Auroraのプライマリインスタンスのみが書き込みを担当する。リードレプリカは読み取りのみ処理するため、書き込みに関してはアクティブ-パッシブに相当する。リードレプリカはプライマリ障害時に昇格できる
・Amazon ElastiCache for Redis（クラスターモード無効 + レプリカ）: プライマリが書き込みを担当し、レプリカはリードのみ。プライマリ障害時にレプリカが自動昇格する
・Amazon OpenSearch Service（マスターノード）: 専用マスターノード構成では、1台がアクティブマスター、残りがスタンバイマスターとして待機する
以下にAWSサービスの分類をまとめる。
| AWSサービス | 構成タイプ | フェールオーバー時間の目安 |
|---|---|---|
| ALB + EC2 Auto Scaling | アクティブ-アクティブ | ヘルスチェック失敗まで（10秒前後） |
| Amazon ECS/EKS（マルチAZ） | アクティブ-アクティブ | Pod再スケジュールまで（秒～1分） |
| ElastiCache（クラスターモード有効） | アクティブ-アクティブ（シャーディング） | シャード単位でのフェールオーバー |
| Amazon RDS マルチAZ | アクティブ-パッシブ | 60～120秒（自動フェールオーバー） |
| Amazon Aurora（書き込み） | アクティブ-パッシブ | 30秒前後（レプリカ昇格） |
| ElastiCache（クラスターモード無効） | アクティブ-パッシブ | 数十秒（フェールオーバー） |
| AWS Global Accelerator | アクティブ-アクティブ（マルチリージョン） | DNS伝播なしで即時（1分未満） |
Azureサービス別 実装パターン一覧
アクティブ-アクティブを採用するAzureサービス
・Azure Load Balancer + VM（Availability Zones分散）: 複数のAvailability Zoneにデプロイしたバックエンドプールに対してロードバランシングを行う。あるZoneのVMが障害を起こすと、そのVMへのルーティングが停止し残存VMが処理を継続する
・Azure Kubernetes Service（AKS）マルチゾーン: Podを複数Availability Zoneに分散配置することで、Zone障害時もサービスが継続する。KubernetesのService/Ingressがロードバランシングを担う
・Azure Traffic Manager（Weighted/Performanceルーティング）: 複数エンドポイントを同時に有効化し、重み付けや地理的最適化でトラフィックを分散する。エンドポイント障害時は自動的にトラフィックが健全なエンドポイントに集中する
・Azure Front Door（複数バックエンド）: 複数リージョンのバックエンドを同時稼働させるグローバルロードバランサー。バックエンドのヘルスチェックに基づいて自動フェールオーバーを行う
アクティブ-パッシブを採用するAzureサービス
・Azure SQL Database フェールオーバーグループ: プライマリリージョンのSQLデータベースがすべての書き込みを処理し、セカンダリリージョンはレプリカとして待機する。フェールオーバーグループの自動フェールオーバーポリシーを設定すると、プライマリ障害時に自動的にセカンダリが昇格する（RTOは数十秒～数分）
・Azure Cache for Redis（Geo-replication）: プライマリキャッシュが書き込みを担当し、セカンダリキャッシュはリードのみ。プライマリ障害時の切り替えは手動または自動で行う
・Azure Site Recovery（ASR）: オンプレや別リージョンのVMをDRサイトにレプリケーションし、障害時にフェールオーバーする。通常時はレプリカは待機状態のアクティブ-パッシブ型DR構成
・Azure Virtual Machines（Availability Set内でのHAクラスター）: Windows Server Failover ClusteringやPacemakerを使ったHAクラスターをAzure VM上で構築する場合は、クラスターソフトウェアの設定に応じてアクティブ-パッシブまたはアクティブ-アクティブになる
| Azureサービス | 構成タイプ | フェールオーバー時間の目安 |
|---|---|---|
| Azure Load Balancer（マルチゾーン） | アクティブ-アクティブ | ヘルスプローブ失敗まで（数十秒） |
| AKS（マルチゾーン） | アクティブ-アクティブ | Pod再スケジュールまで（秒～1分） |
| Azure Traffic Manager | アクティブ-アクティブ（マルチエンドポイント） | DNS TTL依存（30秒～数分） |
| Azure SQL Database フェールオーバーグループ | アクティブ-パッシブ | 自動: 数十秒～数分 |
| Azure Cache for Redis（Geo-replication） | アクティブ-パッシブ | 手動切り替え主体 |
| Azure Site Recovery | アクティブ-パッシブ（DR用途） | 手動フェールオーバー時は数時間も可 |
コスト試算で見るトレードオフ
構成タイプによってコストの発生構造が大きく変わる。以下は概算の比較だ（2026年9月時点の東京リージョン料金を参照）。
ケース1: Webアプリサーバー層の冗長化
EC2 c6i.xlarge（4vCPU/8GB）を3台でアクティブ-アクティブ構成にする場合と、アクティブ-パッシブで2台（1台がスタンバイ）にする場合を比較する。
アクティブ-アクティブ（3台すべて稼働）の場合、3台分のEC2料金がかかるが、全3台がトラフィックを処理するため同等キャパシティをアクティブ-パッシブで実現するよりもコスト効率が良い場合がある。2台のアクティブ-パッシブであれば、スタンバイがトラフィックを処理しないため、実質1台分のキャパシティしか利用できないことになる。
ケース2: RDSマルチAZ構成
Amazon RDS db.r6g.large（2vCPU/16GB）のマルチAZ料金は、シングルAZ料金の約2倍になる（スタンバイインスタンスにも同等の料金が課金されるため）。スタンバイは通常時にトラフィックを処理しないため、この「2倍のコスト」はフェールオーバー保証のために支払う保険料と考えると理解しやすい。
実際には、スタンバイを使ったリードレプリカの追加（RDS for MySQLなど）とは別カウントになるため、読み取り性能の向上にはMulti-AZではなくリードレプリカを別途作成する必要がある。
まとめ: コスト最適化の考え方
・ステートレス層（Web・API）: アクティブ-アクティブで全ノードをトラフィック処理に活用し、Auto Scalingで必要量を維持する方がコスト効率が良い
・DB書き込み層: アクティブ-パッシブは避けられないが、スタンバイへのリードオフロードが可能なサービスを選ぶことでスタンバイコストを一部回収できる
・DR用途: フェールオーバーの頻度が低いなら、AWS DR戦略の「Pilot Light」や「Warm Standby」パターンを使ってスタンバイを最小構成に抑える選択肢もある（DR戦略4パターンの詳細はこちら）
設計判断の基準：どちらを選ぶか
実際の設計では、アプリケーションのコンポーネント層ごとに適した構成タイプを選ぶことになる。以下のフローで判断できる。
Step 1: ステートレスか、ステートフルか
まず最初に確認すべきは、そのコンポーネントがリクエスト間で状態を持つかどうかだ。
・ステートレス（各リクエストが独立して完結する）→ アクティブ-アクティブが適している
・ステートフル（セッション・トランザクション状態を持つ）→ 状態の扱い方次第で判断が変わる
Step 2: 書き込みの一貫性要件
・複数ノードへの同時書き込みが許容される（結果整合性でOK）→ アクティブ-アクティブも選択肢
・強整合性が必要（銀行取引・在庫管理など）→ 単一書き込みノードが必要なのでアクティブ-パッシブ寄りの設計
Step 3: RTO要件
・RTOが数秒以内の場合 → アクティブ-アクティブが必要（アクティブ-パッシブではフェールオーバー時間がRTO違反になる）
・RTOが数分以内の場合 → アクティブ-パッシブも選択肢に入る
・RTOが数時間以内（DR用途）→ アクティブ-パッシブ（ASR、AWS Site Recovery等）で十分なケースが多い
Step 4: コスト制約
・コスト最適化が優先 → ステートレス層はアクティブ-アクティブにしてリソースを有効活用
・信頼性が最優先（コストは二次的）→ アクティブ-パッシブでも問題ない。ただしスタンバイの「遊び」コストは計上しておくこと
実際の設計では層ごとに使い分ける
典型的な3層アーキテクチャ（Web層・アプリ層・DB層）では以下のような使い分けが一般的だ。
・Web/アプリ層: アクティブ-アクティブ（ALBやAzure LB + 複数インスタンス）
・キャッシュ層: アクティブ-アクティブ（ElastiCacheクラスターモード）またはアクティブ-パッシブ（シングルノード + レプリカ）
・DB書き込み層: アクティブ-パッシブ（RDSマルチAZ、Azure SQL フェールオーバーグループ）
・DBリード層: アクティブ-アクティブ的に複数リードレプリカを活用可能
AWSのマルチAZ構成とオートスケーリングの詳細も合わせて参照されたい。
よくある設計ミスと対処法
【ミス1】RDSマルチAZをアクティブ-アクティブと混同する
「RDSをマルチAZにしたから読み書きパフォーマンスが2倍になる」と期待するエンジニアがいる。これは誤りだ。RDSのマルチAZはアクティブ-パッシブであり、スタンバイは通常時のクエリを一切処理しない。
読み取り性能を向上させたいなら、マルチAZとは別にリードレプリカを作成する必要がある。RDSのリードレプリカとマルチAZのスタンバイは、別々のインスタンスとして課金される。
【ミス2】アクティブ-アクティブでセッションをローカルメモリに持つ
アクティブ-アクティブ構成では、ロードバランサーが異なるリクエストを異なるインスタンスに振り分ける。ユーザーのセッション情報をインスタンスのローカルメモリに保存すると、振り分け先が変わったときにセッション切れが発生する。
対処法は以下のいずれか。
・ロードバランサーのスティッキーセッション（セッションアフィニティ）を有効化する（ただしノード障害時はセッションが失われる）
・セッション情報をElastiCacheやAzure Cache for Redisなどの外部セッションストアに移す（推奨）
【ミス3】フェールオーバー時間をRTOに算入しない
設計書に「RDS マルチAZで高可用性確保」と書いておきながら、SLAのRTO目標を「30秒以内」と設定するケースがある。RDSのフェールオーバーには通常60～120秒かかるため、これはSLA違反になる。
アクティブ-パッシブ構成でRTO目標を設定する際は、実際のフェールオーバー時間を実測して設定すること。マネジメントコンソールのRDSイベント履歴や、実際に手動フェールオーバーを行ったときの時間を計測して使う。
【ミス4】フェールオーバー後の状態確認を怠る
フェールオーバーが完了した後、新プライマリが正常に処理を引き継いでいるかを確認しないまま放置するケースがある。特にRDSのフェールオーバー後は、アプリケーション側のDB接続エンドポイントが自動的に切り替わるが、コネクションプールがキャッシュした古い接続が残っている場合がある。
Amazon RDS Proxyを使うとフェールオーバー時のコネクション管理が改善されるため、フェールオーバー時のアプリケーション断絶を最小化できる。
【ミス5】マルチリージョンのアクティブ-アクティブでDNSのTTLを長く設定する
Route 53などで複数リージョンのアクティブ-アクティブ構成を組む場合、DNSのTTLが長いと障害時にクライアントが古いエンドポイントにアクセスし続ける。TTLは60秒以下に設定し、フェールオーバーの伝播時間を最小化すること。AWS Global Acceleratorを使えばDNSに依存しないルーティングが可能なため、フェールオーバー時間をさらに短縮できる。
本記事のまとめ
アクティブ-アクティブとアクティブ-パッシブの違いは、クラウド高可用性設計の根幹をなす概念だ。以下に要点を整理する。
・アクティブ-アクティブは全ノードが同時稼働してトラフィックを処理する。RTOが短く、リソース効率が良い一方、状態管理が複雑になる
・アクティブ-パッシブはプライマリのみが稼働し、スタンバイは待機する。書き込みの整合性を保ちやすいが、フェールオーバーに時間がかかりスタンバイのコストが発生する
・AWSのRDSマルチAZはアクティブ-パッシブだ。「マルチAZ＝性能2倍」は誤りで、通常時はスタンバイがトラフィックを一切処理しない
・実際の設計ではWeb/アプリ層はアクティブ-アクティブ、DB書き込み層はアクティブ-パッシブと、コンポーネント層ごとに使い分けるのが正しい
・RTO要件・整合性要件・コスト制約の3軸で判断し、どちらの構成が適切かを決める
| 判断ポイント | アクティブ-アクティブを選ぶ | アクティブ-パッシブを選ぶ |
|---|---|---|
| 状態の有無 | ステートレスなコンポーネント | ステートフルで整合性が重要な処理 |
| RTO要件 | 数秒以内が必要 | 数分の停止が許容できる |
| コスト効率 | 全ノードを有効活用したい | 設計シンプルさを優先できる |
| スケーラビリティ | 水平スケールが必要 | 固定規模で十分 |
| 代表的なユースケース | WebサーバーAPIサーバーECS/EKS | RDSマルチAZ、Azure SQL FG、ASR |
PR
SRE サイトリライアビリティエンジニアリング（O’Reilly）
Googleが実践するSRE手法を体系化した名著。SLI/SLO/SLAの設計からエラーバジェット・フェールオーバー設計まで、高可用性設計の思想と実践が詳述されており、クラウドのHA構成を深く理解したいエンジニアに必読の一冊。
