2026.09.23 インフラ

Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順

AWS Lambdaの請求書を開いて、Lambda本体より CloudWatch Logs の行が大きくて驚いた経験は珍しくありません。課金はリクエスト数とGB秒の2軸で決まりますが、月額を左右するのはその外側にある付帯課金です。この記事では、東京リージョンの単価を AWS Price List API の実測値で並べ、CLIの実行ログから課金GB秒を割り出す手順、CloudWatch Logs と API Gateway が請求に占める比率、メモリ振り直しと arm64 切り替えの手順までを扱います。数値はすべて2026年9月時点の一次情報に基づきます。

まとめ：Lambda料金の実額を決める単価と付帯課金の要点

東京リージョンのLambdaは、リクエスト100万件あたり0.20USD、x86の実行が1GB秒あたり0.0000166667USDです。無料枠は月100万リクエストと40万GB秒。管理画面の裏で動く程度の関数なら、この枠だけで月数十円に収まります。

月間数千万リクエストの規模に入ると景色が変わります。Lambda本体が月150USD前後の構成でも、REST API の API Gateway を前段に置けば127USD、ログを1実行あたり1KB出せば CloudWatch Logs が21USD上乗せされ、請求の半分近くを Lambda 以外が占めます。打ち手は効果の大きい順に「API Gateway を HTTP API へ替える」「ログ量と保持期間を削る」「arm64 へ切り替える」の3つ。メモリ削減は最後です。CPUがメモリに比例するため、下げると実行時間が伸びて逆効果になる領域があります。

Lambdaが割に合わなくなる条件は2つ。常時稼働に近い負荷が続く場合と、1実行が数分を超える処理を大量に回す場合で、前者は Fargate や EC2、後者は Lambda Managed Instances や Step Functions が受け皿になります。

東京リージョンのLambda単価とGB秒の段階制・無料枠の適用範囲

料金を読み違える原因は、単価がリージョンごとに違うことと、GB秒に段階制があることの2点です。AWSは AWS Lambda の料金ページで単価を公開していますが、表示がリージョン選択で切り替わるため、社内資料に米国標準リージョンの数字がそのまま入り込みがちです。ここでは東京リージョン（ap-northeast-1）の値だけを扱います。

Price List APIで実測した東京リージョンのリクエストとGB秒の単価

AWS Price List API の ap-northeast-1 オファーファイル（AWSLambda・版 20260919002359）から抽出した単価が下表です。リクエスト単価は x86 と arm64 で同額で、差が出るのは実行時間側だけになります。

課金項目	東京リージョンの単価
リクエスト	0.0000002USD／件
実行・x86（第1段階）	0.0000166667USD／GB秒
実行・arm64（第1段階）	0.0000133334USD／GB秒
エフェメラルストレージ	0.000000037USD／GB秒
レスポンスストリーミング	0.008USD／GiB
イベントポーラー（SQS）	0.0119USD／時
イベントポーラー（Kafka等）	0.238USD／時

リクエストは100万件あたり0.20USD。エフェメラルストレージは512MB超過分、ストリーミングは月100GiB超過分が対象です。見落とされやすいのが下2行のイベントポーラーで、SQS以外のイベントソースマッピングは1ユニットあたり0.238USD／時、24時間動かせば月171USDになります。関数を1度も呼ばなくても発生するため、Kafka連携を常時待ち受ける構成では本体より先に効いてきます。

x86とarm64で境界がずれるGB秒の3段階料金の適用条件

実行単価は月間GB秒の累計に応じた段階制で、段階の境界がアーキテクチャによって違います。

段階	x86の範囲（億GB秒）	x86の単価	arm64の範囲（億GB秒）	arm64の単価
第1段階	0〜60	0.0000166667	0〜75	0.0000133334
第2段階	60〜150	0.0000150000	75〜187.5	0.0000120001
第3段階	150超	0.0000133334	187.5超	0.0000106667

