＜1-2＞ SAA-C03の試験範囲を4つのドメインから読み解く
SAA-C03の試験範囲は、細かいAWSサービス名を丸暗記する前に、まず4つのドメインで読むと整理しやすくなります。
公式試験ガイドでは、SAA-C03は次の4領域で構成されています。配点が最も大きいのは「セキュアなアーキテクチャの設計」で、次に「回復性」「高パフォーマンス」「コスト最適化」が続きます。
- セキュアなアーキテクチャの設計: 30%
- 回復性に優れたアーキテクチャの設計: 26%
- 高パフォーマンスなアーキテクチャの設計: 24%
- コスト最適化されたアーキテクチャの設計: 20%
試験対策では、サービスを単体で覚えるよりも「この選択肢は4ドメインのどれを満たすための設計か」と読むことが重要です。 たとえば、Amazon S3、Amazon RDS、Elastic Load Balancing、Auto Scaling、IAM、AWS KMSは、単独サービスとしてではなく、セキュリティ、可用性、性能、コストのどの要求を満たすかで問われます。
この記事では、2026年4月時点で確認できるAWS公式のSAA-C03試験ガイドを前提に、4つのドメインを学習の地図として整理します。
この記事で理解すること
- SAA-C03の4ドメインと配点
- 各ドメインで問われる設計判断の方向性
- AWS Well-Architected Frameworkとの関係
- サービス名を覚える前に見るべき判断軸
- 試験対策で間違えやすい読み方
まず結論: 4ドメインは「設計判断の軸」
SAA-C03は、AWSサービスの名前を知っているかだけを見る試験ではありません。公式試験ガイドでも、AWS Well-Architected Frameworkに基づいて、要件に合うソリューションを設計できることが確認対象になっています。
つまり、選択肢を読むときは次のように考えます。
- 権限、暗号化、ネットワーク制御の話なら、まずセキュリティを見る
- 障害時の継続、マルチAZ、バックアップの話なら、回復性を見る
- レイテンシー、スループット、スケーリングの話なら、高パフォーマンスを見る
- 過剰なリソース、購入オプション、ストレージ階層の話なら、コストを見る
ここがポイント: SAA-C03では「どのサービスを使うか」だけでなく、「そのサービスをどの目的で選ぶか」が問われます。
AWS Well-Architected Frameworkには6つの柱がありますが、SAA-C03の試験ドメインとして前面に出るのは、セキュリティ、信頼性、高パフォーマンス、コスト最適化に近い4領域です。運用上の優秀性やサステナビリティもAWS設計では重要ですが、SAA-C03の配点表を読むと、まず上の4ドメインを軸に学習を組み立てるのが自然です。
4つのドメインを配点で見る
配点は、学習時間のかけ方を決める目安になります。30%のドメインと20%のドメインを同じ量で扱うより、まず重い領域から固めるほうが復習しやすくなります。
| ドメイン | 配点 | 中心になる設計判断 | 関連しやすいAWSサービス例 |
|---|---|---|---|
| Design Secure Architectures | 30% | 誰に、どの権限で、どの経路から、どのデータへアクセスさせるか | IAM、IAM Identity Center、KMS、VPC、Security Group、AWS WAF、Secrets Manager |
| Design Resilient Architectures | 26% | 障害が起きても処理を続ける、または素早く復旧する設計にするか | ELB、Auto Scaling、Multi-AZ、Route 53、S3、RDS、DynamoDB |
| Design High-Performing Architectures | 24% | 要求される応答速度、処理量、拡張性を満たす構成にするか | CloudFront、ElastiCache、EC2、Lambda、EBS、S3、DynamoDB |
| Design Cost-Optimized Architectures | 20% | 必要な性能や可用性を保ちながら、無駄な支出を減らすか | Savings Plans、Reserved Instances、S3 Storage Classes、Auto Scaling、AWS Budgets |
この表で大事なのは、サービス名が複数のドメインにまたがることです。たとえばS3は、暗号化やバケットポリシーではセキュリティ、耐久性やレプリケーションでは回復性、ストレージクラスではコスト最適化として出てきます。
Domain 1: セキュアなアーキテクチャの設計
配点が最も大きい領域です。SAA-C03対策では、IAM、ネットワーク境界、暗号化、認証認可を先に押さえる価値があります。
何を見ればよいか
セキュリティの問題では、まず「誰が何にアクセスするのか」を読みます。
- 人間の利用者か、AWSサービスか
- 同一アカウント内か、クロスアカウントか
- 一時的な権限でよいか、長期的な認証情報が必要か
- データは保存時と転送時のどちらで保護する必要があるか
- インターネット公開が必要か、プライベート接続でよいか
IAMポリシー、ロール、リソースベースポリシー、Security Group、NACL、KMSキーなどは、それぞれ守る場所が違います。ここを混同すると、選択肢の絞り込みが難しくなります。
試験対策上の押さえどころ
最小権限の原則は、SAA-C03のセキュリティ判断で何度も使う考え方です。必要以上に広い権限、長期アクセスキーの配布、パブリックアクセスの放置は、設計上の弱点として読みます。
代表的な判断軸は次のとおりです。
- アプリケーションからAWSサービスへアクセスするなら、IAMロールを優先して考える
- 複数アカウントを扱うなら、AWS OrganizationsやSCPの役割を確認する
- 機密情報をアプリケーションに直書きしない
- 保管データの暗号化にはKMSの関与を確認する
- ネットワーク制御ではSecurity GroupとNACLの違いを分ける
Domain 2: 回復性に優れたアーキテクチャの設計
回復性は、障害を完全に避ける話ではありません。障害が起きる前提で、サービスを継続する、または許容時間内に戻す設計です。
可用性と耐障害性を分けて読む
可用性の文脈では、単一障害点を減らす設計が問われます。Multi-AZ構成、複数インスタンス、Elastic Load Balancing、Auto Scaling、Route 53のルーティングなどが代表例です。
耐障害性や復旧の文脈では、バックアップ、レプリケーション、フェイルオーバー、RTO/RPOが判断材料になります。
- RTO: どれくらいの時間で復旧する必要があるか
- RPO: どれくらいのデータ損失まで許容できるか
- Multi-AZ: 同一リージョン内で可用性を高める設計
- Multi-Region: リージョン障害や地理的要件まで見る設計
間違えやすい点
回復性の問題では、過剰設計に注意します。すべてをMulti-Regionにすればよいわけではありません。要件がMulti-AZで満たせるなら、よりシンプルでコストも抑えやすい選択肢が正解に近くなります。
SAA-C03では、要件に対して「十分な回復性」を選ぶ読み方が必要です。
Domain 3: 高パフォーマンスなアーキテクチャの設計
高パフォーマンスは、単に大きなインスタンスを選ぶ話ではありません。ユーザーに近い場所で配信する、キャッシュする、疎結合にする、ワークロードに合うデータストアを選ぶ、といった設計判断が中心です。
性能要件を分解する
問題文に性能の話が出たら、何が不足しているのかを分けます。
- レイテンシーを下げたいのか
- スループットを上げたいのか
- 急なアクセス増に追従したいのか
- 読み取りが多いのか、書き込みが多いのか
- グローバルユーザー向けに配信したいのか
たとえば、静的コンテンツを世界中に配るならCloudFrontが候補になります。データベースの読み取り負荷が高いなら、リードレプリカやキャッシュを検討します。キューを使って非同期化すれば、前段のアプリケーションと後段の処理を分離できます。
サービス選択の見方
高パフォーマンス領域では、次のような比較が出やすくなります。
- EC2のインスタンスタイプ選択
- EBSボリュームタイプの違い
- RDS、DynamoDB、ElastiCacheの使い分け
- CloudFrontとリージョナルな配信の違い
- Lambdaやコンテナを使ったスケーリング設計
「速くする」ではなく、どの部分のボトルネックを解消するかで読むと、選択肢を切り分けやすくなります。
Domain 4: コスト最適化されたアーキテクチャの設計
コスト最適化は、安い構成を選ぶだけではありません。必要な可用性、性能、セキュリティを満たしたうえで、使っていないリソースや過剰な構成を減らす設計です。
コスト問題で見るポイント
問題文に「コストを最小化」「使用量が予測可能」「アクセス頻度が低い」「一時的な処理」といった表現があれば、コスト最適化の視点を強めます。
- 定常的なEC2利用ならSavings PlansやReserved Instancesを検討する
- 中断可能なバッチ処理ならSpot Instancesが候補になる
- アクセス頻度が低いオブジェクトはS3ストレージクラスを見直す
- 需要変動が大きいならAuto Scalingやサーバーレスを検討する
- 使っていないリソース、過剰なプロビジョニングを避ける
ただし、コストだけで選ぶと誤ります。たとえば可用性要件が高い本番DBで、単に安いからという理由だけで単一AZ構成を選ぶのは危険です。
4ドメインはAWS Well-Architectedの考え方とつながる
AWS Well-Architected Frameworkは、クラウド上の設計を評価するためのベストプラクティス集です。公式ドキュメントでは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、サステナビリティの6つの柱が示されています。
SAA-C03の4ドメインは、このうち特に試験で中心になる設計観点に対応していると考えると理解しやすくなります。
| SAA-C03のドメイン | 近いWell-Architectedの柱 | 試験での読み方 |
|---|---|---|
| セキュアなアーキテクチャ | Security | 権限、暗号化、ネットワーク保護、データ保護を確認する |
| 回復性に優れたアーキテクチャ | Reliability | 障害時の継続、復旧、冗長化、バックアップを確認する |
| 高パフォーマンスなアーキテクチャ | Performance Efficiency | レイテンシー、スループット、スケーリング、適切なリソース選択を見る |
| コスト最適化されたアーキテクチャ | Cost Optimization | 過剰構成を避け、使用量やアクセス頻度に合う購入・配置を選ぶ |
この対応関係を持っておくと、個別サービスの記事を読むときにも迷いにくくなります。たとえば「RDS Multi-AZ」は回復性、「RDSリードレプリカ」は主に読み取り性能、「Reserved DB Instances」はコスト、というように、同じRDSでも論点を分けられます。
間違えやすい読み方
4ドメインを読むときに、初心者がつまずきやすい点を整理します。
- セキュリティとネットワークを別物として覚えすぎる
- Multi-AZとMulti-Regionを同じ高可用性として扱う
- パフォーマンス改善をインスタンスサイズ変更だけで考える
- コスト最適化を「最安構成の選択」とだけ考える
- サービス名を見ただけで正解と決め、要件を読み落とす
特に注意したいのは、1つの選択肢が複数ドメインに関係するケースです。CloudFrontはパフォーマンス改善に使われますが、AWS WAFやTLSと組み合わせればセキュリティにも関係します。Auto Scalingは回復性や性能だけでなく、需要に応じて台数を調整するためコストにも関係します。
試験対策メモ: 選択肢を読む順番
SAA-C03の選択肢は、どれもAWSらしく見えることがあります。迷ったときは、次の順番で読み直すと整理しやすくなります。
- 問題文の最優先要件を探す
- セキュリティ、回復性、性能、コストのどれが中心かを決める
- 必須条件を満たしていない選択肢を消す
- 過剰設計や運用負荷が大きすぎる選択肢を疑う
- AWSマネージドサービスで要件を満たせるかを見る
たとえば「管理負荷を下げたい」と書かれている場合、EC2に自前で構築するより、RDS、DynamoDB、S3、Lambdaなどのマネージドサービスが適する場面があります。一方で、特殊なOS設定や細かい制御が必要ならEC2が候補に残ります。
このように、ドメインと要件を結びつけて読むと、暗記したサービス名をそのまま当てはめるより判断が安定します。
このテーマで最低限覚えること
- SAA-C03の4ドメインは、セキュリティ30%、回復性26%、高パフォーマンス24%、コスト最適化20%。
- 最も配点が大きいのはセキュリティなので、IAM、暗号化、ネットワーク制御、最小権限を優先して固める。
- 回復性は障害前提の設計であり、Multi-AZ、バックアップ、フェイルオーバー、RTO/RPOを分けて理解する。
- 高パフォーマンスは、レイテンシー、スループット、スケーリング、キャッシュ、適切なデータストア選択で読む。
- コスト最適化は最安構成ではなく、要件を満たしたうえで無駄を減らす設計として考える。
次に個別サービスを学ぶときは、「このサービスは4ドメインのどこで効くのか」をメモしていくと復習しやすくなります。S3、RDS、EC2、VPC、IAMのような頻出サービスほど、1つのドメインだけに閉じず、複数の設計観点で整理するのがポイントです。