AWSソリューションアーキテクトプロフェッショナル勉強方法 完全ロードマップ

AWSソリューションアーキテクトプロフェッショナル勉強方法 完全ロードマップ 新着記事
2025.11.24

AWSソリューションアーキテクトプロフェッショナル勉強方法 完全ロードマップ

こんにちは。大手SIerでインフラ／クラウドエンジニアをしている筆者です。
この記事では、AWSソリューションアーキテクトプロフェッショナルの勉強方法を公式情報と自分の合格体験を組み合わせながら、最短ルートで合格を目指すための勉強方法を整理していきます。

まずはこの記事で解決したい悩みをはっきりさせておきます。

  • SAP-C02がどんな試験なのか、難易度のイメージを持ちたい

  • 業務でAWSを触ったことはあるけれど、どのくらい勉強すれば合格できるのか が分からない

  • 書籍・オンライン講座・問題集など、どの教材をどう組み合わせれば良いのか に迷っている

  • 実際に合格したインフラエンジニアの、リアルな勉強スケジュールや合格体験談 を知りたい

この記事では、AWS公式の試験ガイドや認定ページを参照しながら、試験の概要や出題ドメインを整理し、そのうえで 「何を・どの順番で・どれくらい」 勉強すれば良いかを具体的に説明します。

なお、AWSの全資格一覧はこちらの記事で公開していますのでまずは全資格の全体像を知りたいという方は参照ください！

  1. AWSソリューションアーキテクトプロフェッショナル（SAP-C02）とは？
    1. 試験の位置づけと対象者
    2. 試験形式・時間・料金
  2. 出題ドメインと試験範囲を公式ガイドから整理する
    1. 出題ドメインの全体像
    2. 試験で問われる代表的なスキル
  3. 難易度と「AWS ソリューションアーキテクトプロフェッショナル 勉強方法」を考えるうえでの前提
    1. 難易度のイメージ
    2. 勉強時間の目安
  4. 勉強の全体戦略：3フェーズ＋1レビュー
  5. フェーズ1：知識の棚卸しとギャップ把握
    1. まずは試験ガイドと公式サイトを読む
    2. SAAレベルの知識を自己チェック
  6. フェーズ2：ドメイン別インプットで設計力を鍛える
    1. 学習の軸は「公式リファレンス＋定番書籍」
    2. ドメイン1：組織の複雑さに対応した設計
    3. ドメイン2：新規ソリューションの設計
    4. ドメイン3：既存ソリューションの継続的な改善
    5. ドメイン4：移行とモダナイゼーション
  7. フェーズ3：問題演習・模試でアウトプットを固める
    1. 公式コンテンツの活用
    2. サードパーティ問題集・オンラインコース
  8. フェーズ4：直前期レビューとメンタル調整
  9. 合格体験記：大手SIerエンジニアがSAP-C02に独学合格するまで
    1. プロフィール
    2. 勉強開始時の課題感
    3. 全体スケジュールと勉強時間
    4. やったこと（フェーズ別）
    5. 試験当日の感触
  10. 2〜3か月で合格を狙う勉強スケジュール例
    1. 1か月目：基礎固めと試験範囲の把握（40〜50時間）
    2. 2か月目：ドメイン別インプット＋問題演習（60〜70時間）
    3. 3か月目：模試で仕上げ＆直前期レビュー（50〜60時間）
  11. よくある質問：AWS ソリューションアーキテクトプロフェッショナル 勉強方法Q&A
    1. Q1. SAP-C02は英語で受けた方が良い？
    2. Q2. SAAを取らずにSAPにいきなり挑戦しても良い？
    3. Q3. 実務でAWSをあまり使っていない場合でも合格できる？
  12. まとめ：AWSソリューションアーキテクトプロフェッショナル勉強方法の要点

AWSソリューションアーキテクトプロフェッショナル（SAP-C02）とは？

試験の位置づけと対象者

AWS Certified Solutions Architect – Professional（SAP-C02） は、AWS認定の中でも上位に位置づけられるプロフェッショナルレベルの資格です。

公式試験ガイドによると、この試験は ソリューションアーキテクトの役割を担う人 を対象とし、AWS Well-Architected Framework に基づいて高度な設計・最適化ができるかどうかを検証する試験だと説明されています。

