AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA ドメイン3：高パフォーマンスアーキテクチャの設計｜配点24%を「5つの層×スケール」で攻略する

AWS SAA-C03 の第3ドメイン「高パフォーマンスアーキテクチャの設計（24%）」を、公式タスクステートメント3.1〜3.5に沿って完全攻略する。結論は「ストレージ・コンピュート・DB・ネットワーク・データ取り込みの5層それぞれで“ボトルネックを別サービスに逃がす”設計を選ぶこと」。S3/FSx・Auto Scaling/Lambda・リードレプリカ/ElastiCache/DAX・CloudFront/Global Accelerator・Kinesis まで、SAA 本番で問われる性能設計の判断軸と頻出ひっかけを、そのまま得点に変わる粒度で解説する。

#AWS #SAA #SAA-C03 #Solutions Architect #高パフォーマンス #CloudFront #ElastiCache #キャッシュ #試験対策 #AWS認定資格

「性能が足りないなら、より大きいインスタンスにすればいい」——その反射が、SAA-C03 のドメイン3では失点に直結する。 配点 **24%（採点対象50問のうち約12問）**を占めるこの第3ドメイン「高パフォーマンスアーキテクチャの設計」は、ドメイン1（30%）・ドメイン2（26%）に次ぐ第3の得点源だ。出題は **5つのタスクステートメント（3.1〜3.5）**に構造化されている。結論から言えば、ドメイン3は「ストレージ／コンピュート／DB／ネットワーク／データ取り込みの5層それぞれで、ボトルネックを“別のマネージドサービスに逃がす”」という一貫した発想で攻略できる。本記事では、各層の中核サービス・選定判断・頻出ひっかけを、SAA 本番でそのまま選択肢を絞れる粒度まで分解する。読み終えれば、性能要件のシナリオを前にして「どの層が詰まっているのか」を一瞬で見抜けるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

  1. 結論：ドメイン3は「5つの層」ごとに“逃がし先”を選ぶ
  2. ドメイン3の全体像と5つのタスクステートメント
  3. タスク3.1・3.2：ストレージとコンピュートの性能設計
  4. タスク3.3：高パフォーマンスなデータベース設計
  5. タスク3.4・3.5：ネットワークとデータ取り込みの性能設計
  6. ドメイン3の頻出ひっかけパターン
  7. 次のアクション チェックリスト
  8. 関連記事
  9. 関連サイト

1. 結論：ドメイン3は「5つの層」ごとに“逃がし先”を選ぶ

SAA-C03 ドメイン3を攻略する最短ルートは、性能問題を「どの層が詰まっているか」で切り分け、その層の負荷を別のマネージドサービスに逃がすことだ。これが本記事の結論である。

理由は、ドメイン3の5つのタスクステートメントが、そのまま ストレージ（3.1）・コンピュート（3.2）・データベース（3.3）・ネットワーク（3.4）・データ取り込み（3.5） という5つの層に対応しているからだ。高パフォーマンスとは漠然と「速いシステム」ではなく、各層のボトルネックを個別に特定し、キャッシュ・分散・専用サービスへオフロードして解消するという設計の積み重ねだと捉えると、出題の狙いが一気に見通せる。

具体例で見よう。「DB への読み込みが集中して遅い」はDB層（3.3）——正解は リードレプリカや ElastiCache によるキャッシュだ。「世界中のユーザーへの配信が遅い」はネットワーク層（3.4）——CloudFront の出番。要件のキーワードから詰まっている層を特定し、その層の定番の“逃がし先”を引き出す——これがドメイン3の解き方の骨格だ。

SAA の4ドメイン全体像を押さえ、配点上位のドメイン1（セキュリティ・30%）とドメイン2（弾力性・26%）を固めたら、次はこの配点24%のドメイン3に学習時間を投じるのが正しい順序だ。

2. ドメイン3の全体像と5つのタスクステートメント

まず、ドメイン3の構造を1枚の表で俯瞰する。公式試験ガイドのタスクステートメントを、本記事の「5層モデル」に対応づけたものだ。

タスク層問われる判断中核サービス
3.1ストレージワークロードに合う高性能ストレージを選べるかS3 / EBS / EFS / FSx
3.2コンピュート負荷に応じて伸縮する高性能な計算基盤を組めるかEC2 / Auto Scaling / Lambda / Fargate
3.3データベース読み書きの負荷を適切にオフロードできるかRDS / Aurora / ElastiCache / DAX
3.4ネットワーク距離と経路の遅延を最小化できるかCloudFront / Global Accelerator / VPC Endpoint
3.5データ取り込み大量データを高スループットで処理できるかKinesis / Glue / Athena

5つの層は独立して見えて、実際の問題では組み合わせて問われる。たとえば「動的コンテンツと静的コンテンツが混在するグローバルサイトを高速化したい」なら、CloudFront（3.4）＋ S3（3.1）＋ ElastiCache（3.3）が同時に登場する。だからこそ、各層を個別に固めたうえで「複数層を貼り合わせる」訓練が効く。

3. タスク3.1・3.2：ストレージとコンピュートの性能設計

