最低課金と切り上げ

なぜそうなるのか

AWS のメーターがすべて実際の量をそのまま読むわけではない。量子化するメーターは、どこかの単位の次の倍数まで切り上げた値を読む。切り下げるメーターは無い。最低課金・下限・切り上げのいずれかを課金ルールに持つサービスは、このサイトのカタログ全体に散らばっている。そしてそのすべてが、各サービスの料金ページの注記として、バラバラに書かれている。注記ではない。サービスをまたいで何度も顔を出す同じ 1 本のルールで、小さい仕事が「数量 × 単価」の予想どおりの値段にならない理由はこれだ。

一番きれいに言い切っているのは EC2 だ。「1 秒単位で課金され、最低 60 秒」。ただしこれは Amazon Linux・Windows・RHEL・Ubuntu・Ubuntu Pro に適用されるのであって、起動できる OS すべてではない。SUSE Linux Enterprise Server は今も時間単位で、端数の 1 時間は 1 時間として課金される。同じインスタンスタイプ、同じリージョン、同じ仕事。選んだ AMI だけで、量子が 1 秒になるか 3,600 秒になるかが決まる。EBS も EC2 に追随していて、プロビジョンドストレージ・プロビジョンド IOPS・プロビジョンドスループットのすべてが「1 秒単位・最低 60 秒」で課金される。

時間単位が過去の遺物かというと、そうでもない。Application Load Balancer は「稼働している 1 時間または 1 時間未満ごと」に課金され、「端数の 1 時間は 1 時間として課金される」。us-east-1 で 1 時間 $0.0225、これに LCU 1 時間あたり $0.008 が乗る。作って 90 秒だけ試して消せば、$0.0225 だ。Amazon OpenSearch Service も同じ形で、しかも時計の始まりが思っているより早い。課金は「インスタンスが利用可能になった時点で開始」し、「端数のインスタンス時間は 1 時間として課金される」。

実際に動いた量, メーター のやりとり。1ステップずつ:

1. 実際に動いた量 から メーター: EC2 (Amazon Linux):8 秒稼働。時間メーターで課金、60 秒。
2. 実際に動いた量 から メーター: ALB:90 秒稼働。時間メーターで課金、1 時間。
3. 実際に動いた量 から メーター: Lambda:27.40 ms 実行。時間メーターで課金、28 ms。
4. 実際に動いた量 から メーター: S3 Standard-IA:4 KB のオブジェクト。GBメーターで課金、128 KB。
5. 実際に動いた量 から メーター: Comprehend:12 文字。個数メーターで課金、3 ユニット。

理由は理不尽ではない。最低課金は、配置・イメージの取得・アタッチ・ブートといった固定費を、それより短いかもしれない時間に按分しているだけだ。だから最低課金は誠実だし、同時に予測可能でもある。課金対象が小さく短くなるほど、請求額に占める「量子の分」が「実際に使った分」を上回っていく。

で、いくらなの

Lambda は AWS のコンピュートの中で最も量子化が粗くない。しかもそれは意図的にそうなった。 2020 年 12 月までは実行時間を 100 ms 単位に切り上げていた。今は「1 ms 単位に切り上げ」で、最低実行時間もない。AWS 自身の例では、実測 27.40 ms の呼び出しが以前は 100 ms 課金だったのが 28 ms 課金になっている。もう一方の次元であるメモリに至ってはほとんど量子化されていない。128 MB から 10,240 MB まで 1 MB 刻みで指定でき、us-east-1 で 1 GB 秒 $0.0000166667、これにリクエスト 100 万件 $0.20 が乗る。だから 1,024 MB で 200 ms の関数は、同じ関数を 1 秒動かしたときの本当に 5 分の 1 で済む。これは例外的な挙動だ。他のサービスに当てはめてはいけない。

Lambda に残っている丸めは、終わり側ではなく時計の始まり側にある。2025 年 8 月 1 日以降、ZIP パッケージ + マネージドランタイムのオンデマンド呼び出しでも INIT フェーズが課金対象の実行時間に算入されるようになった。以前は課金されていなかった部分だ。SnapStart はまた別種の下限を持ち、公開したバージョンのスナップショットのキャッシュには「最低 3 時間」の課金がかかる。

CodeBuild は 1 つの料金ページの中に、同じ時間メーターに対する 3 種類の量子を同居させている。 オンデマンドの EC2 コンピュートは「分単位で計算し、分に切り上げ」。オンデマンドの Lambda コンピュートは秒に切り上げ。予約キャパシティフリートは分単位の切り上げに加えて、インスタンスごとに「最低 60 分」の課金がある。しかも時計は「新しいインスタンスをリクエストした時点から、インスタンスが終了するまで」動く。ビルド開始ではなくプロビジョニング開始だ。新規に立ち上げた予約インスタンス上の 3 分のビルドは、60 分として請求される。予約 macOS インスタンスはさらにその上に 24 時間の最低課金が乗る。

自分, フリートのインスタンス, ビルド のやりとり。1ステップずつ:

1. 自分 から フリートのインスタンス: インスタンス要求。ここで時計が動く。時間メーターで課金、0 分地点。
2. フリートのインスタンス から ビルド: プロビジョニング完了、4 分待機。時間メーターで課金、課金。
3. 自分 から ビルド: ビルド実行 3 分。時間メーターで課金、課金。
4. ビルド から フリートのインスタンス: ビルド終了、インスタンスは残る。時間メーターで課金、課金。
5. 自分 から フリートのインスタンス: 12 分地点で終了。時間メーターで課金、最低 60 分。