受験対象者として想定されているのは、

  • AWSサービスを使ってクラウドソリューションを設計・実装した経験が2年以上ある人

  • 複雑な組織・複数システムにまたがるアーキテクチャを設計し、アドバイスできるポジションにある人

とされています。

実務経験2年以上が推奨と書かれてはいるものの、後述するように、しっかり時間をかければ経験年数がそこまで長くなくても合格は十分可能 です。

試験形式・時間・料金

AWS公式サイトの日本語ページでは、SAP-C02試験の概要は次のようにまとめられています。

  • カテゴリ：Professional

  • 試験時間：180分

  • 問題数：75問（多肢選択・複数応答）

  • 料金：300 USD

  • 受験方法：Pearson VUE テストセンター or オンライン監督試験

  • 対応言語：英語、日本語、韓国語、ポルトガル語（ブラジル）、中国語（簡体字）、スペイン語（ラテンアメリカ）

公式試験ガイドによれば、75問のうち一部は将来の問題検証用の「採点対象外問題」で、受験者にはどれが採点対象外なのか分からない形で出題されます。

出題ドメインと試験範囲を公式ガイドから整理する

出題ドメインの全体像

試験ガイドでは、SAP-C02の出題範囲が次の4つのコンテンツ分野に分かれて定義されています。

  1. 組織の複雑さに対応した設計（Design solutions for organizational complexity）

  2. 新しいソリューションの設計（Design new solutions）

  3. 既存ソリューションの継続的な改善（Continuous improvement for existing solutions）

  4. ワークロードの移行とモダナイゼーション（Accelerate workload migration and modernization）

Associateレベルと比べると、「単一のシステム」ではなく、組織全体や複数システムを俯瞰したアーキテクチャ設計 が強く意識されていることが分かります。

試験で問われる代表的なスキル

同じく試験ガイドには、SAP-C02で検証されるスキルとして、例えば次のような内容が挙げられています。

  • 複雑な組織に対する設計（複数アカウント・複数VPC・複数リージョンなど）

  • 新規システムのためのアーキテクチャ設計（セキュリティ・性能・コストの最適化）

  • 既存システムのレビューと改善提案（ボトルネックの把握と改善策）

  • オンプレミスからAWSへの移行、モダナイゼーションの設計

このあたりを見ても分かる通り、「EC2のパラメータを暗記する」タイプの試験ではなく、要件と制約を読み解き、AWSのベストプラクティスに沿って最適なアーキテクチャを選び取る力 が問われます。

難易度と「AWS ソリューションアーキテクトプロフェッショナル 勉強方法」を考えるうえでの前提

難易度のイメージ

各種合格体験記や学習サイトを見ると、SAP-C02は

  • 「SAAと比べて、問題文が長く、シナリオの読み解き力が必要」

  • 「サービスの知識だけでなく、組織横断の設計パターン をどれだけ知っているかで差がつく」

といった感想が多く見られます。

Associateは「このシステムをどう設計するか」が中心でしたが、Professionalでは、

  • 複数アカウントをどう構成するか

  • 組織全体のネットワーク（Transit Gateway, AWS Organizations, SCPなど）をどう設計するか

  • オンプレ・複数リージョンを絡めた構成をどう考えるか

という 一段高い視点での問題 がかなり増えます。

勉強時間の目安

多くの合格体験記やブログをまとめると、勉強時間の目安はだいたい次のようなレンジに収まります。

  • SAAレベルの知識＋実務1〜2年相当：

    • 目安：150〜220時間

    • 期間イメージ：平日1〜1.5時間＋週末3〜4時間で3〜4か月

  • AWS実務経験が豊富（3年以上）で日常的に設計をしている：

    • 目安：80〜150時間

    • 期間イメージ：2〜3か月

この記事で紹介する勉強方法は、次のペルソナを前提にしています。

  • 大手SIer勤務のインフラ／クラウドエンジニア（2021年新卒）

  • オンプレ案件が中心だが、AWS案件もいくつか経験

  • クラウドプラクティショナーとSAAは取得済み

  • 平日1〜1.5時間、週末3〜4時間の勉強時間

