AWS SAA-C03 回復性設計 完全攻略 — Domain 2（26%）を「冗長化」と「疎結合」で取る

AWS SAA-C03 セキュア設計 完全攻略（2026-06-01 公開）で配点最大の Domain 1 を攻略しました。次に控えるのが配点 26% の Domain 2「Design Resilient Architectures」です。Domain 1 と合わせると、この 2 ドメインだけで試験全体の 56% を占めます。ここを固めれば、合格圏は一気に現実的になります。

回復性（resilience）の設計が問うのは、たったひとつの問いに集約できます。「どこか 1 か所が壊れても、システム全体は動き続けるか」。AWS SAA-C03 回復性設計は、この問いに「はい」と答えられる構成を、サービスの組み合わせで実現できるかを試します。鍵となるのは冗長化と疎結合という 2 本の柱です。

回復性とは何か — 可用性・耐久性・回復性の違い

最初に用語を整理します。試験では似た言葉が選択肢に並び、定義の混同を狙ってきます。

可用性は「いま使えるか」、耐久性は「データが消えないか」、回復性は「壊れても立ち直れるか」を指します。S3 がイレブンナインの耐久性を持つからといって、可用性が同じとは限りません。この区別ができると、設問が何を問うているのかが見えてきます。

回復性を高める第一歩は、単一障害点（SPOF: Single Point of Failure）の排除です。1 台の EC2、1 つの AZ、1 つのリージョンに依存している構成を見つけ、冗長化していく。これが Domain 2 の出発点です。

実務で陥りがちなのは、可用性と耐久性を同じものとして扱ってしまう誤りです。たとえば「データは S3 に置いているから安全」と考えても、それは耐久性の話であって、アプリケーションが落ちないこと（可用性）や、障害から自動で立ち直ること（回復性）を保証するものではありません。三者は独立した品質特性であり、それぞれに対する打ち手が異なります。AWS SAA-C03 回復性設計の設問は、この区別を前提に「いま問われているのはどの特性か」を読み取る力を試してきます。問題文に「ダウンタイムを最小化したい」とあれば可用性と回復性の話、「データを失いたくない」とあれば耐久性の話、というふうに、キーワードから論点を切り分ける習慣をつけましょう。

Multi-AZ 設計の基本 — AZ 障害を吸収する

AWS のリージョンは複数のアベイラビリティゾーン（AZ）で構成されます。AZ は物理的に分離されたデータセンター群で、電源・冷却・ネットワークが独立しています。ひとつの AZ が災害や障害で停止しても、別の AZ は動き続ける設計です。

回復性設計の基本中の基本は、リソースを複数の AZ に分散させることです。EC2 なら複数 AZ にインスタンスを配置し、RDS なら Multi-AZ 配置でスタンバイを別 AZ に持ちます。RDS の Multi-AZ では、プライマリに障害が起きると通常 35 秒未満で自動的にスタンバイへフェイルオーバーし、データ損失なく切り替わります。

ここで頻出の判断軸が「Multi-AZ と リードレプリカの違い」です。Multi-AZ は可用性のための同期レプリケーションで、スタンバイは通常読み取りに使えません。一方リードレプリカは読み取り負荷分散が目的の非同期レプリケーションです。「可用性を上げたい」なら Multi-AZ、「読み取り性能を上げたい」ならリードレプリカ。目的で選ぶのが正解です。

なぜ複数 AZ への分散がこれほど重視されるのか、設計者の視点で考えてみましょう。AZ 同士は数十キロメートル離れた別の施設に置かれつつ、低レイテンシの専用回線で結ばれています。この「近すぎず遠すぎない」距離設計が、災害の同時被災を避けながら同期レプリケーションを成立させる絶妙な落としどころになっています。だからこそ、可用性が要求される本番ワークロードでは、コンピュート層もデータベース層も、最低 2 つの AZ にまたがって配置するのが鉄則です。逆に、開発環境やバッチ処理のように一時的なダウンタイムが許容できる場面では、単一 AZ でコストを抑える判断も成立します。要件に応じて冗長度を選ぶ、この使い分けが設計者の腕の見せどころです。

