コミットメント割引が実際に買っているもの

なぜそうなるのか

Savings Plans は何も予約しない。1時間あたり何ドル使うかを約束する契約で、対象は「そのとき手元にある適格な使用量」なら何でもいい。AWS の定義もそのまま「$/hour で測るコミットメント」だ。プランが名指ししているのはドルの額であって、インスタンスではない。期間は1年 (365日) か3年 (1,095日)。最小コミットは $0.00001/hour から買える。

だから請求書上で Savings Plans は座りが悪い。アカウントの中に「プランという形をしたもの」は存在しない。どのリソースもプランを指していないし、プランもどのリソースも指していない。請求書には plan ARN で識別された手数料として現れ、そこで生まれた割引はまったく別の場所に落ちる。別アカウントということも普通にある。

Reserved Instance は先にあった、そして別物の仕組みだ。こちらは属性を名指しする — インスタンスファミリー、サイズ、プラットフォーム、テナンシー、そしてリージョンか特定の AZ か。条件に一致した使用量が割引される。容量まで付いてくるかどうかは最後の選択だけで決まる。ここを間違えて買っている人が多い。リージョン指定の RI は容量を予約しない。AWS 自身がそう明記している。単なる値段だ。AZ 指定の RI は名指しした AZ に容量を予約する。「起動が失敗しないように」と思って RI を買い、それがリージョン指定だったなら、買ったのは割引であって保険ではない。

Savings Plans の種類は3つではなく4つある。Database Savings Plans が re:Invent 2025 で増えたが、古いページはまだ追いついていない。

• Compute Savings Plans — EC2 をファミリー・サイズ・リージョン・OS・テナンシー問わず。加えて Fargate と Lambda。On-Demand 比で最大66%。
• EC2 Instance Savings Plans — 1リージョンの1インスタンスファミリーに固定。その中でサイズ・OS・テナンシーは自由。最大72%。
• Database Savings Plans — Aurora / RDS / DynamoDB / ElastiCache / DocumentDB / Neptune / Timestream / Keyspaces / DMS / OpenSearch Service。最新世代のプロビジョンドインスタンスとサーバーレスが対象。最大35%、1年、前払いなし。
• SageMaker AI Savings Plans — SageMaker AI のインスタンス使用量。ファミリー・サイズ・リージョン・コンポーネントを跨いで効く。最大64%。

上から下に読むとトレードは明快だ。プランが狭いほど割引が深い。手放した自由度の分だけ金が返ってくる。

次が、あの意味不明な行を生んでいる仕組み。AWS は1時間ごとに独立して、適格な使用量を並べ替え、コミット額をそこに突っ込む。まず無料利用枠、次に Reserved Instances、その次に Savings Plans。Savings Plans の中では EC2 Instance プランが先で Compute プランが後だ。Compute のほうが守備範囲が広いので、狭いプランでは届かない使用量のために取っておく。残った使用量については、適格な組み合わせごとに割引率を計算し、割引率の高い順にコミットを当てていく。同率ならプラン料率の低いほうが先。使用量が尽きるかコミットが尽きるまで続き、余った使用量は On-Demand で課金される。

ここから2つ、直ちに帰結する。ひとつ、会計単位は1時間。14時に使い残したコミットは15時には存在しない。もうひとつ、この並べ替えのどこにもアカウントの概念がない。プランは組織内のどのアカウントでも買えて、共有がオン (デフォルト) なら、まず購入アカウントの使用量に当たり、次に他のアカウントの使用量へ、割引額の大きいところを追いかけて流れていく。手数料は買った側に残る。ベネフィットは一番深い割引が取れる場所へ行く。管理アカウントに手数料の行だけが孤立していて、実際の節約は3階層下のチームのアカウントに出ている — 理由はこれで全部だ。

で、いくらなの

コミットの単位は1時間あたりのドル。その見返りの料率は、プランの種類と期間で変わる。m5.xlarge / Linux / 共有テナンシー / us-east-1 を、AWS 自身の Price List API (2026年8月5日公開分) から引くとこうなる。

• On-Demand — $0.192/hr。
• Compute Savings Plan・1年・前払いなし — $0.141。約27%引き。この料率はファミリーもサイズもリージョンも跨いで付いてくる。
• EC2 Instance Savings Plan・1年・前払いなし・us-east-1 の m5 — $0.121。約37%引き。どこにも付いてこない。
• Compute Savings Plan・3年・全額前払い — $0.088。約54%引き。
• EC2 Instance Savings Plan・3年・全額前払い — $0.072。62.5%引きで、このインスタンスが到達できる最深値。「最大72%」と謳われている商品でこれだ。看板の割引率はカタログ全体の天井であって、自分のインスタンスに当てはめる数字ではない。