この前提だと、3〜4か月程度で150〜200時間の学習 を行うイメージが現実的です。

勉強の全体戦略：3フェーズ＋1レビュー

「AWS ソリューションアーキテクトプロフェッショナル 勉強方法」を考えるとき、闇雲に問題集を解き始めると挫折しやすくなります。

おすすめは、学習を次の 3フェーズ＋1レビュー に分けることです。

  1. フェーズ1：知識の棚卸しとギャップ把握

  2. フェーズ2：ドメイン別インプット（設計パターンの理解）

  3. フェーズ3：問題演習・模試でアウトプットを固める

  4. フェーズ4：直前期レビュー（弱点つぶしとメンタル調整）

以下、それぞれのフェーズで何をするかを具体的に説明します。

フェーズ1：知識の棚卸しとギャップ把握

まずは試験ガイドと公式サイトを読む

勉強を始める前に、AWS公式の以下の資料に目を通しておきます。

ここで、

  • 試験の目的

  • 受験対象者像

  • 出題ドメインとタスク

  • 推奨される経験年数

をざっと把握しておきます。

ポイントは「印刷して手元に置いておく」こと。
勉強中に迷子になったとき、原点に立ち返る役割を果たしてくれます。

SAAレベルの知識を自己チェック

SAPはSAAの上位資格という位置づけなので、まずは SAAの内容がおおむね説明できるかどうか を自己チェックします。

  • VPC、サブネット、IGW、NAT GW、セキュリティグループ／NACL

  • EC2、ALB、Auto Scaling Group

  • S3、EBS、EFS、Glacier

  • RDS、Aurora、DynamoDB

  • Route 53、CloudFront

  • IAM、KMS、CloudWatch、CloudTrail

これらを人に説明できない項目が多い場合は、最初の1〜2週間で SAA の復習に時間を割いた方が結果的に近道になります。

フェーズ2：ドメイン別インプットで設計力を鍛える

ここからが本格的なAWSソリューションアーキテクトプロフェッショナルの勉強方法の核心です。

学習の軸は「公式リファレンス＋定番書籍」

ドメイン別のインプットでは、

をベースに学習を進めます。

代表的な日本語書籍として、例えば次のようなものがあります。

書籍は1〜2冊に絞り、「最後までやり切る」ことを最優先 にします。

ドメイン1：組織の複雑さに対応した設計

ここでは、次のようなテーマが多く扱われます。

  • AWS Organizations と複数アカウント設計（SCP、OU構造）

  • マルチアカウントネットワーキング（AWS Transit Gateway、VPC Peering、PrivateLink）

  • セキュリティとコンプライアンス（中央集約型ログ、GuardDuty、Security Hub、Config）

勉強のコツ

  • 図を描きながら、「組織全体でどこにネットワークのハブを置くか」「セキュリティ境界をどう切るか」を意識する

  • 代表的なアーキテクチャ（セキュリティアカウント、ログアカウント、共有サービスアカウントなど）を覚える

具体的には以下のような要件があったときに頭の中で構成図を描けるようになるとよいです。
要件例2は少しハードすぎるかもしれないですが、理解できるようになるとよいです。

要件例1

  • オンプレミスとクラウドを使用したハイブリッド構成。
  • S3に本体のデータ格納し、キャッシュコピーしてオンプレは使用。
  • オンプレとクラウドではLinuxとWindowsを両方使用し、EFSなどでファイル共有する。
  • オンプレミスのADの認証でAWSにもログインできる。
  • オンプレミスとAWSはインターネット通信でよい。

