3秒でわかる
使ったリソースの量に応じて後から請求される料金体系。初期費用を抑えられる代わりに、上限を置かないと請求が青天井になります。
もう少し詳しく
どういうものか
従量課金は、実際に消費した量を数えて、その分だけ支払う仕組みです。数える対象はサービスごとに違い、仮想マシンなら起動していた秒数、ストレージなら月平均の保存量、API なら呼び出し回数やトークン数が単位になります。
契約時に台数や容量を決めないので、使い始めるときの金額はゼロに近くなります。請求額が確定するのは月が終わった後です。
なぜ必要か
自社でサーバーを買うと、繁忙期に耐えられる台数を先に買うことになり、暇な時期はその台数が遊びます。従量課金なら、必要なときだけ増やして、終わったら消せます。個人開発や検証環境では、動かしていない時間の費用がゼロになる効果が特に大きくなります。
裏返すと、負荷が読める定常運用では割高になります。安定して回り続けるものは、期間を約束して割引を受ける契約に切り替えたほうが安くなります。
具体例
見積もりは掛け算の積み上げです。数える単位を取り違えると桁が変わります。
# 生成 AI の API を月30万リクエスト呼ぶ場合の概算
in_tokens_per_req = 1200
out_tokens_per_req = 400
requests = 300_000
price_in = 3.0 / 1_000_000 # 入力100万トークンあたり3ドル
price_out = 15.0 / 1_000_000 # 出力は5倍高い
cost = requests * (in_tokens_per_req * price_in + out_tokens_per_req * price_out)
print(round(cost, 2)) # 2880.0 ドルつまずきやすいところ
似た用語との違い
| 契約 | 支払い方 | 向いている場面 |
|---|---|---|
| 従量課金 | 使った分だけ後払い | 量が読めない、検証中 |
| 定額 | 毎月同じ額 | 予算を固定したい |
| 長期予約 | 1年3年を約束して割引 | 負荷が安定した本番 |
覚え方
水道と同じで、蛇口を開けた分だけ請求されます。開けっ放しが一番怖い、という感覚を先に持っておくと事故が減ります。