SAA（Solutions Architect Associate）攻略・ 2026-07-02

SAA ドメイン2：弾力性のあるアーキテクチャの設計｜配点26%を疎結合と多重化で攻略する

AWS SAA-C03 の第2ドメイン「弾力性のあるアーキテクチャの設計（26%）」を、公式タスクステートメント2.1〜2.2に沿って完全攻略する。結論は「スケールで捌き（2.1）／多重化で落とさない（2.2）の2軸で考える」こと。Auto Scaling・ELB・SQS/SNS/EventBridge による疎結合、Multi-AZ・Route 53 フェイルオーバー・DR 4戦略まで、SAA 本番で問われる設計判断と頻出ひっかけを、そのまま得点に変わる粒度で解説する。

#AWS #SAA #SAA-C03 #Solutions Architect #高可用性 #Auto Scaling #疎結合 #試験対策 #AWS認定資格

「単一の EC2 が落ちたらサービスも止まる」——その設計を選んだ瞬間、SAA-C03 のドメイン2では失点する。 配点 **26%（採点対象50問のうち約13問）を占めるこの第2ドメイン「弾力性のあるアーキテクチャの設計」は、ドメイン1（30%）に次ぐ第2の得点源だ。出題は明確に2つのタスクステートメント（2.1 と 2.2）**へ構造化されている。結論から言えば、ドメイン2は「負荷は “スケール” で捌き（2.1）、障害では “多重化” で落とさない（2.2）」という2軸で攻略できる。本記事では、各タスクの中核サービス・設計判断・頻出ひっかけを、SAA 本番でそのまま選択肢を絞れる粒度まで分解する。読み終えれば、長いシナリオ問題を前にしても「これはスケールの話か、可用性の話か」を一瞬で見抜けるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

1. 結論：ドメイン2は「スケール」と「多重化」の2軸で解く

SAA-C03 ドメイン2を攻略する最短ルートは、問題を「スケールの話」か「可用性の話」かに二分することだ。これが本記事の結論である。

理由は、ドメイン2の2つのタスクステートメントが、そのままこの2軸に対応しているからだ。タスク2.1＝スケーラブルで疎結合（負荷が増えても捌けるか）、タスク2.2＝高可用性・フォールトトレラント（一部が壊れても止まらないか）。弾力性（レジリエンス）とは漠然と「強いシステム」ではなく、「伸縮性（スケール）」と「耐障害性（多重化）」という2つの独立した性質の合成だと捉えると、出題の狙いが一気に見通せる。

具体例で見よう。「アクセスが急増しても処理を止めたくない」はスケール軸（2.1）——正解は Auto Scaling と SQS による疎結合だ。「AZ 障害が起きても RDS を止めたくない」は可用性軸（2.2）——RDS Multi-AZ の出番。要件のキーワードから軸を特定し、その軸の定番サービスを引き出す——これがドメイン2の解き方の骨格だ。

SAA の4ドメイン全体像を押さえ、配点最大のドメイン1（セキュリティ）を固めたら、次はこの配点26%のドメイン2に学習時間を投じるのが正しい順序だ。

2. ドメイン2の全体像と2つのタスクステートメント

まず、ドメイン2の構造を1枚の表で俯瞰する。公式試験ガイドのタスクステートメントを、本記事の2軸モデルに対応づけたものだ。

タスク	軸	問われる判断	中核サービス
2.1	スケール軸	負荷増に伸縮で応え、部品を疎結合にできるか	Auto Scaling / ELB / SQS / SNS / EventBridge
2.2	可用性軸	単一障害点をなくし、障害から自動復旧できるか	Multi-AZ / Route 53 / RDS / Aurora / バックアップ

2つのタスクは独立して見えて、実際の問題では重なって問われる。たとえば「急増するトラフィックを AZ 障害に強い構成で捌きたい」なら、Auto Scaling ＋ ELB（2.1）と Multi-AZ 配置（2.2）が同時に登場する。だからこそ、各軸を個別に固めたうえで「2軸を貼り合わせる」訓練が効く。

3. タスク2.1：スケーラブルで疎結合なアーキテクチャの設計

スケール軸の中心は、**「増える負荷にどう応えるか」と「部品同士をどう切り離すか」**の2点だ。

垂直スケールより水平スケール、そして自動化

まず問われるのがスケールの方向だ。1台のインスタンスを大きくする垂直スケール（スケールアップ）には上限があり、単一障害点にもなる。SAA が推すのは、台数を増やす水平スケール（スケールアウト）——EC2 Auto Scaling と ELB を組み合わせ、負荷に応じて自動でインスタンスを増減させる型だ。「トラフィックの増減に自動で追従したい」「コストを抑えつつ突発負荷に耐えたい」とあれば、ほぼこの構成が正解になる。

疎結合（Decoupling）——同期を非同期に変える

弾力性のもう一つの鍵が疎結合だ。コンポーネントを直接つなぐと、片方の障害や過負荷がもう片方に波及する。間にメッセージングを挟んで切り離すのが定石だ。

要件	適切なサービス
処理を非同期のキューに溜めて順に捌く	SQS
1つのイベントを複数の宛先に一斉配信（ファンアウト）	SNS
イベントのルーティング・SaaS/AWS サービス連携	EventBridge
複数ステップの処理をワークフローで管理	Step Functions