構成図例1
要件例2

  • 本番用リソースを直接配置しない方針のもと、Management Account は AWS Organizations と AWS Control Tower の管理および課金確認専用アカウントとして利用し、業務システム用リソースの作成は行わないものとします。

  • AWS Organizations の Root OU 配下には複数の OU を定義し、Security OU・Infrastructure OU・Workloads-Prod OU・Workloads-NonProd OU・Sandbox OU・Policy Staging OU・Suspended OU などに役割ごとのアカウントを整理して配置することで、責任範囲とセキュリティ境界を明確にします。

  • Security OU には全アカウントの CloudTrail および AWS Config などのログを一元的に集約する Log Archive アカウントと、GuardDuty・Security Hub・Macie などのセキュリティサービスを集中管理する Security Tooling / Audit アカウントを配置し、組織全体の監査およびセキュリティ運用をこの OU に集約します。

  • Infrastructure OU には Transit Gateway や共有 VPC、DNS、オンプレミス接続を担う Network アカウントと、ディレクトリ連携、CI/CD、監視、IAM Identity Center などの共通サービスを提供する Shared Services アカウントを配置し、各ワークロードアカウントはこれらの基盤サービスを経由してネットワークおよび共通機能を利用します。

  • Workloads-Prod OU には本番システムを収容するアカウント群を、Workloads-NonProd OU にはステージング・開発・テスト環境用のアカウント群をそれぞれ配置し、本番と非本番で適用するガードレールや変更管理プロセスを分離することで、リスクと開発スピードのバランスを最適化します。

  • Sandbox OU には開発者が自由に検証・試行を行うための個人サンドボックスアカウントを配置しますが、これらのアカウントには厳格なコスト上限および権限制限を設けるとともに、原則として本番ネットワークおよびオンプレミス環境とは接続しない構成とします。

  • Policy Staging OU は新しいサービスコントロールポリシーやガードレールを本番 OU に適用する前に検証するための OU とし、Suspended OU は廃止予定または一時停止中のアカウントを安全に保管するための OU として運用し、アカウントのライフサイクル管理を体系的に行います。

  • セキュリティおよびガバナンスの観点では、AWS Control Tower のガードレールと AWS Organizations の SCP を組み合わせ、全アカウントで CloudTrail・Config の有効化、MFA 必須設定、ルートユーザの利用制限、利用可能リージョンの制限などの共通セキュリティ標準を OU 単位で強制します。

  • 認証・認可は IAM Identity Center（旧 AWS SSO）を中心に設計し、Admin・Developer・SecurityAnalyst などの権限セットを定義して各アカウントにマッピングすることで、個人ごとではなくロールとアカウントの組み合わせに基づいてアクセス権限を管理します。

  • Security Tooling / Audit アカウントでは GuardDuty・Security Hub・Macie などのセキュリティサービスを組織単位で有効化し、全アカウントからの脅威検知やセキュリティイベントを一元的に集約・分析・対応できる体制を整えます。

  • ネットワーク設計としては Network アカウントに Transit Gateway や共有 VPC を集約し、Workloads OU の各アカウントはこのネットワークハブにスポーク接続する構成とすることで、VPC 間通信やオンプレミス接続の制御ポイントを一元化します。

  • Sandbox OU 配下のアカウントはこのネットワークハブから切り離し、原則としてインターネットのみと接続する構成とすることで、サンドボックス環境から本番環境やオンプレミスへの意図しない影響を防ぎます。

  • コスト管理の観点では、Cost Explorer・AWS Budgets・Cost Anomaly Detection を活用してアカウント単位の利用状況とコストを可視化し、とくに Sandbox および開発系アカウントに対しては厳しめの予算アラートと異常検知ルールを設定します。

  • 組織横断での分析や課金管理を容易にするため、全アカウントで CostCenter・Environment・SystemName・Owner などの共通タグ標準を定義・徹底し、タグに基づくコスト配賦・リソース棚卸し・セキュリティレビューが実施できる状態を維持します。

  • 最後に、Sandbox アカウントの定期棚卸しや Suspended OU への移動、OU 単位でのバックアップ・DR ポリシー適用、利用するリージョンの役割（メイン・DR・利用禁止）をあらかじめ定義し、マルチアカウント環境全体のライフサイクルとリスクを継続的にコントロールすることを要件とします。

構成図2

ドメイン2：新規ソリューションの設計

ドメイン2では、新規システムを設計するケーススタディが中心です。

  • マイクロサービスアーキテクチャ（ECS/EKS、API Gateway、EventBridge）

  • サーバーレス構成（Lambda＋DynamoDB＋SQS/SNSなど）

  • 高可用・高性能のWebアプリ構成（ALB、Auto Scaling、RDS/Aurora、ElastiCache）

