料金を下げる仕組み ― 購入オプションと最適化

導入

同じEC2でも、払い方を変えるだけで料金は大きく変わります。「長く使うと約束すれば安くなる」「余っている枠を安く借りる」——コスト最適化の基本を押さえましょう。

説明

第3章でも触れたEC2の購入オプションは、コストの観点で改めて重要です。

オンデマンド … 契約なしで使った分だけ。柔軟だが単価は高い。短期・予測できない用途向け。
リザーブドインスタンス（RI） … 1年または3年の利用を約束する代わりに大幅割引。ずっと動かすサーバー向け。
Savings Plans … 「1時間あたり◯ドル使う」と利用量をコミットして割引。RIより柔軟。
スポットインスタンス … AWSの余剰キャパを最大9割引で。中断される可能性があるため、止まっても平気なバッチ処理向け。

リザーブドインスタンスには柔軟性の度合いがあり、試験で問われます。

種類・性質	内容
スタンダードRI	割引率は最大。ただしインスタンスファミリーの変更はできない
コンバーティブルRI	割引率はやや低いが、期間中に別のインスタンスファミリー・OS・テナンシーへ交換できる
インスタンスサイズの柔軟性	同じファミリー内であれば、サイズが変わっても割引が自動的に適用される（例：`m5.large` 用のRIが `m5.xlarge` の半分に適用される）
AZの指定	リージョン単位のRIはAZをまたいで柔軟に適用。ゾーン単位のRIはそのAZの容量も予約する

もう一点、AWS Organizationsを使って複数アカウントを一括請求にしている場合、RIやSavings Plansの割引は組織全体で共有されます。あるアカウントで買ったRIが、同じ組織の別アカウントの該当インスタンスにも適用される（共有をオフにすることも可能）ため、アカウントごとに買い直す必要はありません。

ストレージも、S3のストレージクラスを使い分ければコストを下げられます（アクセスの少ないデータは安いクラスへ）。コスト最適化の合言葉は「使わないものは止める・大きすぎるものは適正サイズにする（ライトサイジング）・長く使うものはコミットして割引を受ける」です。

flowchart TD
    Q["使い方は？"] --> S["止まっても平気なバッチ"]
    Q --> L["ずっと動かす"]
    Q --> V["予測できない・短期"]
    S --> SP["スポット 最大9割引"]
    L --> RI["リザーブド / Savings Plans"]
    V --> OD["オンデマンド"]

具体例

月額の請求が膨らんできたSaaS企業が、コスト最適化の“3つの合言葉”で見直しをかけました。

使わないものは止める … 開発・検証用のEC2が、誰も使わない夜間・週末も動きっぱなしだった。スケジュールで自動停止するようにし、稼働を平日日中だけに。
大きすぎるものは適正サイズに（ライトサイジング） … CPU使用率が常時5%しかない m5.4xlarge を、Cost ExplorerやTrusted Advisorの提案を見て m5.large へ縮小。性能は足りたまま料金が数分の一に。
長く使うものはコミットして割引 … 24時間動かし続ける本番DBサーバーは、オンデマンドのままだったのをリザーブド（3年）に。加えて、めったに見ない古いログはS3の安いクラス（Glacier）へライフサイクルで移動。

これらを積み重ねた結果、性能を落とさずに月額を大きく削減できました。「止める・縮める・コミットする」——コスト最適化はこの3手の繰り返しです。

読んでみよう

「長期利用の約束＝RI/Savings Plansで割引」「止まってよい処理＝スポットで大幅割引」「予測不能＝オンデマンド」。使い方に合わせて払い方を選ぶのがコスト最適化の柱です。