arm64は単価が2割安いうえ、段階の境界が25%高い位置にあります。第1段階の上限60億GB秒は、1,024MBの関数を毎秒2,000回・平均100msで回してようやく届く水準。中規模の業務システムなら第1段階だけで見積もって差し支えありません。

無料枠100万リクエストと40万GB秒が適用される範囲と対象外の項目

無料枠はリージョン別ではなくアカウント全体へ月単位で適用され、Price List API 上も Global の項目として定義されています。40万GB秒という枠は、512MBの関数を平均200msで動かすなら約400万回分。社内向けの通知バッチやWebhook受けなら、実運用でも枠内に収まることが珍しくありません。

枠外の項目には注意が必要です。Provisioned Concurrency の待機課金、SnapStart のキャッシュとリストア課金、レスポンスストリーミングの超過分は別勘定になります。Lambdaの仕組みと実行環境のライフサイクルはAWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断で扱っているため、ここでは金額の話に絞ります。

AWS CLIの実行ログから課金GB秒を割り出す月額試算の手順

見積もりの精度を決めるのは単価ではなく、平均実行時間と割り当てメモリの実測値です。想定で置いた200msが実際には480msだった、というずれは2.4倍の請求になります。

invokeのREPORT行から課金対象の時間とメモリを読む手順

Lambdaは実行のたびに REPORT 行をログへ出力し、課金対象の時間（Billed Duration）と割り当てメモリ、実使用メモリが並びます。CLIから確認します。

# 関数を1回実行し、末尾のREPORT行から課金対象の時間と実使用メモリを読む
aws lambda invoke \
  --function-name my-function \
  --log-type Tail \
  --query LogResult --output text \
  --region ap-northeast-1 response.json | base64 --decode | grep REPORT

# 出力例
# REPORT RequestId: 1a2b3c  Duration: 182.35 ms  Billed Duration: 183 ms
#        Memory Size: 512 MB  Max Memory Used: 96 MB  Init Duration: 210.11 ms

この例は Memory Size が512MBで Max Memory Used が96MB、メモリを持て余した状態です。ただし後述のとおり、ここで単純に下げると総額が上がる場合があります。単価そのものを確認したいときは、料金ページを読むより Price List API を叩くほうが確実です。

# 東京リージョンのLambda実行単価をAWS Price List APIから取得する
BASE=https://pricing.us-east-1.amazonaws.com
PATH_JSON=$(curl -s $BASE/offers/v1.0/aws/AWSLambda/current/region_index.json \
  | jq -r '.regions["ap-northeast-1"].currentVersionUrl')

curl -s $BASE$PATH_JSON | jq -r '
  .terms.OnDemand as $t
  | .products | to_entries[]
  | select(.value.attributes.usagetype == "APN1-Lambda-GB-Second")
  | .key as $sku
  | $t[$sku][].priceDimensions[]
  | "\(.beginRange)-\(.endRange) \(.pricePerUnit.USD)"'

月間リクエスト数と平均実行時間から月額を概算する規模別の試算表

課金GB秒は「リクエスト数 × 平均実行時間（秒） × メモリ（GB）」で求めます。x86・1,024MB・平均300ms・月3,000万リクエストなら、3,000万 × 0.3 × 1 = 900万GB秒。無料枠40万GB秒を引いた860万GB秒に0.0000166667USDを掛けて143.33USD、リクエスト側は2,900万件で5.80USD、合計149.13USDです。

構成	月間課金GB秒	本体の月額（x86・東京）
300万req・200ms・512MB	30万（全量が無料枠内）	0.40USD
3,000万req・300ms・1,024MB	900万	149.13USD
同上・arm64	900万	120.47USD

小規模側では実行課金がほぼ消えます。それでも請求が数十USDに膨らむのは、次章の付帯課金が理由です。

Lambda本体より高くつくCloudWatch LogsとAPI Gatewayの単価

Lambdaが単体で動くことはほとんどありません。前段にAPI Gateway、背後にCloudWatch Logsがつき、この2つが請求に占める比率は本体と同等かそれ以上です。単価表だけの見積もりが外れる理由がここにあります。

