はじめに：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コスト最適化の最も重要なポイントです。