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開発とラーメンを愛するエンジニア。技術の探求と美味しいラーメンを求めて日々奮闘中です。