AWS Certified Solutions Architect - Associate (SAA-C03) #6 Domain 2-1 回復力のあるアーキテクチャ — Multi-AZ・Auto Scaling・ELB

2026年5月14日木曜日

読了 6分

#5 でセキュリティドメイン (30%) を終えました。これから 2 つ目のドメインである 回復力 (Resilience, 26%) に入ります。回復力の最初の問いはシンプルです。「インスタンスが 1 つ、あるいはデータセンターが 1 つ死んでもサービスは継続するのか」 です。その答えの土台が Multi-AZ 配置、Auto Scaling、そしてロードバランサーです。

アベイラビリティーゾーン (AZ) と高可用性 #

リージョン (Region) は複数の アベイラビリティーゾーン (Availability Zone, AZ) で構成されます。各 AZ は物理的に分離された 1 つ以上のデータセンターであり、電力・冷却・ネットワークが独立しています。1 つの AZ で障害が発生しても、他の AZ は影響を受けません。

高可用性設計の基本原則は 「リソースを複数の AZ に分散する」 ことです。単一の AZ にのみインスタンスを置くと、その AZ の障害時にサービスが停止します。試験で「高可用性」という単語が出てきたら、ほぼ必ず Multi-AZ 配置が答えの一部です。

Multi-AZ (複数の AZ) と Multi-Region (複数のリージョン) を区別してください。ほとんどの高可用性は Multi-AZ で十分であり、Multi-Region はリージョン全体の障害対策やグローバルなレイテンシ改善のための別テーマです (#7 DR で扱います)。

Auto Scaling グループ (ASG) #

Auto Scaling グループは EC2 インスタンス数を需要に合わせて自動的に増減させる単位です。回復力とコスト効率を同時に押さえる中核的な構成要素です。

構成 #

起動テンプレート (Launch Template) — どの AMI・インスタンスタイプ・セキュリティグループでインスタンスを起動するかを定義
容量設定 — 最小 (min) / 最大 (max) / 希望 (desired) インスタンス数
複数の AZ に分散 — ASG は指定したサブネット (AZ) にインスタンスを均等に分散し、不均衡が生じると再調整します

スケーリングポリシー #

ポリシー	動作	代表的な用途
Target Tracking	指標を目標値に維持 (例: CPU 50%)	最も一般的・推奨
Step Scaling	指標の区間ごとに段階的に増減	きめ細かい制御
Simple Scaling	しきい値超過時に決められた数だけ	単純なケース
Scheduled Scaling	決められた時刻にあらかじめ調整	予測可能なトラフィック (業務時間)
Predictive Scaling	過去のパターンから将来の需要を予測	周期的なパターン

「トラフィックが増えたら自動的にインスタンスを追加せよ」という最もよくある要件は Target Tracking で答えます。「毎日午前 9 時にトラフィックが急増する」のように 時刻が分かれば Scheduled Scaling です。

ヘルスチェックで障害インスタンスを置換 #

ASG はヘルスチェックで異常なインスタンスを検知し、終了して新しいインスタンスに置換します。ヘルスチェックの種類は 2 つです。

EC2 ヘルスチェック — インスタンスの状態 (システム/インスタンスの status check) のみを見ます。
ELB ヘルスチェック — ロードバランサーがアプリケーションレベル (例: HTTP 200) で検査します。インスタンスは生きていてもアプリが死んでいるケースを捕捉するには、ELB ヘルスチェックを有効にする必要があります。

Elastic Load Balancing (ELB) #

ELB はトラフィックを複数のインスタンス (またはコンテナ・Lambda) に分散し、ヘルスチェックで正常なターゲットにのみ送ります。3 種類があり、レイヤーと用途で区別します。

種類	レイヤー	プロトコル	特徴
ALB (Application)	L7	HTTP/HTTPS	パス・ホストベースのルーティング、コンテナ・Lambda ターゲット、WebSocket
NLB (Network)	L4	TCP/UDP/TLS	超高性能・超低レイテンシ、固定 IP (Elastic IP)
GLB (Gateway)	L3	IP	サードパーティの仮想アプライアンス (ファイアウォール・IDS) の配備・拡張

ALB — HTTP パス (/api, /img) やホストヘッダーで異なるターゲットグループにルーティングする必要があれば ALB です。マイクロサービス・コンテナ環境の標準的な選択肢です。
NLB — 数百万 RPS、超低レイテンシ、TCP/UDP、あるいは 固定 IP が必要なら NLB です。ALB は固定 IP を持たず、DNS 名でのみ公開されます。
GLB — トラフィックをファイアウォールのようなサードパーティアプライアンスに通過させる必要があるときに使います。

知っておくべき ELB の機能 #

SSL/TLS 終端 — ロードバランサーで証明書を処理 (ACM 連携)
スティッキーセッション — 同じクライアントを同じターゲットに固定
クロスゾーン負荷分散 (Cross-Zone) — すべての AZ のターゲットに均等に分散。ALB はデフォルト有効、NLB はデフォルト無効
接続ドレイニング (Deregistration Delay) — ターゲットを外す前に進行中のリクエストを完了させるために待機

組み合わせて動作する全体像 #

典型的な高可用性 Web 層は次のように組み合わされます。

複数の AZ にまたがるサブネット
前段に ALB (トラフィック分散 + ヘルスチェック)
その後ろに Auto Scaling グループ (需要に応じて増減、障害インスタンスの置換)

この組み合わせなら、インスタンス障害は ASG が、AZ 障害はマルチ AZ 分散が、トラフィック急増はスケーリングが吸収します。

試験の出題パターン #

「HTTP パス/ホストベースのルーティング」 → ALB
「超高性能 TCP または 固定 IP が必要」 → NLB
「サードパーティの ファイアウォールアプライアンス の挿入」 → GLB
「トラフィックに応じて EC2 を 自動増減」 → ASG + Target Tracking
「毎日特定の時刻 のトラフィック急増に備える」 → Scheduled Scaling
「インスタンスは生きているが アプリが死んでいる 場合に置換」 → ELB ヘルスチェックを使用
「高可用性 が要求される」 → 複数の AZ 分散 + ELB + ASG

よく出会う落とし穴 #

1) ALB に固定 IP があると考える #

