はじめに：On-Demand・Savings Plans・Reservedの違いと実務での選び方
AWSを利用する上で避けて通れないのがコスト管理です。
AWSにはさまざまな料金モデルがありますが、特に重要なのが次の3つです。
- On-Demand
- Savings Plans
- Reserved Instances
これらを正しく理解していないと、
- 想定よりもコストが高くなる
- 割引を活用できない
- 将来的な構成変更が難しくなる
といった問題が発生します。
この記事では、AWSのコスト設計を実務で行う際の考え方として、
- AWS料金モデルの基本
- 割引モデルが存在する理由
- 実務で使える判断フレームワーク
- アーキテクチャ別のコスト戦略
を体系的に解説します。
AWS料金モデルの基本
まずはAWSの主要な料金モデルを整理します。
| モデル | 概要 | 割引率 | 柔軟性 |
|---|---|---|---|
| On-Demand | 従量課金 | なし | 高い |
| Savings Plans | 利用金額コミット | 最大約66% | 中 |
| Reserved Instances | リソース予約 | 最大約72% | 低 |
イメージとしては次の関係になります。
柔軟性重視
On-Demand
↓
Savings Plans
↓
Reserved
コスト最適
つまり
- 柔軟性を取ると高い
- 長期利用を約束すると安い
という構造になっています。
なぜAWSには割引モデルがあるのか
AWSはクラウドサービスですが、実体は巨大なデータセンターです。
そのため、AWS側には次の課題があります。
- 将来の利用量が読めない
- キャパシティ計画が難しい
そこでAWSは
長期利用を約束する代わりに割引を提供する
というモデルを採用しています。
| モデル | AWS側のメリット |
|---|---|
| Savings Plans | 利用量の予測 |
| Reserved | キャパシティ確保 |
つまり割引モデルは
AWSとユーザーの双方にメリットがある仕組み
と言えます。
AWSコスト最適化の基本思想
AWSのコスト設計では、負荷を次の2種類に分けて考えます。
総負荷
├ ベースライン負荷
└ 変動負荷
ベースライン負荷
常に存在する処理
例
- Webサーバー
- DB
- コンテナ基盤
変動負荷
トラフィックによって変動する処理
例
- Auto Scaling
- イベント処理
これを料金モデルに当てはめると次のようになります。
| 負荷タイプ | 推奨モデル |
|---|---|
| ベースライン負荷 | Savings Plans / Reserved |
| 変動負荷 | On-Demand |
実務で使えるAWS料金モデルの判断フレームワーク
AWSコスト設計では、次の5つの観点で判断すると整理しやすくなります。
① 常時稼働か
② 処理の性質
③ 負荷の安定性
④ 構成変更の可能性
⑤ サービス特性
順番に見ていきます。
① 常時稼働かどうか
最初に判断するのは
常時稼働か、イベント駆動か
です。
| 状態 | 推奨 |
|---|---|
| 常時稼働 | EC2 / コンテナ |
| イベント駆動 | サーバーレス |
常時稼働の例
- Webサーバー
- DB
- コンテナ基盤
イベント駆動の例
- API
- バッチ
- 非同期処理
イベント駆動の場合は、サーバーレスの方がコスト効率が高いケースが多いです。
② 処理の性質
処理時間も重要な判断材料です。
| 処理タイプ | 推奨 |
|---|---|
| 短時間処理 | Lambda |
| 長時間処理 | EC2 |
| 常時接続 | EC2 |
例えば
- API処理 → Lambda
- バッチ処理 → Lambda
- ゲームサーバー → EC2
となることが多いです。
③ 負荷の安定性
次に、ワークロードの安定性を確認します。
| 負荷 | 推奨 |
|---|---|
| 大きく変動 | On-Demand |
| 概ね安定 | Savings Plans |
| 完全固定 | Reserved |
例えば
変動負荷
- キャンペーンサイト
- 新規サービス
安定負荷
- 社内システム
- Webサービス
④ 構成変更の可能性
クラウドではインスタンス変更が頻繁に発生します。
| 変更頻度 | 推奨 |
|---|---|
| 高い | Savings Plans |
| 低い | Reserved |
Savings Plansは
- インスタンスタイプ変更可能
- リージョン変更可能
という特徴があります。
そのため最近のAWS設計では
基本はSavings Plans
というケースが多くなっています。
⑤ サービス特性
最後にサービス特性を確認します。
| サービス | 推奨 |
|---|---|
| EC2 | Savings Plans |
| ECS / EKS | Savings Plans |
| Lambda | On-Demand |
| DynamoDB | On-Demand |
| RDS | Reserved |
特にDBは
- 長期稼働
- 構成変更が少ない
ためReservedが適しています。
アーキテクチャ別コスト戦略
実務では、多くのシステムが次のパターンに分類されます。
| パターン | 構成 |
|---|---|
| Webサーバー型 | EC2 + ALB |
| DB中心型 | RDS |
| コンテナ基盤型 | ECS / EKS |
| サーバーレスAPI型 | Lambda |
| イベント処理型 | S3 + Lambda |
Webサービス
構成例
ALB
EC2
Auto Scaling
RDS
コスト戦略
EC2 → Savings Plans
RDS → Reserved
スケール → On-Demand
コンテナ基盤
構成例
ALB
ECS / EKS
コスト戦略
Compute Savings Plans
サーバーレスAPI
構成例
API Gateway
Lambda
DynamoDB
コスト戦略
基本：On-Demand
サーバーレスは
- リクエスト数
- 実行時間
で課金されるため、低トラフィックでは非常に安価になります。
実務で使われるAWSコスト最適化ルール
割引モデルを使うときは、次のルールがよく使われます。
3ヶ月観測ルール
過去3ヶ月の利用量
を分析してから割引を購入します。
70%コミットルール
ベース負荷の70%
だけコミットします。
理由は
- トラフィック変動
- 将来の構成変更
への対応です。
まとめ
AWSのコスト設計は、次の順番で考えることが重要です。
① アーキテクチャ設計
② ワークロード特性
③ 料金モデル選択
④ 割引適用
一般的には次のような構成になります。
| ワークロード | 推奨 |
|---|---|
| イベント駆動 | サーバーレス |
| EC2基盤 | Savings Plans |
| DB | Reserved |
| 変動負荷 | On-Demand |
コスト最適化の本質は「料金モデル」ではなく「アーキテクチャ設計」にあります。
適切な構成を選ぶことが、AWSコスト最適化の最も重要なポイントです。