CloudWatch Logsの取り込み0.76USD／GBが本体を上回る条件

CloudWatchの料金表によると、東京リージョンのカスタムログ取り込みはStandardログクラスで0.76USD／GB、保存は0.033USD／GB月、Logs Insightsのスキャンは0.0076USD／GBです。

1実行あたり1KBのログを出す関数を月3,000万回動かすと、取り込み量は約28.6GBで21.74USD。前章の本体149.13USDに対して15%の上乗せで済みます。問題はデバッグログを残したまま本番へ出た場合で、1実行10KBなら286GBの217USD、本体を超えます。Lambdaのログ送信に関する公式ドキュメントのとおりログはLambdaが自動でCloudWatch Logsへ送るため、コード側でログレベルを絞る以外に流量を止める手立てはありません。

# ログ保持期間を14日に設定し、保存料金の累積を止める
aws logs put-retention-policy \
  --log-group-name /aws/lambda/my-function \
  --retention-in-days 14 \
  --region ap-northeast-1

API GatewayのREST APIがLambda本体を上回る21倍の単価差

API Gatewayの料金は東京リージョンでREST APIが100万リクエストあたり4.25USD（最初の3.33億リクエスト）、HTTP APIが1.29USD（最初の3億リクエスト）です。Lambdaのリクエスト単価0.20USDと比べると、REST APIは21倍、HTTP APIでも6.5倍になります。

月3,000万リクエストのAPIなら、REST APIで127.50USD、HTTP APIで38.70USD。Lambda本体149.13USDと並べると、REST APIを選んだ時点で請求はほぼ倍です。WAF連携やAPIキーによる使用量プランを要件が求めていないなら、HTTP APIへ寄せるだけで月89USDが消えます。関数のチューニングでは届かない額です。ストレージ側の内訳はS3の料金を実額で計算するでも同じ形式でまとめています。

メモリ設定の振り直しとPower Tuningで1実行あたりの総額を下げる調整

付帯課金を削ったうえで本体に手を入れるなら、最初の対象はメモリ設定です。メモリ設定の公式ドキュメントは、LambdaがCPUをメモリ量に比例して割り当てると明記しています。この一文が料金の直感を裏切ります。

1,769MBで1vCPU相当というCPU割り当てと総額が逆転する条件

設定できるメモリは128MBから10,240MBまで1MB刻みで、1,769MBを割り当てた時点で1vCPU相当になります。それ以下はvCPUの取り分が1未満です。

CPUバウンドな処理では、メモリを2倍にすると実行時間が半分近くまで縮み、GB秒は変わらないまま応答だけが速くなります。128MBで3秒かかる画像変換を512MBで0.6秒に縮められるなら、GB秒は0.375から0.3へ下がり総額まで安くなる計算です。公式ドキュメントも128MBは単純なイベント変換とルーティング用途に限って推奨しています。

逆に、外部APIの応答待ちが大半を占めるI/Oバウンドな関数では、メモリを増やしても待ち時間は縮まずGB秒だけが増えます。判断軸は単純で、CPUを使う処理は上げ、待つだけの処理は下げる。見るべき数値は Max Memory Used ではなく、メモリを変えたときの Billed Duration の変化です。

Lambda Power Tuningで最安のメモリ値を実測する手順

メモリと実行時間の関係は処理内容ごとに違い、机上では決まりません。公式ドキュメントが名指しで紹介しているのが AWS Lambda Power Tuning です。Step Functionsのステートマシンとして動き、同じ関数を複数のメモリ設定で並列実行して所要時間と料金を測ります。

Serverless Application Repositoryからステートマシンをデプロイする
対象関数のARNと試したいメモリ値の配列（128・512・1024・1769・3008など）を入力に渡して実行する
出力される最安構成と最速構成を比較し、応答時間の要件を満たす範囲で安いほうを採る

本番同等の入力で回すことが条件です。テスト用の軽いペイロードで測ると、実運用より小さいメモリが最安と出ます。値が決まったら設定へ反映してください。

