AWS請求書の「マイナス行」を割引率と読むと5倍ずれる — SPとRIを請求書だけで見分ける3つのテスト

「今、割引はどれくらい効いていますか」と聞かれたとき、請求書のマイナス行を合計して請求総額で割る——この計算をしている現場をよく見かけます。そしてこの計算は、Savings Plans（SP）を使っている限りほぼ確実に過大になります。

実際に請求書を3か月分並べて検算したケースでは、請求書の表面上は15.0%引きに見えていたのに、SPの正味効果は2.9%でした。約5倍の乖離です。

この記事では、その乖離がなぜ起きるのかと、請求書PDFだけでできる3つのテストを書きます。特別なツールは要りません。手元の請求書で再現できます。

なぜ「マイナス行の合計」が割引率にならないのか

先に構造を押さえます。SPとRI（Reserved Instances）は、同じ「長期コミットによる割引」でありながら、請求書での見え方が根本的に違います。

なお、以下に出てくる請求書の行名は概ねこの名前で出るという程度に読んでください。請求書の種類やペイヤー構成によって文言が変わることがあります。大事なのは名前そのものではなく、「割引を適用する側の行」と「コミット費用を計上する側の行」が別々に存在する、という構造のほうです。

問題はSPの②です。マイナス行だけを見て割引額と呼ぶと、そのSPがあるからこそ発生しているコミット費用が相殺されていません。割引の恩恵だけ数えて、その対価を数えていない状態です。

RIのほうはもっと厄介で、そもそも比較対象が消えています。これは後半で扱います。

テスト1: SPの正味効果を出す

まずSPから。次のサンプル請求書で計算してみます（金額は説明用の架空の値ですが、比率は実測ケースのものです）。

やりがちな計算はこうです。

1,500.00 ÷ 10,000.00 = 15.0%   ← これは割引率ではない

正しくはコミット費用を差し引きます。

SPが無かった場合の支払 = Charges − SPコミット費用
                       = 10,000.00 − 1,250.00 = 8,750.00

SPの正味効果 = 8,750.00 − 8,500.00 = 250.00 USD/月
             （= SP適用額 1,500.00 − コミット費用 1,250.00）

総額に対する効き = 250.00 ÷ 8,750.00 = 2.9%
SP対象部分だけの割引率 = 250.00 ÷ 1,500.00 = 16.7%

15.0%と2.9%、約5倍の差はここから生まれます。冒頭の実測ケースもまったく同じ構造で、SP対象部分だけを見た割引率は17.5%でした。

ここで大事なのは、16.7%（17.5%）と2.9%はどちらも正しいということです。分母が違うだけです。社内で「うちはSPで17%引き」と説明されている数字はたいてい前者で、請求総額に対する効きは後者です。乗り換えや構成変更の判断ができるのは後者のほうだけです。

テスト2: 時間比例性テストでRIを見つける

RIはマイナス行が出ないので、別の手がかりを使います。

RI月額料金とSPコミット費用は「単価 × 月間時間数」で決まるので、月の日数に完全に比例します。逆に言えば、複数月の そのサービスのCharges ÷ 月間時間数 を並べてブレなければ、その中身は固定料金だと言えます。

サンプル（4月=720h / 5月=744h / 6月=720h）:

5月だけ金額が増えているのは利用が増えたからではなく、単に31日あるからです。$/hに直すと完全に一致します。これは「このサービスのChargesは実質すべて時間固定料金である」という証拠で、RI月額料金の存在を請求書だけで示せたことになります。

同一アカウントの3か月で実測したブレ幅（$/hの最大値と最小値の差を平均で割った値）が、こちらです。

このケースでは、ElastiCacheのRIは事前のヒアリングでは申告に上がっていませんでした。それでも請求書3か月分だけで「ここに固定料金がある」と指摘できています。

判定の目安としては、ブレ幅が1%未満なら固定料金を疑い、10%前後あればオンデマンドと見てよい、という程度の粗さで十分に使えます。

テスト3: コミット費用の行が 0.00、または存在しない

3つめは見落としやすく、そして影響が最も大きいパターンです。

Savings Plans for AWS Compute usage の行は存在するのに金額が USD 0.00、あるいはその行がそもそも出てこない。その一方でSP適用額のマイナス行は毎月きちんと出ている——このパターンを見たら、SPを All Upfront（全額前払い）で購入済みと考えてください。コミット費用は購入時に払い終わっているので、月次の請求には乗ってこないのです。

0.00 だけが唯一のサインではない点に注意してください。請求書の作りによっては、金額ゼロの行を出さずに省いてくることがあります。「マイナス行は出ているのに、対応するコミット費用が見当たらない」という非対称そのものがサインです。

これを見落とすと、判断を大きく間違えます。

• 月々のNet請求は「前払い済みの分を除いた、実質オンデマンド部分だけ」になっている。つまり見かけの月額が実力より小さく見える
• 何らかの事情でSPを失うと、SP適用額がまるごとオンデマンドとして請求に戻る
• 前払い済みの金額は、実務上は戻らないものとして考える必要があります。SPは原則として解約・売却・他アカウントへの移管ができません。ただし無条件に「返品不可」ではなく、AWSは2024年3月に返品窓口を追加しています。時間あたりコミットが$100以下・購入から7日以内・同一暦月（UTC）内といった条件を満たす場合に限り、前払い分が全額返金されます（返品回数にも制限があります）。すでに運用に乗っているSPはこの窓口の外なので、判断としては「戻らない」で差し支えありません
• RIについては、Standard RI に限り AWS Reserved Instance Marketplace で売却できます。Convertible RI は売却できません

実際、All Upfrontを見落としたまま「今の月額」を基準に乗り換えを試算すると、割引後でも現状より高くなるという逆転が起きます。見かけの月額と、SPを失ったあとの本来の月額を比べていないからです。