Elastic Load Balancing の選定 — ALB / NLB / GWLB / CLB

複数 AZ に分散したリソースへトラフィックを振り分けるのが Elastic Load Balancing（ELB）です。ELB には 4 タイプがあり、レイヤーと用途で選び分けます。

判断のコツはシンプルです。HTTP のパスやホスト名で振り分けたいなら ALB。TCP レベルで最速・固定 IP が要るなら NLB。仮想ファイアウォールを挟みたいなら GWLB。CLB は旧世代なので、試験で「最適なものを選べ」と問われたら基本的に選びません。ALB のターゲットグループは EC2 だけでなく Lambda や IP も指定でき、コンテナや サーバーレスとも組み合わせられます。

具体例で感覚をつかみましょう。ひとつのドメインで「/api はバックエンド、/img は画像サーバー、それ以外は Web サーバー」と振り分けたい——これは L7 のパスを見て判断する必要があるため ALB の独壇場です。一方、ゲームサーバーや IoT のバックエンドのように、ミリ秒単位のレイテンシと毎秒数百万接続が要求される場面では、L4 で動く NLB が適します。NLB はクライアントの送信元 IP をそのままバックエンドに渡せる点でも、ファイアウォールのログ要件などと相性が良い。このように「どのレイヤーで判断するか」を問題文から読み取れば、4 つの選択肢は自然に絞り込めます。

ロードバランサーとヘルスチェックはセットです。ELB は定期的にバックエンドの健全性を確認し、異常なインスタンスへの振り分けを自動で止めます。これが回復性の要です。

Auto Scaling の設計 — 需要に追従する

冗長化に弾力性を加えるのが Auto Scaling です。負荷に応じてインスタンス数を自動で増減し、可用性とコスト効率を両立させます。スケーリングポリシーは主に次の通りです。

設計の出発点はターゲット追跡です。「CPU 使用率を 50% に保つ」と設定すれば、AWS が自動でインスタンス数を調整します。予測可能なピークがあるならスケジュールスケーリングを併用し、機械学習に任せたいなら予測スケーリングを足す。複数ポリシーは組み合わせ可能です。

Auto Scaling は EC2 だけでなく、ECS タスク・DynamoDB・Aurora レプリカ・Spot Fleet にも適用できます。「アプリの負荷に応じて自動でスケールさせたい」という要件は、Auto Scaling を中心に据えるのが定石です。

設計上のポイントは、スケールアウト（台数を増やす）とスケールアップ（1 台を大きくする）の区別です。回復性の観点では、台数を増やす水平スケールが基本になります。1 台を巨大にしても、その 1 台が落ちれば全滅だからです。小〜中規模のインスタンスを複数 AZ に並べ、Auto Scaling で増減させる。この「数で粘る」構成が、可用性とコスト効率の両面で優れています。さらに、最小台数・希望台数・最大台数を適切に設定することで、障害でインスタンスが失われても自動で補充され、常に目標台数が維持されます。この自己修復こそ、Auto Scaling が回復性設計の中核に置かれる理由です。

ステートレス設計 — セッションを外部化する

Auto Scaling でインスタンスが増減する以上、各インスタンスが状態（セッション情報など）を内部に抱えていると問題が起きます。スケールインでインスタンスが消えれば、そこに保存されていたログイン状態も消えてしまうからです。

解決策はステートレス設計です。セッション情報をインスタンスの外、すなわち Amazon ElastiCache や Amazon DynamoDB に外部化します。こうすればどのインスタンスがリクエストを受けても同じセッションを参照でき、インスタンスは自由に増減できます。

この「状態を外に出す」という発想は、回復性設計の根幹です。インスタンスを「いつでも捨てて作り直せる使い捨ての部品」として扱えるようになれば、障害復旧もスケーリングも一気に楽になります。これは家畜とペットのたとえで語られることがあります。1 台ずつ手をかけて大切に育てる「ペット」ではなく、群れとして扱い不調な個体は即座に入れ替える「家畜」として扱う。クラウドネイティブな設計では、後者の発想が圧倒的に強いのです。アップロードされたファイルは S3 へ、セッションは ElastiCache や DynamoDB へ、設定は外部のパラメータストアへ。インスタンスの中に「失うと困るもの」を一切残さない。この徹底が、結果として高い回復性を生みます。

