前提

業務上の必要性からリザーブドインスタンスについて学ぶ必要性が出てきたので勉強します。
リザーブドインスタンスについての私の理解がAWSSAA取得時に学んだEC2の割安プラン位の解像度なので深堀します。
特にリザーブドインスタンス切り替え時のプランの見直しという観点で調べます。

まずは座学

以下の動画をとりあえず視聴した。
リザーブドインスタンスでAWS節約！ #EC2 – Qiita
リザーブドインスタンスを完全理解！これを読めばとりあえず大丈夫。 | Katsuya Place
RI /SP のギモン、解消します！#devio2021

コンバーティブルで契約して途中でリソース設定変更しようとしても安くすることは結構難しいようだ
EC2の上にFargateが乗ってたりするとSavingplanの方が良い→EC2以外にLambda,Fargateを使っているかどうか＆一時間当たりの利用費でコミットして割引
RIとSPの使い分け→RIは一定のリソースを長期安定的に利用する場合(基幹システムとか)、SPはEC2やFargateの利用料が短期間で頻繁に変動する場合

切り替え時にどうするべきか(ググる＆AIを詰める)

以下gpt先生に聞いてみる
Q,AWSのEC2インスタンスについて一年単位でリザーブドインスタンスを利用しています。更改期限が近付いてきたのでRIを適切な内容で契約し直したいです。どうしたらよいか正確に思いつく限り列挙してください

A.
まとめ：チェックリスト形式で整理

選択肢	内容
① 予約購入（Renew予約）	期限タイミングで自動的に購入・更新されるよう予約する
② 新規購入	同条件のRIを改めて購入する
③ Modify	Standard/Convertible RIどちらも、AZやサイズなどを構成調整可能
④ Exchange	Convertible RIに限り、異なる構成へ交換可能（True-up cost注意）
⑤ Marketplace購入	標準RIでMarketplaceの他ユーザー出品を購入する
⑥ Savings Plansへの切り替え検討	将来の柔軟性とコスト最適化の観点で検討

Q2,今回更改のタイミングでRIを最適化するためにインスタンスタイプなど契約内容の見直しをしたいです。今後一年間適切なRIを契約するために出来ることを正確に教えてください

A2,
要点まとめ（チェックリスト）

目的	おすすめの手段
使用パターンに合ったRIを契約したい	Cost Explorer推奨やCompute Optimizerによる診断
柔軟性と将来の変更対応力を重視	Convertible RIまたはSavings Plans
組織内でコスト効率を高めたい	AWS Organizationsによる共有
RIの最適性を継続したい	定期的な見直し／サードパーティツール活用
買い直し・更新を手間なく確実に行いたい	FinOps専門プログラムの導入検討

ここで旨そうなのが1,2だと判断した。深堀する

Q3,以下の路線で進めたいです。どうすればよいのか可能な限り詳細に正確に教えてください

1. 実利用に基づいた最適な買い直し（Cost Explorerの推奨）

AWS Cost Explorerの「Reserved Instance Recommendations」機能を使い、過去の利用（7/30/60日）から将来に有効なRIの推奨を得られます。期間、Offeringクラス（Standard vs Convertible）、支払いオプション（前払いなし／部分／全額前払い）などの条件を設定し、推奨と見積もりを確認できます。

2. インスタンスの最適化による構成見直し（Compute Optimizer）

AWS Compute Optimizerを有効化して、現在利用中インスタンスの「過剰供給」「不足」「最適」などの診断を行い、よりコスト効率や性能に優れるインスタンスタイプを提案します。最大3つの候補（Option 1〜3）と性能リスク、時間あたり価格も提示されます。

Auto Scalingグループにも適用可能です（但し対象インスタンスタイプに制限あり、設定条件要確認）。

A3,了解です。ご指定の2本柱（①Cost ExplorerのRI推奨／②Compute Optimizerのリサイズ提案）で、今日から実行できる実務手順をできるだけ具体的・正確にまとめます。

