AWS Certified Solutions Architect Associate 合格体験記 | 頻出問題 |
AWS認定資格のSolutions Architect Associateの学習方法と合格のためのポイントを詳しく解説

SAA-C03試験対応 🎉2025年の最新試験バージョンに対応した学習ガイドと試験対策を提供します。
資格概要
AWS Certified Solutions Architect Associateは、AWSのクラウドアーキテクチャ設計に特化した 認定資格です。高可用性、耐障害性、セキュリティ、コスト最適化など、 クラウドシステムの設計に必要なスキルが評価されます。
資格のメリット
- クラウドアーキテクチャ設計スキルの証明
- 高可用性設計の実践力
- セキュリティ設計能力の証明
- クラウドアーキテクトとしてのキャリア形成
実際の試験体験から
Solutions Architect Associate試験は、実践的な設計シナリオが中心です。 特に、VPC、EC2、RDS、S3、IAMなど、基本的なサービスの深い理解と、 それらを組み合わせた設計力が問われます。
合格体験:合格ラインの720点に対して、812点で合格。
テストセンターでの受験のコツ
初めての方向け:重要な注意点
- ✓到着時間について
予約時間の30分前でも受験可能な場合があります。早めの到着でも柔軟に対応してくれることが多いので、 時間に余裕を持って行くことをおすすめします。
- ✓待ち時間の過ごし方
公共交通機関の遅延で試験に遅れるのは避けたいところ...。早めにテストセンター付近に到着しておくのがベストですが、 実はテストセンターのロビーではあらゆる勉強が禁止されています。 そのため、周辺のカフェで時間を潰すことをおすすめします。筆者も近くのカフェで最後の見直しをしていました。
- ✓持ち物チェック
重要:有効な身分証明書が2つ必要です!筆者の場合は、マイナンバーカードと運転免許証の組み合わせでOKでした。 この2つの準備を忘れると受験できないので要注意です。
- ✓事前準備(トイレ問題)
受付前にトイレを済ませておきのが鉄則です。実は筆者、コーヒーを飲むと 異常なほどトイレが近くなるタイプなんです(笑)試験前のカフェでは、 緊張もあってついつい飲みすぎてしまい...。幸い受付前に気づきましたが、 試験中のトイレ退室は時間のロスになるので要注意です!
当日の流れ
- 受付で身分証明書を提示
- 持ち物を専用ロッカーに保管
- 試験室のルール説明
- 試験開始
💡 補足情報
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開発とラーメンを愛するエンジニア。技術の探求と美味しいラーメンを求めて日々奮闘中です。