SAA 試験範囲：4ドメイン詳細解説｜SAA-C03 の出題タスクと配点を設計の地図に変える
AWS SAA-C03 の出題は「セキュア（30%）・回復性（26%）・高性能（24%）・コスト最適化（20%）」の4ドメインに分かれる。結論は「各ドメインを “何を最適化する設計か” の一言に畳み、配点上位から攻める」のが最短ルートだ。本記事は、4ドメインそれぞれの公式タスクステートメント（1.1〜4.4）を分解し、各ドメインで問われる中核サービス・設計判断・頻出ひっかけ・学習の優先順位までを、SAA 受験者がそのまま学習計画に落とせる粒度で詳説する。試験範囲の全体像を1枚の地図にしたい人のための完全ガイドだ。
「SAA は範囲が広すぎて、どこから手をつければいいか分からない」——この悩みの正体は、試験範囲を“サービスの羅列”として見ていることにある。SAA-C03 の出題は 65問・130分・720点合格、その中身は「セキュア（30%）・回復性（26%）・高性能（24%）・コスト最適化（20%）」という 4つのドメインにきれいに分かれている。各ドメインはさらに公式のタスクステートメント（1.1〜4.4）へ細分化され、「何を最適化する設計か」が明確に決まっている。つまり SAA の範囲は、広いのではなく構造化されている。本記事では、4ドメインそれぞれのタスク・中核サービス・設計判断・頻出ひっかけを分解し、試験範囲を1枚の地図に変える。読み終えれば、あなたは「どのドメインに何時間かける」かを自分で設計できるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：4ドメインは「何を最適化する設計か」で畳める
- 出題4ドメインと配点の全体像
- ドメイン1：セキュアなアーキテクチャの設計（30%）
- ドメイン2：回復性の高いアーキテクチャの設計（26%）
- ドメイン3：高性能なアーキテクチャの設計（24%）
- ドメイン4：コスト最適化アーキテクチャの設計（20%）
- ドメイン横断で問われる「設計の重なり」
- 配点から逆算する学習の優先順位
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：4ドメインは「何を最適化する設計か」で畳める
SAA-C03 の試験範囲を攻略する最短ルートは、4ドメインをそれぞれ「何を最適化する設計か」という一言に畳むことだ。これが本記事の結論である。
理由はシンプルだ。SAA は個々のサービス知識を問う試験ではなく、「与えられた要件に対して最適な構成を選ぶ」設計試験だからだ。同じ S3 でも、ドメイン1では「バケットポリシーで誰のアクセスを守るか」、ドメイン4では「ストレージクラスでコストをどう削るか」と、問われる観点が違う。サービスを丸暗記しても、観点が定まっていなければ選択肢を絞れない。
そこで4ドメインを次のように畳む。ドメイン1＝「守る設計」、ドメイン2＝「止めない設計」、ドメイン3＝「速く捌く設計」、ドメイン4＝「無駄を削る設計」。この4語を頭に置くだけで、長い問題文を読んだときに「これはどのドメインの判断を求めているか」が瞬時に分かるようになる。
具体例を挙げよう。「ピーク時のアクセス急増にも応答速度を保ちたい」という要件なら、まず思い浮かべるのは**ドメイン3（速く捌く）の CloudFront・ElastiCache・Auto Scaling だ。一方「障害が起きても処理を失わせたくない」ならドメイン2（止めない）**の SQS・Multi-AZ が候補になる。要件のキーワードからドメインを特定し、そのドメインの定番サービスを引き出す——これが SAA の解き方の骨格である。
CLF 合格者なら、この畳み方は自然に飲み込めるはずだ。SAA 試験完全ガイドで試験全体の概要をつかんだら、本記事で各ドメインの中身に踏み込んでいこう。
2. 出題4ドメインと配点の全体像
まず、SAA-C03 の採点対象50問がどう配分されるかを押さえる。配点比率は、そのまま学習時間の配分の地図になる。
| ドメイン | テーマ（畳んだ一言） | 配点 | 目安問題数 |
|---|---|---|---|
| ドメイン1 | セキュアなアーキテクチャ（守る設計） | 30% | 約15問 |
| ドメイン2 | 回復性の高いアーキテクチャ（止めない設計） | 26% | 約13問 |
| ドメイン3 | 高性能なアーキテクチャ（速く捌く設計） | 24% | 約12問 |
| ドメイン4 | コスト最適化アーキテクチャ（無駄を削る設計） | 20% | 約10問 |
注目すべきは、**上位2ドメイン（セキュア＋回復性）だけで56%**を占める点だ。ここを固めれば過半数の得点源を押さえられる。逆に、配点最小のコスト最適化（20%）を完璧にしても、セキュリティが穴だらけでは合格は遠い。配点上位から攻める——これが範囲攻略の大原則だ。
| 評価項目 | セキュア 推奨 | 回復性 | 高性能 | コスト |
|---|---|---|---|---|
| 畳んだ一言 | 守る | 止めない | 速く捌く | 無駄を削る |
| 配点 | 30% | 26% | 24% | 20% |
| 代表サービス | IAM / KMS | SQS / Multi-AZ | CloudFront / ElastiCache | ストレージクラス / スポット |
| キーワード | アクセス・暗号化 | 可用性・自動復旧 | レイテンシ・スループット | 料金・リソースサイジング |
3. ドメイン1：セキュアなアーキテクチャの設計（30%）
配点最大のドメイン1は、AWS がセキュリティを最優先事項として扱う姿勢の表れだ。ここは「守る設計」、すなわち誰に・何を・どう守らせるかを問う。公式タスクステートメントは3つに分かれる。
| タスク | 内容 | 中核サービス |
|---|---|---|
| 1.1 | AWS リソースへのセキュアなアクセスを設計 | IAM（ユーザー / ロール / ポリシー） |
| 1.2 | セキュアなワークロード・アプリケーションを設計 | Security Group / NACL / WAF |
| 1.3 | 適切なデータセキュリティ管理を判断 | KMS / S3 暗号化 / Secrets Manager |
1.1 セキュアなアクセス設計
中心は IAM だ。SAA では「IAM ユーザーに長期キーを配るのか、IAM ロールで一時認証にするのか」という判断が繰り返し問われる。EC2 上のアプリが S3 にアクセスするなら、アクセスキーをハードコードするのは誤答で、正解は IAM ロールをインスタンスにアタッチする——この型は丸ごと覚える価値がある。クロスアカウントアクセス、フェデレーション（IdP 連携）、最小権限の原則もこのタスクの定番だ。
1.2 セキュアなワークロード設計
ネットワーク境界の制御が主役。Security Group と NACL の使い分けはほぼ毎回問われる。「SG はステートフルでインスタンス単位・許可ルールのみ、NACL はステートレスでサブネット単位・拒否ルールも書ける」——この差を即答できないと失点する。Web アプリ保護なら WAF、プライベート接続なら PrivateLink や VPC エンドポイントが選択肢に上がる。
1.3 データセキュリティ管理
暗号化の設計だ。KMS による鍵管理を軸に、「保管時の暗号化（at rest）と転送時の暗号化（in transit）」を区別して問われる。S3 なら SSE-S3 / SSE-KMS の選択、認証情報の管理なら Secrets Manager と Parameter Store の使い分け（自動ローテーションが要るなら Secrets Manager）が頻出だ。
4. ドメイン2：回復性の高いアーキテクチャの設計（26%）
ドメイン2は「止めない設計」。障害が起きても、止まらない・自動で復旧する仕組みを問う。タスクステートメントは2つだ。
| タスク | 内容 | 中核サービス |
|---|---|---|
| 2.1 | スケーラブルで疎結合なアーキテクチャを設計 | SQS / SNS / ELB / Auto Scaling |
| 2.2 | 高可用性・耐障害性のアーキテクチャを設計 | Multi-AZ / Route 53 / バックアップ |
2.1 スケーラブルで疎結合な設計
キーワードは疎結合（loose coupling）だ。コンポーネント同士を直接つなぐと、片方が落ちると連鎖して止まる。そこで間にキューやトピックを挟む。非同期で処理を貯めるなら SQS、複数の宛先へ同報するなら SNS、イベント駆動でルーティングするなら EventBridge。「処理が一時的に詰まってもメッセージを失いたくない」という要件は、ほぼ SQS が正解になる。負荷分散は ELB と Auto Scaling の組み合わせが定番だ。
2.2 高可用性・耐障害性の設計
Multi-AZ（複数のアベイラビリティゾーンに分散）が中核概念。単一 AZ 構成は「可用性が低い」誤答パターンで、正解は複数 AZ への分散になりやすい。DB では RDS Multi-AZ（自動フェイルオーバーで可用性向上）と リードレプリカ（読み取り負荷分散）の目的の違いが頻出だ。DNS レベルのフェイルオーバーは Route 53 のヘルスチェック、災害復旧は RTO/RPO に応じた DR 戦略（バックアップ＆リストア／パイロットライト／ウォームスタンバイ／マルチサイト）が問われる。
5. ドメイン3：高性能なアーキテクチャの設計（24%）
ドメイン3は「速く捌く設計」。レイテンシを下げ、スループットを上げるための適切なサービス選定を問う。範囲が広く、タスクは5つに細分化される。
| タスク | 内容 | 中核サービス |
|---|---|---|
| 3.1 | 高性能でスケーラブルなストレージを設計 | S3 / EBS / EFS / FSx |
| 3.2 | 高性能でスケーラブルなコンピュートを設計 | EC2 / Auto Scaling / Lambda |
| 3.3 | 高性能なデータベースを設計 | RDS / Aurora / DynamoDB / DAX |
| 3.4 | 高性能なネットワークを設計 | CloudFront / Global Accelerator |
| 3.5 | データの取り込み・変換を設計 | Kinesis / Glue |
ストレージ・コンピュートの性能設計
ストレージは用途で選ぶ。ブロックなら EBS、共有ファイルなら EFS、オブジェクトなら S3。EBS のボリュームタイプ（gp3 / io2）や、Windows 共有なら FSx という選択も問われる。コンピュートは Auto Scaling による水平スケーリングが基本で、「需要変動に応じて自動で増減」という要件はここに直結する。
データベース・ネットワークの性能設計
DB は読み取りが重いなら ElastiCache でキャッシュ、DynamoDB ならマイクロ秒応答の DAX を足す。RDB のスケールは Aurora のリードレプリカが定番だ。ネットワークの高速化は、静的・動的コンテンツのエッジ配信なら CloudFront、TCP/UDP を含むグローバルなレイテンシ低減なら Global Accelerator——この2つの使い分けが頻出ひっかけだ。
6. ドメイン4：コスト最適化アーキテクチャの設計（20%）
配点は最小だが、実務で最も喜ばれるのがこのドメイン4「無駄を削る設計」だ。性能・可用性を保ちながら、いかにコストを下げるかを問う。タスクは4つ。
| タスク | 内容 | 中核サービス |
|---|---|---|
| 4.1 | コスト最適化されたストレージを設計 | S3 ストレージクラス / ライフサイクル |
| 4.2 | コスト最適化されたコンピュートを設計 | スポット / リザーブド / Savings Plans |
| 4.3 | コスト最適化されたデータベースを設計 | RDS / Aurora Serverless |
| 4.4 | コスト最適化されたネットワークを設計 | データ転送 / VPC エンドポイント |
ストレージとコンピュートのコスト最適化
ストレージは S3 ストレージクラスの選定が中心。アクセス頻度が読めないなら Intelligent-Tiering、アーカイブなら Glacier 階層、自動移行は ライフサイクルポリシーで行う。コンピュートはコミットメント割引が鍵だ。中断耐性があるバッチなら スポット（最大9割引）、安定稼働なら リザーブドや Savings Plans。「常時稼働の本番 DB」にスポットを選ぶのは誤答だ——ワークロードの性質と割引モデルの相性が問われる。
データベース・ネットワークのコスト最適化
DB は、断続的・予測不能な負荷なら Aurora Serverless で使った分だけ課金。ネットワークではデータ転送料金が盲点になりやすい。同一 AZ 内は無料だが、AZ 間・リージョン間・インターネット向けは課金される。S3 への通信を VPC エンドポイント（Gateway 型）経由にして NAT Gateway 料金を削る、といった設計が問われる。コスト可視化は Cost Explorer と Budgets が定番だ。
7. ドメイン横断で問われる「設計の重なり」
ここまで4ドメインを分けて説明したが、実際の試験問題は複数ドメインにまたがる。SAA が難しく感じる最大の理由はここにある。
たとえば「グローバルなユーザーに低レイテンシで静的コンテンツを配信し、かつ転送コストを抑えたい」という要件は、**ドメイン3（高性能＝CloudFront でエッジ配信）とドメイン4（コスト＝キャッシュで転送料削減）**が同時に問われている。あるいは「機密データを複数 AZ に冗長化して保管」は、**ドメイン1（暗号化）×ドメイン2（可用性）**の重なりだ。
この「重なり」を読み解くコツは、要件文を一度ドメインのキーワードに分解することだ。「低レイテンシ」「グローバル」→ 性能（ドメイン3）、「コストを抑え」→ コスト（ドメイン4）、というように要件を色分けすれば、長文に惑わされず必要なサービスを引き出せる。Well-Architected Framework の6つの柱を理解しておくと、この分解がさらにスムーズになる（SAA の4ドメインは、運用・セキュリティ・信頼性・性能効率・コストの柱と地続きだ）。
8. 配点から逆算する学習の優先順位
最後に、4ドメインの配点をふまえた学習順を提案する。範囲が広い SAA でも、攻める順番を間違えなければ効率的に合格ラインに届く。
| 優先 | ドメイン | 学習の狙い |
|---|---|---|
| 1番目 | ドメイン1（30%） | 配点最大。IAM・暗号化・SG/NACL を最優先で固める |
| 2番目 | ドメイン2（26%） | Multi-AZ・疎結合・DR で過半数の得点源を確保 |
| 3番目 | ドメイン3（24%） | サービス選定の幅が広い。使い分けの暗記が効く |
| 4番目 | ドメイン4（20%） | 割引モデルとストレージクラスで短期に詰められる |
ドメイン1と2で56%。ここを安定して取れる状態を作れば、合格ライン（72%）まで残りはドメイン3・4から拾うだけになる。最初の1ヶ月はドメイン1・2に集中し、2ヶ月目でドメイン3・4を広げ、3ヶ月目を模試の反復に充てる——この順番が、範囲攻略の王道だ。具体的な週次計画はSAA 試験完全ガイドの3ヶ月ロードマップを参照してほしい。
9. 次のアクション チェックリスト
4ドメインの地図を、今日からの学習計画に落とし込むための具体アクションをまとめる。
10. 関連記事
- SAA 試験完全ガイド｜SAA-C03 の出題範囲・難易度・3ヶ月合格戦略 — 本記事の上位ガイド
- CLF 合格後の次のステップ：SAA への道 — CLF→SAA の移行手順
- Well-Architected Framework 6つの柱 — 4ドメインの設計思想の土台
- AWS IAM 完全ガイド — 配点最大ドメイン1の中核
- Security Group と Network ACL の違い — ドメイン1の頻出ひっかけ
- Amazon SQS と SNS の違い完全比較 — ドメイン2の疎結合設計
- RDS Multi-AZ と Read Replica の違い — ドメイン2の可用性設計
- CloudFront とは？CDN の仕組みと活用 — ドメイン3の性能設計
- S3 ストレージクラス 7種類の使い分け — ドメイン4のコスト最適化
11. 関連サイト
AWS 公式
- AWS Certified Solutions Architect – Associate（公式）
- SAA-C03 試験ガイド（公式 PDF）
- AWS 認定 一覧（公式）
- AWS Well-Architected Framework（公式）