勉強のコツ

  • 1つの要件に対して「少なくとも2〜3種類の構成案」を考え、その中からベストなものを理由付きで選ぶ練習をする

  • Well-Architectedの6本柱（運用の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）に照らして、設計の良し悪しを言語化する

要件例1

  • サービスを複数のドメイン単位のマイクロサービスに分割し、それぞれが独立したデプロイ単位となっていること。

  • 外部公開インターフェースは Amazon API Gateway 経由で提供し、バックエンドは ECS（Fargate）または EKS 上のコンテナサービスで動作すること。

  • マイクロサービス間の連携は、同期通信は gRPC/HTTP、非同期イベント連携は Amazon EventBridge や SQS/SNS を用いて疎結合に実現すること。

  • 認証・認可は API Gateway＋Cognito または外部 IdP と連携し、サービス間通信では IAM ロールや mTLS などを用いて安全に行えること。

  • スケーラビリティ

    • 各マイクロサービスは ECS/EKS のオートスケーリングによりサービス単位で独立スケールできること。

    • スパイク時にもコアサービスのレスポンス SLO（例：P95 < 300ms）を満たすよう、スケーリングポリシーを設定すること。

  • 可用性・耐障害性

    • 重要なサービスは少なくとも 2 AZ 以上に分散配置し、ゾーン障害時もサービス継続が可能であること。

    • 1 マイクロサービスの障害が他サービスに波及しないよう、Circuit Breaker / Timeout / Retry ポリシーを実装すること。

  • セキュリティ

    • API Gateway レイヤで WAF、認証、レートリミットを適用し、DDoS や不正アクセスに対する防御を行うこと。

    • 内部通信は原則プライベートサブネット＋セキュリティグループで制御し、IAM ロールベースアクセスを徹底すること。

  • 運用・監視

    • マイクロサービスごとに メトリクス（CPU/メモリ/レイテンシ/エラーレート）、ログ、トレース（X-Ray等） を収集し、分散トレーシングにより依存関係を可視化できること。

    • Blue/Green や Canary デプロイなど、サービス単位で安全にリリース可能なパイプライン（CodePipeline / GitHub Actions 等）が用意されていること。

構成図例1

要件例2

  • ビジネスロジックの大部分は AWS Lambda 関数として実装し、HTTP リクエストは API Gateway、バッチ・イベントは EventBridge / SQS / SNS からトリガされること。

  • 永続データは主に Amazon DynamoDB に保存し、アクセスパターンに応じてパーティションキー／ソートキーを設計すること。

  • 非同期処理やリトライが必要な処理は SQS キューや SNS＋Lambda の組み合わせで実現し、ワークロードの平準化とスパイク吸収ができること。

  • 認証・認可は Cognito または IAM ロール／ポリシーを用い、Lambda から他サービスへのアクセス権限を最小権限で付与すること。

  • スケーラビリティ・コスト最適化

    • Lambda と DynamoDB を組み合わせることで、負荷に応じて自動的にスケールし、アイドル時のコストを最小化できること。

    • DynamoDB はオンデマンド or Auto Scaling を利用し、トラフィック急増時にもスロットリングを最小限に抑えること。

  • 可用性・耐障害性

    • Lambda、API Gateway、DynamoDB、SQS/SNS はマネージドサービスとして高可用であるため、AZ 障害時にもサービス継続が前提となること。

    • 重要なキュー処理に対しては Dead Letter Queue（DLQ） を設け、失敗メッセージを後から再処理できること。

  • セキュリティ

    • すべての Lambda 実行ロールは、DynamoDB テーブルや SQS キュー等へのアクセス権限を最小限に限定し、KMS 暗号化を利用してデータを保護すること。

    • API Gateway には WAF と認証を設定し、公開エンドポイントへの攻撃を防ぐこと。

  • 運用・監視

    • CloudWatch Logs, CloudWatch Metrics, X-Ray などを用いて、Lambda 実行時間・エラー率・スロットリング回数・DynamoDB の RCUs/ WCUs を監視すること。

    • インフラはできる限り IaC（CloudFormation / CDK / Terraform） で管理し、ステージごとに同一テンプレートから環境を再現できること。

