【SAA-C03】可用性と耐障害性の設計パターン｜マルチAZ・Auto Scaling・ELB活用

SAA-C03では「単一障害点（SPOF：Single Point Of Failure）をなくす設計」が繰り返し問われます。ここでは可用性（落ちにくさ）と耐障害性（壊れても続けられること）を高める基本パターンを、具体例・早見表・よくある誤りとともに整理します。

可用性設計の3つの柱

個々のサービス機能は、次の3つの観点で整理すると覚えやすく、問題も解きやすくなります。

• 冗長化：同じ役割を複数用意し、1つ壊れても大丈夫にする（例：複数AZ配置）
• 自動復旧：壊れたら自動で置き換え・切替する（例：Auto Scaling、マルチAZフェイルオーバー）
• 負荷分散：正常なリソースにだけ振り分ける（例：ELB＋ヘルスチェック）

マルチAZによる冗長化

• サブネットを複数AZに用意し、EC2・ELB・RDSなどを分散配置する。これが可用性設計の土台。
• RDSのマルチAZ配置は、別AZの待機系へ同期レプリケーションし、障害時に自動フェイルオーバーする。可用性のための機能で、待機系は読み取りには使えない。
• ELBも複数AZにまたがって配置し、AZ障害時に生きているAZへ振り向ける。

Auto Scaling と ELB の組み合わせ

• Auto Scaling：需要に応じてインスタンス数を自動で増減し、さらに異常インスタンスを自動で置き換える（自己修復）。希望台数・最小・最大を設定する。
• ELB（Elastic Load Balancing）：ヘルスチェックで異常インスタンスを検知し、正常なインスタンスにのみトラフィックを振り分ける。Webは ALB、超高スループット/固定IPは NLB。
• 両者はターゲットグループで連携し、「増えた台数へ自動で振り分け」「落ちた台数を自動で切り離し＆再作成」を実現する。

データ層の耐障害性

• S3：同一リージョン内の複数AZにまたがり、99.999999999%（イレブンナイン）の高耐久。静的コンテンツやバックアップの保管に最適。
• DynamoDB：複数AZへ自動レプリケーション。グローバルテーブルでマルチリージョン化も可能。
• RDS/Aurora：マルチAZで待機系へ同期。Auroraはストレージを3AZ×2＝6か所に複製し特に堅牢。
• EFS：複数AZから同時マウントできる共有ファイルストレージ。

リージョン障害への備え（一歩上の設計）

AZ全滅やリージョン障害に備えるなら、マルチリージョン構成と Route 53 のフェイルオーバールーティング（ヘルスチェック連動）で別リージョンへ切り替えます。要件のRTO/RPOが厳しいほど、常時稼働の待機系を厚くします。

可用性を高める手段 早見表

チェックリスト

• 「冗長化・自動復旧・負荷分散」の3観点でサービスを整理できる
• マルチAZ（可用性）とリードレプリカ（読み取りスケール）を混同しない
• Auto Scaling（自己修復・増減）とELB（ヘルスチェック・振り分け）の役割を説明できる
• S3・DynamoDB・Aurora の耐障害性の特徴を言える
• リージョン障害には マルチリージョン＋Route 53 と結びつけられる

まとめ

可用性設計は「冗長化・自動復旧・負荷分散」の3観点で整理すると得点しやすくなります。役割の混同（特にマルチAZとリードレプリカ）に注意しましょう。クイズで理解を確認し、資格対策ページもあわせてご活用ください。試験番号・配点は改訂されることがあるため、申込前にAWS認定 公式ページで最新の試験ガイドをご確認ください。