はじめに
AWSのコストが高くなっていませんか？特にデータベースなどのリソースを長期間使い続ける場合、リザーブドインスタンス（Reserved Instances） を活用することで、最大75%のコスト削減が可能です。
本記事では、AWS Black Beltセミナーの内容を基に、リザーブドインスタンスについて初心者向けに解説します。
1. リザーブドインスタンスとは？
基本概念
リザーブドインスタンスは、コミットメント型の割引プラン です。簡単に言うと：
「1年間または3年間、このサービスを使い続けます」と約束する代わりに、通常料金（オンデマンド料金）から大幅な割引を受けられる
という仕組みです。
割引率の目安
- 1年間コミット: 約30～40%の割引
- 3年間コミット: 最大75%の割引
リザーブドインスタンス vs セービングスプラン
AWSのコミットメント型割引には、主に2つのオプションがあります：
| 項目 | セービングスプラン | リザーブドインスタンス |
|---|---|---|
| 対象 | EC2など計算リソース向け | EC2、RDS、ElastiCache等広範囲 |
| 柔軟性 | 高い（インスタンスファミリー変更可） | 低い（属性が固定される傾向） |
| 推奨用途 | コンピューティング | データベースなど安定的なワークロード |
ポイント: EC2は柔軟性が高いセービングスプランを、RDSなどは条件が固定されやすいリザーブドインスタンスを使う傾向があります。
2. どんなワークロードに適しているか？
リザーブドインスタンスは、以下のような特徴を持つワークロードに最適です：
✅ 適している例
- データベース（RDS、DynamoDB等）
- キャッシュレイヤー（ElastiCache）
- 本番環境の基幹システム
- リソース変動が少ない環境
❌ 適さない例
- テスト環境（スケール変動が頻繁）
- 一時的なジョブ（SpotInstancesの方が良い）
- サーバーレスメインの環境
簡潔に言うと: 「この1年間、ほぼ同じ構成で使い続ける」という確実性があれば、リザーブドインスタンス購入を検討しましょう。
3. リザーブドインスタンスの仕組み（重要！）
誤解しやすいポイント
多くの人が勘違いしていることですが、リザーブドインスタンスは物理的なリソースではありません。
【重要な理解】
購入したリザーブドインスタンス
↓（自動的に適用）
条件に合致した起動中のリソース
↓
割引料金で利用できる
つまり、「この条件のリソースを割引料金で使う権利」 を購入しているのです。
具体例
RDSの例で説明します：
購入内容: MySQL R8G 2XLarge × 1台分
適用される場合:
- ✅ 起動中の MySQL R8G 2XLarge → 割引料金で利用
- ✅ PostgreSQL R8G 2XLarge → 割引料金で利用（条件一致）
適用されない場合:
- ❌ MySQL T4G XLarge → オンデマンド料金のまま（インスタンスファミリーが異なる）
- ❌ 別のリージョンのMysql R8G 2XLarge → オンデマンド料金のまま（リージョンが異なる）
重要: 条件が合わなくても、購入済みのリザーブドインスタンスは課金されます。これが購入計画が重要な理由です。
4. 対応サービスと特徴
リザーブドインスタンスが使えるサービス一覧
以下のサービスでリザーブドインスタンスが利用可能です：
- EC2 - 仮想マシン
- RDS - 管理型データベース
- ElastiCache - キャッシュサービス
- DynamoDB - NoSQLデータベース（「リザーブドキャパシティ」と呼ばれます）
- Redshift - データウェアハウス
- OpenSearch Service - 検索・分析
- MemoryDB - インメモリデータベース
サービスごとの違い
各サービスの重要な特徴を表にまとめました：
| サービス | 柔軟性 | 特記事項 |
|---|---|---|
| EC2 | 中程度 | 変更・交換・マーケットプレス売却が可能 |
| RDS | あり | エンジン・エディション指定が必須 |
| ElastiCache | あり（10月以降） | Redis/Memcached で異なる正規化係数 |
| DynamoDB | なし | キャパシティユニット単位の購入 |
| Redshift | なし | サイズ固定 |
5. RDSを例にした詳しい設定方法
RDSリザーブドインスタンスの構成パターン
RDSでは、デプロイオプションを選ぶ必要があります：
【シングルAZ構成を購入】
- r8g.large × 1台分を購入
→ シングルAZのr8g.largeに適用される
→ 正規化係数：1
【マルチAZ構成を購入】
- r8g.large × 1台分を購入
→ 実はシングルAZ2台分に相当
→ 正規化係数：2
→ つまり、マルチAZ構成ではシングルAZ2台購入する必要がある
【Aurora クラスタ（マルチAZDB構成）を購入】
- r8g.large × 1台分を購入
→ シングルAZ3台分に相当（ライター1台+リーダー2台）
→ または、マルチAGDB 1台 + シングルAZ 1台分を購入
注意: マルチAZ構成を検討している場合は、購入するリザーブドインスタンスの台数計算に注意してください！
6. 「サイズの柔軟性」について
サイズの柔軟性とは？
RDSやElastiCacheなど、一部のサービスでは、購入したリザーブドインスタンスを異なるサイズのリソースに適用できます。この仕組みを 「サイズの柔軟性」 と呼びます。
正規化係数の概念
各インスタンスサイズには「正規化係数」が定義されています：
【例：RDS MySQL シングルAZ】
small: 正規化係数 = 1
medium: 正規化係数 = 2
large: 正規化係数 = 4
2xlarge: 正規化係数 = 16
【意味】
- small 4台分 = large 1台分
- small 16台分 = 2xlarge 1台分
具体的な適用例
【購入内容】
large × 8台分（正規化係数合計：8 × 4 = 32）
【適用可能なパターン】
- large 8台に適用 ✅
- 2xlarge 2台に適用 ✅（2 × 16 = 32）
- large 4台 + 2xlarge 1台に適用 ✅（4×4 + 1×16 = 32）
- large 1台 + medium 14台に適用 ✅（1×4 + 14×2 = 32）
Aurora IOOptimizedの注意点
AuroraのIOOptimized構成では、通常構成の30%分、正規化係数が増加します：
【例：small サイズ】
- 標準構成: 正規化係数 = 1
- IOOptimized: 正規化係数 = 1.3
【購入時の注意】
購入数は整数のみ対応なので、必要に応じて調整が必要
例：xlarge IOOptimized 5台が必要な場合
- 計算: 10.4 × 5 = 52
- 購入方法: 2xlarge 3台（48）+ large 1台（4）= 計52
7. 支払いオプションの選択
3つの支払い方法
リザーブドインスタンスでは、3つの支払い方法から選べます：
| 支払い方法 | 支払いタイミング | 割引率 | 用途 |
|---|---|---|---|
| 全額前払い | 開始時に一括払い | 最高 | キャッシュが豊富な場合 |
| 一部前払い | 開始時に約半額 + 月額 | 中程度 | バランス型 |
| 前払いなし | 月額のみ | 低い | キャッシュが限定的な場合 |
サービスごとの対応状況
全てのサービスが3つの支払い方法に対応しているわけではありません：
【RDS】
- 1年: 全額前払い、一部前払い、前払いなし ✅
- 3年: 全額前払い、一部前払いのみ（前払いなし非対応）
【DynamoDB】
- 一部前払いのみ対応
【その他のサービス】
- サービスごとに異なる
重要: 購入前に、対象サービスの支払い方法を必ず確認してください！
8. 購入計画の立て方（最も重要）
ステップ1：リソース調査
まず、どのリソースがリザーブドインスタンス対象になるか把握します。
# RDSの例：リソース一覧をCLIで取得
aws rds describe-db-instances --region ap-northeast-1 \
--query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier, Engine:Engine, DBInstanceClass:DBInstanceClass}'
ステップ2：ヒアリング
リソース所有者に以下の質問を行います：
「このリソースは、今後1年間、サイズやエンジンを変更することなく、使い続けますか？」
この答えが「Yes」であれば、リザーブドインスタンス購入の候補になります。
ステップ3：購入条件の決定
以下の3点を決めます：
3-1. 購入アカウント
- 推奨: リソースを所有する個別のメンバーアカウント
- 理由: 管理が容易で、更新時に対応がしやすい
- 避けた方が良い: 管理アカウント一括購入（管理が複雑になる可能性）
3-2. タイプ・オプション
- インスタンスファミリー: ヒアリング結果から決定
- エンジン: ヒアリング結果から決定
- 支払いオプション: 経理部門と相談して決定
3-3. サイズと購入台数
【基本原則】
現在のリソースサイズで購入する
【例外パターン】
- 1年後にサービス終了予定 → 小さめを購入
例：2xlarge → xlarge に計画されている場合
→ large × 2台分を購入する（リスク軽減）
- 今後スケールアップする予定 → 多めに購入
ステップ4：損益分岐点の確認（オプション）
購入する前に、「いつから得になるか」を計算します：
【例：RDS MySQL r8g.large シングルAZ 1台】
- オンデマンド料金: 月額$200
- リザーブドインスタンス（1年全額前払い）: 年額$1,500
計算:
- 損益分岐点 = 1,500 ÷ 200 = 7.5ヶ月
- つまり、7.5ヶ月以上使うならお得！
推奨:
損益分岐点が8～9ヶ月程度なら購入を検討する価値がある
大切なポイント
「完璧な調査」を目指さず、大きなコストから始める
全てのリソースを完璧に調査するのに時間がかかってしまうと、その間は割引が全く受けられません。コストが大きいアカウント・リソースから小さく始めることをお勧めします。
9. 購入手順（マネジメントコンソール）
注意事項（重要！）
- リザーブドインスタンスはキャンセルできません → 購入前の確認が必須
- 自動更新機能がない → 有効期限を記録し、手動で更新する必要あり
- サービスによって画面が異なる → 購入前に確認しましょう
EC2の購入例
1. EC2ダッシュボード → リザーブドインスタンス
2. 以下をチェック:
- プラットフォーム（Windows/Linux など）
- インスタンスタイプ
- スコープ（リージョナル/ゾーン）
- テナンシー
3. 「右上のキャパシティ予約」でゾーンRIも表示
4. 数量決定後、カートでレビュー
5. レビュー画面で「条件の誤りがないか」を確認
6. 購入
RDSの購入例
1. RDSダッシュボード → リザーブドインスタンス
2. 以下を選択:
- DBエンジン（MySQL/PostgreSQL等）
- ライセンス（LI/BYOL）
- デプロイ（シングルAZ/マルチAZ）
- インスタンスクラス
- 期間（1年/3年）
- 支払いオプション
3. 「次へ」でレビュー画面に遷移
4. 最終確認後、購入
大量購入時はCLIを推奨
複数のリザーブドインスタンスを購入する場合、CLIを使うと効率的です：
# ステップ1：オファリングIDを取得
aws rds describe-reserved-db-instances-offerings \
--db-instance-class db.r8g.large \
--engine mysql \
--multi-az \
--duration 31536000 \
--filters Name=db-instance-family,Values=db.r8g \
--region ap-northeast-1
# ステップ2：リザーブドインスタンスを購入
aws rds purchase-reserved-db-instances-offering \
--reserved-db-instances-offering-id <オファリングID> \
--db-instance-count 3 \
--region ap-northeast-1
10. 購入後のモニタリング（重要）
モニタリング指標1：使用率（Utilization）
定義: リザーブドインスタンスがどれだけ利用されているか
使用率 = （リザーブドインスタンスが適用された時間）/ （コミット期間）
理想: 100% に近い
許容: 損益分岐点を下回らなければ損していない
確認方法:
AWS管理コンソール
→ 請求とコスト管理
→ 使用状況レポート
→ グラフで確認（サービスフィルターを設定）
モニタリング指標2：カバレッジ（Coverage）
定義: リザーブドインスタンスでカバーされている割合
カバレッジ = （リザーブドインスタンスで支払った料金）/ （支払うべき料金 on-demand）
例：RDSのカバレッジが50%
= RDS料金の50%がリザーブドインスタンスでカバーされている
注意点:
- 業界標準やベンチマークはない（ワークロードによって異なる）
- ミッションクリティカル: 90%近い
- サーバーレスメイン: 0%に近いこともある
- 目標値はワークロード特性で判断
モニタリング指標3：コスト削減額
確認方法:
AWS管理コンソール
→ 請求とコスト管理
→ 使用状況レポート（上部）
→ 「削減効果」セクション
※ CSVダウンロード可能
AWS Budgetsでアラート設定
使用率・カバレッジが想定外の値になったときに気づけるよう、アラートを設定します：
1. AWS管理コンソール
→ 請求とコスト管理
→ Budgets
2. 予算を作成
- 使用率が目標値を下回った場合に通知
- カバレッジが低下した場合に通知
コストエクスプローラーでの分析
フィルター設定:
- 購入タイプ: "Reserved" を選択
- 使用タイプ: "Heavy Utilization" など
- 詳細オプション: "償却コスト" を選択
※ 毎月の料金比率を正確に確認できます
11. CUR（Cost and Usage Report）での詳細分析
CURを使う場面
コストエクスプローラー: 簡易的な分析
CUR: 詳細な分析（チャージバック、リソース単位での確認）
重要な列の説明
| 列名 | 意味 |
|---|---|
| lineItemType | "Reservation" = 購入時, "Usage" = 月額 |
| discount | リザーブドインスタンスの割引 |
| effectiveCost | 実質的な負担コスト（割引済み） |
| unblendedCost | 割引前のコスト |
チャージバック用の計算
対象リソースへのチャージバック額
= アカウントID x リソースID で絞った行の effectiveCost合計
費用削減額の計算
費用削減額 = onDemandCost - effectiveCost
(支払ったはずの料金) (実際の支払い)
12. よくある落とし穴と対策
落とし穴1：リージョンの間違い
❌ 東京リージョンで購入したRI
→ バージニア北部のリソースには適用されない
✅ 購入前にマネジメントコンソールのリージョン設定を確認
落とし穴2：インスタンスファミリーの不一致
❌ r8g.large RIを購入したのに
→ t4g.large リソースが起動している
✅ ヒアリング時に「インスタンスファミリーは固定か」を確認
落とし穴3：エンジンの指定ミス
❌ MySQL BYOL で購入したのに
→ Oracle License Included で購入済みだった
✅ 購入画面で、ライセンス種別を確認
落とし穴4：クォーター超過
❌ 東京リージョンで既に30台のRDSリザーブドインスタンスを購入
→ さらに20台購入しようとしたら購入できない
✅ 購入前に AWS に「クォーター緩和申請」を事前に実施
落とし穴5：サイズ計算の誤り
❌ Aurora IOOptimized 5台を想定したのに
→ xlarge 5台分の小数点の正規化係数を購入した
✅ IOOptimized を使う場合は、正規化係数を正確に計算
例: 10.4 × 5 = 52.0
→ 2xlarge 3台（48） + large 1台（4） = 52
13. リザーブドインスタンス共有機能
組織内での割引共有
複数のAWSアカウント間でリザーブドインスタンスの割引を共有できます：
【例】
ビジネスユニットA: アカウント1, 2
ビジネスユニットB: アカウント3, 4
アカウント1 で購入したRI
→ アカウント1のリソースに優先的に適用
→ 余剰分は アカウント2, 3, 4 で自動的に共有
共有の設定方法
1. 管理アカウントにログイン
2. 請求とコスト管理
→ 請求設定
→ リザーブドインスタンス及びセービングスプランの割引共有
3. 共有を有効/無効 切り替え
注意点
- デフォルト: 共有有効
- 共有を無効にすると、特定アカウント間での細かい制御はできない
（すべて無効か、すべて有効かの選択肢のみ）
- セービングスプランとリザーブドインスタンスは独立しない
（両者に同じ共有設定が適用される）
14. 推奨事項機能の活用と注意点
コストエクスプローラーの推奨事項
AWSは自動的にリザーブドインスタンスの購入を提案してくれます：
AWS管理コンソール
→ コストエクスプローラー
→ Reserved Instances の推奨事項セクション
推奨事項の前提条件
過去7日間 / 30日間 / 60日間
のいずれかの使用パターンから推奨
【注意】将来予測は含まれていない
推奨事項をそのまま採用してはいけない理由
❌ 今後ワークロードが増加する → 推奨値は足りない可能性
❌ 確実に減少する計画がある → 推奨値は多すぎる可能性
❌ サイズ柔軟性あり → 最小サイズが推奨される傾向
✅ 推奨事項は参考値として使い、購入計画を自分で立てる
15. まとめ
リザーブドインスタンスのポイント
| ポイント | 内容 |
|---|---|
| 割引率 | 最大75%（3年全額前払い） |
| 対象ワークロード | 安定的で1年以上変動のないもの（DB等） |
| 仕組み | 「割引で使う権利」を購入（物理リソースではない） |
| 購入前 | リージョン、ファミリー、エンジン、台数を厳密に確認 |
| 購入後 | キャンセル不可、手動更新が必要 |
| モニタリング | 使用率、カバレッジ、削減額を追跡 |
実施の流れ
1️⃣ リソース調査
↓
2️⃣ ヒアリング（1年間変わらないか確認）
↓
3️⃣ 損益分岐点確認
↓
4️⃣ 購入条件決定（アカウント、サイズ、支払いオプション等）
↓
5️⃣ 購入（確認入念に！）
↓
6️⃣ モニタリング（使用率・カバレッジ追跡）
↓
7️⃣ 次の購入計画に反映
EC2 vs RDS での使い分け
【EC2】
→ セービングスプラン推奨
（柔軟性が高いため）
【RDS等のDB】
→ リザーブドインスタンス活用
（スケール固定で長期利用のため）
まとめ
AWSのリザーブドインスタンスは、正しく活用すれば非常に強力なコスト削減ツール です。
ただし、購入計画の段階での確認が何より重要です。焦らず、大きなコストから始めて、経験を積んでいくことをお勧めします。
また、購入後のモニタリングも手を抜かず、次の購入計画に活かしましょう。
参考資料
- AWS Black Belt Online Seminar - Reserved Instances（YouTube）
- AWS Black Belt Online Seminar - Reserved Instances（セミナー開始時刻）
- AWS Black Belt Online Seminar シリーズ
- AWS 公式ドキュメント - リザーブドインスタンス