# 実測で決めたメモリ値を関数へ反映する
aws lambda update-function-configuration \
  --function-name my-function \
  --memory-size 1024 \
  --region ap-northeast-1

arm64への切り替えとSavings Plansで単価そのものを下げる選択

使用量を変えずに単価側を下げる手段が2つあります。アーキテクチャの切り替えとSavings Plansによる割引で、どちらも関数のロジックに手を入れずに効きます。

arm64への切り替えで2割下がる実行単価とCompute Optimizerの制約

前掲のとおり、arm64の実行単価は第1段階で0.0000133334USD／GB秒、x86の0.0000166667USDに対してちょうど20%安です。月900万GB秒の構成なら143.33USDが114.67USDになり、年間で約344USDの差が出ます。切り替えはアーキテクチャ指定の変更とパッケージの再ビルドで済みます。

制約が1つあります。AWS Compute Optimizerのメモリ推奨はx86_64の関数だけが対象で、arm64へ移した関数には推奨が出ません。メモリの実測チューニングを先に済ませ、確定した値でarm64へ移す順序にすると両方の利点を取れます。

Compute Savings Plansが適用される範囲と最大66%という前提

Compute Savings PlansはEC2・Fargateに加えてLambdaにも適用され、1年または3年の利用量をコミットすることで最大66%の削減が示されています。ただしこの66%はEC2を含む全体の最大値で、Lambda単体の割引率は小さくなります。

判断の目安は、Lambdaの月額が安定して数百USDに達しているかどうかです。スパイク型のワークロードでコミット額を高く置くと、使い切れない分がそのまま損失になります。月額が二桁USDの段階なら、前章までの付帯課金の削減を先に打ってください。

Provisioned ConcurrencyとSnapStart導入時に増える課金項目

コールドスタート対策の2つの機能は、どちらも課金体系を変えます。「速くする代わりに高くなる」と単純化されがちですが、項目が増えるものと実行単価が下がるものが混在しています。

Provisioned Concurrencyの待機課金と実行単価が下がる条件

Provisioned Concurrencyは実行環境を事前に初期化して待機させる機能で、東京リージョンでは待機分が0.0000053835USD／GB秒（arm64は0.0000043068USD）かかります。呼ばれなくても発生する課金です。

見落とされやすいのは、有効化した関数の実行単価が別立てになり、x86で0.0000125615USD／GB秒と通常より約25%安くなる点です。実行量が多いほど、待機課金を実行側の割引が相殺します。1,024MBの関数を1つ常時確保すると待機だけで月約14USD。日中8時間だけなら、Application Auto Scalingのスケジュール設定で確保時間を絞ってください。

SnapStartでキャッシュとリストアが別課金になるランタイム

「SnapStartは追加費用なし」という説明は、2026年9月時点では正確ではありません。SnapStartの公式ドキュメントのとおり無償なのはJavaのマネージドランタイムに限られ、Python 3.12以降と.NET 8以降ではスナップショットのキャッシュ料金とリストア料金が別に発生します。東京リージョンの単価はキャッシュが0.0000015046USD／GB秒（最低3時間分）、リストアが0.0001397998USD／GBです。

1,024MBの関数でバージョンを1つ保持すれば、キャッシュだけで月約4USD。発行するたびに積み上がるため、古いバージョンを残す運用では想定外の額になります。有効化できるのは発行済みバージョンだけで、$LATESTには設定できません。

Lambdaの従量課金が割に合わなくなる条件と移行先の判断基準

ここまでの単価をそろえると、Lambdaが不利になる条件は計算で出せます。境界は稼働率と1実行の長さの2つです。

常時稼働に近い負荷でLambdaがEC2より割高になる稼働率の分岐点

1,024MBの関数を24時間365日動かし続けると、月730時間 × 3,600秒 × 1GB × 0.0000166667USD で約43.80USD。同じ東京リージョンのFargateはvCPUが0.05056USD／時、メモリが0.00553USD／GB時なので、0.5vCPU・1GBのタスクを常時動かすと月約22.49USD。Lambdaの半分強で収まります。

