AWS SAA-C03 高性能設計 完全攻略 — Domain 3（24%）をワークロード逆引きで取る

AWS DR 設計 完全攻略（2026-06-03 公開）までで、安全に・落ちずに・壊れても復旧する設計が揃いました。ここからは配点 24% の Domain 3「Design High-Performing Architectures」に進みます。テーマは「速さ」です。

AWS SAA-C03 高性能設計が問うのは、サービスの性能スペックの暗記ではありません。「このワークロードの特性なら、どのサービスを・どう構成すれば最も性能が出るか」という逆引きの判断力です。コンピュート・ストレージ・データベース・ネットワークという 4 領域それぞれで、ワークロードから最適解を導く思考を整理していきましょう。

高性能設計の原則 — スケールアップ vs スケールアウト

性能向上の手段は、大きく 2 方向に分かれます。この区別が Domain 3 全体の土台になります。

クラウドの強みが最大限に活きるのはスケールアウトです。需要に応じて台数を増減させ、複数 AZ に分散すれば、性能と可用性を同時に得られます。一方、リレーショナルデータベースの書き込みのように、水平分割が難しい処理ではスケールアップが現実解になる場面もあります。「まず水平、難しければ垂直」という優先順位を持っておくと、選択肢を絞りやすくなります。

性能のもうひとつの軸が「ボトルネックの特定」です。CPU なのか、メモリなのか、ディスク I/O なのか、ネットワークなのか。どこが詰まっているかで打ち手はまったく変わります。やみくもに大きなインスタンスを選ぶのではなく、ボトルネックに対して的確なリソースを与える。これが高性能設計の基本姿勢です。

試験では、この原則が「デカップリングと組み合わせて性能を引き出す」形でも問われます。たとえば、急激なアクセス増に対してアプリサーバーを増やすだけでは、その先のデータベースが詰まれば全体は速くなりません。前段にキャッシュを置き、書き込みはキューで受け流し、読み取りはレプリカへ分散する——こうした多層の工夫で、はじめてシステム全体のスループットが上がります。AWS SAA-C03 高性能設計の設問は、単一サービスの最適化ではなく、システム全体を見渡した性能設計を問うてくる点に注意してください。「一番の弱点はどこか」を見抜く目が、正解への近道になります。

コンピュートの性能選定 — EC2 ファミリと サーバーレス

コンピュートの選定は、まずワークロードの性質を見極めることから始まります。EC2 にはワークロード特性に応じたインスタンスファミリがあります。

• 汎用（M 系・T 系）: CPU・メモリのバランス型。標準的な Web/アプリサーバー
• コンピュート最適化（C 系）: CPU 性能重視。バッチ処理、ゲームサーバー、科学計算
• メモリ最適化（R 系・X 系）: 大容量メモリ。インメモリ DB、大規模キャッシュ
• ストレージ最適化（I 系・D 系）: 高速ローカルストレージ。大規模な分散データベース、データウェアハウス
• 高速コンピューティング（P 系・G 系）: GPU 搭載。機械学習、推論、グラフィック処理

「メモリを大量に使うインメモリ分析」なら R 系、「GPU で機械学習」なら P 系、というように、ボトルネックとなるリソースからファミリを逆引きします。

加えて、サーバー管理から解放されるサーバーレスの選択肢があります。AWS Lambda はイベント駆動の短時間処理に、AWS Fargate はコンテナをサーバー管理なしで動かす用途に向きます。さらに、Arm ベースの AWS Graviton プロセッサは、同等性能で価格性能比に優れるため、対応ワークロードでは積極的に検討する価値があります。「サーバー管理をなくしたい」「価格性能比を上げたい」という要件は、サーバーレスや Graviton への誘導サインです。

