前回の記事では、EC2のストレージサービスであるEBSとAMIについて解説しました。本記事では、EC2の料金体系について詳しく解説します。オンデマンド、リザーブドインスタンス、スポットインスタンス、Savings Plansの4つの料金モデルを理解し、ワークロードに応じた最適な選択ができるようになりましょう。

EC2の料金モデル概要

EC2には、使用パターンやコミットメントに応じた複数の料金モデルが用意されています。適切な料金モデルを選択することで、オンデマンド料金と比較して最大90%のコスト削減が可能です。

4つの料金モデルの比較

graph TB
    subgraph "EC2料金モデル"
        OD[オンデマンド<br/>柔軟性重視]
        RI[リザーブドインスタンス<br/>長期契約で最大72%割引]
        SP[Savings Plans<br/>柔軟な長期契約で最大72%割引]
        Spot[スポット<br/>最大90%割引]
    end
    
    OD -->|契約なし| Flex[柔軟な利用]
    RI -->|1〜3年契約| Fixed[固定的な利用]
    SP -->|1〜3年契約| Flexible[柔軟な長期利用]
    Spot -->|中断あり| Interrupt[中断可能なワークロード]
料金モデル 割引率 契約期間 中断リスク 主な用途
オンデマンド なし(基準価格) なし なし 開発・テスト、一時的なワークロード
リザーブドインスタンス 最大72% 1年または3年 なし 定常稼働のワークロード
Savings Plans 最大72% 1年または3年 なし 柔軟性を保ちたい定常ワークロード
スポット 最大90% なし あり バッチ処理、耐障害性のあるワークロード

オンデマンドインスタンス

オンデマンドインスタンスは、EC2の基本的な料金モデルです。事前契約や前払いなしで、使用した分だけ秒単位(最低60秒)で課金されます。

オンデマンドの特徴

特徴 説明
課金単位 秒単位(最低60秒)
前払い 不要
契約期間 なし
柔軟性 最も高い
コスト 基準価格(最も高い)

オンデマンドが適しているケース

オンデマンドインスタンスは以下のようなケースで最適です。

  • 開発・テスト環境: 短期間だけ必要な環境
  • スパイク対応: 予測できない負荷への一時的な対応
  • 初期検証: 必要なリソース量が確定していない段階
  • 短期プロジェクト: 数週間程度の一時的なワークロード
graph LR
    subgraph "オンデマンドの使いどころ"
        A[需要が予測できない] --> OD[オンデマンド]
        B[短期間の利用] --> OD
        C[開発・テスト] --> OD
        D[スパイク対応] --> OD
    end

リザーブドインスタンス(RI)

リザーブドインスタンス(RI)は、1年または3年の期間でインスタンスの使用を契約することで、オンデマンド料金と比較して最大72%の割引を受けられる料金モデルです。

リザーブドインスタンスの種類

RIには「スタンダード」と「コンバーティブル」の2種類があります。

種類 最大割引率 インスタンスファミリー変更 OS・テナンシー変更 主な用途
スタンダードRI 最大72% 不可 不可 構成が確定している定常ワークロード
コンバーティブルRI 最大66% 可能 可能 柔軟性を残しつつコスト削減したい場合

支払いオプション

RIには3つの支払いオプションがあります。支払いオプションによって割引率が異なります。

支払いオプション 内容 割引率
全前払い 契約期間分を一括前払い 最大(最も割引される)
一部前払い 一部を前払い、残りを月払い 中間
前払いなし すべて月払い 最小(割引率は低め)

リザーブドインスタンスの適用

RIは購入すると、一致する属性(インスタンスタイプ、リージョン、プラットフォーム、テナンシー)を持つ実行中のインスタンスに自動的に適用されます。