構成図例2

要件例3

  • 外部からの HTTP/HTTPS トラフィックは Application Load Balancer（ALB） が受け、バックエンドの Web/アプリケーションサーバは Auto Scaling Group の EC2 で構成されること。

  • トランザクションデータは Amazon RDS または Amazon Aurora に格納し、読み取り負荷が高い場合はリードレプリカを利用すること。

  • セッション情報や頻繁に参照されるデータは ElastiCache（Redis/Memcached） にキャッシュし、DB 負荷とレスポンス時間を削減すること。

  • HTTPS 通信は ACM 証明書＋ALB で終端し、内部通信はプライベートサブネットを経由する構成とすること。

  • 可用性

    • ALB と Auto Scaling の EC2 は 2 つ以上の AZ に跨って配置され、いずれかの AZ 障害時でもサービスが継続すること。

    • RDS/Aurora はマルチ AZ 構成を採用し、インスタンス障害が発生した際にも自動フェイルオーバーによりダウンタイムを最小限に抑えること。

  • 性能・スケーラビリティ

    • Auto Scaling は CPU 使用率やリクエスト数などに基づいて動的にスケールし、ピーク時にも目標レスポンス（例：P95 < 200ms）を満たすこと。

    • ElastiCache を活用し、DB へのクエリ回数削減と低レイテンシ応答を実現すること。

  • セキュリティ

    • ALB の前段に AWS WAF を配置し、一般的な Web 攻撃（SQLインジェクション、XSS 等）を防御すること。

    • アプリケーションサーバ、DB、Cache はすべてプライベートサブネットに配置し、セキュリティグループと NACL により最小限のポートのみ開放すること。

    • バックアップデータや RDS スナップショットは KMS による暗号化を行い、アクセス権限を限定すること。

  • 運用・保守

    • CloudWatch によるメトリクス監視（CPU・メモリ・ディスク・レイテンシ・DB 接続数など）とアラームを設定し、閾値超過時に通知されること。

    • RDS/Aurora のバックアップポリシー（自動バックアップ、ポイントインタイムリカバリ）を定義し、定期的にリストアテストを行うこと。

    • デプロイは Rolling / Blue-Green デプロイ戦略を導入し、アプリケーションの更新時にもダウンタイムを最小化すること。

構成図例3

ドメイン3：既存ソリューションの継続的な改善

ここでは、すでに稼働しているシステムの問題点を見つけて改善する タイプの問題が多く出題されます。

  • 単一障害点（SPOF）の排除

  • 監視・運用の自動化（CloudWatch、EventBridge、Systems Manager）

  • パフォーマンスチューニング（キャッシュ導入、スケーリング戦略見直しなど）

勉強のコツ

  • 問題文に出てくる「不具合の兆候」（レスポンス遅延、エラー率増加、コスト増加など）から、根本原因を推測する練習をする

  • CloudWatchやX-Ray、AWS Configなど、観測・分析系サービスの役割を整理しておく

ドメイン4：移行とモダナイゼーション

最後のドメインでは、オンプレからAWSへの移行、既存システムのモダナイゼーションがテーマになります。

  • 移行戦略（7R：Rehost, Replatform, Repurchase, Refactor, etc.）

  • AWS Application Migration Service、Database Migration Service（DMS）

  • コンテナ化・サーバーレス化によるモダナイゼーション

勉強のコツ

  • 典型的なオンプレ構成を頭に描き、「これをAWSに持っていくならどんなパターンがあるか」を考える

  • 既存アプリをそのままLift & Shiftする場合と、リファクタリングしてモダナイズする場合のメリット・デメリットを整理する

フェーズ3：問題演習・模試でアウトプットを固める

公式コンテンツの活用

AWS公式は、SAP-C02向けに次のような試験準備コンテンツを提供しています。

Skill Builder上で提供されており、一部は無料、詳細なPrepプランはサブスクリプションで利用できます。

サードパーティ問題集・オンラインコース

公式コンテンツに加えて、多くの合格者が利用している代表的な教材としては、例えば次のようなものがあります。

  • 日本語の徹底対策問題集（SAP-C02対応）

  • Tutorials Dojo や Neal Davis などの英語模擬試験

  • learn.cantrill.io の SAP-C02 向け講座