API Gateway ＋ Lambda のサーバーレス構成は、リクエスト量に応じて自動でスケールし、アイドル時のコストもゼロに近い——「運用負荷を下げつつ弾力性を確保したい」要件で強い。読み込み負荷の分散には RDS リードレプリカ、キャッシュによる負荷軽減には ElastiCache や DynamoDB Accelerator（DAX）、配信の高速化とオリジン負荷軽減には CloudFront が選択肢に上がる。

4. タスク2.2：高可用性・フォールトトレラントなアーキテクチャの設計

可用性軸の主役は、「単一障害点（SPOF）をなくす多重化」だ。ここで毎回のように問われるのが、Multi-AZ と Multi-Region の使い分けである。

高可用性の第一手は Multi-AZ

「AZ 障害に耐えたい」という要件の答えは、ほぼ Multi-AZ 配置だ。RDS Multi-AZ は同期レプリカを別 AZ に置き、障害時に自動フェイルオーバーする。Aurora はさらに3 AZ に6本のデータコピーを持ち、可用性・耐久性が一段高い。EC2 層は Auto Scaling グループを複数 AZ にまたがせるのが基本形だ。

高可用性（Multi-AZ）と耐障害性（Multi-Region）の使い分け

評価項目	Multi-AZ 推奨	Multi-Region
守る対象	AZ（データセンター）障害	リージョン全体の障害
レイテンシ	同一リージョン内で低遅延	リージョン間で遅延あり
コスト	比較的低い	高い（二重の構成）
主な用途	一般的な高可用性の標準構成	大規模DR・グローバル配信
キーワード	「AZ 障害」「自動フェイルオーバー」	「リージョン障害」「地理的DR」

まず Multi-AZ で足りるかを判断し、リージョン障害まで要求されて初めて Multi-Region を選ぶ。

過剰に Multi-Region を選ばないのがコツだ。要件が「AZ 障害への耐性」で止まっているのに Multi-Region を選ぶと、コスト最適化の観点で誤答になりうる。

Route 53 と Global Accelerator による経路の可用性

DNS レベルの可用性設計では Route 53 が中心だ。ルーティングポリシーのうち、フェイルオーバールーティング＋ヘルスチェックで、正常なエンドポイントへ自動的に振り向ける構成が頻出。TCP/UDP レベルで固定 IP と高速フェイルオーバーが要るなら Global Accelerator が候補になる。

障害からの復旧手段として、スナップショットや AWS Backup による定期バックアップも可用性設計の一部だ。ステートレス設計（セッション情報を DynamoDB や ElastiCache に外出しする）も、インスタンスを使い捨て可能にして耐障害性を高める定番の型である。

5. ディザスタリカバリ（DR）4戦略の使い分け

ドメイン2で avoid できないのが、DR（災害復旧）の4戦略だ。RTO（復旧時間目標）と RPO（復旧時点目標）、そしてコストのトレードオフで選ぶ。

戦略	概要	RTO / RPO	コスト
バックアップ＆リストア	バックアップから復元	遅い（数時間）	最安
パイロットライト	最小構成を常時起動、有事に拡張	中（数十分）	低〜中
ウォームスタンバイ	縮小版を常時稼働、有事に増強	速い（数分）	中〜高
マルチサイト（Active-Active）	本番同等を複数拠点で常時稼働	最速（ほぼ0）	最高

6. ドメイン2の頻出ひっかけパターン

ドメイン2は、AWS の設計思想（水平スケール・疎結合・多重化・マネージド活用）に沿わない選択肢が誤答になりやすい。本番で迷ったときの判断材料として、正答に寄せる打ち手と避けるべき誤答を整理する。

7. 次のアクションチェックリスト

ドメイン2の2軸モデルを、今日からの学習に落とし込むための具体アクションをまとめる。

8. 関連記事

SAA 試験完全ガイド｜SAA-C03 の出題範囲・難易度・3ヶ月合格戦略 — 本シリーズの上位ガイド
SAA 試験範囲：4ドメイン詳細解説 — ドメイン1〜4の全体像
SAA ドメイン1：セキュアなアーキテクチャの設計 — 配点最大の前ドメイン
EC2 Auto Scaling の仕組みと設定方法 — タスク2.1 の水平スケールの軸
Amazon SQS と SNS の違い完全比較 — 疎結合の頻出ひっかけ
RDS Multi-AZ と Read Replica の違い — 高可用性の第一手
Amazon Route 53 完全ガイド（ルーティングポリシー7種） — DNS フェイルオーバー設計
AWS Backup の使い方と料金 — バックアップによる復旧

9. 関連サイト

AWS 公式

💡 学習中のひとこと

SAA-C03 ドメイン2「弾力性のあるアーキテクチャの設計」は配点26%・約13問の第2の得点源です。攻略の骨格は、問題を「スケール軸（2.1：Auto Scaling・ELB・SQS/SNS で伸縮と疎結合）／可用性軸（2.2：Multi-AZ・Route 53・DR 戦略で多重化と復旧）」の2軸に分けて捉えること。

本番のシナリオ問題は2軸が重なって出題されますが、要件文を「これは負荷を捌く話か、障害で落とさない話か」と色分けすれば、必要なサービスを迷わず引き出せます。迷ったら水平スケール・疎結合・多重化に寄せる——「高スペック1台」ではなく「小さな部品に分散」が AWS の答えです。まずは Auto Scaling ＋ ELB の標準形から、今日の学習をスタートしましょう。