graph TB
    subgraph "リザーブドインスタンスの適用"
        RI[購入したRI<br/>m5.xlarge / 東京リージョン]
        
        subgraph "実行中のインスタンス"
            I1[m5.xlarge<br/>東京リージョン ✓]
            I2[m5.large<br/>東京リージョン ✓]
            I3[c5.xlarge<br/>東京リージョン ✗]
        end
        
        RI -->|自動適用| I1
        RI -->|サイズ柔軟性| I2
    end

リージョンスコープのRIを購入した場合、同一インスタンスファミリー内であればサイズの柔軟性が適用され、異なるサイズのインスタンスにも割引が適用されます(Linux/UNIXのみ)。

リザーブドインスタンスが適しているケース

  • 24時間365日稼働するサーバー: Webサーバー、データベースサーバー
  • ベースライン負荷: 常に一定量のリソースが必要なワークロード
  • 本番環境: 構成が安定している本番システム

Savings Plans

Savings Plansは、1年または3年の期間で一定の使用量(USD/時間)をコミットすることで、最大72%の割引を受けられる柔軟な料金モデルです。RIと比較して、より柔軟にコスト削減を実現できます。

Savings Plansの種類

EC2に関連するSavings Plansには2種類あります。

種類 最大割引率 適用範囲 柔軟性
Compute Savings Plans 最大66% EC2、Fargate、Lambda 最も柔軟
EC2 Instance Savings Plans 最大72% 特定リージョンのEC2インスタンスファミリー RIと同等

Compute Savings Plans

Compute Savings Plansは最も柔軟なプランです。以下の変更を行っても、自動的に割引が適用されます。

  • インスタンスファミリーの変更(例: c5からm5へ)
  • インスタンスサイズの変更(例: xlargeから2xlargeへ)
  • リージョンの変更(例: 東京からバージニアへ)
  • OSの変更(例: LinuxからWindowsへ)
  • EC2からFargateやLambdaへの移行
graph TB
    subgraph "Compute Savings Plansの柔軟性"
        CSP[Compute Savings Plans<br/>$10/時間のコミット]
        
        subgraph "自動適用される"
            E1[EC2 c5.xlarge<br/>東京リージョン]
            E2[EC2 m5.2xlarge<br/>バージニアリージョン]
            F[Fargate タスク]
            L[Lambda 関数]
        end
        
        CSP --> E1
        CSP --> E2
        CSP --> F
        CSP --> L
    end

EC2 Instance Savings Plans

EC2 Instance Savings Plansは、特定のリージョンとインスタンスファミリーにコミットする代わりに、より高い割引率(最大72%)を提供します。

柔軟性 対応
アベイラビリティゾーン 変更可能
インスタンスサイズ 変更可能
OS 変更可能
テナンシー 変更可能
インスタンスファミリー 固定(変更不可)
リージョン 固定(変更不可)

Savings Plansとリザーブドインスタンスの違い

比較項目 Savings Plans リザーブドインスタンス
コミット対象 使用量(USD/時間) インスタンス数
柔軟性 高い(特にCompute) 低い
キャパシティ予約 なし あり(AZスコープの場合)
管理の複雑さ シンプル やや複雑

Savings Plansが適しているケース

  • ワークロードの変更が予想される: モダナイゼーションを計画中
  • マルチリージョン展開: 複数リージョンでEC2を使用
  • コンテナ・サーバーレス併用: EC2、Fargate、Lambdaを組み合わせて使用
  • シンプルな管理を重視: RIの複雑な管理を避けたい

スポットインスタンス

スポットインスタンスは、AWSクラウド内の未使用のEC2キャパシティを活用し、オンデマンド料金と比較して最大90%のコスト削減を実現できる料金モデルです。

スポットインスタンスの仕組み

スポットインスタンスは、AWSの余剰キャパシティを利用するため、キャパシティが不足すると2分前の通知を受けて中断される可能性があります。

sequenceDiagram
    participant User as ユーザー
    participant AWS as AWS
    participant Spot as スポットインスタンス
    
    User->>AWS: スポットインスタンスリクエスト
    AWS->>Spot: インスタンス起動
    AWS-->>User: 起動完了
    
    Note over AWS,Spot: キャパシティ不足発生
    
    AWS->>User: 中断通知(2分前)
    AWS->>Spot: インスタンス中断