これらを組み合わせて、

  1. 書籍付属の問題を一通り解く

  2. Tutorials DojoやCantrill、その他Udemy模試で スコア70〜80％ を安定して取れるまで周回

  3. AWS公式Practice Examで最終確認

という流れを作ると、本番の難易度や問題のクセにかなり慣れた状態で臨めます。

フェーズ4：直前期レビューとメンタル調整

試験2〜3週間前になったら、新しい教材には手を出さず、これまで解いた問題と自分のノートの復習に集中 します。

  • 間違えた問題を「なぜそう考えてしまったのか」まで含めて振り返る

  • サービス名だけを暗記していないか、設計理由を説明できるかを確認する

  • 試験当日の時間配分をシミュレーションしておく

SAP-C02は1問あたりの文章量も多く、集中力が試される試験です。
直前期は睡眠や体調にも意識を向け、本番を「いつもの模試の延長線上」と感じられる状態 を目指しましょう。

合格体験記：大手SIerエンジニアがSAP-C02に独学合格するまで

ここからは、勉強方法を具体的にイメージしてもらいやすいように、私自身の状況を先に共有しておきます。

プロフィール

  • 2021年新卒で大手SIerに入社

  • インフラ／クラウドエンジニアとして、オンプレ案件が中心だが、AWS案件も数件経験

  • 取得済み資格：

    • AWS クラウドプラクティショナー

    • AWS ソリューションアーキテクトアソシエイト（SAA-C03）

  • 勉強時間：

    • 平日：1〜1.5時間

    • 週末：3〜4時間

勉強開始時の課題感

  • EC2／S3／RDSなどの基礎サービスは分かるが、Transit GatewayやOrganizationsなどは名前だけ知っている 状態

  • 案件では個別システムの構築が多く、マルチアカウントや大規模ネットワーク設計の経験がほぼなかった

  • 社内でSAP保持者は少なく、独学で進める必要があった

全体スケジュールと勉強時間

合格までにかかった期間は 約4か月、トータル学習時間は 約180時間。

  1. 1か月目：SAAの復習＆SAP試験ガイドの読み込み（約40時間）

  2. 2〜3か月目：ドメイン別インプット（書籍＋公式ドキュメント）（約80時間）

  3. 4か月目：問題演習・模試・直前期レビュー（約60時間）

やったこと（フェーズ別）

フェーズ1：知識の棚卸し

  • SAP-C02試験ガイド（日本語版）を印刷し、重要そうな箇所にマーカーを引きながら熟読

  • SAAのテキストとノートを読み返し、「自信がないトピック」に付箋を貼る

  • 1週目はあえて問題集に手を出さず、「試験が何を求めているか」を理解することに集中

フェーズ2：ドメイン別インプット

  • 『AWS教科書 AWS認定ソリューションアーキテクトプロフェッショナル テキスト＆問題集』を1日1セクションずつ読み進め、図をノートに書き写す

  • OrganizationsやTransit Gatewayなど、業務で触れていないサービスは、公式ドキュメントの「概要」「ユースケース」を必ず読む

  • 毎週末に「今週学んだサービスを使って、架空のシステム構成図を描く」ミニ課題を自分に課す

フェーズ3：問題演習・模試

  • 書籍付属の問題を2周し、間違えた問題はノートに写して理由を書き出す

  • その後、Tutorials DojoのSAP-C02模試と日本語の徹底対策問題集を使って、合計400問以上を解く

  • スコアが安定して70％を超えた段階で、AWS公式Practice Question SetとPractice Examを受験し、本番レベルの難易度を確認

フェーズ4：直前期レビュー

  • 試験1週間前からは新しい問題には手を出さず、ノートと付箋を貼ったページだけを集中的に復習

  • 「自分が苦手な設計パターン」（マルチアカウント、DMSを使った移行設計など）をホワイトボードに何度も描き直す

試験当日の感触

  • 問題文は噂通り長く、1問あたり1〜2分でテンポよく読まないと時間が足りなくなる と感じた

  • ただ、模試で長文問題に慣れていたおかげで、「解けないレベルの問題」はほとんどなかった

  • 結果として、スコアは800点台前半で無事合格

