SAA ドメイン4：コスト最適化アーキテクチャの設計｜配点20%を「4層×4原則」で攻略する
AWS SAA-C03 の第4ドメイン「コスト最適化アーキテクチャの設計（20%）」を、公式タスクステートメント4.1〜4.4に沿って完全攻略する。結論は「ストレージ・コンピュート・DB・ネットワークの4層それぞれに“使った分だけ払う／長期は割引で買う／頻度で階層化する／転送を減らす”の4原則を当てはめること」。Savings Plans・RI・スポットの使い分け、S3 ストレージクラス、Auto Scaling/サーバーレス、CloudFront/VPC Endpoint によるデータ転送削減、Cost Explorer/Budgets/Trusted Advisor まで、SAA 本番で問われるコスト設計の判断軸と頻出ひっかけを、そのまま得点に変わる粒度で解説する。
「安く作れ」と言われて反射的にインスタンスを止める——その発想だけでは、SAA-C03 のドメイン4は攻略できない。 配点 **20%（採点対象50問のうち約10問）**を占めるこの第4ドメイン「コスト最適化アーキテクチャの設計」は、4ドメインの最後に位置しながら、合格ラインを固めるうえで見落とせない得点源だ。出題は **4つのタスクステートメント（4.1〜4.4）**に構造化されている。結論から言えば、ドメイン4は「ストレージ／コンピュート／DB／ネットワークの4層それぞれに、コスト最適化の4原則を当てはめる」という発想で一気に見通せる。本記事では、各層の中核サービス・料金オプションの選定判断・頻出ひっかけを、SAA 本番でそのまま選択肢を絞れる粒度まで分解する。読み終えれば、「最もコスト効率が高い構成はどれか」という問いに、迷わず正解を引き当てられるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：ドメイン4は「4つの層」に「4つの原則」を当てはめる
- ドメイン4の全体像と4つのタスクステートメント
- タスク4.2：コンピュートの料金オプションを使い分ける
- タスク4.1・4.3：ストレージとDBを頻度で階層化する
- タスク4.4：データ転送コストを削る
- コスト可視化ツールと頻出ひっかけパターン
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：ドメイン4は「4つの層」に「4つの原則」を当てはめる
SAA-C03 ドメイン4を攻略する最短ルートは、コスト最適化を「勘や我慢」ではなく「4つの原則」に落とし込み、各層に機械的に当てはめることだ。これが本記事の結論である。
理由は、ドメイン4の4つのタスクステートメントが、そのまま ストレージ（4.1）・コンピュート（4.2）・データベース（4.3）・ネットワーク（4.4） という4つの層に対応しており、どの層にも共通する判断原則が存在するからだ。その原則とは次の4つに集約できる。
- 使った分だけ払う — 常時起動ではなく、需要に応じて起動・縮小する（Auto Scaling・サーバーレス）
- 長期利用は割引で買う — 定常的な負荷は Savings Plans・RI でコミットして最大72%引く
- アクセス頻度で階層化する — めったに読まないデータは安い階層へ自動で移す（S3 ストレージクラス・ライフサイクル）
- データ転送を減らす — 課金される経路（NAT・インターネット向き送信）を避け、キャッシュ・VPC 内通信に寄せる
具体例で見よう。「常時稼働する本番 DB のコストを下げたい」は原則2——Savings Plans や RI でコミットする。「中断してよいバッチのコストを下げたい」は原則1＋スポットインスタンス（最大90%引き）。「めったにアクセスしないログの保管費を下げたい」は原則3——S3 Glacier へ階層化。要件のキーワードから「どの原則を効かせる問題か」を見抜く——これがドメイン4の解き方の骨格だ。
SAA の4ドメイン全体像を押さえ、配点上位のドメイン1（30%）・ドメイン2（26%）・ドメイン3（24%）を固めたら、最後にこの配点20%のドメイン4で得点を積み上げれば、合格ラインは盤石になる。
2. ドメイン4の全体像と4つのタスクステートメント
まず、ドメイン4の構造を1枚の表で俯瞰する。公式試験ガイドのタスクステートメントを、本記事の「4層×4原則」に対応づけたものだ。
| タスク | 層 | 効かせる原則 | 中核サービス・オプション |
|---|---|---|---|
| 4.1 | ストレージ | 頻度で階層化 | S3 ストレージクラス / ライフサイクル / Glacier |
| 4.2 | コンピュート | 使った分だけ・長期は割引 | Savings Plans / RI / スポット / Auto Scaling / Lambda |
| 4.3 | データベース | 使った分だけ・適材適所 | Aurora Serverless / DynamoDB オンデマンド / RI |
| 4.4 | ネットワーク | 転送を減らす | CloudFront / VPC Endpoint / NAT 設計 |
コスト最適化問題の特徴は、「動く構成」が複数あるなかで「最も安い構成」を1つ選ばせる点にある。技術的にはどれも正解でも、コスト観点で優劣がつく——だからこそ、4原則という“ものさし”を持って選択肢を評価する訓練が効く。
3. タスク4.2：コンピュートの料金オプションを使い分ける
ドメイン4で最も出題が集中するのがコンピュート層だ。中心テーマは、EC2 の4つの料金オプション——オンデマンド・リザーブドインスタンス（RI）・Savings Plans・スポット——を、ワークロードの性質で正しく割り当てられるかである。
ワークロードの「起動パターン」で料金を選ぶ
判断軸はシンプルで、**「いつ・どれだけ動くか」**だ。予測不能で短期なら定価のオンデマンド、常時稼働で長期なら割引コミット（RI／Savings Plans）、中断してよいなら激安のスポット。この対応を反射で引けるようにする。
| 評価項目 | オンデマンド | Savings Plans / RI 推奨 | スポット |
|---|---|---|---|
| 向くワークロード | 短期・予測不能・検証 | 常時稼働の定常的な負荷 | 中断可能なバッチ・並列処理 |
| 割引率の目安 | なし（定価） | 最大約72% | 最大約90% |
| コミット | 不要 | 1年 or 3年 | 不要（中断リスクあり） |
| キーワード | 「一時的」「予測できない」 | 「24時間365日」「安定稼働」 | 「中断に強い」「フォールトトレラント」 |
Savings Plans と RI はどちらを勧めるか
近年の SAA では、柔軟性の高い Savings Plans が推されやすい。RI が「特定のインスタンスタイプ・リージョン」に縛られるのに対し、Compute Savings Plans は「1時間あたり◯ドル使う」というコミットなので、インスタンスファミリー・サイズ・OS・リージョンをまたいでも割引が自動適用される。
そして、そもそもサーバーを持たない選択肢も忘れてはいけない。断続的・イベント駆動の処理なら Lambda、コンテナなら Fargate で、アイドル時間に一切課金されない構成にできる。Auto Scaling で需要に追従して台数を縮める（原則1）のも、コスト最適化の基本動作だ。適切なサイズ選定は Compute Optimizer のレコメンドに任せられる。
4. タスク4.1・4.3：ストレージとDBを頻度で階層化する
ストレージ（4.1）——アクセス頻度に払う額を合わせる
ストレージ層の原則は明快で、**「読まないデータに高い金を払わない」**ことに尽きる。S3 ストレージクラスは、アクセス頻度に応じて単価の異なる階層を用意しており、頻繁に読むデータは Standard、めったに読まないデータは低頻度アクセス（Standard-IA）やアーカイブの Glacier へ置く。
| データのアクセス頻度 | 適切なストレージクラス |
|---|---|
| 頻繁にアクセスする | S3 Standard |
| アクセス頻度が読めない・変動する | S3 Intelligent-Tiering |
| 月数回以下・低頻度 | S3 Standard-IA / One Zone-IA |
| 数分〜数時間待てるアーカイブ | S3 Glacier Flexible / Deep Archive |
データベース（4.3）——「使った分だけ」を DB にも効かせる
DB 層のコスト最適化は、コンピュートと同じ原則の応用だ。負荷が変動・断続的なら、キャパシティを固定せず需要追従型を選ぶ。Aurora Serverless v2 は負荷に応じて容量を自動増減し、アイドル時のコストを抑える。DynamoDB のオンデマンドキャパシティは、トラフィックが読めないワークロードで「使った分だけ」課金にできる。一方、予測可能で安定した負荷なら、RI（RDS/ElastiCache）やプロビジョンドキャパシティでコミット割引を効かせる方が安い。分析用途（OLAP）を汎用 DB で無理に回さず、Redshift や Athena に適材適所で振るのもコスト削減につながる。
5. タスク4.4：データ転送コストを削る
見落とされがちだが、SAA で確実に問われるのがデータ転送（データ egress）コストだ。AWS では、インターネットへの送信（アウトバウンド）や一部の経路に転送料金がかかる。原則は**「課金される経路を通さない」**——キャッシュ・VPC 内通信・専用エンドポイントに寄せる。
| コストがかさむ経路 | 削減する設計 |
|---|---|
| オリジンから毎回インターネット配信 | CloudFront でエッジキャッシュし、オリジンへの転送を削減 |
| プライベートサブネットから S3/DynamoDB への通信 | NAT Gateway 経由をやめ、VPC Gateway Endpoint で無料化 |
| NAT Gateway の処理データ量が多い | 通信先を精査し、Endpoint やアーキテクチャ見直しで NAT 通過量を削減 |
6. コスト可視化ツールと頻出ひっかけパターン
コスト最適化は「設計」だけでなく「可視化と統制」もセットで問われる。ここは3つのツールの役割分担を押さえれば十分だ。
- Cost Explorer：過去〜将来のコストを可視化・分析する。「どこにいくらかかっているか」を把握する“分析”ツール。
- AWS Budgets：予算を設定し、超過（または超過予測）でアラートする“見張り”ツール。
- Trusted Advisor：使われていないリソースや割引の余地など、**コスト最適化の“改善提案”**をチェック項目で示す。
7. 次のアクション チェックリスト
ドメイン4の「4層×4原則」を、今日からの学習に落とし込むための具体アクションをまとめる。
8. 関連記事
- SAA 試験完全ガイド｜SAA-C03 の出題範囲・難易度・3ヶ月合格戦略 — 本シリーズの上位ガイド
- SAA 試験範囲：4ドメイン詳細解説 — ドメイン1〜4の全体像
- SAA ドメイン1：セキュアなアーキテクチャの設計 — 配点最大のドメイン
- SAA ドメイン2：弾力性のあるアーキテクチャの設計 — スケール×多重化
- SAA ドメイン3：高パフォーマンスアーキテクチャの設計 — 前ドメイン（性能設計）
- EC2 オンデマンド・リザーブド・スポット料金の使い分け — コンピュート料金の基礎
- Savings Plans とは？EC2/Fargate/Lambda のコミット割引 — 柔軟な割引プラン
- S3 ストレージクラス 7 種類の使い分け — 頻度で階層化する
- AWS Cost Explorer と Budget の使い方 — コストの可視化と通知
9. 関連サイト
AWS 公式
- コンテンツ分野4：コストを最適化したアーキテクチャの設計（公式試験ガイド）
- SAA-C03 試験ガイド（公式 PDF）
- AWS Certified Solutions Architect – Associate（公式）
- AWS Savings Plans（公式）
- AWS Cost Explorer（公式）