スポットインスタンスの特徴

特徴 説明
割引率 最大90%(インスタンスタイプとリージョンにより変動)
中断リスク あり(2分前の通知)
入札 不要(現在は固定価格)
価格変動 需給に応じて変動(ただし請求は起動時の価格)

スポットインスタンスの中断対策

スポットインスタンスの中断に備えて、以下の対策を講じることが重要です。

対策 説明
複数インスタンスタイプ 異なるインスタンスタイプを混在させる
複数AZ 複数のアベイラビリティゾーンに分散
チェックポイント 処理の途中経過を定期的に保存
中断通知の監視 メタデータサービスで中断通知を監視

スポットインスタンスが適しているケース

  • バッチ処理: データ分析、画像処理、トランスコーディング
  • CI/CDパイプライン: ビルド、テスト実行
  • ビッグデータ処理: EMR、Spark、Hadoop
  • コンテナワークロード: ECS、EKSのワーカーノード
  • 機械学習: モデルトレーニング
graph TB
    subgraph "スポットインスタンスの活用例"
        Spot[スポットインスタンス]
        
        Spot --> Batch[バッチ処理<br/>中断しても再実行可能]
        Spot --> CICD[CI/CD<br/>ビルド・テスト]
        Spot --> ML[機械学習<br/>チェックポイント対応]
        Spot --> Container[コンテナ<br/>自動復旧]
    end

スポットインスタンスに適さないケース

以下のワークロードにはスポットインスタンスは推奨されません。

  • リアルタイム処理を行うWebサーバー
  • ステートフルなデータベースサーバー
  • 中断が許容されないミッションクリティカルなアプリケーション

インスタンスの停止と終了の違い

EC2インスタンスには「停止(Stop)」と「終了(Terminate)」の2つの状態があり、料金への影響が異なります。

停止と終了の比較

項目 停止(Stop) 終了(Terminate)
EC2インスタンス料金 課金停止 課金停止
EBSボリューム 保持される(課金継続) 設定により削除
Elastic IP 保持される(課金継続) 設定により解放
プライベートIPアドレス 保持される 解放される
インスタンスID 保持される 解放される
再起動 可能 不可
stateDiagram-v2
    [*] --> running: 起動
    running --> stopped: 停止
    stopped --> running: 開始
    running --> terminated: 終了
    stopped --> terminated: 終了
    terminated --> [*]
    
    note right of running: EC2料金課金中
    note right of stopped: EC2料金停止<br/>EBS料金は継続
    note right of terminated: 全料金停止<br/>データ消失の可能性

停止時の注意点

インスタンスを停止しても、以下のリソースには課金が継続します。

  • EBSボリューム: ストレージ容量に対する課金
  • Elastic IP: インスタンスに関連付けられていないEIPは課金対象
  • EBSスナップショット: 保存されているスナップショットのストレージ料金

終了保護

誤ってインスタンスを終了してしまうことを防ぐため、「終了保護」を有効にすることを推奨します。

1
2
3
4
# AWS CLIでの終了保護の有効化
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --disable-api-termination

コスト最適化のベストプラクティス

EC2のコストを最適化するためのベストプラクティスを紹介します。

1. 料金モデルの組み合わせ

単一の料金モデルに依存せず、ワークロードの特性に応じて複数のモデルを組み合わせます。

graph TB
    subgraph "料金モデルの組み合わせ例"
        Base[ベースライン負荷<br/>Savings Plans / RI]
        Normal[通常負荷<br/>オンデマンド]
        Spike[スパイク<br/>スポット + オンデマンド]
        Batch[バッチ処理<br/>スポット]
    end
    
    Base -->|常時稼働| Stable[安定した割引]
    Normal -->|柔軟な対応| Flex[柔軟性確保]
    Spike -->|コスト効率| Cost[コスト最適化]
    Batch -->|大幅割引| Save[最大90%削減]

