--- title: "AWS Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順" url: "https://www.issoh.co.jp/tech/details/17740/" published: 2026-09-23 updated: 2026-10-18 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順 AWS Lambdaの請求書を開いて、Lambda本体より CloudWatch Logs の行が大きくて驚いた経験は珍しくありません。課金はリクエスト数とGB秒の2軸で決まりますが、月額を左右するのはその外側にある付帯課金です。この記事では、AWS Lambdaの料金を東京リージョンの単価で AWS Price List API の実測値から並べ、CLIの実行ログから課金GB秒を割り出す手順、CloudWatch Logs・API Gateway・NAT Gateway が請求に占める比率、Cost Explorer で請求のLambda分を確かめる方法、メモリ振り直しと 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がメモリに比例するため、下げると実行時間が伸びて逆効果になる領域があります。RDS接続のためにVPCへ入れた関数では、NAT Gatewayの固定費（2AZで月約90USD）が本体を桁違いに上回る場合もあり、構成図の段階で通信経路を確かめておく必要があります。 Lambdaが割に合わなくなる条件は2つ。常時稼働に近い負荷が続く場合と、1実行が数分を超える処理を大量に回す場合で、前者は Fargate や EC2、後者は Lambda Managed Instances や Step Functions が受け皿になります。 ## 東京リージョンのLambda単価とGB秒の段階制・無料枠の適用範囲 料金を読み違える原因は、単価がリージョンごとに違うことと、GB秒に段階制があることの2点です。AWSは [AWS Lambda の料金ページ](https://aws.amazon.com/jp/lambda/pricing/)で単価を公開していますが、表示がリージョン選択で切り替わるため、社内資料に米国標準リージョンの数字がそのまま入り込みがちです。ここでは東京リージョン（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連携を常時待ち受ける構成では本体より先に効いてきます。SQSをイベントソースにしたときにキュー側で増えるリクエスト料金は、[Amazon SQSの料金を東京リージョンの実額で試算する：64KB課金・FIFO単価・ロングポーリングでの削減手順](https://www.issoh.co.jp/tech/details/18453/)で空受信の数え方とあわせて試算しています。 ### 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とは？仕組み・料金体系とコールドスタート対策・採用判断](https://www.issoh.co.jp/tech/details/15407/)で扱っているため、ここでは金額の話に絞ります。 ### 1ミリ秒単位の切り上げと初期化コードまで数える実行時間の定義 GB秒の「秒」がどこからどこまでを指すかは、[料金ページ](https://aws.amazon.com/jp/lambda/pricing/)の注記に定義があります。実行時間はコードの実行開始から処理が返るか中止されるまでで、1ミリ秒単位で切り上げます。平均3.2msで終わる軽い関数でも4ms分を払う計算ですが、100ms単位だった頃と比べれば端数の影響はほぼ消えました。 見落としやすいのは同じ注記の後半です。ハンドラーの外に書いた初期化コードの実行時間も課金対象に入り、Lambda拡張機能を使う関数ではシャットダウンフェーズで拡張機能が終わるまでの時間も含まれます。ライブラリの読み込みやDB接続の確立をハンドラー外に置く書き方は再利用の面で正しいものの、コールドスタートの回数が多い関数では初期化にかかった秒数もそのまま請求の対象です。依存パッケージを削ってデプロイサイズを小さくする作業は、応答時間だけでなく料金の対策にもなります。 ## 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 | 同じ計算をスクリプトにしておくと、メモリや平均実行時間を変えたときの差をすぐ確かめられます。第1段階の単価と無料枠の控除だけを入れた最小の形です。 ``` # 東京リージョン・x86のLambda本体の月額を試算する（第1段階の単価、無料枠を控除） REQ_PRICE = 0.0000002 # USD／リクエスト GBS_PRICE = 0.0000166667 # USD／GB秒（arm64なら0.0000133334） def lambda_monthly_usd(requests, avg_sec, memory_mb): gb_seconds = requests * avg_sec * (memory_mb / 1024) billable_gbs = max(gb_seconds - 400_000, 0) billable_req = max(requests - 1_000_000, 0) return billable_gbs * GBS_PRICE + billable_req * REQ_PRICE print(round(lambda_monthly_usd(30_000_000, 0.3, 1024), 2)) # 149.13 print(round(lambda_monthly_usd(3_000_000, 0.2, 512), 2)) # 0.4 ``` 円で社内稟議に載せる場合は、為替を仮に1USD＝150円と置くと149.13USDは約2万2,370円、arm64の120.47USDは約1万8,070円です。単価はUSD建てで、円での金額は為替によって月ごとに動くため、稟議書には採用したレートを併記しておくと後で差額の説明に困りません。画面操作で見積もる場合の料金計算ツールの使い方は[AWSの見積もりとは？料金計算ツールの使い方と費用が変わる要因](https://www.issoh.co.jp/column/details/13183/)で整理しています。 小規模側では実行課金がほぼ消えます。それでも請求が数十USDに膨らむのは、次章の付帯課金が理由です。 ## Lambda本体より高くつくCloudWatch LogsとAPI Gatewayの単価 Lambdaが単体で動くことはほとんどありません。前段にAPI Gateway、背後にCloudWatch Logsがつき、この2つが請求に占める比率は本体と同等かそれ以上です。単価表だけの見積もりが外れる理由がここにあります。 ### CloudWatch Logsの取り込み0.76USD／GBが本体を上回る条件 [CloudWatchの料金表](https://aws.amazon.com/jp/cloudwatch/pricing/)によると、東京リージョンのカスタムログ取り込みは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のログ送信に関する公式ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)のとおりログはLambdaが自動でCloudWatch Logsへ送るため、コード側でログレベルを絞る以外に流量を止める手立てはありません。JSON構造化ログへの切り替えやS3への長期退避まで含めた運用の組み立ては[AWS Lambdaのログ運用ガイド](https://www.issoh.co.jp/tech/details/4031/)にまとめています。 ``` # ログ保持期間を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の料金](https://aws.amazon.com/jp/api-gateway/pricing/)は東京リージョンでREST APIが100万リクエストあたり4.25USD（最初の3.33億リクエスト）、HTTP APIが1.29USD（最初の3億リクエスト）です。Lambdaのリクエスト単価0.20USDと比べると、REST APIは21倍、HTTP APIでも6.5倍になります。段階制単価やWebSocket・キャッシュ・WAFまで含めた試算は[API Gatewayの料金を東京リージョンの実額で計算する：REST・HTTP・WebSocketの単価と付帯課金](https://www.issoh.co.jp/tech/details/18477/)で扱っています。 月3,000万リクエストのAPIなら、REST APIで127.50USD、HTTP APIで38.70USD。Lambda本体149.13USDと並べると、REST APIを選んだ時点で請求はほぼ倍です。WAF連携やAPIキーによる使用量プランを要件が求めていないなら、HTTP APIへ寄せるだけで月89USDが消えます。関数のチューニングでは届かない額です。ストレージ側の内訳は[S3の料金を実額で計算する](https://www.issoh.co.jp/tech/details/17537/)でも同じ形式でまとめています。データベース側の単価内訳は[DynamoDBの料金を東京リージョンの実額で試算する](https://www.issoh.co.jp/tech/details/17798/)で示しているのは、GSIとScanが請求を押し上げる条件まで含めた計算結果です。LambdaからRDSへ接続する構成なら、[AWS RDSの料金を東京リージョンの実額で計算する](https://www.issoh.co.jp/tech/details/17883/)で延長サポート課金を含めた月額を同じ手順で出せます。 ### VPC内のLambdaが外部APIへ出るときのNAT Gateway課金 RDSやElastiCacheへ接続するためにLambdaをVPCへ入れると、外部APIやSaaSへの通信経路が変わります。[VPC接続のLambdaに関する公式ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc-internet.html)のとおり、VPCに接続した関数はそのままではインターネットへ出られず、プライベートサブネットからNAT Gatewayを経由させる構成が必要です。ドキュメントは耐障害性のためにAZごと1台を勧めています。 [Amazon VPCの料金ページ](https://aws.amazon.com/jp/vpc/pricing/)が参照する東京リージョンの単価データ（2026年9月25日公開版）では、NAT Gatewayは1台0.062USD／時、処理データが0.062USD／GBです。2AZに1台ずつ置くと、通信がほぼ無くても730時間 × 2台で月90.52USD。前掲の300万リクエスト規模の関数なら、Lambda本体の0.40USDに対してNAT Gatewayの固定費が200倍を超えます。1時間未満の稼働も1時間として数えるため、検証環境で作っては消す運用でも端数が積み上がります。 削り方は通信先で分かれます。S3とDynamoDBへの通信は[ゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html)に向ければ追加料金なしでNAT Gatewayを迂回でき、データ処理料も消えます。外部APIを呼ぶ必要が無い関数では、そもそもVPCに入れない構成を選ぶことが、費用を最も安く抑える方法です。NAT GatewayとNATインスタンスの費用差は[NAT ゲートウェイと NAT インスタンスの違い・料金](https://www.issoh.co.jp/tech/details/3868/)、インターフェース型エンドポイントとの損益分岐は[VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点](https://www.issoh.co.jp/tech/details/2326/)で計算しています。 ``` # 関数がVPCに接続されているか（SubnetIdsが空でなければNAT Gateway経由の課金対象になりうる） aws lambda get-function-configuration \ --function-name my-function \ --query 'VpcConfig.{Subnets:SubnetIds,SecurityGroups:SecurityGroupIds}' \ --region ap-northeast-1 ``` ## メモリ設定の振り直しとPower Tuningで1実行あたりの総額を下げる調整 付帯課金を削ったうえで本体に手を入れるなら、最初の対象はメモリ設定です。[メモリ設定の公式ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html)は、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](https://github.com/alexcasalboni/aws-lambda-power-tuning) です。Step Functionsのステートマシンとして動き、同じ関数を複数のメモリ設定で並列実行して所要時間と料金を測ります。 1. Serverless Application Repositoryからステートマシンをデプロイする 2. 対象関数のARNと試したいメモリ値の配列（128・512・1024・1769・3008など）を入力に渡して実行する 3. 出力される最安構成と最速構成を比較し、応答時間の要件を満たす範囲で安いほうを採る 本番同等の入力で回すことが条件です。テスト用の軽いペイロードで測ると、実運用より小さいメモリが最安と出ます。値が決まったら設定へ反映してください。 ``` # 実測で決めたメモリ値を関数へ反映する 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](https://aws.amazon.com/jp/savingsplans/compute-pricing/)はEC2・Fargateに加えてLambdaにも適用され、1年または3年の利用量をコミットすることで最大66%の削減が示されています。ただしこの66%はEC2を含む全体の最大値で、Lambda単体の割引率は小さくなります。 判断の目安は、Lambdaの月額が安定して数百USDに達しているかどうかです。スパイク型のワークロードでコミット額を高く置くと、使い切れない分がそのまま損失になります。月額が二桁USDの段階なら、前章までの付帯課金の削減を先に打ってください。 ## Provisioned ConcurrencyとSnapStart導入時に増える課金項目 コールドスタート対策の2つの機能は、どちらも課金体系を変えます。「速くする代わりに高くなる」と単純化されがちですが、項目が増えるものと実行単価が下がるものが混在しています。 ### Provisioned Concurrencyの待機課金と実行単価が下がる条件 [Provisioned Concurrency](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html)は実行環境を事前に初期化して待機させる機能で、東京リージョンでは待機分が0.0000053835USD／GB秒（arm64は0.0000043068USD）かかります。呼ばれなくても発生する課金です。 見落とされやすいのは、有効化した関数の実行単価が別立てになり、x86で0.0000125615USD／GB秒と通常より約25%安くなる点です。実行量が多いほど、待機課金を実行側の割引が相殺します。1,024MBの関数を1つ常時確保すると待機だけで月約14USD。日中8時間だけなら、Application Auto Scalingのスケジュール設定で確保時間を絞ってください。 ### SnapStartでキャッシュとリストアが別課金になるランタイム 「SnapStartは追加費用なし」という説明は、2026年9月時点では正確ではありません。[SnapStartの公式ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html)のとおり無償なのはJavaのマネージドランタイムに限られ、Python 3.12以降と.NET 8以降ではスナップショットのキャッシュ料金とリストア料金が別に発生します。東京リージョンの単価はキャッシュが0.0000015046USD／GB秒（最低3時間分）、リストアが0.0001397998USD／GBです。 1,024MBの関数でバージョンを1つ保持すれば、キャッシュだけで月約4USD。発行するたびに積み上がるため、古いバージョンを残す運用では想定外の額になります。有効化できるのは発行済みバージョンだけで、$LATESTには設定できません。 ## Cost ExplorerのLambda請求内訳とBudgetsの超過検知手順 試算と実際の請求がずれていないかは、月末を待たずに確かめられます。請求の内訳を見る道具が Cost Explorer、使い過ぎを知らせる道具が AWS Budgets です。どちらも関数のコードには触れずに設定できます。 ### get-cost-and-usageでLambdaの請求をリクエストとGB秒に分解する [get-cost-and-usageのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/ce/get-cost-and-usage.html)にあるとおり、SERVICEで絞り込み、USAGE\_TYPEでグループ化すると、Lambdaの請求がリクエスト課金・GB秒課金・Provisioned Concurrencyなどの使用タイプ別に並びます。試算のどの項目が外れたかを特定するにはこの粒度が要ります。 ``` # 2026年9月分のAWS Lambdaの請求を使用タイプ別に集計する aws ce get-cost-and-usage \ --time-period Start=2026-09-01,End=2026-10-01 \ --granularity MONTHLY \ --metrics UnblendedCost UsageQuantity \ --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Lambda"]}}' \ --group-by Type=DIMENSION,Key=USAGE_TYPE ``` 注意点が2つあります。1つは、CloudWatch Logs・API Gateway・NAT Gatewayの請求はそれぞれ別のサービス名で計上されるため、SERVICEをAWS Lambdaに絞った結果には出てこないことです。付帯課金まで含めた「このLambdaアプリの総額」を見たいなら、関数と周辺リソースに共通のタグを付けてコスト配分タグとして有効化し、タグでグループ化します。もう1つは、[Cost Explorerの料金](https://aws.amazon.com/jp/aws-cost-management/aws-cost-explorer/pricing/)のとおりAPI経由の照会は1リクエスト0.01USDかかる点です。日次バッチで叩く程度なら月数十円ですが、ダッシュボードから毎分呼ぶ作りにすると無視できない額になります。画面での分析方法は[AWS Cost Explorerとは？コスト可視化・分析の仕組みと料金](https://www.issoh.co.jp/tech/details/15628/)で解説しています。 ### AWS BudgetsでLambdaの月額に上限を置き、予測超過で通知する設定 試算で月150USDと見込んだなら、その金額を予算として登録し、実績または予測が8割を超えた時点で通知させます。[create-budgetのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/budgets/create-budget.html)では絞り込みの書き方としてCostFiltersとFilterExpressionの2系統が示され、両者は併用できません。サービス1つで絞るだけなら次の形で足ります。 ``` # budget.json：AWS Lambdaのコストだけを対象にした月150USDの予算 { "BudgetName": "lambda-monthly", "BudgetLimit": { "Amount": "150", "Unit": "USD" }, "TimeUnit": "MONTHLY", "BudgetType": "COST", "CostFilters": { "Service": ["AWS Lambda"] } } # notifications.json：予測額が予算の80%を超えたらメール通知 [ { "Notification": { "NotificationType": "FORECASTED", "ComparisonOperator": "GREATER_THAN", "Threshold": 80, "ThresholdType": "PERCENTAGE" }, "Subscribers": [ { "SubscriptionType": "EMAIL", "Address": "ops@example.com" } ] } ] # 予算を登録する aws budgets create-budget \ --account-id 123456789012 \ --budget file://budget.json \ --notifications-with-subscribers file://notifications.json ``` 通知の種類は実績（ACTUAL）より予測（FORECASTED）を先に置くほうが役に立ちます。ログの出し過ぎや再試行のループは月の前半に兆候が出るため、予測ベースの通知なら、月末の請求が確定する前にこれらを止めることが可能です。予算・タグ・アラートの設計をアカウント全体で整えたい場合は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)の中で既存環境の棚卸しから対応しています。 ## Lambdaの従量課金が割に合わなくなる条件と移行先の判断基準 ここまでの単価をそろえると、Lambdaが不利になる条件は計算で出せます。境界は稼働率と1実行の長さの2つです。 ### 常時稼働に近い負荷でLambdaがEC2より割高になる稼働率の分岐点 1,024MBの関数を24時間365日動かし続けると、月730時間 × 3,600秒 × 1GB × 0.0000166667USD で約43.80USD。同じ東京リージョンの[Fargate](https://aws.amazon.com/jp/fargate/pricing/)はvCPUが0.05056USD／時、メモリが0.00553USD／GB時なので、0.5vCPU・1GBのタスクを常時動かすと月約22.49USD。Lambdaの半分強で収まります。 ただし単価だけを比べるのは誤りです。EC2やFargateにはコンテナ定義・スケーリング設定・監視の運用工数が乗り、月20USDの差はエンジニア1時間分にも届きません。判断基準は負荷の変動幅に置いてください。ピークと谷が10倍以上動くなら、谷で課金が消えるLambdaのほうが年間では安く付きます。平坦な負荷なら[Amazon EC2](https://www.issoh.co.jp/tech/details/15424/)側へ寄せる。この線で切ります。移行判断にはワークロードの実測が前提になるため、構成の棚卸しから相談したい場合は[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)で対応しています。 ### 長時間処理をManaged InstancesやStep Functionsへ逃がす判断 [Lambdaのクォータ一覧](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)によると、標準の関数のタイムアウトは900秒（15分）です。一方、Lambda Managed Instancesの関数は非同期呼び出しとイベントソースマッピング経由（Amazon MQとDocumentDBを除く）で5,400秒（90分）まで許容されます。15分で足りない処理への選択肢は、現在3つあります。 - Managed Instances：自アカウントのEC2上で動き、EC2料金に管理手数料が乗る（東京の手数料実額と損益分岐は[Lambda Managed Instancesの料金試算](https://www.issoh.co.jp/tech/details/17767/)で解説） - Durable Functions：操作0.0000106USD・保存0.20USD／GB月・書き込み0.33USD／GBという別体系で、待機中の実行課金が発生しない - Step Functions：複数の関数を段階に分けて15分の制限内に収める 待ち時間が処理の大半を占めるワークフローなら Durable Functions が最も安く、実装は[Lambda Durable Functionsとは？東京リージョン対応と15分制限を超える長時間ワークフロー実装](https://www.issoh.co.jp/tech/details/10107/)で扱っています。純粋にCPU処理が長いなら Managed Instances、業務フローとして段階が分かれるなら[AWS Step Functions](https://www.issoh.co.jp/tech/details/15429/)。待機時間の比率で決めるのが早道です。 ## よくある質問 Lambdaの料金について繰り返し問われる5つの論点に答えます。数値はいずれも東京リージョン・2026年9月時点のものです。 ### Lambdaの無料枠に期限はありますか？ AWS 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による分割で扱ってください。 ## 関連記事 - [AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15407/)：金額の前提となる実行環境のライフサイクル - [S3の料金を実額で計算する｜東京リージョンの単価内訳とコストを下げる設定手順](https://www.issoh.co.jp/tech/details/17537/)：ストレージ側の単価内訳 - [FaaSとは？サーバーレスとの関係・実行時間やコールドスタートの制約と採用判断](https://www.issoh.co.jp/tech/details/13204/)：Lambdaが属する実行モデルの制約 - [サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説](https://www.issoh.co.jp/column/details/13005/)：検討段階での使い分けの整理 - [Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15424/)：常時稼働での比較対象 - [AWS RDSの料金を東京リージョンの実額で計算する：延長サポート課金と単価の下げ方](https://www.issoh.co.jp/tech/details/17883/)：Lambdaの接続先になるDB側の月額 - [AWS Lambdaのログ運用ガイド｜CloudWatch Logsの見方・JSON構造化・S3出力とコスト削減](https://www.issoh.co.jp/tech/details/4031/)：ログ課金を抑える運用の具体策 --- 出典: [AWS Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順]()（株式会社一創）