固定 IP (Elastic IP) は NLB の特徴です。ALB は DNS 名でのみ公開されます。

2) Auto Scaling を垂直スケーリングと誤解する #

ASG は 水平スケーリング (インスタンス数の増減) です。インスタンスをより大きなタイプに変更する垂直スケーリングとは異なります。

3) EC2 ヘルスチェックでアプリ障害を捕捉しようとする #

EC2 ヘルスチェックはインスタンスの状態のみを見ます。アプリケーションレベルの障害は ELB ヘルスチェックで検知します。

4) 高可用性と Multi-Region を混同する #

ほとんどの高可用性は Multi-AZ で解決します。Multi-Region はリージョン障害対策・グローバルなレイテンシ改善用であり、コストが大きくなります。

まとめ #

今回の記事で押さえたこと:

高可用性の土台は 複数の AZ 分散。Multi-AZ と Multi-Region を区別する
Auto Scaling — 水平増減。Target Tracking が基本、時刻予測は Scheduled。ヘルスチェックで障害インスタンスを置換
ELB — ALB (L7 パスルーティング) · NLB (L4 超高性能・固定 IP) · GLB (アプライアンス)
アプリ障害の検知は ELB ヘルスチェック。クロスゾーン分散は ALB がデフォルト有効/NLB がデフォルト無効
標準パターン — マルチ AZ + ALB + ASG の組み合わせ

次回 — Domain 2-2 DR パターン #

単一リージョン内の回復力を押さえたので、次は リージョン単位の災害に備える DR 戦略です。

#7 Domain 2-2 DR パターンでは、RTO と RPO の意味、4 つの DR 戦略 (Backup & Restore · Pilot Light · Warm Standby · Multi-Site Active/Active) のコスト・復旧時間のトレードオフ、そして Route 53 failover とクロスリージョンレプリケーションで実装する方法を整理します。