Fargate も「時計が早く始まる」タイプで、下限はもう少し小さい。「秒単位で計算し、最低 1 分」。そして「コンテナイメージのダウンロード (docker pull) を開始した時点からタスクが終了するまで」が課金対象だ。Windows タスクだけは最低 5 分になる。Glue は 3 か所に別々の下限を置いていて、ETL ジョブは最低 1 分、クローラーの実行とプロビジョンド開発エンドポイントは最低 10 分。いずれも下限を超えた先は秒単位課金だ。

バイトメーターでは、量子は「最小オブジェクトサイズ」の形をとる。 S3 Standard-IA と One Zone-IA は「オブジェクトが 128 KB 未満の場合、128 KB として課金される」。Glacier Instant Retrieval も同じ 128 KB。Glacier Flexible Retrieval と Deep Archive には最小オブジェクトサイズがない代わりに、オブジェクトごとに 40 KB のオーバーヘッドが乗る。名前とメタデータの 8 KB が S3 Standard の単価で、インデックスの 32 KB がアーカイブクラス自身の単価だ。EFS はもっと細かく、そしてもっと正直だ。IA と Archive のストレージは「4 KiB 単位で計測され、ファイルあたり最低 128 KiB の課金」があり、これらのクラスへのデータアクセスは「128 KiB 単位で計測」される。極めつけに、CloudWatch の StorageBytes メトリクスが「小さいファイルの丸めによって消費されたバイト数の合計」を出してくれる。これは珍しいし、使う価値がある。自分の丸め誤差を数値で公開しているメーターだ。

個数メーターでは、量子は「リクエストあたりの最低個数」になる。 Comprehend はテキストを「100 文字を 1 ユニットとして計測し、リクエストごとに 3 ユニット (300 文字) の最低課金」を取る。us-east-1 で最初の 1,000 万ユニットまで 1 ユニット $0.0001。Transcribe は音声を「1 秒単位で課金、リクエストごとの最低課金は 15 秒」。Athena はスキャンしたバイト数を「メガバイト単位に切り上げ、1 クエリあたり最低 10 MB」で数え、1 TB $5。3 サービス、3 メーター、仕組みは 1 つ。

例外と罠

最適化する軸を間違える。 最低課金を下回っている領域では、速度はタダであり、同時に何の価値もない。Glue のクローラーを 40 秒から 20 秒にしても、払うのは 10 分のままだ。予約フリート上の CodeBuild ジョブを 6 分から 2 分にしても、払うのは 60 分のままだ。ここで効くレバーは性能ではない。まとめること (実行回数を減らして 1 回を長くし、量子に占める実作業の割合を上げる) か、量子そのものを乗り換えること、CodeBuild なら 60 分の下限がないオンデマンドフリートに移ることだ。Lambda はその真逆で、1 ms 粒度・最低実行時間なしなので、削った 1 ミリ秒がそのまま金になる。プロファイルを取る前に、自分がどちらの領域にいるかを先に確かめること。

「小さいものが大量」は、3 つのメーターすべてで同時に最悪になる。 Standard-IA の 4 KB オブジェクトは 128 KB として課金される (32 倍)。3 秒の Transcribe リクエストは 15 秒として課金される (5 倍)。20 文字の Comprehend 呼び出しは 300 文字として課金される (15 倍)。小さいファイル・短い呼び出し・小さいメッセージで組んだパイプラインは、この 3 つを同時に踏む。そしてこの 3 つの倍率は、どれもコードのどこにも書かれていない。極端なのは小さいオブジェクトのアーカイブで、10 KB のファイルを Deep Archive に送ると、S3 Standard 単価の 8 KB + Deep Archive 単価の 32 KB + 移行リクエスト分が計上される。中身より帳簿のほうが大きい。S3 は現在、2024 年 9 月以降に作成された 128 KB 未満のオブジェクトについて IA 系クラスへのライフサイクル移行を拒否する。サービスが自分の丸めから利用者を守っているわけだ。

最小サイズと最低保管期間は別の仕組みで、しかも掛け算になる。 最小サイズは数量に対する倍率で、これは消えない。あの 4 KB のオブジェクトは、存在している限り毎時間 128 KB として課金され続ける。最低保管期間は期間側の下限で、Standard-IA のオブジェクトを 1 日目に消しても 30 日分は請求される。日割りの早期削除料として精算される形だ。Standard-IA と One Zone-IA が 30 日、Glacier Flexible Retrieval と Glacier Instant Retrieval が 90 日、Deep Archive が 180 日、EBS スナップショットアーカイブが 90 日。この 2 つは同じオブジェクトに同時にかかり、掛け合わされる。短期保持のライフサイクルルールが損をするのはこれが理由だ。オブジェクトを Standard-IA に移して 7 日後に削除するポリシーは、1 個あたり 128 KB × 30 日を払う。S3 Standard に置きっぱなしにするより明確に高い。

自分のアプリ, S3 Standard-IA を通る経路。1ホップずつ:

• S3 Standard-IA (us-east-1) は存在している間ずっとGBメーターで課金される。

1. 自分のアプリ から S3 Standard-IA: PUT:4 KB のオブジェクト。個数メーターで課金、Tier1 リクエスト 1 件。
2. S3 Standard-IA から 自分のアプリ: 1 日目に削除。GBメーターで課金、128 KB × 30 日。