導入
SAA-C03（AWS認定ソリューションアーキテクト アソシエイト）は、単なるサービス暗記では点が伸びにくい試験です。なぜなら出題の多くが「この要件なら、どの設計判断が妥当か？」という設計者の判断力を問う形式だからです。つまり、サービス名を知っているだけでは足りず、要件を読んで“設計の型”に落とし込み、そこからサービスを選ぶ必要があります。
ここで強力なのが AWS Well-Architected Framework（WAF） です。WAFは「良いアーキテクチャの判断基準」を5つの柱で整理しています。SAA-C03の問題文は、一見バラバラなサービス選定に見えても、実はこの5本柱のどれか（または複数）に必ず紐づきます。
この記事では、Well-Architectedの5本柱を“試験で解ける形”に変換します。具体的には次の流れです。
- **要件（問題文）**を読む
- それを5本柱の観点に翻訳する
- さらに**頻出設計パターン（型）**に変換する
- 最後にサービス選定をする
この「翻訳機」を頭に入れるだけで、問題を見た瞬間に「これは信頼性の単一障害点排除」「これはセキュリティの最小権限」「これはコスト最適化のストレージ階層化」と、解き方の方向が定まります。結果として、迷いが減り、消去法も強くなり、正答率が安定します。
本記事は、次のような人に特におすすめです。
- サービスは一通り覚えたのに模試の点が伸びない
- 選択肢で最後まで迷って時間が足りない
- 「どれも正しそう」に見えて決め手がない
- 要件からアーキテクチャを組み立てるのが苦手
次のブロックで、5本柱を試験頻出の設計パターンに変換した「全体マップ」を作ります。ここができると、以降の学習が一気に整理されます。
5本柱→頻出設計パターン変換表
まずはSAA-C03での最重要ポイントを一言でまとめます。
**Well-Architectedの5本柱＝試験の“採点基準”**です。問題文に書かれている要件は、実質的に「どの柱を満たす設計が正しいか」を問うています。
Well-Architected 5本柱
- 運用優秀性（Operational Excellence）：監視、可観測性、運用自動化、変更管理、運用手順
- セキュリティ（Security）：最小権限、監査、暗号化、境界防御、データ保護
- 信頼性（Reliability）：単一障害点排除、復旧設計、バックアップ、マルチAZ/リージョン
- パフォーマンス効率（Performance Efficiency）：スケーリング、適切なサービス選択、キャッシュ、サーバレス
- コスト最適化（Cost Optimization）：従量課金の活用、ストレージ階層化、予約/スポット、無駄削減
ここからが本題です。試験では柱そのものより、柱を満たす定番の設計パターンを問われます。以下の「変換表」を暗記ではなく“理解”しておくと、問題文が読みやすくなります。
5本柱 → 試験頻出パターン変換表
運用優秀性
- 問い（問題文のサイン）
- 「監視したい」「メトリクス」「ログを集約」「通知したい」
- 「構成の逸脱を検知」「変更の履歴を追いたい」
- 定番パターン（型）
- 可観測性：メトリクス/ログ/トレースの設計
- 構成管理：望ましい状態の維持、逸脱検知
- 自動化：手順をコード化（再現性）
- 定番解（代表サービス）
- CloudWatch / CloudTrail / AWS Config
- Systems Manager（Run Command, Automation）
- EventBridge + Lambda（イベント駆動の運用）
セキュリティ
- 問い
- 「最小権限」「誰が何をしたか」「暗号化」「キー管理」
- 「インターネットから隔離」「秘密情報」
- 定番パターン
- IAM最小権限 / ロール前提
- 監査ログ（操作証跡）
- 暗号化（保存時/転送時）
- ネットワーク分離（VPC設計、Private化）
- 定番解
- IAM / Organizations SCP / KMS / Secrets Manager
- WAF / Shield / Security Group / NACL
- VPC Endpoint（プライベート接続）
信頼性
- 問い
- 「高可用性」「障害に耐える」「DR」「RTO/RPO」「バックアップ」
- 定番パターン
- マルチAZ、冗長化、フェイルオーバー
- DR戦略（バックアップ＆リストア、パイロットライト等）
- 定番解
- ALB + Auto Scaling + Multi-AZ
- RDS Multi-AZ / Aurora
- S3 + バージョニング + レプリケーション
パフォーマンス効率
- 問い
- 「急なアクセス増」「低レイテンシ」「スケーラブル」「疎結合」
- 定番パターン
- キャッシュ、CDN、非同期化（キュー）
- サーバレス/マネージドでスケール
- 定番解
- CloudFront / ElastiCache
- SQS / SNS / EventBridge
- Lambda / Fargate / DynamoDB
コスト最適化
- 問い
- 「最小コスト」「ピークが読めない」「使ってないリソース」
- 定番パターン
- ストレージ階層化、ライフサイクル
- 予約（Savings Plans/RI）とスポット
- サーバレスでアイドルコスト削減
- 定番解
- S3 Standard/IA/Glacier + Lifecycle
- Savings Plans / Spot
- Lambda / DynamoDB On-Demand など
この表を見てわかる通り、SAA-C03は「柱→型→サービス」という順番で整理すると、問題文が“暗号”ではなく“ヒント集”になります。次のブロックから、柱ごとに頻出の型を具体的なサービス判断へ落とし込みます。
運用優秀性×セキュリティ
ここでは 運用（見える化・自動化） と セキュリティ（権限・監査・暗号化） をセットで攻略します。SAA-C03では、この2つが絡む問題が非常に多いからです。たとえば「誰が何をしたか追跡しつつ、設定逸脱も検知し、通知もしたい」といった“全部盛り”が典型です。
ログ・監査の鉄板：CloudTrail / CloudWatch / Config の使い分け
よくある混乱ポイントを最短で整理します。
- CloudTrail：
“誰が、いつ、何をしたか”＝API操作の証跡（監査ログ）- IAM、S3、EC2などの操作履歴
- セキュリティ監査で定番
- CloudWatch：
“メトリクス・ログ・アラーム”＝運用監視（監視と通知）- CPU、ALBのリクエスト数、Lambdaエラー
- ログ収集→メトリクス化→アラーム通知
- AWS Config：
“設定が望ましい状態か”＝構成のスナップショットと逸脱検知- 「S3がパブリックになった」など設定変更の追跡
- ルール違反の検知（Config Rules）
試験の要件→解（テンプレ）
- “監査（誰が操作）” → CloudTrail
- “監視（メトリクス/アラーム）” → CloudWatch
- “設定逸脱（構成が正しいか）” → Config
- “イベントで自動処理” → EventBridge + Lambda / SSM Automation
最小権限の鉄板：IAMユーザーよりロール、長期キーより一時クレデンシャル
SAA-C03はセキュリティの解答でよく「より安全な方」を選ばせます。
- アプリ/EC2/LambdaがAWSにアクセスするなら
→ IAMユーザーのアクセスキー埋め込みは避け、IAMロールを使う - クロスアカウントなら
→ AssumeRole（STS）で一時的に権限を得る設計が定番 - 組織全体で禁止したいなら
→ IAMポリシーではなくOrganizationsのSCPが候補に出る
暗号化の鉄板：KMSが絡む選択肢は“鍵の管理責任”で判断
S3、EBS、RDSなどの暗号化で頻出なのがKMSです。試験では次の観点で判断すると外しにくいです。
- “AWS管理で十分” → SSE-S3 など（ただし選択肢に出ないことも多い）
- “キーのローテーション、監査、アクセス制御が必要” → KMS（CMK/KMSキー）
- “アプリが秘密情報を扱う” → Secrets Manager（DBパスワード等）
ネットワークの鉄板：Private化 + VPC Endpoint
「インターネットを経由させずにS3/DynamoDBへアクセスしたい」
この要件が見えたら、VPC Endpoint が最有力です。
- S3/DynamoDB → Gateway Endpoint
- その他（SSM, Secrets Manager等） → Interface Endpoint
セキュリティ面の“ありがち誤答”は、NAT Gatewayでインターネットに出してしまう構成です。要件が「インターネットを経由しない」なら、Endpointが正解側に寄ります。
まとめ
- 監査＝CloudTrail、監視＝CloudWatch、逸脱＝Config
- 認証情報は埋め込まない＝ロール（STS）
- 暗号化で管理したい＝KMS
- インターネットを経由しない＝VPC Endpoint
次はSAA-C03の得点源である「信頼性×パフォーマンス」に進みます。ここが理解できると、アーキテクチャ問題が一気に楽になります。
信頼性×パフォーマンス効率
SAA-C03の中心は、結局ここです。
落ちない（Reliability） と 速い/伸びる（Performance） を両立する設計判断が頻出だからです。
高可用の鉄板：マルチAZが“基本形”
問題文に「高可用」「ダウンタイム最小」「耐障害性」とあれば、まず疑うべきは**単一障害点（SPOF）**です。SPOFを潰す最短ルートがマルチAZです。
- Web/APP：ALB + Auto Scaling（複数AZ）
- DB：RDS Multi-AZ / Aurora（冗長化）
- さらに高度：マルチリージョン（要件が強い場合）
誤答の典型
- “EC2を1台大きくする（スケールアップ）”で高可用にしようとする
- “バックアップがあるからOK”と勘違い（バックアップは可用性ではなく復旧策）
DR（災害対策）はRTO/RPOで決める
DRは暗記になりがちですが、試験はだいたいこうです。
- RPOが小さい（データ損失をほぼ許容しない）
→ レプリケーションや同期に寄る - RTOが小さい（すぐ復旧したい）
→ 常時/準備済みの構成に寄る - コスト最優先
→ バックアップ＆リストア寄り
ここで大事なのは、問題文がどこまで求めているか。
「コストを最小に」「復旧は数時間以内でOK」のように書いてあれば、過剰設計（常時稼働）は不正解になりやすいです。
疎結合・非同期の鉄板：SQS / SNS / EventBridge の役割で判断
試験に出る“非同期化”は、要件のサインがわかりやすいです。
- “ピーク吸収したい/一時的に処理が詰まる” → SQS（キューで平準化）
- “複数の購読者に通知したい/Pushしたい” → SNS
- “イベントでサービス連携したい/ルーティングしたい” → EventBridge
ここは頻出ですが、迷ったらこう考えます。
SQS＝ためる（バッファ）、SNS＝知らせる（Pub/Sub）、EventBridge＝つなぐ（イベントバス）。
低レイテンシの鉄板：キャッシュとCDN
「世界中のユーザー」「画像配信」「静的コンテンツ」「レイテンシを下げたい」
この要件が見えたら、CloudFront がかなり強いです。
- S3 + CloudFront：静的配信の定番
- ALB/EC2 + CloudFront：動的もキャッシュ可能
DBやAPIが遅いなら**ElastiCache（Redis/Memcached）**が候補。
「読み取りが多い」「同じデータを何度も参照」などがサインです。
データベース選定：RDS/Aurora/DynamoDBを“要件”で切る
SAA-C03のDB選定は、Well-Architectedの観点だとこう整理できます。
- RDS：一般的なリレーショナル。既存SQL、整合性、トランザクション重視
- Aurora：RDS互換で高性能・高可用を強く求める（クラウド最適化）
- DynamoDB：サーバレスでスケール、低運用、キー・バリュー/ドキュメント、超高スループット
問題文サイン例
- “ミリ秒レイテンシでスケール/運用負荷を最小化” → DynamoDB
- “互換SQL + 高可用/高性能” → Aurora
- “既存のRDB、一般要件” → RDS
まとめ
- 高可用＝マルチAZ（SPOF排除）
- DR＝RTO/RPO/コストでバランス
- 非同期＝SQS/SNS/EventBridgeを役割で
- 低レイテンシ＝CloudFront/ElastiCache
- DB選定＝要件のサインを拾う
最後は、試験で差がつく「コスト最適化」と、Udemyでの学習導線です。
コスト最適化＋Udemyおすすめ
SAA-C03は「安い構成を作る試験」ではありません。ですが、選択肢の中で**“要件を満たしつつ最もコスト効率が良い”**ものを選ぶ問題は非常に多いです。特に、過剰設計を選ばせて落とす“コスト罠”が定番です。
ストレージの鉄板：S3のクラス＋ライフサイクル
「長期保管」「アクセス頻度が下がる」「コスト削減」
この要件が見えたら、S3ライフサイクルで階層化が最有力です。
- 直近はStandard
- しばらくしたらIA
- 長期はGlacier系
さらに「誤削除に備えたい」→ バージョニングがセットで出がちです。
“コスト最小”だけに引っ張られて、いきなり全部Glacierにするような選択肢は要件を満たせず不正解になりやすいです。
コンピュートの鉄板：需要が一定ならSavings Plans、変動が大きいならサーバレス/スポット
- 一定稼働が多い：Savings Plans（またはRI）
- バッチ/中断OK：Spot
- アクセスが読めない、アイドルが無駄：Lambda/Fargateなどマネージド寄り
誤答の典型
- “常に最大台数でEC2を立てる”
- “高性能インスタンスで解決（過剰）”
- “マルチリージョン常時稼働”をコスト要件が弱いのに選んでしまう
データ転送と配信：CloudFrontはパフォーマンスだけでなくコストにも効く
CloudFrontはレイテンシ改善の印象が強いですが、オリジンへのアクセス削減にも効きます。
「静的コンテンツが多い」「アクセスが集中」なら、結果的にバックエンド負荷が減り、コスト最適化にもつながります。
SAA-C03の“コスト罠”回避チェックリスト
問題を解く前に、次を自問すると外しにくいです。
- その要件は「マルチリージョン必須」と本当に書いてある？
- “最小運用”が主目的なのに、自前運用（EC2管理）を選んでいない？
- “コスト最小”が主目的なのに、常時稼働・高額サービスを選んでいない？
- “可用性”と“バックアップ”を混同していない？（別物）
Udemyでのおすすめ学習法
SAA-C03は「理解→演習→復習」のループが命です。Udemyはこのループを最短で回せる教材が揃っています。特におすすめは次の組み合わせです。
まずは“全体像がつながる”講座
- Well-Architectedの5本柱を軸に、VPC/セキュリティ/可用性/ストレージ/DBを一気に整理できる講座
- ゴール：サービス暗記ではなく「要件→型→サービス」の思考回路を作る
次に“模試”で弱点を炙り出す
- 模試は、解説が丁寧で「なぜ他が違うか」まで書かれているものが強い
- ゴール：選択肢を“柱の観点”で切れるようにする
最後に“ハンズオン”で定着
- VPC、IAM、S3、CloudFront、RDS/Aurora、DynamoDB、SQS/SNS/EventBridgeあたりは、触ると一気に記憶が固定されます
- ゴール：用語が「体験」と結びつき、問題文のイメージが湧く
まとめ
SAA-C03は、サービスを覚える試験ではなく「要件から正しい設計判断をする試験」です。その判断基準として最も強力なのが、AWS Well-Architected Frameworkの5本柱です。本記事では、5本柱をそのまま覚えるのではなく、試験頻出の“設計パターン（型）”に変換して解ける形に整理しました。
具体的には、運用優秀性はCloudWatch/CloudTrail/Configによる可観測性と自動化、セキュリティは最小権限（ロール）・監査・KMS暗号化・VPC Endpointによる閉域化が定番です。信頼性はマルチAZを基本にRTO/RPOでDRを判断し、パフォーマンス効率は非同期化（SQS/SNS/EventBridge）やキャッシュ（CloudFront/ElastiCache）でスケールと低レイテンシを実現します。コスト最適化はS3ライフサイクル、Savings Plans/Spot、サーバレス活用で“過剰設計の罠”を避けるのがポイントです。
この「柱→型→サービス」の翻訳機を身につけると、問題文のヒントが見えるようになり、迷いが減って正答率が安定します。学習はUdemyの**講座（全体理解）＋模試（弱点抽出）＋ハンズオン（定着）**のセットが最短ルートです。次の模試からは、ぜひ問題文を5本柱に翻訳し、設計パターンへ落とし込む流れで解いてみてください。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