2. 適切なインスタンスサイズの選択

インスタンスサイズが大きすぎると無駄なコストが発生します。CloudWatchメトリクスを監視して、適切なサイズに調整しましょう。

メトリクス 確認ポイント 対応
CPU使用率 平均10%以下 サイズダウンを検討
メモリ使用率 平均20%以下 サイズダウンを検討
ネットワーク 帯域を使い切っている サイズアップまたはタイプ変更

3. 不要なリソースの削除

使用していないリソースを定期的に確認し、削除します。

リソース 確認方法 削減効果
停止中のインスタンス EC2ダッシュボードで確認 EBSコスト削減
未使用のEBSボリューム 「available」状態のボリューム ストレージコスト削減
古いスナップショット 作成日時を確認 スナップショットコスト削減
未使用のElastic IP 関連付けられていないEIP IP課金削減

4. AWS Cost Explorerの活用

AWS Cost Explorerを使用して、コストの推移と内訳を可視化します。

  • 使用率レポート: RIとSavings Plansの使用率を確認
  • 推奨事項: AWSからのコスト削減推奨を確認
  • コスト配分タグ: プロジェクトやチーム別にコストを追跡

5. Auto Scalingの活用

負荷に応じてインスタンス数を自動調整することで、必要以上のリソースを維持するコストを削減します。

graph LR
    subgraph "Auto Scalingによるコスト最適化"
        Low[低負荷時<br/>2インスタンス]
        Normal[通常時<br/>4インスタンス]
        High[高負荷時<br/>8インスタンス]
    end
    
    Low -->|負荷増加| Normal
    Normal -->|負荷増加| High
    High -->|負荷減少| Normal
    Normal -->|負荷減少| Low

料金モデルの選択フローチャート

ワークロードに適した料金モデルを選択するためのフローチャートです。

flowchart TD
    Start[ワークロードの分析] --> Q1{中断を許容できるか?}
    
    Q1 -->|はい| Q2{バッチ処理・開発用途か?}
    Q1 -->|いいえ| Q3{使用量は予測可能か?}
    
    Q2 -->|はい| Spot[スポットインスタンス<br/>最大90%割引]
    Q2 -->|いいえ| Q3
    
    Q3 -->|はい| Q4{1年以上継続利用するか?}
    Q3 -->|いいえ| OnDemand[オンデマンド<br/>柔軟性重視]
    
    Q4 -->|はい| Q5{構成変更の可能性は?}
    Q4 -->|いいえ| OnDemand
    
    Q5 -->|高い| ComputeSP[Compute Savings Plans<br/>最大66%割引]
    Q5 -->|低い| Q6{キャパシティ予約が必要か?}
    
    Q6 -->|はい| RI[リザーブドインスタンス<br/>最大72%割引]
    Q6 -->|いいえ| EC2SP[EC2 Instance Savings Plans<br/>最大72%割引]

まとめ

本記事では、EC2の料金体系とコスト最適化について解説しました。

  • オンデマンド: 柔軟性が最も高いが、コストも最も高い
  • リザーブドインスタンス: 長期契約で最大72%割引、キャパシティ予約も可能
  • Savings Plans: 柔軟な長期契約で最大72%割引、管理がシンプル
  • スポット: 最大90%割引だが、中断リスクあり

コスト最適化のポイントは以下の通りです。

  1. ワークロードの特性を分析し、適切な料金モデルを選択する
  2. 複数の料金モデルを組み合わせて最適化する
  3. 定期的にリソースの使用状況を確認し、不要なリソースを削除する
  4. Cost Explorerを活用してコストを可視化・分析する

次回は、スケーラブルなオブジェクトストレージサービスであるS3について解説します。バケットの作成からアクセス制御、ストレージクラスの使い分けまで、S3の主要機能を学んでいきましょう。

参考リンク