1) Cost Explorerの「RI購入推奨」を使って“実利用ベース”で買い直す

前提の有効化・権限

Cost Explorer を有効化（未有効なら）：Billing & Cost Management から Cost Explorer を初回起動。データ準備に最大数日かかります。 AWS ドキュメント+1
組織・権限の確認：管理アカウントで Cost Explorer への組織メンバーのアクセスを許可（推奨）。リンクドアカウントの推奨表示は権限設定に依存します。IAMのBillingアクセス有効化も忘れずに。 AWS ドキュメント+1

RI購入推奨の基本仕様（理解）

推奨は**過去 7/30/60 日の “オンデマンド利用”**のみを材料に算出（既存RI/Spot/Savings Plansでカバーされた分は除外）。将来予測は行いません。 AWS ドキュメント
画面では**Term（1年/3年）／Offering class（Standard/Convertible）／支払い（No/Partial/All Upfront）**などを条件指定して、節約見込み・購入案が出ます。CSVで保存も可。 AWS ドキュメント

具体的な手順（コンソール）

Cost Management コンソール → 左ナビ Reservations > Recommendations。Serviceで Amazon EC2 を選択。 AWS ドキュメント
右側の Recommendation parameters で以下を設定：
- Term：「1 year」
- Offering class：Standard か Convertible
- Payment option：No/Partial/All Upfront
- Based on the past：7/30/60日のいずれか（安定度に応じて選択）
- 必要に応じ Region / Platform（Linux/Windows等）/ Tenancy も絞り込み
  → 推奨結果のEstimated monthly savings / Estimated savings vs On-Demand を確認。推奨行の View associated usage で根拠となる利用明細へドリルダウン可能。 AWS ドキュメント
Download CSV（右上のRecommended actions）でエクスポートし、社内レビュー／証跡化。 AWS ドキュメント

既存カバレッジの把握（重要）

Cost Explorer の RI Utilization / RI Coverage レポートで、現在の利用率・カバー率を確認し、目標値を設定（例：EC2カバー率80%など）。Normalized units でサイズ横断の可視化が可能。 AWS ドキュメント+1

契約属性の決め方（失敗しない勘所）

スコープ：
- Regional RI … サイズ柔軟性あり（Linux/UNIX × 共有テナンシに限る）。AZをまたいで割引適用。**購入のキューイング（予約）**が可能。通常はこちらが無難。 AWS ドキュメント
- Zonal RI … 容量予約が得られる代わりに、サイズ柔軟性なし・キュー不可。特定AZでキャパ確保が必要なときだけ。 AWS ドキュメント
サイズ柔軟性の仕組み：同一ファミリー内で正規化係数（normalized units）により相互適用（例：m4.large×4 = m4.2xlarge×1）。 AWS ドキュメント
キュー購入の活用：現行RIの満了日時に合わせてRegional RI をキューし、割引の“空白時間”をゼロに。 AWS ドキュメント
組織間の割引共有：Organizations 利用時はRI/SP割引共有の設定が有効か確認（無効だと請求が悪化）。適用優先順位も把握しておくと○。 AWS ドキュメント+1

自動化・API/CLI（任意）

推奨のAPI/CLI取得：ce get-reservation-purchase-recommendation（Cost Explorer API/CLI）。フィルタは LINKED_ACCOUNT などが使用可。 AWS ドキュメント

2) Compute Optimizerで“型とサイズ”を見直す（ASG含む）

セットアップ

Opt-in：アカウント（または組織全体）で Compute Optimizer を有効化。自動でサービスリンクドロールが作成されます。組織全体で有効化する場合は Trusted access をオン。 AWS ドキュメント+1
データ要件：EC2/ASG の推奨には直近14日で30時間以上の CloudWatch メトリクスが必要。初回解析は最大24時間待ち。推奨に価格を表示するには Cost Explorer有効化が前提。 AWS ドキュメント

推奨の見方（EC2単体）

