SAA-C03で苦しくなりやすいのは、サービス名を知らないことより、どの構成が要件に最も合うかを比較する場面です。可用性、セキュリティ、性能、コスト、運用負荷が同時に書かれるため、一つのサービスだけ覚えていても最後の二択が残ります。
更新日 2026-10-05
AWS Certified Solutions Architect - Associate 攻略ガイド
SAA-C03で壁になるのは、サービスを知っていても構成を選べない場面です。EC2もLambdaも処理を実行できます。しかし処理時間、負荷の変動、既存アプリケーションの制約、管理に使える人員まで読むと、候補の優先順位が変わります。このガイドでは、サービスの説明を設計の根拠へ変える練習を扱います。
このページ内のミニケースは、学習方法を説明するために資格合格.webが独自に作成したものです。実際のAWS Certified Solutions Architect - Associateの非公開試験問題を転載・再現したものではありません。
基礎知識に、通信とデータの流れを足す
Cloud Practitionerで学んだ「S3はオブジェクトストレージ」「IAMはアクセス管理」という知識は出発点です。SAAでは誰がどの経路でアクセスし、どこで認可され、障害時に何へ切り替わるかを構成として考えます。
利用者からWebアプリケーションへ届く経路と、アプリケーションがデータを読み書きする経路を描いてください。VPC、サブネット、ルート、ロードバランサー、実行環境、保存先を並べ、矢印に通信の目的を書きます。説明できない矢印が次に調べる場所です。
範囲はAWS公式SAA-C03試験ガイドで確認します。コンソール操作の暗記だけで終わらず、要件を満たす構成と制約を説明する練習へ進みます。
必須条件を拾ってから、構成を比較する
「データを国外へ出せない」は候補を除外する必須条件です。「運用負荷を最小化したい」は残った候補を比較する条件です。同列のキーワードとして読むと、安くても所在地要件を満たさない構成を選んでしまいます。
架空の画像投稿サービスを考えます。画像は直ちに保存し、サムネイルの完成は遅れてよく、投稿が集中しても受付を続けたいという要件です。受付と画像加工を同期処理にする必要はあるでしょうか。保存後にキューへ依頼を渡せば、加工の遅れを受付から切り離せます。一方、加工結果をその場で返す要件なら、同じ設計だけでは応答要件を満たしません。
復習ノートにはサービス一覧より、「許容する遅延」「失ってはいけないデータ」「止めてよい処理」「減らしたい管理作業」を残します。
必須条件から候補を絞る
画像投稿の要求から、所在地などの必須条件、同期と非同期の判断、残る候補の比較へ進む。
- 業務の要求画像を直ちに保存し、加工の完成は遅れてよい。受付を止めないことが目的。
- 必須条件で除外国外保存が禁止なら、所在地を満たさない構成は価格比較の前に除外する。
- 処理の結び付きを選ぶ加工の遅延を許すならキューで分離する。即時の結果が必要なら応答要件を見直す。
- 残る候補を比較必須条件を満たす構成どうしで、管理作業と費用を比べて選定理由を残す。
障害を一つ起こして、構成を追い直す
複数AZにEC2を置いても、セッション情報が各インスタンスのローカルにだけあれば、別のインスタンスへ移った利用者の状態を引き継げないことがあります。台数を数えるだけでは全体の可用性を説明できません。
図から一台を消し、次にAZを一つ使えなくします。負荷分散で送り先が変わった後、必要な状態やデータに到達できるか、残った容量で処理を続けられるかを確認します。計算資源が分散されても、依存する部品が単一AZに残っていないか点検してください。
災害対策では、復旧までに許される時間のRTOと、失ってよいデータ期間のRPOを分けます。バックアップがあっても復元に長時間かかれば短いRTOには合いません。複製先があっても切替手順や依存先を確認していなければ、復旧の説明は未完成です。
障害範囲と復旧条件
インスタンスとAZの障害範囲、RTOの復旧時間、RPOの許容データ損失を比較する。
- インスタンス障害一台を失っても別の送り先へ切り替わるか。ローカルだけにあるセッションに注意。
- AZ障害計算資源だけでなく依存先も確認する。残ったAZの容量とデータへの到達性を見る。
- RTO：復旧時間停止から復旧までの許容時間。バックアップの有無だけでなく復元・切替の所要時間を見る。
- RPO：データ損失失ってよいデータ期間。リージョン災害への備えでも複製と復旧手順を合わせて確認する。
負荷分散・台数調整・非同期化を使い分ける
ロードバランサーはリクエストを振り分け、Auto Scalingは容量を調整し、キューは受付と処理の時間を分離します。三つを「アクセスが増えたら使うもの」とまとめず、どこが詰まっているかを見ます。
画像加工の待ち行列が伸びているなら、受付サーバーだけ増やしても加工の遅れは縮まりません。ワーカーの処理能力とキューの滞留を確認します。非同期化しても作業量は消えず、後で処理できる容量と失敗時の扱いが必要です。
SQS標準キューの公式説明では、メッセージが複数回届く可能性や順序が変わる可能性が示されています。同じ画像加工依頼を再処理しても不整合を起こさない設計を考えてください。注文処理に変えると、二重請求を避ける判断も必要になります。
画像受付から非同期加工へ
ALBから受付EC2へ投稿し、画像保存後に加工依頼をキューへ渡し、ワーカーが処理する。台数調整は別の役割。
- ALB：受付へ振り分け投稿リクエストを受付のEC2へ分散する。ALB自体がEC2の台数を増やすわけではない。
- 受付：画像を保存元画像を保存し、加工依頼をキューへ渡す。受付の台数調整はAuto Scalingが担う。
- キュー：時間を分離依頼を蓄え、加工待ちを受付から切り離す。SQS標準キューでは重複や順序の変化に備える。
- ワーカー：加工する滞留に応じて処理容量を見直す。同じ依頼を再処理しても不整合を起こさないようにする。
保存先は、データの形と使い方で絞る
画像と注文明細を同じ観点だけで選ぶと混乱します。オブジェクトとして取り出すのか、OSからブロックデバイスとして使うのか、複数環境でファイル共有するのかを分けます。DBでは検索方法、更新の一貫性、トランザクション、負荷の形まで読みます。
| 要件の例 | まず比較する観点 | 早合点しやすい点 |
|---|---|---|
| 画像を保存しHTTPで配信 | オブジェクト保存と配信経路 | ファイル共有と同じ扱いにする |
| 複数のLinux環境でファイル共有 | 共有ファイルシステムの対応とアクセス条件 | 各EC2のディスクを共有だと思う |
| 注文と明細を整合させて更新 | データモデルとトランザクション | SQLという単語だけで構成を決める |
| 読み取り増加でDBが詰まる | 読み取り分散とキャッシュの許容鮮度 | 可用性対策を性能対策と取り違える |
RDSの単一スタンバイのMulti-AZ DBインスタンスでは、スタンバイを読み取りの送り先に使いません。読み取りレプリカや、読み取り可能なインスタンスを持つMulti-AZ DBクラスターと一括りにしないようにします。「障害に備えたい」と「読み取りを増やしたい」は別の要求です。
データの使い方と保存先
画像配信、ブロックと共有ファイル、注文の整合した更新、読み取り分散の4要件を比較する。
- 画像をHTTPで配信オブジェクト保存と配信経路を検討する。共有ファイルシステムとは使い方が異なる。
- ディスクか共有ファイルかOSのブロックデバイスと、複数Linux環境で使う共有ファイルを分けて選ぶ。
- 注文と明細の更新データモデル、検索方法、整合性、トランザクションの要件からDBを比較する。
- 読み取りの負荷増加読み取り分散やキャッシュの鮮度を検討する。単一スタンバイのMulti-AZは読み取り先にしない。
通信経路と、操作する権限は別々に確認する
プライベートサブネットから保存先への経路があっても、実行主体に権限がなければ操作できません。IAMで許可しても経路がなければ接続できません。ネットワークと認可を同じチェック欄に入れないようにします。
EC2上のアプリケーションがS3へ画像を保存する例では、「どのロールが、どのバケットの、どの操作を行うか」を言葉にします。アクセスキーをコードへ埋め込む方法とロールを使う方法で、管理作業がどう変わるかも説明してください。暗号化するデータと鍵へのアクセスも別に確認します。
Security GroupとNACLは、適用する境界、状態追跡、許可と拒否の扱いをセットで比較します。「セキュリティを強くする」とまとめず、必要な通信だけ通す、秘密情報を管理する、操作の証跡を残すという要求へ対応させます。
通信経路と認可の別チェック
EC2からS3への経路と通信制御を確認し、ロールの操作権限、暗号鍵と証跡を別に確認する。
- 通信経路EC2からS3へ到達する経路を確認する。IAMの許可があっても経路は作られない。
- 通信の許可Security GroupとNACLの境界・状態追跡・許可と拒否を比較し、必要な通信を通す。
- 操作の認可どのロールが、どのバケットの、どの操作を行うか確認する。到達できても権限がなければ操作できない。
- 鍵と証跡データの暗号化と鍵へのアクセスを確認し、操作の証跡を残す。通信と認可の確認を置き換えない。
コストは、同じ要件を満たす候補どうしで比べる
夜だけ動く開発環境と常時稼働する本番環境では、稼働時間の見直しと購入モデルの検討の比重が違います。中断できるバッチなら再実行を考えた選択ができますが、停止を許容しない処理へそのまま持ち込めません。
保存も容量単価だけで決めず、アクセス頻度、取り出しに許される時間、保存期間、リクエストや取り出しに伴う費用を見ます。通信経路が変わる構成では転送量も比較対象です。必須条件を満たした候補の中で、費用と管理負担を比べてください。
一つの構成を、条件を変えて三回解き直す
毎回別のサービスを覚えるより、一つの画像投稿サービスを変形すると判断の境界が見えます。
- 投稿数だけ急増したら、受付、キュー、ワーカー、保存先のどこに容量が必要か考える。
- 加工結果を即座に返す要件に変えたら、非同期処理を使える範囲を見直す。
- AZ障害でも受付を続ける要件に変えたら、計算資源と依存する部品を点検する。
採用する構成と、他の候補を退ける理由を一文ずつ書きます。「管理が楽だから」で終わらず、減らせる具体的な作業と、その構成でも守るべき制約を説明します。
同じ構成を三つの条件で再検討
投稿数の急増、即時応答、AZ障害の順に同じ構成を解き直し、各案の採用と不採用の理由を比べる。
- 変更1：投稿数が急増元の画像投稿構成で、受付・キュー・ワーカー・保存先のどこに容量が必要か考える。
- 変更2：結果を即時に返す元の構成の応答要件を変え、非同期処理を使える範囲を見直す。
- 変更3：AZ障害でも受付元の構成でAZを一つ失い、計算資源・依存先・残存容量を点検する。
- 三案の根拠を比較各条件で採用する構成と退ける候補の理由を書く。説明できない制約は元の構成へ戻って調べる。
復習は、落とした設計条件へ戻る
間違いを知識不足、要件の読み落とし、構成の途中での思考停止へ分けます。Multi-AZと読み取り分散の混同ならDBの比較へ、所在地制約の見落としなら必須条件を書き出す練習へ戻ります。
正解しても、別の候補が満たせない条件を説明できなければ復習候補です。弱点分析で分野を絞った後、その分野の教材をすべて読む前に、迷った二つを並べて条件を一つ変えてください。
模擬試験では時間配分を確認します。長い設問を目的、必須条件、比較条件の順に短く整理し、選択肢に含まれる運用作業まで読みます。保留した設問も、何が不明だったかを残せば振り返りが具体的になります。
次の学習へ進む目安
VPC内の経路を描けなければネットワークの学習教材へ、サービスは分かるのに構成を比較できなければ問題演習へ進みます。苦手な判断は弱点分析で絞り、複数分野をまたぐ設計と時間配分は模擬試験で確かめてください。
到達目標は、画像投稿サービスを描き、通信・権限・保存・障害・負荷・費用の観点から構成の理由を説明できることです。説明できない矢印や部品が次の学習テーマになります。
この学習ガイドは2026-10-05に改訂しました。受験料、試験時間、配信方式、認定更新の条件は、申込時にAWS認定公式ページで確認してください。