ただ、人が詰まるのは料率ではない。行の種類のほうだ。コミットがある請求書には、ない請求書には出てこない charge type が並び、しかもそのいくつかは互いを打ち消すために存在する。

• SavingsPlanUpfrontFee — 全額前払い・一部前払いプランの一時金。購入日に立つ。
• SavingsPlanRecurringFee — 前払いなし・一部前払いプランの時間課金。期間中は毎時追加される。全額前払いプランでもこの行は出るが、そちらが表しているのはその請求期間で使い切れなかった分だ。
• SavingsPlanCoveredUsage — 割引が当たった使用量。ただし unblended cost には On-Demand だったらいくらだったかが入る。だからこの行だけ見ても何も安くなっていないように見える。
• SavingsPlanNegation — それを打ち消すマイナスの行。plan ARN・operation・usage type・AZ で1時間ごとにまとめられるので、1本の negation が複数の covered usage を相殺する。行数は合わない。本当の金額はどちらの行でもなく savingsPlan/SavingsPlanEffectiveCost にある。
• RIFee — Reserved Instance の定期手数料。Savings Plans の recurring fee が時間単位なのに対し、こちらは月単位。全額前払い RI で金額が $0.00 でも行は立つ。AWS がこの行に reservation/AmortizedUpfrontFeeForBillingPeriod と reservation/ReservationARN を載せているからだ。$0.00 の RIFee はバグではなく容れ物。
• DiscountedUsage — RI が当たったインスタンス使用量。AWS のドキュメントは、この行の unblended rate は 0 だと明記している。例の $0.00 の行はこれで、意味は「無料」ではなく「カバー済み」。

そしてコスト列が3種類ある。わざと食い違うように作られている。

• unblended — 課金された日の現金。前払いは購入日に、定期費は月初に立つ。「AWS はいつ、いくら請求したのか」に答える列。
• amortized — コミットを期間に均した額。AWS の例では、$365 の全額前払い1年プランに一致する使用量があると、1日あたり $1 の amortized cost になる。「このワークロードは実際いくらで動いたのか」に答える列。
• blended — 組織全体の SKU ごとの平均料率。管理アカウント側で計算され、メンバーアカウントへの配賦に使われる。AWS はコンソールに出る blended rate を参考値だと言い切っている。割引を組織で均して社内チャージバックするなら使える。請求書との突き合わせには絶対に使わない。合わないから。

このページにメーターのバッジが付いていないのは手抜きではない。コミットメントはメーターを回さない。インスタンス1時間は $0.192 だろうと $0.088 だろうと time を回す。そのインスタンスから出ていく転送は bytes を回すし、どの Savings Plans もそれをカバーしない。Lambda の呼び出しは units を回す。プランはメーターの横に座って、単価だけを書き換える。

Lambda の料率表がそれを文字どおり見せてくれる。Compute Savings Plans は Lambda をカバーしていて、us-east-1 の料率表には両方のメーターが載っている — duration が $0.0000147 / GB-second、request が1件 $0.0000002。後者は On-Demand のリクエスト単価そのものだ。units メーターはプランの守備範囲に入っていて、割引がゼロ。AWS 自身の計算例でも Lambda リクエストの割引率は0%になっている。同じメーター、同じ回数、同じ単価。プランがあってもなくても。

例外と罠

使わなかったコミットは、貯まらずに消える。 コミットは引き出せる回数券ではなく、支出の下限だ。$10/hour で契約して、ある1時間に適格な使用量が $6 しかなければ、残りの $4 は消滅する。AWS は「未使用分は翌時間に繰り越されない」と明記している。ピークに合わせてサイズしたプランが高くつくのはこれが理由で、谷の時間帯にもピーク分を払い続けることになる。全額前払いプランなら被害額は直接読める。SavingsPlanRecurringFee の行が、その期間の未使用分そのものを報告している。

coverage と utilization は別物で、しかも打ち手が正反対。 utilization は「コミットのうち何%を使えたか」 — $10 のコミットに対して $9.80 使えば98%。coverage は「適格な使用量のうち何%をプランが払ったか」。utilization が高くて coverage が低いなら買い足す局面。utilization が低いなら買いすぎで、できることは待つことしかない。片方だけ出しているダッシュボードは、確実に逆方向を指す。

コミットは、それを正当化したワークロードより長生きする。 購入後に条件は変更できない。上に別のプランを積むことしかできない。返品の逃げ道は狭く、AWS はその境界を全部書いている — 時間コミットが $100 以下、購入から7日以内、かつ同一暦月内、しかも管理アカウントあたり年10件まで。アカウントを別の組織に移すとそれすら閉じる。移行後は7日以内であっても新しい組織からは返品できない、と AWS は明記している。3年プランとは、来四半期に存在しているかどうかも分からないワークロードの試算に基づいて、誰かが3年分の支出を決めたということだ。