「フォールトトレランスと高可用性って同じもの？」——クラウド移行の設計レビューで、この疑問が出ない現場をほとんど見たことがない。オンプレ時代は「二重化」で済んでいた話が、クラウドに来とたん急に用語が増えて混乱するのは当然だ。
この記事では、Fault Tolerance（FT）とHigh Availability（HA）の本質的な違いを整理し、AWSとAzureで具体的にどう実装するかを解説する。設計判断の基準と、コストのトレードオフも含めてカバーする。
なぜ「フォールトトレランス」と「高可用性」は混同されるのか
オンプレ時代の二重化は、多くの場合「物理サーバーを2台並べてHAクラスタを組む」という一択だった。そのため「冗長化＝高可用性」という認識が身に染みているエンジニアが多い。
クラウドに移行すると、選択肢が一気に広がる。マルチAZ配置、Auto Scaling、Active-Active構成、レプリケーション……それぞれに異なる可用性の概念が絡んでくる。ここで「FTとHAは別物」という認識がないまま設計すると、コストが跳ね上がるか、逆に本番で痛い目を見る。
一言で整理すると：
・Fault Tolerance（FT）: 障害が起きても無停止で動き続ける設計
・High Availability（HA）: 障害が起きたとき短時間で自動復旧する設計
FTはHAより要求水準が高く、コストも格段に上がる。どちらを選ぶかはビジネス要件次第だ。
フォールトトレランス（Fault Tolerance）とは
1. 定義と仕組み
Fault Toleranceとは、システムの一部が障害を起こしても、ユーザーから見て一切のダウンタイムやデータ損失なしに動き続けることを保証する設計思想だ。
航空機のエンジンが最も分かりやすい例えで、エンジン1基が故障しても残りのエンジンで飛行を続けられる。金融のコアシステムや医療機器制御など、「1秒の停止も許されない」業務に適用される。
FTの実現には次の要素が必要になる：
・同期レプリケーション: 全ノードに即時書き込みが完了するまでコミットしない
・アクティブ-アクティブ構成: 複数ノードが常時稼働してリクエストを処理
・自動フェイルオーバー（ゼロ秒）: クライアントが再試行する必要がない透過的な切り替え
RTOは0秒、RPOは0データ損失が目標になる。
2. AWSにおけるFTの実装例
AWSでFTに近い構成を実現するサービスとして代表的なのはAmazon Aurora Global Databaseだ。プライマリリージョンで書き込みつつ、1秒未満のRPOでセカンダリリージョンにレプリケーションする。リージョン障害時のフェイルオーバーも自動化できる。
# Aurora Global Database の状況確認（AWS CLI） aws rds describe-global-clusters \ --region ap-northeast-1 # フェイルオーバー実行（セカンダリを昇格） aws rds failover-global-cluster \ --global-cluster-identifier my-global-cluster \ --target-db-cluster-identifier arn:aws:rds:us-east-1:123456789:cluster:my-secondary
Amazon S3は別の意味でFT的な設計で、データを最低3つのAZに自動レプリケーションし、イレブンナインの耐久性を実現している。ただしS3はオブジェクトストレージなので、RDBの代替にはならない。
EC2でFTを実現しようとすると、EC2 Auto RecoveryやElastic Fabric Adapter（EFA）を組み合わせたActive-Active構成になり、コストは大幅に上がる。
高可用性（High Availability）とは
1. 定義と仕組み
High Availabilityとは、一定期間内のシステム稼働率をSLAとして定義し、障害時は許容される停止時間内に自動復旧する設計だ。「99.9%以上の稼働率を保証する」「障害後5分以内に復旧する」といった形で要件を定義する。
稼働率と許容停止時間の関係を把握しておくと設計がしやすい：
| 稼働率 | 年間許容停止時間 | 月間許容停止時間 |
|---|---|---|
| 99%（ツーナイン） | 87.6時間 | 7.3時間 |
| 99.9%（スリーナイン） | 8.76時間 | 43.8分 |
| 99.99%（フォーナイン） | 52.6分 | 4.38分 |
| 99.999%（ファイブナイン） | 5.26分 | 26.3秒 |
HAの実現には短時間のダウンタイムが「許容される」前提がある。障害検知→フェイルオーバー→DNS切り替えの一連のプロセスで数秒～数分の停止が発生することは許容内とする考え方だ。
2. AWSにおけるHA実装例
AWSでHAを実現する代表的な構成はマルチAZ配置だ。Amazon RDSのマルチAZ配置では、プライマリとスタンバイを別AZに配置し、プライマリ障害時に自動フェイルオーバーする（通常60秒～120秒程度）。
# RDS マルチAZ確認（AWS CLI） aws rds describe-db-instances \ --query 'DBInstances[*].[DBInstanceIdentifier,MultiAZ,AvailabilityZone]' \ --output table # EC2 AutoScaling ヘルスチェック設定例 aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --health-check-type ELB \ --health-check-grace-period 300
EC2では、Application Load Balancer（ALB）＋Auto ScalingグループをマルチAZで構成することが標準的なHA設計になる。1台が落ちてもALBが検知してトラフィックを迂回させ、Auto Scalingが新しいインスタンスを起動する。この間にダウンタイムが数秒～数十秒発生することは許容される設計だ。
フォールトトレランス vs 高可用性：設計上の違い
| 観点 | Fault Tolerance（FT） | High Availability（HA） |
|---|---|---|
| 障害時の挙動 | 無停止で継続（透過的） | 短時間停止後に自動復旧 |
| RTO目標 | 0秒 | 数秒～数分 |
| RPO目標 | 0（データ損失なし） | 数秒～数分のデータ損失を許容 |
| 構成の複雑さ | 高い | 標準的 |
| コスト | 高い（2倍以上になることも） | HAに比べて抑えられる |
| 典型的なユースケース | 金融コアシステム、医療機器制御 | Webアプリ、業務システム全般 |
| AWSの代表例 | Aurora Global DB、S3 | RDSマルチAZ、ALB+ASG |
コストの現実とトレードオフ
設計の意思決定で一番難しいのは「どこまでやるか」の判断だ。RTO/RPOの要件を業務部門から引き出し、その水準に見合うコストを提示する作業が現場では必要になる。
参考として、東京リージョン（ap-northeast-1）の料金感を挙げる（2026年5月時点）。
・RDS MySQL シングルAZ（db.t3.medium）: 約$0.085/時間（月額約$62）
・RDS MySQL マルチAZ（db.t3.medium）: 約$0.170/時間（月額約$124）— HA構成でほぼ2倍
・Aurora Global Database（db.r6g.large × 2リージョン）: 月額$300～— FT水準で5倍以上になることも
「どうせならFTにしよう」という判断はコストを正しく把握した上で下さないと、後から予算を削られてアーキテクチャの作り直しになる。稼働率ごとの許容停止時間を業務部門に数字で示し、RTO/RPO要件を合意してから設計に入るのが正しい順序だ。
実務Tips：オンプレ経験者が陥りやすい誤解
オンプレからクラウドに移行するエンジニアが特に混乱するポイントをまとめた。
・「マルチAZにすれば完璧」という思い込み: マルチAZはHAであってFTではない。RDSのマルチAZフェイルオーバーには60秒以上かかる場合がある。金融系のトランザクションで60秒の停止が許容されないなら、Auroraや専用のActiveActiveアーキテクチャが必要だ。
・非同期レプリケーションを同期と勘違い: RDSのリードレプリカは非同期レプリケーションなので、プライマリ障害時にデータ損失が発生する可能性がある。RPO=0が必要ならマルチAZ構成を使うこと。
・ロードバランサーをFTの代替と見なす: ALBはトラフィックを迂回させるが、バックエンドのインスタンスが全滅すればサービスは停止する。HA設計ではAuto Scalingと組み合わせて最小稼働台数を保証することが前提になる。
・AZが1つなら「2台並べても意味がない」: 同一AZ内のインスタンス2台は、そのAZのインフラ障害が発生した場合は共倒れになる。AZ障害に備えるにはマルチAZ配置が必須だ。
Azureの場合、可用性セット（Availability Set）と可用性ゾーン（Availability Zone）の違いも混乱ポイントだ。可用性セットは同一データセンター内の障害ドメインとアップデートドメインで分離し、可用性ゾーンは物理的に独立したゾーン間の冗長化を実現する。HA要件を満たすには可用性ゾーンが必要になる。
# Azure VM を可用性ゾーンに配置（Azure CLI） az vm create \ --resource-group myResourceGroup \ --name myVM1 \ --image UbuntuLTS \ --zone 1 az vm create \ --resource-group myResourceGroup \ --name myVM2 \ --image UbuntuLTS \ --zone 2
AWS vs Azureのサービス対応表
| 設計目的 | AWSサービス | Azureサービス |
|---|---|---|
| DBのHA（マルチAZ） | Amazon RDS マルチAZ | Azure SQL Database ゾーン冗長 |
| DBのFT水準 | Amazon Aurora Global Database | Azure SQL Hyperscale + ゾーン冗長 |
| Webサーバーの自動復旧 | ALB + EC2 Auto Scaling | Azure Load Balancer + VMSS |
| 複数AZ/ゾーンの分離 | マルチAZ配置 | 可用性ゾーン（Availability Zones） |
| DR（別リージョン） | AWS Backup + クロスリージョンレプリケーション | Azure Site Recovery |
本記事のまとめ
・Fault Tolerance（FT）は障害が起きても無停止で動き続ける設計。RTO=0、RPO=0が目標で、コストは高い。
・High Availability（HA）は障害後に短時間で自動復旧する設計。RTO/RPOは数秒～数分の範囲で許容し、コストはFTより現実的。
・ほとんどのWebシステムや業務システムはHA設計で十分で、AWSならマルチAZ＋ALB＋Auto Scalingが標準的な出発点になる。
・FTが必要かどうかはRTO/RPO要件を業務部門と合意してから判断する。コストの跳ね方が大きいため、先に試算して提示するのが鉄則だ。
・オンプレの「二重化」とは別物であることを前提に、クラウドの冗長設計を再定義する必要がある。
クラウド設計で信頼性を語るときの指標（SLA・SLO・SLI）については、姉妹記事「SLA・SLO・SLIの違いとは？クラウドエンジニアが知るべき信頼性指標の実践ガイド」もあわせて参照してほしい。また、LinuxサーバーをクラウドのHA構成に組み込む際の基礎は、姉妹サイトLinuxMaster.JPで詳しく解説している。
フォールトトレランスとHAの使い分け、実務で迷っていませんか？
クラウド実務に役立つ「Cloud Certification」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。
