EC2料金モデル完全比較 — On-Demand/Reserved/Spot/Savings Plans

EC2の4つの料金モデル

モデル	割引率	コミット	中断リスク	適用先
On-Demand	なし（定価）	なし	なし	短期・予測不能なワークロード
Reserved Instance	最大72%割引	1〜3年	なし	常時稼働の安定したワークロード
Savings Plans	最大66%割引	1〜3年	なし	柔軟なコミット（EC2/Fargate/Lambda対応）
Spot Instance	最大90%割引	なし	あり（2分前通知）	中断耐性のあるワークロード

On-Demand

最もシンプルな料金体系。使った分だけ秒単位で課金される。

用途:
- 短期または不規則なワークロード
- 新しいアプリケーションの開発・テスト
- コミット量を判断できない段階での運用

Reserved Instance (RI)

特定のインスタンスタイプ・リージョン・テナンシーをコミットして割引を受ける。

タイプの選択:
Standard RI:   最大72%割引、変更不可（インスタンスタイプ等）
Convertible RI: 最大54%割引、条件を変更可能（タイプ変更等）

支払いオプション:
All Upfront:   全額前払い（最大割引）
Partial Upfront: 一部前払い
No Upfront:    前払いなし（割引率は低い）

スコープ:
Regional RI: リージョン内のAZ間で柔軟に適用
Zonal RI:   特定AZに固定（インスタンスキャパシティを予約できる）

RIはEC2以外のサービス（RDS, ElastiCache等）にも存在する。

Savings Plans

柔軟性が高いRIの後継。特定の時間あたり使用量（$/時間）をコミットする。

Compute Savings Plans:
  - EC2（全タイプ・全リージョン・全OS・全テナンシー）
  - Fargate
  - Lambda
  - 最大66%割引（最も柔軟）

EC2 Instance Savings Plans:
  - 特定リージョン・インスタンスファミリーのEC2のみ
  - 最大72%割引（RIと同等）
  - OS・サイズ・AZは変更可能

SageMaker Savings Plans:
  - SageMaker専用

RIとSavings Plansの使い分け

Reserved Instance が優れる点:
  - Zonal RIでキャパシティ予約が可能
  - 既存のRI購入システムとの互換性

Savings Plans が優れる点:
  - インスタンスタイプ変更が自由（Compute SP）
  - FargateやLambdaにも適用
  - 管理が容易

Spot Instance

未使用EC2キャパシティを利用するため最大90%割引だが、AWSがキャパシティを必要とした場合に2分前通知で中断される。

# Spot Instanceのリクエスト
aws ec2 request-spot-instances \
  --instance-count 5 \
  --type one-time \
  --launch-specification '{
    "ImageId": "ami-xxx",
    "InstanceType": "m5.xlarge",
    "KeyName": "my-key",
    "SpotPrice": "0.2"
  }'

# Spot Fleet（複数タイプから最安値を選択）
aws ec2 request-spot-fleet \
  --spot-fleet-request-config '{
    "SpotPrice": "0.5",
    "TargetCapacity": 10,
    "LaunchSpecifications": [
      {"InstanceType": "m5.xlarge", "SpotPrice": "0.2"},
      {"InstanceType": "m4.xlarge", "SpotPrice": "0.19"},
      {"InstanceType": "r5.large", "SpotPrice": "0.15"}
    ],
    "AllocationStrategy": "lowestPrice"
  }'

Spot中断への対策

中断耐性のあるワークロード:
- バッチ処理（途中から再開可能）
- 機械学習訓練（チェックポイント保存）
- Webクローリング
- CIパイプライン
- 画像・動画処理

中断への対応策:
1. Spot中断通知（2分前）をポーリング or EventBridgeで検知
2. チェックポイントをS3に保存
3. Auto ScalingグループでOn-Demandとのミックス設定

# Spot中断通知の検知
import requests

token = requests.put(
    'http://169.254.169.254/latest/api/token',
    headers={'X-aws-ec2-metadata-token-ttl-seconds': '21600'}
).text

response = requests.get(
    'http://169.254.169.254/latest/meta-data/spot/termination-time',
    headers={'X-aws-ec2-metadata-token': token}
)

if response.status_code == 200:
    print(f"Spot中断予告: {response.text}")
    # チェックポイント保存・クリーンアップ処理

Auto Scalingとの組み合わせ

# Auto Scaling混合インスタンス設定（On-Demand + Spot）
MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-xxx
    Overrides:
      - InstanceType: m5.xlarge
      - InstanceType: m4.xlarge
      - InstanceType: m5a.xlarge
  InstancesDistribution:
    OnDemandBaseCapacity: 2        # 最低2台はOn-Demand
    OnDemandPercentageAboveBaseCapacity: 20  # 追加分の20%はOn-Demand
    SpotAllocationStrategy: capacity-optimized  # 中断確率が低いプールを優先

コスト最適化の推奨戦略

ベースライン（常時稼働分）: Savings Plans or RI
変動分（スケーリング）:     Spot Instance（中断耐性あり）or On-Demand
バッチ処理:               Spot Instance
開発環境:                 Spot Instance or スケジュールRDS停止

試験頻出ポイント

シナリオ	回答
中断してはいけないワークロードでコスト削減	Reserved InstanceまたはSavings Plans
バッチ処理でコスト最小化	Spot Instance
キャパシティを予約したい	Zonal Reserved Instance
FargateとEC2に同じコミットを適用	Compute Savings Plans
Spot中断通知のタイミング	2分前

まとめ

EC2のコスト最適化はOn-DemandとSpotの組み合わせが基本だ。安定したベースラインにSavings PlanまたはRI、変動部分とバッチにSpotを使うことで最大70〜80%のコスト削減が可能だ。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感