ここで意識したいのが、性能とコストはしばしば表裏一体だという点です。たとえば、断続的にしか動かない処理に常時起動の EC2 を割り当てるのは、性能的にも費用的にも無駄が大きい。こうしたワークロードを Lambda に載せ替えれば、実行時だけ課金され、かつ自動でスケールします。性能設計の選択が、そのままコスト最適化につながる場面は多く、両者を切り離さずに考える視点が求められます。なお、Lambda には実行時間やメモリの上限があるため、長時間・大規模な処理にはコンテナ（Fargate）や EC2 が適する、という見極めも必要です。

ストレージの性能選定 — EBS ボリュームタイプ

EC2 にアタッチするブロックストレージ EBS には、性能特性の異なるボリュームタイプがあります。SSD 系と HDD 系で大きく分かれます。

判断軸は明快です。高い IOPS を確実に確保したいなら io2/io1。コストと性能のバランスなら gp3。大きなファイルを順次読み書きする（高スループットだが IOPS は不要）なら st1。ほとんどアクセスしないなら sc1。「ランダムアクセスが多いか、シーケンシャルか」「IOPS かスループットか」を問題文から読み取るのが鍵です。

ここで重要な概念が IOPS とスループットの違いです。IOPS は「1 秒あたりの入出力操作回数」で、小さなデータへのランダムアクセスが多いデータベースで効いてきます。一方スループットは「1 秒あたりのデータ転送量（MB/s）」で、大きなファイルを連続して読み書きするログ処理やビッグデータ解析で効きます。同じ「速いストレージ」でも、求められる速さの種類がまったく違うのです。データベースのトランザクションが詰まっているなら IOPS、巨大なファイルの読み込みが遅いならスループット、という具合に、症状からボトルネックを特定してボリュームタイプを選ぶ。この切り分けが Domain 3 の頻出パターンです。

S3 と EFS/FSx の使い分け — ストレージの種類を選ぶ

ストレージはブロックだけではありません。用途に応じて 3 つの種類を選び分けます。

• オブジェクトストレージ（Amazon S3）: HTTP でアクセスする無限スケールのストレージ。静的ファイル、バックアップ、データレイク
• ファイルストレージ（Amazon EFS / Amazon FSx）: 複数サーバーから同時マウントできる共有ファイルシステム
• ブロックストレージ（Amazon EBS）: 単一インスタンスにアタッチする仮想ディスク

「複数の EC2 から同じファイルに同時アクセスしたい」なら、EBS では実現しにくく、EFS が適します。Linux 向けの共有ファイルなら EFS、Windows 向けや高性能計算なら FSx（FSx for Windows File Server、FSx for Lustre 等）を選びます。「大量の静的コンテンツを安く・無限に」なら S3。ストレージの種類を取り違えると設計全体が破綻するため、ここは確実に区別しておきましょう。特に FSx for Lustre は、機械学習の学習データセットや HPC のように、極めて高いスループットと低レイテンシが要求される場面で選ばれます。S3 のデータセットを高速に処理したい時に、S3 と連携する FSx for Lustre を一時的なスクラッチ領域として使う、という構成も頻出パターンです。「共有か単独か」「Linux か Windows か」「超高速計算か」という 3 つの問いで、ファイルストレージの選択は明確になります。

データベースの性能 — リードレプリカ・Aurora・DynamoDB

データベースの性能向上は、読み取りと書き込みで打ち手が異なります。

読み取り負荷の分散には、リードレプリカが定番です。Amazon RDS は MySQL・MariaDB・PostgreSQL で最大 15 のリードレプリカを作成でき、読み取りクエリを複数のレプリカに振り分けられます。Amazon Aurora も最大 15 の Aurora レプリカで読み取りをスケールアウトできます。可用性のための Multi-AZ 配置と、読み取り性能のためのリードレプリカは目的がまったく異なります。AWS SAA-C03 回復性設計 完全攻略（2026-06-02 公開）で扱った Multi-AZ が「障害に耐える」仕組みであるのに対し、リードレプリカは「読み取りを速くする」仕組みである、という区別を改めて押さえてください。