Compute Optimizer コンソール → EC2 instances。Finding（Over-provisioned / Under-provisioned / Optimized）で絞り込み。 AWS ドキュメント
詳細を開くと Current に対し Option 1〜3 の候補、性能リスク（Performance risk）、時間あたりコスト、主要メトリクスが表示。性能リスクは CPU/メモリ/ネットワーク/EBS などの最大リスクで評価されます。 AWS ドキュメント+1
変更前後は負荷テストを推奨（AWS記載）。 AWS ドキュメント

Auto Scaling グループ（ASG）の扱い

Compute Optimizer は ASG 推奨も提供。ただし対象要件があり、未対応のインスタンスタイプや Spot 混在、MixedInstancesPolicy、ECS/EKS ワークロード混在などは非対応。 AWS ドキュメント
「他の型で同需要を低コストに満たせる」場合はNot optimizedと判断されます。 AWS ドキュメント

エクスポートと自動化

推奨は CSV/JSON を S3へエクスポート可（マルチリージョンにも対応）。CLI: aws compute-optimizer export-ec2-instance-recommendations。 AWS ドキュメント+1

実務ワークフロー（1年RIに向けた具体策）

現状把握
- Cost Explorer の RI Utilization / Coverage を確認し、目標カバー率を設定（例：平常時80%・ピークはオンデマンド/Spotで吸収）。Normalized units で偏りを把握。 AWS ドキュメント+1
リサイズ候補の洗い出し（Compute Optimizer）
- Over/Under-provisioned の EC2/ASG を抽出。Option1〜3 の中から、性能リスクが許容範囲で、社内標準（CPU/メモリ/アーキテクチャ方針）に合う型へ“先に”揃える計画を作成。 AWS ドキュメント+1
RIの設計パラメータを決定（Cost Explorer推奨 × ポリシー）
- Regional × Linux/UNIX × 共有テナンシを基本にし、サイズ柔軟性を確保（将来の微調整に強い）。AZ容量保証が必要な一部だけ Zonal。 AWS ドキュメント
- Term/Offering/Payment を1年・Standard or Convertible・支払方針で確定。
- 30/60日推奨を比較し、季節性が強いなら60日、最近の構成変更が多いなら30日で妥当性を確認。 AWS ドキュメント
購入実行の段取り
- 現行RI満了に合わせてキュー購入（Regionalのみ可）。満了直後から割引が連続するように調整。 AWS ドキュメント
- Organizations の割引共有が有効か再確認（無効だと最適カバレッジが崩れます）。 AWS ドキュメント
エビデンスと継続運用
- Cost Explorer 推奨と Compute Optimizer 推奨をCSVで保存して意思決定の根拠化・監査対応。 AWS ドキュメント+1
- 購入後は月次で RI利用率/カバー率 と Compute Optimizer を見直し、ドリフト（型・数）の早期検知をルーチン化。 AWS ドキュメント

迷いやすいポイント（FAQ）

「ASGに推奨が出ない」：要件未満のメトリクス、MixedInstancesPolicy、未対応ファミリー等が原因のことが多い。まず要件と対応ファミリーを確認

以下を気を付けるべきか
・インスタンスタイプのスペックを理解する必要がありそう
・一年以内にEC2を廃止することがあるか
・一年以内にOSやDBエンジンやインスタンスタイプに変更が生じないか

「ConvertibleかStandardか」：将来ファミリー/OS/テナンシを変える可能性が高いなら Convertible、固定運用で最大割引を狙うなら Standard。Cost Explorerの前提は過去利用＝将来利用であることも考慮。 AWS ドキュメント

ハンズオン(上記の内容踏まえてどういう設定が出来るのか実際の画面で見てみる)

EC2>リザーブドインスタンスでまずこの表示が出てきたのでへぇと思いました。
意外に見るところ少ない

やはり重きを置くべきはインスタンスタイプのスペックの理解とこれからスケールする必要がありそうかの判断ということかな

前提