AIAI Agent Dev Labaiagentdev-lab.com
3分適性診断 →

STEP 1 · 学習

SAA-C03 学習ソリューションアーキテクト – アソシエイト

公式の出題分野ごとに要点を読み、各分野の最後にある「この分野を練習する」でその分野だけの問題を解きます。分野の比率が大きいほど本試験での出題が多くなります。

01

セキュアなアーキテクチャの設計

Design Secure Architectures

30%

学習目標

  • IAM ユーザー・グループ・ロール・ポリシーと、STS によるロールの切り替え・クロスアカウントアクセスを使い分けられる
  • Organizations・SCP・Control Tower・IAM Identity Center で複数アカウントの統制を設計できる
  • パブリック／プライベートサブネット、セキュリティグループ、ネットワーク ACL、NAT ゲートウェイ、VPC エンドポイントで通信経路を設計できる
  • KMS・ACM・Secrets Manager・S3 の暗号化とアクセス制御、バックアップとレプリケーションで、データ保護の要件を満たせる

要点

  • 人には IAM Identity Center（または社内 ID とのフェデレーション）、アプリやサービスには IAM ロールの一時的な認証情報を使う。長期のアクセスキーは最小限にし、ルートユーザーは MFA で保護して日常作業に使わない。
  • IAM のポリシー評価では、明示的な拒否が常に優先され、どこにも許可がなければ暗黙的に拒否される。SCP やアクセス許可の境界は「許可の上限」を決めるもので、それ自体は権限を与えない。
  • 別アカウントのリソースへのアクセスは、アクセス先アカウントのロールを AssumeRole する方法か、S3 バケットポリシーなどのリソースベースのポリシーで相手を許可する方法がある。
  • Web サーバーはパブリックサブネット（または ALB のみパブリック）、アプリとデータベースはプライベートサブネットに置く。プライベートサブネットからインターネットへ出るには NAT ゲートウェイ、S3 や DynamoDB へインターネットを経由せずに接続するにはゲートウェイ VPC エンドポイントを使う。
  • セキュリティグループはステートフルで許可ルールのみ、ネットワーク ACL はステートレスで許可と拒否を書け、サブネット単位で特定の IP を拒否したいときに使う。
  • SQL インジェクションやクロスサイトスクリプティングは AWS WAF、DDoS は AWS Shield（Standard は自動・無料、Advanced は有料の高度な保護）。脅威検知は GuardDuty、S3 の機密データ検出は Macie、脆弱性スキャンは Inspector。
  • 保存時の暗号化は KMS（キーポリシーで誰が鍵を使えるかを制御し、自動ローテーションを設定できる）、転送時の暗号化は ACM の証明書で TLS。データベースのパスワードは Secrets Manager で自動ローテーションする。
  • S3 のデータ保護：パブリックアクセスのブロック、バケットポリシー、バージョニング、オブジェクトロック（WORM・保持期間）、レプリケーション（別リージョン・別アカウントへの複製）。バックアップの一元管理は AWS Backup。

業務での使いどころ

  • 経理請求書 PDF を保存する S3 バケットで、パブリックアクセスをブロックし、KMS キーで暗号化。法定保存期間はオブジェクトロックで削除や上書きを防ぐ。
  • 総務子会社ごとの AWS アカウントを Organizations でまとめ、SCP で東京・大阪以外のリージョンの利用を禁止。社員は社内 ID で IAM Identity Center からサインインする。
  • 営業営業支援システムの DB パスワードを Secrets Manager に保存して自動ローテーション。アプリは IAM ロールで取得し、コードにパスワードを書かない。

公式のタスクステートメント（英語）

  • 1.1 Design secure access to AWS resources.
  • 1.2 Design secure workloads and applications.
  • 1.3 Determine appropriate data security controls.

公式の学習リソース

この分野を練習する（90問）→次の分野を読む ↓
02

レジリエントなアーキテクチャの設計

Design Resilient Architectures

26%

学習目標

  • SQS・SNS・EventBridge・Step Functions で、処理を疎結合にする方法を選べる
  • ALB と Auto Scaling、ステートレスな設計で、水平スケーリングする構成を作れる
  • コンテナ（ECS・EKS・Fargate）とサーバーレス（Lambda・API Gateway）を使う場面を判断できる
  • マルチ AZ・マルチリージョン、Route 53 のフェイルオーバー、DR 戦略（バックアップと復元・パイロットライト・ウォームスタンバイ・マルチサイト）を RPO/RTO から選べる