書き込みや超低レイテンシが要求される場合は、Amazon DynamoDB が候補になります。フルマネージドの非リレーショナル（キーバリュー型）データベースで、任意の規模で一桁ミリ秒の応答を実現します。さらに DynamoDB Accelerator（DAX）を併用すれば、読み取りをマイクロ秒級まで高速化できます。「リレーショナルである必要がなく、超高速・超大規模が要る」なら DynamoDB を軸に据えるのが定石です。

キャッシュ階層の設計 — ElastiCache

データベースへのアクセスそのものを減らす——それがキャッシュの役割です。Amazon ElastiCache は、頻繁にアクセスされるデータをメモリ上に保持し、データベースの負荷を劇的に下げます。エンジンは Redis OSS、Memcached、そして新しく Valkey が選べます。

エンジン選定の判断軸を整理します。

「永続化やレプリケーション、ソート済みセットのような高度な機能が要る」なら Redis 系。「とにかくシンプルで、マルチコアを活かしたい」なら Memcached。キャッシュの設計は、データベースの読み取り負荷を下げる最も費用対効果の高い一手であり、Domain 3 で頻出します。

キャッシュには代表的な 2 つの戦略があります。ひとつは遅延読み込み（Lazy Loading）で、必要になった時にだけデータをキャッシュへ載せる方式です。無駄なデータを持たない反面、初回アクセスは必ずキャッシュミスになります。もうひとつは書き込み時に同時にキャッシュも更新する Write-Through で、常に最新が載っている代わりにキャッシュが肥大化しやすい。さらに、古いデータを掴み続けないよう TTL（有効期限）を設定するのが定石です。こうしたキャッシュ戦略の理解は、AWS SAA-C03 高性能設計の中でも実務直結度が高く、設問でも「キャッシュミスを減らすには」「古いデータを返さないためには」という形で問われます。

コンテンツ配信 — CloudFront でエッジに近づける

ユーザーとの物理的な距離も、性能を左右します。地球の裏側のサーバーへアクセスすれば、それだけで数百ミリ秒の遅延が生じます。これを解消するのが Amazon CloudFront です。

CloudFront は世界中のエッジロケーションにコンテンツをキャッシュし、ユーザーに最も近い拠点から配信します。静的コンテンツの配信を高速化するだけでなく、オリジンサーバーへの負荷も軽減します。S3 をオリジンにした静的サイト配信、動的コンテンツのアクセラレーション、両方に効きます。「世界中のユーザーに低遅延でコンテンツを届けたい」なら CloudFront が第一選択です。

CloudFront はキャッシュによってオリジンへのリクエスト数そのものを減らすため、性能とコストの両面で効きます。エッジでヒットすればオリジンの S3 や EC2 にアクセスが届かず、データ転送量も削減されます。加えて、セキュリティの観点では S3 オリジンへの直接アクセスを遮断し、CloudFront 経由のみに限定する構成が定石です。性能・コスト・セキュリティを一度に底上げできる点が、CloudFront が頻出する理由です。

ネットワーク性能 — Placement Group と Global Accelerator

さらに踏み込んだネットワーク性能の最適化手段もあります。EC2 インスタンス間の通信を最適化する Placement Group は、クラスター配置で同一 AZ 内のインスタンスを物理的に近接させ、低レイテンシ・高スループットの通信を実現します。HPC（ハイパフォーマンスコンピューティング）や分散処理で効きます。

一方、AWS Global Accelerator は、AWS のグローバルネットワークと Anycast IP を使い、ユーザーのトラフィックを最寄りのエッジから AWS バックボーン経由で目的のリージョンへ最短で届けます。CloudFront が「コンテンツのキャッシュ配信」なのに対し、Global Accelerator は「アプリケーションそのものへの最適経路」を提供する、という違いを押さえましょう。キャッシュできない動的なトラフィックや、ゲーム・音声通話のように経路品質が体験を左右する用途では、Global Accelerator が効果を発揮します。

AI/ML ワークロードの性能設計 — Bedrock と SageMaker

当ブログの主題である AI ワークロードも、性能設計の対象です。AWS には生成 AI・機械学習の基盤が揃っています。

