AWS Certified Solutions Architect Associate 合格体験記 | 頻出問題 |

AWS認定資格のSolutions Architect Associateの学習方法と合格のためのポイントを詳しく解説

AWS Certified Solutions Architect Associate Badge

SAA-C03試験対応 🎉2025年の最新試験バージョンに対応した学習ガイドと試験対策を提供します。

資格概要

AWS Certified Solutions Architect Associateは、AWSのクラウドアーキテクチャ設計に特化した 認定資格です。高可用性、耐障害性、セキュリティ、コスト最適化など、 クラウドシステムの設計に必要なスキルが評価されます。

資格のメリット

  • クラウドアーキテクチャ設計スキルの証明
  • 高可用性設計の実践力
  • セキュリティ設計能力の証明
  • クラウドアーキテクトとしてのキャリア形成

実際の試験体験から

Solutions Architect Associate試験は、実践的な設計シナリオが中心です。 特に、VPC、EC2、RDS、S3、IAMなど、基本的なサービスの深い理解と、 それらを組み合わせた設計力が問われます。

合格体験:合格ラインの720点に対して、812点で合格。

テストセンターでの受験のコツ

初めての方向け:重要な注意点

  • 到着時間について

    予約時間の30分前でも受験可能な場合があります。早めの到着でも柔軟に対応してくれることが多いので、 時間に余裕を持って行くことをおすすめします。

  • 待ち時間の過ごし方

    公共交通機関の遅延で試験に遅れるのは避けたいところ...。早めにテストセンター付近に到着しておくのがベストですが、 実はテストセンターのロビーではあらゆる勉強が禁止されています。 そのため、周辺のカフェで時間を潰すことをおすすめします。筆者も近くのカフェで最後の見直しをしていました。

  • 持ち物チェック

    重要:有効な身分証明書が2つ必要です!筆者の場合は、マイナンバーカードと運転免許証の組み合わせでOKでした。 この2つの準備を忘れると受験できないので要注意です。

  • 事前準備(トイレ問題)

    受付前にトイレを済ませておきのが鉄則です。実は筆者、コーヒーを飲むと 異常なほどトイレが近くなるタイプなんです(笑)試験前のカフェでは、 緊張もあってついつい飲みすぎてしまい...。幸い受付前に気づきましたが、 試験中のトイレ退室は時間のロスになるので要注意です!

当日の流れ

  1. 受付で身分証明書を提示
  2. 持ち物を専用ロッカーに保管
  3. 試験室のルール説明
  4. 試験開始

💡 補足情報

AWS認定試験は、すべての資格で同じテストセンターのルールが適用されます。 一度受験経験があれば、次回からはスムーズに受験できるはずです。

試験対策のヒント

重要サービスの深い理解

SAA試験では、特に以下のサービスについて深い理解が求められます。 単なる機能の暗記ではなく、実際のビジネスシナリオでの 適切な選択ができるレベルまで理解を深めることが重要です。

コンピューティング & ネットワーク

  • EC2(インスタンスタイプの選択)
  • VPC(サブネット設計、ルーティング)
  • ELB(ALB vs NLB vs CLB)
  • Auto Scaling(スケーリングポリシー)

ストレージ & データベース

  • S3(ストレージクラス、ライフサイクル)
  • RDS(Multi-AZ, Read Replica)
  • DynamoDB(キャパシティユニット)
  • EBS(ボリュームタイプの特徴)

EC2(Elastic Compute Cloud)の重要ポイント

EC2は、AWSの中で最も基本的で重要なサービスです。 「仮想サーバー」と考えると分かりやすいですが、従来のサーバーと違って 数分で立ち上げたり、必要に応じてスペックを変更したりできる柔軟さが特徴です。

インスタンスファミリー主な用途選ぶべき状況
汎用(t3, m5)Webサーバー
開発環境
一般的なワークロードで、特別な要件がない場合
コンピューティング最適化(c5)バッチ処理
ゲームサーバー
CPU性能が重要で、メモリは比較的少なくて良い場合
メモリ最適化(r5)インメモリDB
大規模データ処理
大量のデータをメモリ上で処理する必要がある場合
💡 EC2のコスト最適化戦略

EC2のコストを最適化するには、ワークロードの特性に合わせて適切な購入オプションを 選択することが重要です。以下のシナリオ別の選択ガイドを参考にしてください。

📊 スポットインスタンス(最大90%割引)

