AWS Certified Solutions Architect – Associate（SAA）は、
「AWSを使ってシステムを設計できるか」 を問う試験です。
クラウドプラクティショナーが
“AWSの地図を理解する試験” だとすると、
SAAは
“その地図を使って設計できるかを問う試験” です。
つまり、
AWSの俯瞰 → 構造化 → 設計判断
という流れを体系的に理解する必要があります。
本記事では、クラウドプラクティショナー編の続編として、
ソリューションアーキテクトに必要な視点を構造化して整理します。
🧭 1. SAAの位置づけ（クラウドプラクティショナーとの違い）
SAAで問われるのは「AWSを使った設計判断」です。
クラウドプラクティショナー（CLF）
- AWSの全体像
- サービスの役割
- クラウドの基本概念
- コスト・責務分担モデル
ソリューションアーキテクト（SAA）
- 要件に応じたサービス選定
- 可用性・耐障害性の設計
- セキュリティの組み込み
- スケーラビリティ
- コスト最適化
- 統合（SQS / SNS / EventBridge）
- ネットワーク設計（VPC / ALB / NLB）
つまり、SAAは
「AWSのサービスをどう組み合わせるか」
を問う試験です。
🗺️ 2. AWSサービスの俯瞰（SAA向けに再構造化）
クラウドプラクティショナー編よりも深い粒度で分類します。
① Compute
- EC2
- Lambda
- ECS / Fargate
- Auto Scaling
- Elastic Beanstalk
② Storage
- S3
- EBS
- EFS
- FSx
- S3 Glacier
③ Database
- RDS
- Aurora
- DynamoDB
- ElastiCache
- Redshift
④ Network
- VPC
- Subnet
- Route Table
- NAT Gateway
- ALB / NLB
- Route53
⑤ Security
- IAM
- KMS
- Cognito
- Secrets Manager
- WAF / Shield
⑥ Integration
- SQS
- SNS
- EventBridge
- Step Functions
⑦ Observability
- CloudWatch
- CloudTrail
- X-Ray
SAAでは、この分類を 「設計判断の軸」 として使います。
🏗️ 3. アーキテクチャ設計の基本原則（SAAの本質）
SAAは「AWSらしい設計」ができるかを問います。
① 責務分離
- UI
- アプリケーション
- データ
- ネットワーク
- セキュリティ
- ログ・監査
② 疎結合
- SQS / SNS / EventBridge
- Lambda
- マイクロサービス
③ スケーラビリティ
- Auto Scaling
- ALB
- DynamoDB（水平スケール）
④ 耐障害性
- Multi-AZ
- S3の耐久性
- ALB + 複数ターゲット
⑤ セキュリティ
- IAM
- KMS
- VPC
- WAF
⑥ コスト最適化
- S3
- Lambda
- DynamoDB
- Aurora Serverless v2
SAAは「どの原則を優先すべきか」を判断する試験です。
🧩 4. SAAで頻出する設計パターン
① Web三層構造
- ALB
- EC2 / ECS / Lambda
- RDS / DynamoDB
② サーバレス構成
- API Gateway
- Lambda
- DynamoDB
- S3
- CloudFront
③ マイクロサービス
- ECS / Fargate
- SQS / SNS
- EventBridge
- DynamoDB
④ イベント駆動
- EventBridge
- Lambda
- Step Functions
⑤ バッチ処理
- EventBridge（スケジュール）
- Lambda
- ECS
- S3
⑥ データ分析基盤
- S3（データレイク）
- Glue
- Athena
- Redshift
これらは SAA の問題文に頻出します。
⚖️ 5. SAAで問われる「判断」
SAAは「どちらを選ぶべきか」を問う試験です。
ALB vs NLB
- ALB：HTTP/HTTPS、ルーティング
- NLB：高速、TCP/UDP、固定IP
SQS vs SNS
- SQS：キュー（順番に処理）
- SNS：通知（同時に配信）
DynamoDB vs RDS
- DynamoDB：水平スケール、NoSQL
- RDS：リレーショナル、複雑なクエリ
Lambda vs ECS
- Lambda：イベント駆動、短時間
- ECS：長時間処理、コンテナ管理
S3 vs EFS vs FSx
- S3：オブジェクト
- EFS：POSIX
- FSx：高性能ファイルシステム
Aurora Serverless v2 の使いどころ
- スパイクがある
- 常時稼働ではない
- コスト最適化したい
これらの判断軸を理解すると、SAAの問題が一気に解けるようになります。
📝 6. SAAの試験対策（構造化）
① 問題文の読み方
- 「高可用性」→ Multi-AZ
- 「スケーラブル」→ ALB / Auto Scaling
- 「疎結合」→ SQS / SNS / EventBridge
- 「コスト最適化」→ S3 / Lambda / DynamoDB
② 選択肢の切り捨て方
- EC2単体は基本NG
- 自前で管理する構成はNG
- 冗長化されていない構成はNG
③ 非機能要件の優先順位
- 可用性
- 耐障害性
- セキュリティ
- コスト
④ “AWSらしい設計”の判断基準
- マネージドサービスを使う
- サーバレスを優先
- 疎結合
- 冗長化
- スケールアウト
🗒️ 7. まとめ：SAAは「設計者としてのAWSの地図」を作る試験
クラウドプラクティショナー編で
AWSの地図を理解した あなたは、
SAAでその地図を 設計に使えるようになる フェーズに入ります。
- AWSサービスの俯瞰
- 設計原則
- 設計パターン
- 判断軸
- 非機能要件
これらを構造化して理解することで、
SAAは確実に突破できます。
🔗 関連リンク
AWSの俯瞰と構造化（クラウドプラクティショナー編）（前編）
https://qiita.com/cloud_moso_architect/items/3448a5fd2d403d618120
AWSの俯瞰と構造化（AI プラクティショナー編 #1：全体像）
https://qiita.com/cloud_moso_architect/items/de9307b81e6e23a12cc0
AWSの俯瞰と構造化（AI プラクティショナー編 #2：AIの基礎）
https://qiita.com/cloud_moso_architect/items/6675d611a908ce9bb98d