前回の記事では、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
endEC2 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スナップショット: 保存されているスナップショットのストレージ料金
終了保護
誤ってインスタンスを終了してしまうことを防ぐため、「終了保護」を有効にすることを推奨します。
|
|
コスト最適化のベストプラクティス
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%割引だが、中断リスクあり
コスト最適化のポイントは以下の通りです。
- ワークロードの特性を分析し、適切な料金モデルを選択する
- 複数の料金モデルを組み合わせて最適化する
- 定期的にリソースの使用状況を確認し、不要なリソースを削除する
- Cost Explorerを活用してコストを可視化・分析する
次回は、スケーラブルなオブジェクトストレージサービスであるS3について解説します。バケットの作成からアクセス制御、ストレージクラスの使い分けまで、S3の主要機能を学んでいきましょう。