ただし単価だけを比べるのは誤りです。EC2やFargateにはコンテナ定義・スケーリング設定・監視の運用工数が乗り、月20USDの差はエンジニア1時間分にも届きません。判断基準は負荷の変動幅に置いてください。ピークと谷が10倍以上動くなら、谷で課金が消えるLambdaのほうが年間では安く付きます。平坦な負荷ならAmazon EC2側へ寄せる。この線で切ります。移行判断にはワークロードの実測が前提になるため、構成の棚卸しから相談したい場合はインフラ構築（AWS・Google Cloud・Azure）で対応しています。

長時間処理をManaged InstancesやStep Functionsへ逃がす判断

Lambdaのクォータ一覧によると、標準の関数のタイムアウトは900秒（15分）です。一方、Lambda Managed Instancesの関数は非同期呼び出しとイベントソースマッピング経由（Amazon MQとDocumentDBを除く）で5,400秒（90分）まで許容されます。15分で足りない処理への選択肢は、現在3つあります。

Managed Instances：自アカウントのEC2上で動き、EC2料金に管理手数料が乗る
Durable Functions：操作0.0000106USD・保存0.20USD／GB月・書き込み0.33USD／GBという別体系で、待機中の実行課金が発生しない
Step Functions：複数の関数を段階に分けて15分の制限内に収める

待ち時間が処理の大半を占めるワークフローなら Durable Functions が最も安く、実装はLambda Durable Functionsとは？東京リージョン対応と15分制限を超える長時間ワークフロー実装で扱っています。純粋にCPU処理が長いなら Managed Instances、業務フローとして段階が分かれるならAWS Step Functions。待機時間の比率で決めるのが早道です。

よくある質問

Lambdaの料金について繰り返し問われる5つの論点に答えます。数値はいずれも東京リージョン・2026年9月時点のものです。

Lambdaの無料枠に期限はありますか？

月100万リクエストと40万GB秒の枠は、AWS Price List API 上でもGlobalの項目として定義されており、アカウント作成から12か月で切れる無料枠とは別の扱いです。毎月リセットされ、リージョンをまたいで合算されます。ただしProvisioned ConcurrencyやSnapStartのキャッシュ料金は枠の対象外で、無料枠内の使用量でも請求が発生します。

メモリを下げれば料金は必ず安くなりますか？

いいえ。LambdaはCPUをメモリ量に比例して割り当てるため、CPUを使う処理でメモリを下げると実行時間が伸び、GB秒が増えて総額が上がる場合があります。1,769MBで1vCPU相当という基準が公式ドキュメントに明記されており、それ以下は1vCPU未満の配分です。判断は Billed Duration の実測で行ってください。

x86とarm64ではどれくらい料金が変わりますか？

実行単価は第1段階でx86が0.0000166667USD／GB秒、arm64が0.0000133334USD／GB秒で、ちょうど20%の差です。リクエスト単価は両者とも0.0000002USD／件で変わりません。段階制の境界もarm64のほうが25%高い位置にあるため、規模が大きいほど差が開きます。

LambdaでCloudWatch Logsの請求が高くなるのはなぜですか？

東京リージョンのログ取り込みが0.76USD／GBで、Lambdaのリクエスト単価（100万件で0.20USD）と桁が違うためです。1実行あたり10KBのログを月3,000万回出すと286GBで217USDとなり、本体の実行課金を超えます。保持期間の既定は無期限のため、put-retention-policy で日数を設定してください。

Lambdaの実行時間は最長で何分までですか？

標準の関数は900秒（15分）です。Lambda Managed Instancesの関数に限り、非同期呼び出しとイベントソースマッピング経由（Amazon MQとAmazon DocumentDBを除く）で5,400秒（90分）まで設定できます。さらに長い処理はDurable Functionsのチェックポイント方式やStep Functionsによる分割で扱ってください。