要点

  • 疎結合：処理の受け渡しを SQS のキューで切り離すと、受け側が遅れても送り側は止まらない。1件を複数の宛先に配るならSNS（ファンアウトは SNS→複数の SQS）、イベントのルールで振り分けるなら EventBridge、複数手順の流れと再試行は Step Functions。
  • SQS 標準キューは少なくとも1回の配信で順序は保証されない。順序と重複排除が必要なら FIFO キュー。処理に失敗し続けるメッセージはデッドレターキューへ。
  • 水平スケーリングには、セッション情報をサーバーに持たないステートレス設計が前提（セッションは ElastiCache や DynamoDB に置く）。ALB は HTTP のパスやホスト名で振り分け、NLB は TCP/UDP の高性能・固定 IP 向け。
  • マルチ AZ：ALB と Auto Scaling グループを複数 AZ に、RDS はマルチ AZ 配置（同期スタンバイへの自動フェイルオーバー）。リードレプリカは読み取りの分散用で、主に可用性ではなく性能のための仕組み。
  • DR 戦略は RPO（どこまでのデータ損失を許すか）と RTO（どれだけで復旧するか）で選ぶ。コストの低い順に、バックアップと復元 → パイロットライト（データは常に複製、計算資源は最小限）→ ウォームスタンバイ（縮小版を常時稼働）→ マルチサイト（アクティブ/アクティブ）。
  • Route 53 のフェイルオーバールーティングとヘルスチェックで、正常な側に DNS で切り替える。待機側の環境ではサービスクォータ（上限）も本番と同じ規模で確保しておく。
  • 変更できないレガシーアプリでも、ELB と Auto Scaling の背後に置く、RDS Proxy で接続を集約する、などで信頼性を高められる。AWS X-Ray で分散したアプリの処理の流れと遅延を可視化する。

業務での使いどころ

  • 営業受注データを SQS に積んでから在庫引当を行い、繁忙期に在庫システムが遅れても受注受付を止めない。失敗した受注はデッドレターキューで確認する。
  • 経理月次決算システムの DR を、RPO 1時間・RTO 4時間の要件からパイロットライト方式で設計し、大阪リージョンにデータを常時複製しておく。
  • 総務社内ポータルを ALB と2つの AZ の Auto Scaling グループで構成し、1つの AZ が止まっても閲覧を続けられるようにする。

公式のタスクステートメント（英語）

  • 2.1 Design scalable and loosely coupled architectures.
  • 2.2 Design highly available and/or fault-tolerant architectures.

公式の学習リソース

この分野を練習する（79問）→次の分野を読む ↓
03

高パフォーマンスなアーキテクチャの設計

Design High-Performing Architectures

24%

学習目標

  • S3・EBS（gp3・io2）・EFS・FSx の性能特性から、要件に合うストレージを選べる
  • インスタンスファミリー、Auto Scaling、Lambda、コンテナから、性能と伸縮性に合うコンピューティングを選べる
  • RDS・Aurora・DynamoDB・ElastiCache・DAX・リードレプリカで、読み書きの性能要件を満たせる
  • CloudFront・Global Accelerator・Direct Connect・VPC の構成と、Kinesis・Firehose・Glue・Athena などのデータ取り込みと変換の仕組みを選べる

要点

  • ブロックストレージの EBS は1つの AZ の EC2 に接続（gp3 は汎用でIOPS とスループットを個別に設定、io2 は高 IOPS の DB 向け）。複数の Linux サーバーから同時に使う共有ファイルは EFS、Windows のファイル共有は FSx for Windows File Server、HPC の高速処理は FSx for Lustre。
  • S3 は大きなファイルをマルチパートアップロードで並列に送り、遠隔地からのアップロードは Transfer Acceleration で速くできる。プレフィックスごとに高いリクエストレートに対応する。
  • 読み取りが多い RDB は、リードレプリカで読み取りを分散し、よく読むデータは ElastiCache にキャッシュ。DynamoDB の読み取りをマイクロ秒単位にするなら DAX。
  • Aurora はストレージが3つの AZ に6つのコピーを持ち、最大15のリードレプリカ。負荷が読めない場合は Aurora Serverless v2 で容量を自動調整。
  • 世界中の利用者への静的・動的コンテンツの配信は CloudFront（エッジでキャッシュ）。TCP/UDP の通信を AWS のネットワーク経由で最寄りのリージョンへ届け、固定のエニーキャスト IP を使うなら Global Accelerator。
  • ストリーミングデータの取り込みは Kinesis Data Streams（複数の処理で読み直せる）、S3 や Redshift へそのまま配信するなら Amazon Data Firehose。データの変換（ETL）とカタログは AWS Glue、S3 のデータを SQL で直接分析するなら Athena。
  • HPC のノード間で低遅延通信が必要ならクラスタープレイスメントグループ、障害の影響を分散するならスプレッドプレイスメントグループ。