ストレージ（3.1）——ワークロードの形にストレージを合わせる

ストレージ層で問われるのは、アクセスパターンに合った種類を選べるかだ。汎用の S3 か、低レイテンシのブロックストレージ EBS（gp3/io2） か、共有ファイルの EFS か、用途特化の FSx か——要件のキーワードで切り分ける。

要件適切なサービス
大量オブジェクトの保存・配信、静的サイトS3
高 IOPS・低レイテンシの単一インスタンス用ディスクEBS（io2 Block Express）
複数インスタンスから同時マウントする共有ファイルEFS
Windows 共有 / 高性能 HPC（Lustre）FSx for Windows / Lustre

コンピュート（3.2）——負荷に追従する“伸縮”と“オフロード”

コンピュート層の中心は、負荷に応じて自動で伸縮させることだ。EC2 Auto Scaling と ELB の水平スケールが標準形。適切な インスタンスタイプ（コンピュート最適化 C 系、メモリ最適化 R 系など）の選定もここで問われる。イベント駆動・断続的な処理なら Lambda、コンテナなら Fargate でサーバー管理そのものを不要にし、需要に瞬時に追従させるのが AWS の推す型だ。

CloudFront でオリジンの計算負荷を肩代わりさせる、SQS で処理を非同期にバッファリングして急増を平準化する——計算そのものを減らす／後ろにずらす発想も、コンピュート性能設計の一部として押さえておこう。

4. タスク3.3：高パフォーマンスなデータベース設計

DB層は、SAA で最も頻繁に性能改善を問われる層だ。ポイントは、読み込み負荷と書き込み負荷を別々の手段でオフロードすること。

読み込み負荷は「レプリカ」と「キャッシュ」で逃がす

「DB の読み込みが集中して遅い」——この定番シナリオの答えは2択だ。リードレプリカで読み取りを分散するか、キャッシュで DB へのアクセスそのものを減らすか。RDS リードレプリカは読み取り専用の複製を増やして参照クエリを分散し、ElastiCache は頻繁に読まれるデータをメモリに載せて応答を高速化する。DynamoDB のマイクロ秒応答が要るなら DAX が専用キャッシュになる。

読み込み負荷のオフロード：リードレプリカ と ElastiCache の使い分け
評価項目
リードレプリカ
ElastiCache（キャッシュ） 推奨
効く負荷 読み取りクエリの分散 同じデータへの繰り返しアクセス
仕組み 読み取り専用の複製DBを増やす メモリにデータを載せてDBを迂回
応答速度 DB同等（分散はされる） マイクロ〜ミリ秒（超高速）
キーワード 「レポート」「参照が多い」 「同じ結果を何度も」「セッション」
注意点 レプリカ遅延（結果整合性） キャッシュ無効化の設計が必要
繰り返し読まれる“ホットな”データはまず ElastiCache。全体的な参照クエリの分散はリードレプリカ、と切り分ける。

書き込みスケールとエンジン選定

書き込みのスケールや、DB エンジン自体の選定も問われる。RDBMS のマネージド性能を極めたいなら Aurora（RDS 比で高スループット）、キーバリューで無限にスケールさせたいなら DynamoDB、分析クエリ（OLAP）なら Redshift——トランザクション（OLTP）か分析（OLAP）かで DB を分けるのが基本だ。

5. タスク3.4・3.5：ネットワークとデータ取り込みの性能設計

ネットワーク（3.4）——距離と経路の遅延を潰す

ネットワーク層の主役は、ユーザーとデータの物理的な距離を縮めることだ。静的・動的コンテンツの配信高速化は CloudFront（エッジキャッシュ）が定番。TCP/UDP レベルで固定 IP と AWS グローバルネットワーク経由の高速化が要るなら Global Accelerator が候補になる。

要件適切なサービス
HTTP/HTTPS コンテンツを世界中に高速配信CloudFront
非HTTP（TCP/UDP）を固定IPで高速・低遅延化Global Accelerator
S3・DynamoDB へインターネットを経由せず高速アクセスVPC Endpoint
オンプレとの安定・低遅延な専用線接続Direct Connect

データ取り込み・変換（3.5）——大量データを詰まらせず流す

最後の層は、大量のデータを高スループットで取り込み・変換する設計だ。リアルタイムのストリーミングデータは Kinesis Data Streams、それを S3 等へ配信・ロードするなら Kinesis Data Firehose。蓄積したデータの ETL（変換）は Glue、S3 上のデータへのサーバーレスクエリは Athena が定番だ。大量の書き込みや通知の平準化に SQS・EventBridge を挟むパターンも、この層の頻出構成として押さえておこう。

6. ドメイン3の頻出ひっかけパターン

ドメイン3は、AWS の設計思想（キャッシュ・分散・マネージドへのオフロード）に沿わない選択肢が誤答になりやすい。本番で迷ったときの判断材料として、正答に寄せる打ち手と避けるべき誤答を整理する。

7. 次のアクション チェックリスト

ドメイン3の5層モデルを、今日からの学習に落とし込むための具体アクションをまとめる。

8. 関連記事

9. 関連サイト

AWS 公式