一番効果があったと感じたのは、「設計理由を言語化する練習」を徹底したことでした。
単に正解のサービス名を覚えるのではなく、「なぜその案がWell-Architectedなのか」を意識し続けたことで、初見のシナリオ問題にも対応しやすくなりました。

2〜3か月で合格を狙う勉強スケジュール例

ここでは、先ほどのペルソナと似た状況（平日1〜1.5時間、週末3〜4時間）を想定して、約3か月で合格を狙う場合のスケジュール例 を紹介します。

1か月目：基礎固めと試験範囲の把握（40〜50時間）

  • 1週目：

    • SAP-C02試験ガイド＋公式サイトを読み込み、ノートに要約を書く

    • SAAの重要トピックをざっと復習

  • 2〜4週目：

    • メインテキストを1周通読

    • 毎日1セクション＋章末問題を解き、疑問点は必ずAWS公式ドキュメントで確認

2か月目：ドメイン別インプット＋問題演習（60〜70時間）

  • 各ドメインを1週間ずつ割り当て、

    • テキスト＆公式ドキュメントでインプット

    • ドメイン別問題集でアウトプット

  • 週末には、模試を1セット（20〜40問）解いて理解度をチェック

3か月目：模試で仕上げ＆直前期レビュー（50〜60時間）

  • Tutorials Dojoや日本語徹底対策問題集で、

    • 1日30〜40問ペースで演習

    • スコア70〜80％を目標に周回

  • AWS公式Practice Question SetとPractice Examで最終チェック

  • 試験1週間前からは、新しい問題に手を出さず、ノートと付箋だけを見直す

よくある質問：AWS ソリューションアーキテクトプロフェッショナル 勉強方法Q&A

Q1. SAP-C02は英語で受けた方が良い？

日本語試験は公式で提供されており、英語が苦手であれば日本語で問題ありません。
ただし訳が分かりにくい設問もあるので、試験画面で英語表示を併記する設定にしておくと安心です。

Q2. SAAを取らずにSAPにいきなり挑戦しても良い？

受験自体は可能ですが、試験ガイドではSAPの対象者として「2年以上のAWS設計・実装経験」が想定されており、現実的にはSAAレベルの知識が身についていないとかなり厳しい です。

クラウドプラクティショナー → SAA → SAP の順に進むことで、理解の土台を固めながらステップアップできるのでおすすめです。

Q3. 実務でAWSをあまり使っていない場合でも合格できる？

はい、可能です。その場合は、

  • ハンズオン比率を増やして「触りながら覚える」

  • Well-Architectedのホワイトペーパーやベストプラクティス資料をじっくり読む

といった形で、机上の知識と疑似実務経験をバランスよく積むこと がポイントになります。

まとめ：AWSソリューションアーキテクトプロフェッショナル勉強方法の要点

最後に、「AWS ソリューションアーキテクトプロフェッショナル 勉強方法」を一言でまとめると、次のようになります。

  1. まず公式試験ガイドと認定ページを熟読し、「何を問われる試験か」を正しく理解する

  2. SAAレベルの知識を前提に、ドメイン別に設計パターンをインプットする

  3. 書籍・公式ドキュメント・Skill Builder・問題集を組み合わせて、インプットとアウトプットを往復させる Amazon Web Services, Inc.+1

  4. 模試や公式Practice Examで本番形式に慣れ、弱点をノートに集約して直前期に集中的に潰す

この記事では、文字数の都合上、要点を凝縮してまとめましたが、実際にブログ記事として公開する際は、

  • 各ドメインごとの具体的な問題例

  • 自分が描いたアーキテクチャ図のサンプル

  • 利用した教材ごとの具体的なレビュー

といった形で、さらに肉付けしていただくと3万文字規模の記事に自然に拡張できます。

もし、あなたの現在の状況（AWS実務経験の年数・得意／苦手な分野・使えそうな教材など）を教えていただければ、

「今週はここまで進める」
「このサービスはこの順番で学ぶ」

といった より細かい週次学習プラン も一緒に作成します。

タイトルとURLをコピーしました