SPを持っている場合、割引率の交渉より先に満了日を確認することをおすすめします。満了日が提案の順序を決めます。

RIの効果は原理的に復元できない

ここまで来ると分かりますが、SPは請求書から算定できるのに対し、RIの正味効果は請求書からは復元できません。理由は単純で、比較対象が残らないからです。RI適用分は$0で課金されるので、「本来いくらだったか」という情報がどこにも書かれていません。

推定するなら次の式になります。

RIによる削減額 = F × d / (1 − d)
  F = RI月額料金
  d = RI割引率

RDS / ElastiCache の1年・前払いなしであれば d はおおむね30〜35%です。ただしF も請求書から分離できないため、これはあくまで推定の域を出ません。

推定だと分かったうえで使うのは構いません。やってはいけないのは、この数字を「請求書から算出した割引率」として断定することです。

確定させるには何を見ればいいか

RIを確定させたい場合の依頼データを、取りやすい順に並べます。

1. RDS / ElastiCache コンソールの「リザーブドインスタンス」画面 — 予約数・インスタンスタイプ・期間・前払い区分・満了日・月額料金がまとめて載っています。スクリーンショット1枚で済むので最速かつ最確実です
2. Cost Explorer — 対象サービスでフィルタし、ディメンションを「料金タイプ（Charge type）」または「購入オプション」でグループ化します。RIFee / Usage / DiscountedUsage が分離できます
3. CUR（Cost and Usage Report） — lineItem/LineItemType 別に集計します
4. Reservation / Savings Plans カバレッジレポート

実務では1番だけで足りることがほとんどです。請求書PDFの読み解きに時間をかける前に、まずこの画面を見せてもらうのが早道です。

カバレッジ率の自己申告は請求書と食い違う

ひとつ注意点があります。FinOpsで言う「カバレッジ率」はRI/SP対象の利用に対する比率であって、請求総額に対する比率ではありません。

そのため、事前ヒアリングでの自己申告と、請求書からComputeのSP単体で計算し直した値が大きく食い違うことは珍しくありません。しかも食い違いは一方向ではなく、申告のほうが高く出ることも低く出ることもあります。

これは誰かが嘘をついているわけではなく、単に定義が違うだけです。数字が合わないときは「RDS/ElastiCacheのRIを含めた数値ですか」と質問の形で確認するのが安全です。断定しにいくと、たいてい話がこじれます。

満了後をどう見積もるか

RI/SPを持っている状態で乗り換えや構成変更を検討するなら、満了後のシナリオを別に引いてください。満了後に買い直さない前提であれば、こう組みます。

完全オンデマンド請求額 = 現在の実支払 + SPの正味効果 + RIの正味効果
満了後の想定請求       = 完全オンデマンド請求額 × (1 − 適用される割引率)

ここで間違えやすいのが、RIの不確実性を「割引対象額の割合」のほうに効かせてしまうことです。満了後の請求にはRI月額料金がそもそも存在しません。したがって「RI月額料金を割引対象外として積む」という置き方は誤りです。RIの不確実性は、割引対象の割合ではなくオンデマンドに戻したときの請求額そのものに効きます。

この置き方に直すと、RIの内訳が最後まで分からなくても意思決定の向きは変わらない、という状態にできることが多いです。RIの効果が大きいほど手放す痛みは増えますが、比較の勝ち負けが逆転するところまではなかなか行きません。データが揃うのを待たずに検討を進められます。

もうひとつ、判断材料として効くのがそもそも予約という仕組みが存在しないサービスの比率です。データ転送・S3・VPC・ELB・CloudWatch・WAFなどはRI/SPでは一切割引できません。請求書を読んでいると、この領域だけで請求総額の3割前後に達している構成は珍しくありません。この比率が大きいほど、RI/SPを組み直すという打ち手で届く上限は低くなります。手を付ける前に、まず自社の比率を出しておくと判断が早くなります。

まとめ

• 請求書のマイナス行の合計を割引率と呼ばない。SPコミット費用を引かないと過大になる（実測で約5倍）
• SPの正味効果 = SP適用額 − SPコミット費用。「総額に対する効き」と「SP対象部分の割引率」は別物なので、分母を明示して話す
• Charges ÷ 月間時間数 が月をまたいでブレなければ固定料金。RIのサインになる
• Savings Plans for AWS Compute usage が 0.00 なら All Upfront。見かけの月額が実力より小さい
• RIの正味効果は請求書から復元できない。コンソールのRI画面か、Cost Explorerの料金タイプ別で取る
• 満了後シナリオは全額オンデマンドを基準に組む。RIの不確実性は請求額そのものに効く

CloudCutで確認できる範囲

正直に書くと、ここに書いたテストは請求書PDFさえあれば誰でも再現できます。私たちだけができることではありません。

私たちがやっているのは、この読み解きを毎月の請求書に対して継続的に回したうえで、リセラー経由のフラット割引とRI/SPを組み直す打ち手のどちらがその会社にとって効くのかを、同じ土俵の数字で並べることです。

ひとつ補足しておくと、CloudCutが提供しているのはAWS / Google Cloudの請求代行を通じた最大20%の削減¹ですが、リセラー割引はRI/SPでカバーされた利用分には乗りません（この扱いはリセラー各社の解説による整理で、AWS公式にこの定義が公開されているわけではありません。詳しくは割引対象額の記事に書きました）。つまりSP/RI比率が高い会社ほど、請求総額に対する実効値は表向きの割引率より下がります。逆に、上で触れた「予約が存在しないサービス」の比率が高い会社ほどフラット割引が効きます。この計算まで出さないと、そもそも比較になりません。

現状の請求書を読み解くところからのご相談も承っています。