疎結合の原則 — 同期から非同期へ

冗長化が縦の備えなら、疎結合（loose coupling）は横の備えです。コンポーネント同士が直接・同期的に呼び合う構成は、片方が落ちるともう片方も巻き込まれます。これを「密結合」と呼び、回復性の敵とみなします。

疎結合では、コンポーネントの間にキューやトピックを挟みます。送信側は相手の状態を気にせずメッセージを置き、受信側は自分のペースで処理する。受信側が一時的に落ちても、メッセージはキューに溜まり、復旧後に処理が再開されます。この緩衝材があるかないかで、システムの粘り強さは大きく変わります。

SQS による疎結合 — Standard と FIFO

疎結合の主役が Amazon SQS（Simple Queue Service）です。SQS には 2 タイプあります。

• Standard キュー: ほぼ無制限のスループット。順序は保証されず（ベストエフォート）、メッセージが重複配信される可能性がある（最低 1 回配信）
• FIFO キュー: 順序を厳密に保証し、重複を排除（正確に 1 回処理）。その代わりスループットに上限がある

判断軸は「順序と重複排除が要るか」です。注文処理や決済のように順序が重要なら FIFO。ログ集約や画像処理のように順序を問わず、とにかく大量にさばきたいなら Standard を選びます。

SQS は Auto Scaling とも連動します。キューの深さ（未処理メッセージ数）をメトリクスにしたターゲット追跡スケーリングを組めば、処理待ちが溜まったら自動でワーカーを増やし、捌けたら減らす、という弾力的なバッチ処理基盤が完成します。

もうひとつ押さえたいのが、処理に失敗したメッセージの扱いです。何度処理しても失敗するメッセージをそのままキューに残すと、後続の正常なメッセージまで詰まってしまいます。これを防ぐのがデッドレターキュー（DLQ）です。一定回数以上処理に失敗したメッセージを専用のキューへ退避させ、本流の処理を止めない。さらに退避したメッセージを後から分析して原因を突き止める、という運用が可能になります。「失敗を握りつぶさず、かつ全体を止めない」という設計思想は、AWS SAA-C03 回復性設計の根底に流れる考え方そのものです。

SNS と EventBridge — Pub/Sub とイベント駆動

SQS が「1 対 1 のメッセージ受け渡し」なら、Amazon SNS（Simple Notification Service）は「1 対多の通知」です。ひとつのメッセージを複数の購読者（Lambda、SQS、HTTP エンドポイント等）へ同時に配信する Pub/Sub モデルを実現します。

SNS と SQS を組み合わせた「ファンアウト」パターンは頻出です。SNS トピックに publish したメッセージを複数の SQS キューが受け取り、それぞれ独立に処理する。これにより、ひとつのイベントから複数の処理を並行して走らせつつ、各処理を疎結合に保てます。

さらに高度なイベント駆動を担うのが Amazon EventBridge です。AWS サービスや SaaS、自前アプリのイベントをルールでフィルタし、適切なターゲットへルーティングします。「特定の状態変化が起きたら、この処理を自動で起動する」という設計は EventBridge の得意領域です。SNS が「通知の配信」に最適化されているのに対し、EventBridge は「イベントの内容に応じた賢い振り分け」に強みを持つ、と整理すると選択に迷いません。

Step Functions — ワークフローを可視化する

複数のステップからなる処理を、再試行やエラー処理込みで組み立てるのが AWS Step Functions です。各ステップを状態として定義し、成功・失敗・分岐・並列を宣言的に記述します。

Lambda を手続き的に呼び出してエラー処理を自前で書くと、コードが複雑化し障害点も増えます。Step Functions に任せれば、各ステップの再試行やタイムアウト、失敗時の補償処理を設定で表現でき、処理全体の状態も可視化されます。「複数の Lambda をオーケストレーションし、途中で失敗しても安全に再開したい」という要件は Step Functions の出番です。

