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 単位になったことで、この切り上げによる課金対象時間の無駄が無くなりました。効果の大きさは関数の実行時間の分布によって変わるため、実際にどれだけ請求額が下がるかは自分の関数の Duration を見て判断する必要があります。Fargate は 1 秒単位 (最低 1 分)、RDS は 1 秒単位 (最低 10 分)、S3 はリクエスト数とデータ量ベースと、サービスごとに課金粒度が異なります。この多様性は、各サービスの利用パターンに最適な課金モデルを提供するための設計判断です。
メータリングシステム - 利用量をどう計測しているのか
AWS の課金の裏側には、膨大な利用量データを収集・集計するメータリングシステムが存在します。各サービスは、利用イベント (インスタンスの起動・停止、API リクエスト、データ転送量など) をメータリングレコードとして記録します。EC2 の場合、インスタンスの起動から停止までが 1 秒単位 (最低 60 秒) で計測され、その差分が利用秒数として記録されます。Lambda の場合、関数の実行時間が 1ms 単位で計測されます。計測を担う内部コンポーネントの構成は公開されていませんが、課金対象となる粒度はサービスごとの料金ページに明記されています。S3 の場合、各リクエストがログに記録され、リクエストの種類 (GET、PUT、DELETE など) ごとにカウントされます。これらのメータリングレコードは、AWS の内部パイプラインで集計され、最終的に Cost and Usage Report (CUR) として顧客に提供されます。CUR は 1 行が 1 つの利用レコードに対応しており、大規模な AWS 環境では月間数億行に達することもあります。メータリングの精度は課金の公平性に直結するため、AWS はメータリングシステムの信頼性を極めて高い水準で維持しています。
データ転送料金の複雑さ - なぜ理解が難しいのか
AWS の料金体系で最も理解が難しいのがデータ転送料金です。以下に挙げる単価はいずれも 2026 年 8 月時点のものです。データ転送料金は、データの移動方向、移動元と移動先のリージョン、移動元と移動先のサービス、データ量の階層によって異なります。基本ルールとして、AWS へのデータ転送 (イングレス) は無料、AWS からインターネットへのデータ転送 (エグレス) は有料です。ただし、同一 AZ 内のデータ転送は無料で、同一リージョン内の異なる AZ 間のデータ転送は有料 (0.01 USD/GB) です。ここで見落としやすいのが、AZ 間の転送は送信側と受信側の双方に課金されるという点です。請求明細でも Region-DataTransfer-Regional-Bytes が送信と受信の 2 行に分かれて現れるため、1GB のやり取りにかかる実額は片側の単価の 2 倍になります。異なるリージョン間のデータ転送はさらに高額で、単価はリージョンのペアによって幅があるため、見積もりの際は公式料金表で対象ペアの単価を確認してください。CloudFront 経由のデータ転送は、EC2 から直接インターネットに転送するよりも安い場合があります。これは CloudFront の料金体系が EC2 のデータ転送料金とは別に設定されているためです。たとえば、EC2 から直接インターネットへ転送する単価は us-east-1 で 0.09 USD/GB、CloudFront から日本の閲覧者へ配信する単価は 0.114 USD/GB です。単価だけを並べると CloudFront の方が高く見えますが、実際の総額では 2 つの条件が効きます。1 つは S3 をオリジンにした場合のオリジンフェッチが無料であること、もう 1 つはキャッシュにヒットした分はオリジンへの転送が発生しないことです。キャッシュヒット率が高いワークロードではオリジンから出るデータ量そのものが減るため、S3 から直接配信するよりも総額が下がります。逆に、毎回オリジンへ取りに行く動的なコンテンツでは単価差がそのまま効くため、割高になります。
請求書が届くまでの裏側のパイプライン
AWS の月次請求書は、月末で締められたあと翌月上旬に確定します。確定の日付はアカウントの請求サイクルや販売元によって前後するため、決まった日として扱うことはできません。なお、本節で挙げる単価は 2026 年 8 月時点・米国東部 (us-east-1) のものです。確定までの間に、膨大なメータリングデータの集計、割引の適用 (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 の料金体系の複雑さゆえに、予想外の高額請求が発生するケースは珍しくありません。本節で挙げる単価は 2026 年 8 月時点のものです。最も多い原因は、停止し忘れたリソースです。開発・テスト用に起動した EC2 インスタンス、NAT Gateway、Elastic IP、RDS インスタンスが放置され、月末に数百〜数千ドルの請求が届くパターンです。AWS Budgets でアラートを設定すれば、予算の 80% に達した時点で通知を受け取れます。さらに、AWS Budgets Actions を使えば、予算超過時に自動的に IAM ポリシーを適用してリソースの新規作成を制限できます。Cost Anomaly Detection は機械学習ベースで異常なコスト増加を検出し、通常のパターンから逸脱した支出をアラートします。ただし、検出はリアルタイムではありません。普段は月額 100 USD の S3 料金が突然 1,000 USD に跳ね上がったとしても、異常として検出されるまでに最大 24 時間かかります。Cost Anomaly Detection が Cost Explorer のコストデータを入力に使っており、そのデータ更新の遅延がそのまま検出の遅延になるためです。支出の急増をその場で止める仕組みではなく、翌日までには気付ける仕組みとして運用に組み込むのが現実的です。もう一つの見落としがちなコストは、CloudWatch Logs のデータ取り込み料金です。Lambda や ECS のログが大量に出力されると、CloudWatch Logs の取り込み料金 (us-east-1 で 0.50 USD/GB、東京リージョンでは 0.76 USD/GB) が想定以上に膨らみます。取り込み単価はリージョンによって差があるため、見積もりは利用するリージョンの単価で行ってください。ログレベルの適切な設定と、不要なログの保持期間の短縮が効果的な対策です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。