業務での使いどころ

  • 営業全国の営業担当が使う商品カタログの画像を CloudFront で配信し、本社のサーバーへのアクセスを減らして表示を速くする。
  • 経理月末に集中する請求データの照会を、Aurora のリードレプリカと ElastiCache で分散し、更新処理の遅延を防ぐ。
  • 総務各拠点の入退室ログを Firehose で S3 に集め、Athena で SQL を使って月次の集計を行う。

公式のタスクステートメント（英語）

  • 3.1 Determine high-performing and/or scalable storage solutions.
  • 3.2 Design high-performing and elastic compute solutions.
  • 3.3 Determine high-performing database solutions.
  • 3.4 Determine high-performing and/or scalable network architectures.
  • 3.5 Determine high-performing data ingestion and transformation solutions.

公式の学習リソース

この分野を練習する（72問）→次の分野を読む ↓
04

コストを最適化したアーキテクチャの設計

Design Cost-Optimized Architectures

20%

学習目標

  • S3 のストレージクラスとライフサイクル、EBS の種類とスナップショットの管理で、保存費用を下げられる
  • オンデマンド・Savings Plans・リザーブドインスタンス・スポットと Auto Scaling を組み合わせ、計算費用を下げられる
  • データベースの種類と容量モード（DynamoDB オンデマンド／プロビジョンド、Aurora Serverless）を費用面から選べる
  • NAT ゲートウェイ、VPC エンドポイント、CloudFront、リージョン間・AZ 間のデータ転送の費用を考慮したネットワーク構成を選べる

要点

  • S3：アクセス頻度が分かるならライフサイクルで Standard-IA や Glacier 系へ移行、パターンが読めないなら Intelligent-Tiering。Glacier Instant Retrieval はミリ秒で取り出せる、Flexible Retrieval は数分〜数時間、Deep Archive は最安で取り出しに最大12時間程度。
  • EBS は gp2 から gp3 に変更すると、同じ性能でも費用を下げられることが多い。使っていないボリュームや古いスナップショットを削除する。
  • 計算：常時稼働の安定した負荷は Savings Plans かリザーブドインスタンス、中断してよいバッチや変動分はスポット、短期・予測できない負荷はオンデマンド。Auto Scaling で需要に合わせて台数を増減する。
  • Compute Optimizer で過大なインスタンスを見つけて適正サイズ化する。Cost Explorer・Budgets・コスト配分タグで費用を見える化し、予算超過を通知する。
  • DynamoDB：アクセスが読めない・まばらならオンデマンド、安定して予測できるならプロビジョンド（Auto Scaling 付き）。夜間や週末に使わない開発用 RDS は停止する、または Aurora Serverless v2 を検討する。
  • プライベートサブネットから S3・DynamoDB へ大量の通信がある場合は、NAT ゲートウェイの処理料金を避けるためにゲートウェイ VPC エンドポイント（追加料金なし）を使う。
  • データ転送：インターネットからの受信は原則無料、インターネットへの送信と、リージョン間・AZ 間の通信は有料。CloudFront からの配信はオリジンからの直接配信より割安になる場合が多い。

業務での使いどころ

  • 経理7年間保存が必要な会計証憑を、1年後に S3 Glacier Deep Archive へ移すライフサイクルルールを設定し、保存費用を下げる。
  • 総務開発・検証用の EC2 と RDS を、平日の業務時間外に自動停止するスケジュールを組み、月額費用を下げる。
  • 営業夜間に実行する見込み客データの集計バッチをスポットインスタンスで実行し、中断されても再実行できるように設計する。

公式のタスクステートメント（英語）

  • 4.1 Design cost-optimized storage solutions.
  • 4.2 Design cost-optimized compute solutions.
  • 4.3 Design cost-optimized database solutions.
  • 4.4 Design cost-optimized network architectures.

公式の学習リソース

この分野を練習する（60問）→模擬試験に挑戦する →

読み終えたら

全分野を練習する（301問）模擬試験（65問・130分）SAA-C03 のトップへ
ご利用上の注意（非公式・独自問題・合格保証なし）