未使用のEC2キャパシティを安価で利用できますが、 AWSが必要とする際は中断される可能性があります。

👍 最適なユースケース:

  • • CI/CDパイプラインの実行環境
  • • データ分析やバッチ処理
  • • 開発/テスト環境

⚠️ 避けるべきケース:

データベースや重要なWebサービスなど、 中断が許されないワークロード

🏢 リザーブドインスタンス(最大72%割引)

1年または3年の利用を約束することで、大幅な割引が適用されます。 事前の容量確保も可能です。

👍 最適なユースケース:

  • • 基幹システムの本番環境
  • • 24/7稼働が必要なデータベース
  • • 安定した負荷が見込まれるアプリケーション

⚠️ 避けるべきケース:

短期プロジェクトや、数ヶ月以内に終了/変更が予想される ワークロード

🔄 オンデマンドインスタンス(標準料金)

必要な時に必要なだけ利用でき、事前の約束は不要です。 ただし、割引はありません。

👍 最適なユースケース:

  • • Eコマースサイト(季節変動が大きい)
  • • イベント配信サイト(一時的な高負荷)
  • • 新規サービス(負荷パターンが未知)

例:クリスマスシーズンは通常の3倍のトラフィック、 セール時は5倍の負荷など、予測が難しい変動がある場合

💡 ハイブリッド戦略のすすめ

多くの場合、複数の購入オプションを組み合わせることで 最適なコスト効率を実現できます。

ベストプラクティス例:

  • Webアプリケーションの場合:
    • ベース負荷 → リザーブドインスタンス
    • 変動負荷 → オンデマンドインスタンス
    • 開発環境 → スポットインスタンス
  • データ分析システムの場合:
    • データベース → リザーブドインスタンス
    • 分析処理 → スポットインスタンス
    • 緊急処理 → オンデマンドインスタンス
📝 試験でよく出るシナリオ

シナリオ1:Webアプリケーションのサーバー選択

「トラフィックが日中に集中し、夜間は少ない」 → t3インスタンス + Auto Scalingがベストプラクティス

シナリオ2:バッチ処理サーバーの選択

「毎日深夜に大量データ処理が必要」 → c5インスタンス + スポットインスタンスの組み合わせ

VPC(Virtual Private Cloud)の設計ポイント

VPCは、AWSクラウド内の仮想ネットワークです。 「自分だけのプライベートなデータセンター」をイメージすると分かりやすいでしょう。 セキュリティと可用性を両立させるための重要な基盤となります。

🏗️ 基本的なVPC設計パターン

パブリックサブネット

  • • ALB/NLB配置
  • • Bastionホスト
  • • NAT Gateway

プライベートサブネット

  • • アプリケーションサーバー
  • • データベース
  • • キャッシュ
👍 セキュリティのベストプラクティス
  • • セキュリティグループは最小権限の原則で
  • • NACLでサブネットレベルの制御を追加
  • • フローログで通信を監視
  • • 重要リソースはプライベートサブネットに
⚠️ よくある設計ミス
  • • CIDRレンジが狭すぎる
  • • パブリックIPの過剰な割り当て
  • • セキュリティグループの過度な緩和
  • • 単一AZでの構成
📝 試験でよく出るシナリオ

シナリオ1:複数環境の分離

「開発、ステージング、本番環境を分離したい」 → 環境ごとに別のVPCを作成し、必要に応じてVPC Peeringで接続

シナリオ2:ハイブリッドクラウド

「オンプレミスとAWSを接続したい」 → Direct ConnectまたはVPN接続 + Transit Gateway

ELB(Elastic Load Balancing)の選び方

ELBは、アプリケーションへのトラフィックを複数のターゲットに分散する サービスです。「交通整理係」のようなもので、システムの可用性と スケーラビリティを高めるために重要な役割を果たします。

種類主な特徴ベストな使用シーン
ALB• HTTP/HTTPS対応
• パスベースルーティング
• コンテナ対応
• マイクロサービス
• コンテナベースアプリ
• WebSocket
NLB• TCP/UDP/TLS対応
• 固定IP
• 超低レイテンシー
• TCP/UDPゲーム
• IoTテレメトリ
• 固定IP必須
CLB
(非推奨)
• 基本的な機能のみ
• レガシー互換性
• レガシーEC2-Classic
• 既存システムの維持
📝 実践的な選択のポイント

Webアプリケーションの場合