Amazon Bedrock は、複数の基盤モデルを API 経由で利用できるフルマネージドサービスです。推論のスループットを確保したい場合は、プロビジョンドスループットでキャパシティを予約できます。Amazon SageMaker は、モデルの学習からデプロイまでを担う ML プラットフォームで、推論エンドポイントのオートスケーリングや、GPU インスタンスの選定が性能の鍵を握ります。

AI 推論ワークロードでも、原則は同じです。ボトルネック（多くは GPU とメモリ）を見極め、適切なインスタンスを選び、必要に応じてスケールアウトする。さらに、頻出する推論結果をキャッシュすれば、コストとレイテンシの両方を下げられます。AWS SAA-C03 高性能設計の判断軸は、AI ワークロードにもそのまま応用できるのです。

たとえば、リアルタイム性が不要なバッチ推論なら、SageMaker のバッチ変換やスポット的なキャパシティを使ってコストを抑えられます。逆に、対話型アプリのように即応性が求められる推論では、エンドポイントを常時稼働させ、オートスケーリングで需要変動に追従させる。同じ「AI を動かす」でも、レイテンシ要件によって最適な構成は大きく変わります。3D プリントの不良検知のような画像推論をエッジ寄りで動かすか、クラウドで集中処理するか、といった判断も、結局はワークロード特性からの逆引きに帰着します。

設計シナリオ演習 — 5 つの典型問題

判断軸を試験形式で確認します。

シナリオ 1: 読み取りが多い RDS の性能が頭打ち。 インスタンスを大きくする（スケールアップ）だけでは限界があります。正解はリードレプリカを追加し、読み取りクエリを分散することです。

シナリオ 2: データベースへの同じ問い合わせが大量に発生している。 インスタンス増強より効果的なのは、ElastiCache でクエリ結果をキャッシュし、DB アクセス自体を減らすことです。

シナリオ 3: 世界中のユーザーへ静的コンテンツを配信したい。 オリジンを増強しても距離の問題は解けません。正解は CloudFront でエッジ配信することです。

シナリオ 4: 一桁ミリ秒以下の超低レイテンシで超大規模なキーバリューアクセスが要る。 RDS では要件を満たせません。正解は DynamoDB（必要なら DAX 併用）です。

シナリオ 5: 複数の EC2 から同じファイルへ同時にアクセスしたい。 EBS は単一インスタンス向けで不向き。正解は EFS の共有ファイルシステムです。

5 問とも、判断はワークロードの特性（読み取り中心か、距離か、共有か、超低遅延か）から最適サービスを逆引きする、という一点に集約されます。

まとめ — Domain 3 のチェックリスト

AWS SAA-C03 高性能設計は、次のチェックリストに集約できます。

• まず水平スケール（スケールアウト）、難しければ垂直スケール
• EC2 ファミリはボトルネックとなるリソースから逆引き
• 価格性能比やサーバーレス要件は Graviton・Lambda・Fargate のサイン
• EBS は IOPS 保証なら io2、バランスなら gp3、高スループットなら st1
• 共有ファイルは EFS/FSx、無限オブジェクトは S3、単一ブロックは EBS
• 読み取り分散はリードレプリカ、超高速大規模は DynamoDB（＋DAX）
• DB 負荷低減はまず ElastiCache のキャッシュ
• グローバル配信は CloudFront、最適経路は Global Accelerator
• AI 推論も「ボトルネック特定 → 適切なインスタンス → スケール＋キャッシュ」

次は最後のドメイン、配点 20% の Domain 4「コスト最適化」です。性能を落とさずにコストを下げる——購入オプション・ストレージ階層・データ転送の判断軸を整理し、4 ドメインの学習を完成させます。

参照

• AWS Certified Solutions Architect – Associate（SAA-C03）公式
• Amazon EBS ボリュームタイプ
• Amazon RDS リードレプリカ
• Amazon ElastiCache — Redis と Memcached の比較
• Amazon CloudFront 公式
• AWS Global Accelerator 公式

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.