1. はじめに — D4コスト最適化アーキテクチャ設計とは
本記事は「AWS SAA-C03試験対策」シリーズのVol4（最終巻）です。
Vol0 ロードマップ、Vol1 セキュアアーキテクチャ設計、Vol2 レジリエントアーキテクチャ設計、Vol3 高性能アーキテクチャ設計に続き、最後のドメインD4「コスト最適化アーキテクチャ設計」を体系的に解説します。
本記事で扱うのは第4ドメイン、D4「Design Cost-Optimized Architectures（コスト最適化アーキテクチャ設計）」です。
出題比率は20%で、65問換算なら約13問を占めます（問題バンク400問では80問）。
コスト最適化は「お金を節約すればよい」という単純な話ではありません。
適切なサービスを適切な課金モデルで選び、ストレージ階層を最適化し、コストを可視化して継続的に改善するという設計力が問われます。
D4では特にS3（出現119回）・EC2（108回）・Lambda（47回）・Savings Plans（43回）・Spot（39回）が頻出です。
これらを「どの課金モデルが最適か」という状況判断の観点で押さえることが試験攻略の鍵になります。
- EC2課金4モデル（オンデマンド/RI/Savings Plans/Spot）の使い分け（§2）
- S3ストレージクラス7種とライフサイクルポリシーの設計（§3）
- Lambda・Fargateのサーバーレスコスト最適化（§4）
- RDS・DynamoDBのデータベースコスト最適化（§5）
- Cost Explorer・Budgets・CURによるコスト可視化（§6）
- VPC Endpoint・NAT Gateway・CloudFrontのネットワークコスト削減（§7）
1-1. D4の出題範囲と頻出テーマ
D4の問題は大きく次のカテゴリに分類できます。
どのカテゴリも「コスト最安」ではなく「要件を満たしながらコストを最小化する」設計力を問う構成です。
| カテゴリ | 代表サービス・概念 |
|---|---|
| コンピュート最適化 | EC2課金4モデル・Savings Plans・Spot・Compute Optimizer |
| ストレージ最適化 | S3ストレージクラス・ライフサイクル・Intelligent-Tiering |
| サーバーレス | Lambda・Fargate・API Gateway |
| データベース | RDS Reserved・DynamoDB課金・Aurora Serverless |
| コスト可視化 | Cost Explorer・Budgets・CUR |
| ネットワーク | VPC Endpoint・NAT Gateway・CloudFront |
2. EC2 課金モデル4種 — 状況別の最適選択
D4で最も頻出なのがEC2の課金モデルです。問題バンクでEC2が108回出現し、課金モデルの判断を問う問題が多数を占めます。4つのモデルを「どんな状況で選ぶか」という観点で整理しましょう。
2-1. オンデマンドインスタンス
オンデマンドは事前コミットなし・秒単位（最低60秒）課金のモデルです。
起動・停止のたびに課金される「使った分だけ払う」仕組みで、柔軟性は最も高い一方、単価は4モデル中で最も高くなります。
選ぶ状況: 短期・不規則・予測不可なワークロードが対象です。開発・テスト環境や、新しいアプリの立ち上げ期で需要が読めない場合に適しています。
選ばない状況: 1年以上継続して動かすシステムは、RIやSavings Plansの方がコスト効率は高くなります。
2-2. Reserved Instances（RI）
RIは1年または3年の利用をコミットすることで最大72%の割引を受けられるモデルです。
事前にインスタンスタイプ・リージョン・OSを指定して購入する形になります。
| 区分 | 内容 |
|---|---|
| 期間 | 1年（割引小）・3年（割引大）の選択 |
| 前払い | 全前払（割引最大）・一部前払・前払なし |
| Standard RI | 購入時に確定したインスタンスタイプ固定・Marketplace転売可 |
| Convertible RI | 期間中にインスタンスファミリー変更可・割引率はStandardより小 |
選ぶ状況: 1年以上安定して動かす本番ワークロード（Webサーバー・DBサーバー）が対象です。インスタンスタイプが確定しているサービスにはStandard RI、将来のスペック変更を見込む場合はConvertible RIを選びます。
- Standard RI: 割引率が大きい（最大72%）・インスタンスタイプ変更不可・Marketplace転売可
- Convertible RI: 割引率がやや小さい（最大54%）・インスタンスファミリー変更可・転売不可
「将来スペックアップを考えている」→ Convertible RI。「今のタイプで安定稼働している」→ Standard RIという判断軸で整理しましょう。
2-3. Savings Plans
Savings Plansは特定金額の時間利用をコミットすることで割引を受けるモデルです。
「1時間あたり10ドル以上使い続ける」という形でコミットするため、RIより柔軟性が高く、インスタンスタイプを問わず適用できます。
| 種類 | 適用対象 | 柔軟性 | 割引率 |
|---|---|---|---|
| Compute Savings Plans | EC2・Lambda・Fargate | 高（リージョン・OS問わず） | 最大66% |
| EC2 Instance Savings Plans | 特定リージョン・ファミリーのEC2 | 低 | 最大72% |
選ぶ状況: EC2とLambdaを組み合わせて使っており、どのサービスにコミットが乗るか分からない場合はCompute Savings Plansが適しています。特定リージョンのEC2ファミリーが固定で最大割引を求める場合は、EC2 Instance Savings Plansを選びます。
2-4. Spot インスタンス
SpotはAWSの空きキャパシティを活用したモデルで、最大90%の大幅割引が受けられます。
ただし、AWSがキャパシティを必要とした場合、2分前通知で中断されるリスクがあります。
選ぶ状況: 中断しても問題ないバッチ処理・ビッグデータ分析・CI/CDパイプライン・高性能コンピューティング（HPC）・機械学習の学習ジョブが対象です。チェックポイントで中断後に再開できるワークロード向きです。
選ばない状況: 中断できないWebサービス本番環境・RDS（RDSはSpot非対応）・重要なシングルインスタンスジョブには使えません。
- オンデマンド: 短期・予測不可・ユニークなワークロード
- RI: 1年以上安定稼働・インスタンスタイプが決まっている
- Savings Plans: EC2+Lambda+Fargateを横断してコミット・柔軟性重視
- Spot: 中断許容・バッチ・HPC・ML学習・最大コスト削減
試験では「24時間365日稼働が必要なWebアプリ → RI（オンデマンドより割引）」「週1回の夜間バッチ → Spot（中断可能・最安）」「EC2とFargateを両方使うが将来変動あり → Compute Savings Plans」といった状況判断が問われます。
2-5. AWS Compute Optimizer — Rightsizing 推奨
Compute Optimizerは、CloudWatchのメトリクスを機械学習で分析し、過大スペックのインスタンスを検出して最適サイズを推奨するサービスです。
EC2・EBS・Lambda・ECS on Fargateに対応しており、「今のインスタンスが適切かどうか」を自動的に診断します。
コスト削減の機会を可視化してくれるため、既存インフラのコスト最適化フェーズで活用します。
3. S3 ストレージクラスとライフサイクル
S3はD4で最も出現頻度が高い（119回）サービスです。データのアクセス頻度とコストのトレードオフを理解し、適切なストレージクラスを選ぶ設計力が問われます。
3-1. S3 ストレージクラス7種
S3には目的別に7つのストレージクラスがあります。
| ストレージクラス | 特徴 | 適用シナリオ |
|---|---|---|
| S3 Standard | 高耐久・低レイテンシ・高可用（99.99%） | 頻繁にアクセスするデータ |
| S3 Standard-IA | 低頻度アクセス・Standard比低コスト・取り出し料金あり | 月1回程度のアクセス |
| S3 One Zone-IA | 単一AZ格納・Standard-IAよりさらに低コスト | 可用性より低コスト優先（再作成可能なデータ） |
| S3 Glacier Instant Retrieval | アーカイブ・ミリ秒取得可 | 四半期に1回アクセス・即時取得必要 |
| S3 Glacier Flexible Retrieval | アーカイブ・分〜12時間で取得 | 年1〜2回アクセス・即時性不要 |
| S3 Glacier Deep Archive | 最低コスト・12〜48時間で取得 | 7年以上の長期アーカイブ・規制対応 |
| S3 Intelligent-Tiering | アクセスパターンに応じて自動移動 | アクセスパターン不明・変動が大きい |
S3 One Zone-IAはコストが低い反面、単一AZにしかデータが存在しません。そのためAZ障害時にデータが失われるリスクがあります。「再作成可能なデータ」（サムネイル・中間キャッシュ等）や「オリジナルが別の場所にあるバックアップコピー」に限って使う設計が安全です。
3-2. ライフサイクルポリシー
S3ライフサイクルポリシーを使うと、経過日数に応じて自動的にストレージクラスを遷移・削除できます。
たとえば「アップロードから30日後にStandard-IAへ移動、90日後にGlacier Flexible Retrievalへ移動、365日後に削除」といった設定が可能です。
主な移行制約:
– Standard-IA・One Zone-IAへの遷移は最小保存期間30日（30日以内の削除でも30日分の料金が発生）
– Glacier Flexible Retrievalへは最小90日の保存料金
– Deep Archiveへは最小180日の保存料金
試験では「コスト最小化のためにどのライフサイクルルールを設定するか」が問われます。アクセス頻度が下がるタイミングを見極めて自動遷移を設定することが正解パターンになります。
3-3. S3 Intelligent-Tiering
Intelligent-Tieringは、アクセスパターンを自動監視し、最適なストレージクラスに自動移動するサービスです。
オブジェクトごとに監視コストが発生しますが、アクセスパターンが不規則または予測不明なデータでは、手動ライフサイクル設定より効率的にコストを下げられます。
| アクセス頻度 | 自動移動先 |
|---|---|
| 30日以上アクセスなし | Infrequent Access層（Standard-IA相当） |
| 90日以上アクセスなし | Archive Instant Access層（Glacier Instant相当） |
| 180日以上アクセスなし（オプション有効時） | Deep Archive Access層 |
| アクセス発生 | Frequent Access層（Standard相当）に即時移動 |
4. サーバーレス コスト最適化 — Lambda・Fargate
サーバーレスは「サーバー管理不要」だけでなく、アイドル時間のコスト排除という観点でもコスト最適化に有効です。
4-1. Lambda のコスト構造
Lambdaは実行時間（1ミリ秒単位）× メモリサイズで課金され、リクエスト数に応じた従量課金です。
実行がない時間はコストが発生しない点は、EC2との大きな違いです。
コスト最適化のポイントは次の通りです。
- メモリ最適化: メモリを上げると実行が速くなるため、「メモリ × 時間」のトータルコストを最小化する適切なメモリサイズを見つけるチューニングが重要です
- Graviton2（arm64）対応: x86と同等またはそれ以上の性能を持ちながら約20%低コストで実行できます
- Provisioned Concurrency: コールドスタートを排除しますが、事前起動インスタンスの課金が常に発生します。コールドスタートの影響を受けてはいけないエンドポイントで選択的に使います
Lambda vs EC2 vs Fargate の選択軸:
| 選択肢 | 向いているケース |
|---|---|
| Lambda | ステートレス・ミリ秒〜秒単位の処理・実行頻度が低い・最大15分以内 |
| EC2 | 長時間処理・状態を持つ・RIで安定割引を享受したい |
| Fargate | コンテナベース・EC2管理なし・Spot連携でコスト削減 |
4-2. Fargate のコスト最適化
FargateはEC2インスタンスの管理が不要なコンテナ実行環境です。
Fargate Spotを使うと、EC2と同様にスポット料金（最大70%割引）でFargateタスクを実行できます。
ただし、SpotタスクはAWSの要求で中断される可能性があるため、重要な本番タスクには向きません。
試験では「コンテナを使いたいが、EC2の管理をしたくない・コストも削減したい」という要件に対して、ECS on Fargate Spotが回答パターンとして頻出です。
5. データベース コスト最適化 — RDS・DynamoDB
5-1. RDS のコスト最適化
RDSにもReserved DB Instances（RI）があり、EC2 RIと同様に1年または3年のコミットで最大69%割引を受けられます。
長期的に安定稼働するDBサーバーには積極的にReserved DB Instancesを検討します。
- マルチAZ: スタンバイインスタンスがあり可用性が高い。費用はシングルAZの約2倍
- シングルAZ: 単一AZでコスト半減。AZ障害時の復旧に時間がかかる
試験では「本番DBはマルチAZ必須」「開発・検証環境はシングルAZでコスト削減」という判断が求められます。コスト削減のためにマルチAZを外す選択は、本番環境では慎重な設計が必要です。
読み取りが多いワークロードではリードレプリカを活用します。
マスターへの書き込みはそのままに、読み取りリクエストをリードレプリカに振り分けることで、マスターのインスタンスサイズを下げてコストを削減できます。
5-2. DynamoDB のコスト最適化
DynamoDBには2つの課金モデルがあります。
| モデル | 課金方式 | 向いているケース |
|---|---|---|
| プロビジョンドキャパシティ | 読み書きキャパシティユニット（RCU/WCU）を事前指定 | トラフィックが安定・予測可能 |
| オンデマンドキャパシティ | 実際のリクエスト数に応じた課金 | トラフィックが不規則・急増する場合 |
Auto Scaling: プロビジョンドモードでAuto Scalingを使うと、トラフィックに応じてRCU/WCUを自動調整します。必要以上のキャパシティを常時プロビジョニングするコストを削減できます。
DynamoDB TTL（有効期限）: アイテムに有効期限を設定すると、期限切れのアイテムが自動削除されます。古いセッションデータ・一時データの削除にコストがかからず、ストレージコストを継続的に削減できます。
5-3. Aurora Serverless v2
Aurora Serverless v2は、トラフィックに応じてACU（Aurora Capacity Unit）を自動スケーリングするモードです。
最小ACUを0.5まで下げられるため、アクセスがほぼない夜間や開発環境でコストを大幅に削減できます。
注意点: Aurora Serverless v2はゼロスケール（ACU=0）には対応していません。
完全に停止させたい場合はクラスター自体を停止する必要があり、停止中もストレージ料金は発生します。
「夜間は完全無料にしたい」という要件にはServerless v2は適さないため、代わりにスナップショットから必要時に復元するパターンを検討します。
6. コスト可視化 — Cost Explorer・Budgets・CUR
コストを削減するには、まず「どこにコストが発生しているか」を把握する必要があります。D4ではコスト可視化ツールの使い分けが問われます。
6-1. AWS Cost Explorer
Cost Explorerは、AWSのコストと使用量を視覚的に分析するサービスです。
主な機能は次の通りです。
- コストのグラフ化: サービス別・リージョン別・タグ別にフィルタリングして過去コストを表示
- Rightsizing推奨: EC2インスタンスのCPU/メモリ使用率を分析し、縮小可能なインスタンスを特定
- Savings Plans推奨: 過去の使用パターンから最適なSavings Plansのコミット額を提案
- 予測: 今後12ヶ月先までのコスト予測
「今月どのサービスがコスト増加しているか分析したい」という用途にはCost Explorerが最適です。
6-2. AWS Budgets
AWS Budgetsは、コスト・使用量・Savings Plans利用率の目標を設定し、閾値超過時にアラートを送るサービスです。
| 予算タイプ | 用途 |
|---|---|
| コスト予算 | 月間コストが閾値を超えたらSNSアラート |
| 使用量予算 | 特定サービスの使用量（EC2時間数など）の監視 |
| Savings Plans予算 | Savings Plansのカバレッジ・利用率の目標値管理 |
| RI予算 | RIのカバレッジ・利用率の監視 |
「月間コストが予算の80%を超えたら担当者にメール通知したい」という用途に最適です。
6-3. AWS Cost and Usage Reports（CUR）
CURは、最も詳細なコスト・使用量データをS3に出力するサービスです。
1時間単位・リソース単位の細かい粒度で記録されるため、Cost ExplorerのUIでは見えない詳細分析が可能になります。
代表的な分析パターンは「CUR → S3 → Athena（SQL分析）→ QuickSight（可視化）」です。
「特定のEC2インスタンスIDのコストを時系列で集計したい」「タグ別の費用配賦を詳細に処理したい」という高度なニーズに対応します。
6-4. タグ付け戦略
コスト配分タグを活用すると、プロジェクト・部門・環境別にコストを集計できます。
リソース作成時に「Project=webapp」「Env=production」といったタグを付けておくことで、後からそのディメンションでコストをフィルタリング・分析できます。
- Cost Explorer: GUI・過去コストの分析・Rightsizing推奨・Savings Plans推奨
- Budgets: 予算設定・閾値超過アラート・コスト超過の予防的コントロール
- CUR: 最詳細データ・S3出力・Athenaで独自集計・費用配賦
試験では「コスト削減の機会を可視化したい → Cost Explorer」「月次予算を超過したらアラートを出したい → Budgets」「詳細な使用量データをSQLで分析したい → CUR + S3 + Athena」という使い分けが定番パターンです。
7. ネットワーク コスト最適化
ネットワークのデータ転送費は見落としがちなコストです。適切な設計でデータ転送費を大幅に削減できます。
7-1. VPC Endpoint — データ転送費の削減
VPC EndpointはEC2などのリソースがS3・DynamoDB等のAWSサービスにインターネットを経由せず直接接続するための仕組みです。
| 種別 | 対象サービス | 料金 |
|---|---|---|
| Gateway Endpoint | S3・DynamoDB | 無料 |
| Interface Endpoint | S3以外の多くのAWSサービス（SQS/SNS等） | 時間＋データ処理料金 |
重要: S3・DynamoDBへのGateway Endpointは無料です。
VPCからS3にNAT Gatewayを経由してアクセスするとNATのデータ処理料金が発生しますが、Gateway Endpointを使えばその費用がなくなります。
「EC2からS3へのデータ転送コストを削減するには」という問いに対して、S3 Gateway Endpoint（無料）が最適解になります。
7-2. NAT Gateway のコスト管理
NAT Gatewayはプライベートサブネットのリソースがインターネットへ出る際に使いますが、データ処理料金が発生します。
コスト削減の観点では次の点を押さえておきましょう。
- S3・DynamoDBへのアクセスはGateway Endpoint（無料）に切り替えることでNAT Gateway経由を排除できます
- 同一VPC内のリソース同士はプライベートIPで通信すれば、NAT Gatewayを経由しません
- NAT GatewayはAZごとに作成が推奨のため、AZをまたぐ通信はNATデータ転送費が追加でかかる点に注意します
7-3. CloudFront のコスト最適化
CloudFrontはコンテンツをエッジロケーションにキャッシュすることで、オリジン（S3・EC2）へのリクエスト・データ転送を削減します。
CloudFrontからS3へのオリジンフェッチはAWSネットワーク内通信のため、S3からインターネットへの転送費より低コストになります。
「静的コンテンツの配信コストを下げたい」という場合はS3 + CloudFrontの組み合わせが定石です。
「世界中のユーザーに低レイテンシで配信しつつ、オリジンのトラフィックも減らしたい」という要件でも、CloudFrontが最適解になります。
- コンピュート: 長期安定 → RI / Savings Plans、中断可能バッチ → Spot、短期不規則 → オンデマンド
- ストレージ: アクセス頻度に応じてS3ストレージクラスを選択・ライフサイクルで自動遷移
- サーバーレス: Lambda/Fargateでアイドルコスト排除・Fargate Spotでさらに削減
- データベース: Reserved DB InstancesでRDS割引・DynamoDB TTLで不要データ削除
- 可視化: Cost Explorerで分析、Budgetsでアラート、CURで詳細集計
- ネットワーク: S3/DynamoDBはGateway Endpoint（無料）・CloudFrontでオリジン通信削減
8. CertTrend LMS D4問題演習
D4「コスト最適化アーキテクチャ設計」の知識は、実際の問題形式を解くことで定着します。
CertTrend LMSには、S3・EC2・Savings Plans・Spot・Cost ExplorerなどD4の頻出サービスを網羅した80問を収録しています。
解説には「なぜその選択肢が誤りか」を丁寧に記載しており、暗記ではなく理解で解ける力を身につけられます。
9. 実務で深掘り — コスト最適化本番運用記事
SAA-C03の試験対策（広く浅く）を終えたら、実際のAWS運用で使うコスト最適化の深い知識を習得しましょう。
以下の本番運用記事では、Cost Explorer/Savings Plans/Spotの実装パターン、RI・Spot・Gravitonの詳細設計、FinOps運用モデル、S3ライフサイクルの実装を解説しています。