ほとんどの場合、ALBを選択します。HTTPSの終端、パスベースルーティング、 WebSocketなど、モダンなWebアプリに必要な機能が揃っているためです。

ゲームサーバーの場合

NLBを選択します。TCP/UDPの直接サポート、固定IP、超低レイテンシーが ゲームサーバーには重要な要素となるためです。

Auto Scalingの設定ポイント

スケーリングポリシーの種類

  • • ターゲット追跡:メトリクスの目標値を維持(CPU使用率70%等)
  • • ステップスケーリング:段階的な増減(アラーム閾値に応じて)
  • • シンプルスケーリング:基本的な増減(非推奨)
  • • スケジュールスケーリング:時間帯による増減

設計のベストプラクティス

  • • クールダウン期間の適切な設定
  • • 最小/最大/希望容量の慎重な設定
  • • ヘルスチェックの適切な設定
  • • 複数のメトリクスの組み合わせ

ストレージサービスの選択と設定

S3ストレージクラス

  • • Standard:高頻度アクセス、即時取り出し
  • • Intelligent-Tiering:アクセスパターン不明な場合
  • • Standard-IA:低頻度アクセス、即時取り出し必要
  • • One Zone-IA:低コスト、単一AZ許容
  • • Glacier:長期保管、取り出し時間考慮

EBSボリュームタイプ

  • • gp3:汎用SSD、ほとんどのワークロードに
  • • io2:高IOPS要件のミッションクリティカル
  • • st1:スループット最適化HDD、ログ処理等
  • • sc1:コールドHDD、アクセス頻度の低いデータ

データベースサービスの特徴と選択

RDSの高可用性オプション

  • • Multi-AZ:同期レプリケーション、自動フェイルオーバー
  • • Read Replica:非同期レプリケーション、読み取りスケーリング
  • • Aurora:分散型設計、自動修復機能
  • • バックアップ:自動/手動スナップショット

DynamoDBのキャパシティ設定

  • • プロビジョンド:予測可能なトラフィック
  • • オンデマンド:変動の大きいトラフィック
  • • Auto Scaling:プロビジョンドの自動調整
  • • DAX:インメモリキャッシュ

実践的な学習のコツ:
各サービスについて、以下の観点で整理すると理解が深まります:

  • • ユースケース(どんな時に使うべきか)
  • • 制限事項(何ができないのか)
  • • コスト面での考慮点
  • • 他サービスとの組み合わせパターン

アーキテクチャ設計のベストプラクティス

試験では、単一のサービスだけでなく、複数のサービスを組み合わせた アーキテクチャ設計の知識が問われます。以下のような設計パターンを 押さえておくことが重要です。

Webアプリケーションの構成例

一般的なWebアプリケーションでよく使用される構成例を見てみましょう。 可用性、スケーラビリティ、セキュリティのバランスが重要です。

実装例:
マルチAZ構成のWebアプリケーション

  • • Route 53 → CloudFront → ALB の構成
  • • EC2 Auto Scalingによる可用性確保
  • • RDS Multi-AZによるデータベースの冗長化
  • • S3 + CloudFrontによる静的コンテンツ配信

バックアップと災害対策

データの保護と災害時の復旧は、システム設計の重要な要素です。 コストと復旧時間のバランスを考慮した設計が求められます。

設計例:
コスト効率の良いバックアップ戦略

  • • S3ライフサイクルポリシーによる自動アーカイブ
  • • AWS Backupによる一元管理
  • • スナップショットの定期取得と世代管理
  • • クロスリージョンレプリケーション

試験のコツと注意点

✅ 問題文の読み方

  • キーワードに注目(must, should, etc.)
  • コスト要件を見落とさない
  • 運用面での制約を確認
  • 既存システムとの統合要件

❌ 陥りやすい罠

  • 過剰な設計を選択
  • コストを無視した解答
  • 運用負荷を考慮しない
  • セキュリティ要件の見落とし

重要な判断基準

📌 コストと効果のバランス:必要以上に高価な解決策を避け、要件に見合った選択をする

📌 運用の簡素化:可能な限りマネージドサービスを活用し、運用負荷を軽減

📌 スケーラビリティ:将来の成長を見据えた拡張性のある設計を選択

おちゃめなエンジニア

管理者

Web開発とラーメンを愛するエンジニア。技術の探求と美味しいラーメンを求めて日々奮闘中です。