具体的には、「注文を受け付け、在庫を引き当て、決済し、配送を手配する」といった一連の業務フローを思い浮かべてください。途中の決済で失敗した場合、すでに引き当てた在庫を戻す補償処理が必要になります。これを各 Lambda の中に書き散らすと、フロー全体の見通しが急速に悪化します。Step Functions なら、各ステップと失敗時の遷移を一枚の状態遷移図として宣言でき、どこで止まったかも履歴から一目で追えます。長時間にわたる処理や、人間の承認を挟むワークフローにも対応できる点で、回復性と運用性を同時に高める選択肢です。

サービスの全体像はAWS コアサービス 完全攻略 — CLF-C02 Domain 3（2026-05-28 公開）でも俯瞰しました。Associate ではこれらを「どう組み合わせて回復性を作るか」という設計判断として問われます。

設計シナリオ演習 — 5 つの典型問題

判断軸を試験形式で確認します。

シナリオ 1: Web アプリの可用性を高めたい。 1 AZ に EC2 を増やす選択肢は不正解です。AZ 障害に耐えられないからです。正解は複数 AZ に EC2 を分散し、ALB で振り分け、Auto Scaling で弾力化する構成です。

シナリオ 2: RDS の可用性を高めたい。 リードレプリカ追加は読み取り分散であって可用性向上ではないため、要件次第では不正解です。可用性が目的なら Multi-AZ 配置でスタンバイを別 AZ に持つのが正解です。

シナリオ 3: 注文処理を順序通り・重複なく処理したい。 Standard キューは順序保証がないため不正解。正解は FIFO キューです。

シナリオ 4: ひとつのイベントから複数の処理を並行起動したい。 単一の SQS では 1 対多にならないため不十分。正解は SNS と SQS のファンアウト、または EventBridge のルーティングです。

シナリオ 5: スケールインでセッションが消える。 インスタンス内にセッションを持つ設計が原因です。正解は ElastiCache や DynamoDB へのセッション外部化、すなわちステートレス化です。

5 問とも、判断の軸は「単一障害点を消す（冗長化）」と「コンポーネントを切り離す（疎結合）」のどちらか、あるいは両方です。

まとめ — Domain 2 前編のチェックリスト

AWS SAA-C03 回復性設計の前半は、次のチェックリストに集約されます。

• 可用性・耐久性・回復性の定義を区別する
• 単一障害点を見つけ、複数 AZ で冗長化する
• 可用性なら Multi-AZ、読み取り性能ならリードレプリカ
• ELB は L7 なら ALB、L4 高速なら NLB、仮想アプライアンスなら GWLB
• Auto Scaling はまずターゲット追跡、予測可能なピークはスケジュール
• セッションは外部化してステートレスにする
• 疎結合は SQS（1 対 1）、SNS（1 対多）、EventBridge（イベント駆動）で実現
• 順序・重複排除が要るなら FIFO、スループット優先なら Standard
• 複数ステップの安全なオーケストレーションは Step Functions

冗長化と疎結合は、どちらか一方では不十分です。複数 AZ に冗長化しても、コンポーネントが密結合のままなら、ひとつの障害が連鎖して全体を巻き込みます。逆に疎結合にしても、各コンポーネントが単一構成なら、そこが落ちれば処理は止まります。縦の冗長化と横の疎結合、この両輪がそろって初めて、本当に粘り強いシステムになります。設問でも、両方の観点を同時に満たす構成が正解になることが多い点を意識してください。

ここまでが回復性設計の「平常運転」の備えです。次は、その備えが破られた時の最後の砦——バックアップと災害復旧（DR）、そして RTO/RPO の設計に進みます。コストと復旧速度のトレードオフを、4 つの DR 戦略で整理していきます。

参照

• AWS Certified Solutions Architect – Associate（SAA-C03）公式
• Elastic Load Balancing 公式
• Amazon EC2 Auto Scaling — 動的スケーリング
• Amazon RDS Multi-AZ 配置
• Amazon SQS 公式
• AWS Step Functions 公式

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.