AWS の料金計算の裏側 - 1 秒課金・100ms 課金・リクエスト課金はどう計測されているのか
EC2 の 1 秒課金、Lambda の 1ms 課金、S3 のリクエスト課金など、AWS の多様な課金粒度がどのように計測・集計・請求されているのかを、メータリングシステムの仕組みから解説します。
課金粒度の進化 - 時間単位から 1ms 単位へ
AWS の課金粒度は、サービスの歴史とともに細かくなってきました。EC2 は 2006 年のローンチ時、1 時間単位の課金でした。インスタンスを 1 分だけ使っても 1 時間分の料金が発生する仕組みです。2017 年 10 月、AWS は EC2 の課金を 1 秒単位 (最低 60 秒) に変更しました。この変更により、短時間のバッチ処理やスポットインスタンスの中断時に、実際の利用時間に近い料金だけが請求されるようになりました。Lambda はさらに細かく、2020 年に 100ms 単位から 1ms 単位に変更されました。100ms 単位では、実行時間が 1ms でも 100ms 分の料金が発生していましたが、1ms 単位になったことで、高速な関数のコストが最大 99% 削減されるケースもあります。Fargate は 1 秒単位 (最低 1 分)、RDS は 1 秒単位 (最低 10 分)、S3 はリクエスト数とデータ量ベースと、サービスごとに課金粒度が異なります。この多様性は、各サービスの利用パターンに最適な課金モデルを提供するための設計判断です。
メータリングシステム - 利用量をどう計測しているのか
AWS の課金の裏側には、膨大な利用量データを収集・集計するメータリングシステムが存在します。各サービスは、利用イベント (インスタンスの起動・停止、API リクエスト、データ転送量など) をメータリングレコードとして記録します。EC2 の場合、Nitro System のハイパーバイザーがインスタンスの起動時刻と停止時刻を正確に記録し、その差分から利用秒数を算出します。Lambda の場合、Firecracker のマイクロ VM が関数の実行開始時刻と終了時刻をミリ秒精度で記録します。S3 の場合、各リクエストがログに記録され、リクエストの種類 (GET、PUT、DELETE など) ごとにカウントされます。これらのメータリングレコードは、AWS の内部パイプラインで集計され、最終的に Cost and Usage Report (CUR) として顧客に提供されます。CUR は 1 行が 1 つの利用レコードに対応しており、大規模な AWS 環境では月間数億行に達することもあります。メータリングの精度は課金の公平性に直結するため、AWS はメータリングシステムの信頼性を極めて高い水準で維持しています。
データ転送料金の複雑さ - なぜ理解が難しいのか
AWS の料金体系で最も理解が難しいのがデータ転送料金です。データ転送料金は、データの移動方向、移動元と移動先のリージョン、移動元と移動先のサービス、データ量の階層によって異なります。基本ルールとして、AWS へのデータ転送 (イングレス) は無料、AWS からインターネットへのデータ転送 (エグレス) は有料です。ただし、同一 AZ 内のデータ転送は無料、同一リージョン内の異なる AZ 間のデータ転送は有料 (0.01 USD/GB)、異なるリージョン間のデータ転送はさらに高額 (0.02 USD/GB 程度) です。CloudFront 経由のデータ転送は、EC2 から直接インターネットに転送するよりも安い場合があります。これは CloudFront の料金体系が EC2 のデータ転送料金とは別に設定されているためです。たとえば、us-east-1 から日本へのデータ転送は、EC2 直接で 0.09 USD/GB ですが、CloudFront 経由だと 0.114 USD/GB (日本向け) です。ただし、CloudFront は S3 からのオリジンフェッチが無料のため、S3 + CloudFront の組み合わせは S3 から直接配信するよりも安くなるケースが多いです。
請求書が届くまでの裏側のパイプライン
AWS の月次請求書は、月末締めの翌月 3〜5 日に確定します。この間に、膨大なメータリングデータの集計、割引の適用 (Savings Plans、RI、ボリュームディスカウント)、税金の計算、通貨換算が行われます。Cost Explorer に表示されるコストデータは、リアルタイムではなく最大 24 時間の遅延があります。これは、メータリングデータの収集と集計にタイムラグがあるためです。特に、データ転送料金やサードパーティのマーケットプレイス料金は、集計に時間がかかる傾向があります。Savings Plans と RI の割引適用は、月末にまとめて行われるのではなく、利用が発生した時点でリアルタイムに適用されます。Savings Plans の場合、1 時間ごとにコミットメント額と実際の利用額を比較し、コミットメント額以下の利用には割引料金が、超過分にはオンデマンド料金が適用されます。AWS Organizations の一括請求 (Consolidated Billing) を使用している場合、組織内の全アカウントの利用量が合算されてボリュームディスカウントが計算されます。たとえば、S3 のストレージ料金は最初の 50TB が 0.023 USD/GB、次の 450TB が 0.022 USD/GB と階層化されており、一括請求により全アカウントの合計で階層が判定されるため、個別請求よりも有利になります。
予想外の請求を防ぐための実践的な対策
AWS の料金体系の複雑さゆえに、予想外の高額請求が発生するケースは珍しくありません。最も多い原因は、停止し忘れたリソースです。開発・テスト用に起動した EC2 インスタンス、NAT Gateway、Elastic IP、RDS インスタンスが放置され、月末に数百〜数千ドルの請求が届くパターンです。AWS Budgets でアラートを設定すれば、予算の 80% に達した時点で通知を受け取れます。さらに、AWS Budgets Actions を使えば、予算超過時に自動的に IAM ポリシーを適用してリソースの新規作成を制限できます。Cost Anomaly Detection は機械学習ベースで異常なコスト増加を検出し、通常のパターンから逸脱した支出をアラートします。たとえば、普段は月額 100 USD の S3 料金が突然 1,000 USD に跳ね上がった場合、数時間以内にアラートが送信されます。もう一つの見落としがちなコストは、CloudWatch Logs のデータ取り込み料金です。Lambda や ECS のログが大量に出力されると、CloudWatch Logs の取り込み料金 (0.50 USD/GB) が想定以上に膨らみます。ログレベルの適切な設定と、不要なログの保持期間の短縮が効果的な対策です。クラウドコストの管理手法を体系的に学ぶには、専門書籍 (Amazon)が参考になります。