Lambdaのコストと速度をチューニングする ― レンタルサーバー経営者だった私が、自社フォームのログで確かめたこと

この記事の数値は、当サイトのお問い合わせフォームを処理しているLambda関数のCloudWatch Logsを、2026年11月13日に集計した実測値です。料金と仕様は同日時点の公式情報で確認しました。同日夜に追記：記事の計画どおり本番の関数を更新し、設定ごとの効果を測り直した結果を「本番を更新して、測り直した」に載せました。予想が外れた点もあります。

電話が一斉に鳴る、あの怖さを知っている者として

サーバーの台数を数えることも、OSにパッチを当てることもありません。リクエストが来たときだけ関数が起動し、動いた時間の分だけ料金を払う。機械が壊れる心配は、AWSの側に渡せます。

ただ、手放せないものも残ります。今回、このサイトの問い合わせフォームを処理しているLambdaを見直したところ、2025年6月に作ったときのNode.js 18のまま、メモリも初期値の128MBのまま動いていました。Node.js 18のランタイムは、2025年9月1日に非推奨になっています。サーバーレスでも、放っておいてよいわけではありませんでした。

この記事では、その関数の実際のログを材料に、料金の仕組み、メモリ、Graviton（arm64）、コールドスタート、ログの順に、どこを見直すと費用と待ち時間に効くのかを確かめます。先に結論を書くと、この関数の料金はほぼゼロでした。見直す意味は料金よりも、「お客さまを待たせている時間」と「放置していたランタイム」の側にありました。

Lambdaの料金は「メモリ×時間」で決まる

Lambdaの料金は、リクエスト数と実行時間の2つで決まります。実行時間は、関数に割り当てたメモリ（GB）と実行した秒数を掛けた「GB-秒」で数え、1ミリ秒単位で請求されます。東京リージョンの単価は次のとおりです。

毎月100万リクエストと40万GB-秒までは無料利用枠に収まります。たとえば128MB（0.125GB）で1秒動くと0.125GB-秒、x86_64なら約0.0000021ドルです。メモリを倍にすれば、同じ1秒でも料金は倍になります。逆に、メモリを倍にして実行時間が半分になれば、料金は変わりません。この関係が、あとで出てくるメモリ調整の土台になります。

2025年8月から、初期化の時間も請求されるようになった

コールドスタートは、関数の実行環境が新しく作られるときに走る起動処理です。ランタイムの起動、コードの読み込み、ハンドラーの外に書いた初期化処理（SDKのクライアントを作る処理など）がここで動きます。この時間は、ログに Init Duration として出ます。

以前は、ZIPで配布したマネージドランタイムの関数なら、この初期化（INITフェーズ）の時間は請求されませんでした。AWSは2025年8月1日から、INITフェーズの時間も請求対象の Billed Duration に含めるよう、課金を統一しています。AWSはコールドスタートが呼び出し全体の1%未満だとして、多くの利用者への影響は小さいと説明しています。ところが、呼び出しがまばらな関数では事情が違いました。それが、次の実測ではっきり出ています。

自分のフォームのLambdaを測る

対象は、このサイトの問い合わせフォームです。ブラウザからAPI Gateway経由で呼ばれ、Amazon SESでメールを送るだけの関数で、コード本体は3KBほどしかありません。見直し前の設定は次のとおりでした。

• ランタイムは nodejs18.x、アーキテクチャは x86_64
• メモリは初期値の128MB、タイムアウトも初期値の3秒
• ZIPは6.4MB（AWS SDK for JavaScript v3のSESクライアントと依存パッケージを同梱）
• ロググループの保持期間は「無期限」

測るのに特別なツールは使っていません。Lambdaは呼び出しのたびに REPORT という行をCloudWatch Logsへ書き出し、そこに実行時間、請求時間、初期化時間、使ったメモリの最大値が入っています。CloudWatch Logs Insightsで次のクエリを流すと、コールドスタートの呼び出しと、既存の実行環境を使い回した呼び出し（ウォームスタート）に分けて集計できます。

filter @type = "REPORT"
| fields ispresent(@initDuration) as isCold
| stats count(*) as n,
        avg(@duration) as dur,
        avg(@billedDuration) as billed,
        avg(@initDuration) as init,
        max(@maxMemoryUsed)/1000/1000 as memMB
  by isCold

コンソールなら、CloudWatchの「Logs Insights」でロググループ /aws/lambda/関数名 を選び、期間を指定してこのクエリを貼り付けるだけです。期間はINITの課金が始まった2025年8月1日から2026年11月13日までにしました。この間の呼び出しは70回です（最初の記録は2025年10月5日）。

まず目に付くのは、70回のうち50回、つまり7割がコールドスタートだったことです。問い合わせは多い月でも十数回なので、前の呼び出しから時間が空き、実行環境がほぼ毎回作り直されています。AWSの言う「1%未満」は、呼び出しの多い関数まで含めた全体の話です。小さな業務の関数では、コールドスタートのほうが普通の状態になります。

次に請求時間を見ると、コールドスタートの1,561msは、実行時間1,174msと初期化時間386msの合計とほぼ一致します。2025年7月以前のログでは、コールドスタートでも請求時間は実行時間と同じでした（4回の平均で、実行時間901ms、請求時間902ms）。8月の課金変更が、手元のログにもそのまま表れています。

では、いくら払っているのか。コールドスタート1回は1.561秒×0.125GBで約0.195GB-秒、金額にして約0.0000033ドルです。ウォームスタートとリクエスト料金を足しても、70回の合計は約0.0002ドルで、1ドル150円で計算しても1円に届きません。そもそも無料利用枠の内側です。

この関数の料金を下げる工夫には、意味がありません。見るべきなのは、フォームの送信ボタンを押したお客さまを、コールドスタートでLambdaの中だけでも1.5秒前後待たせていることのほうです（API Gatewayやネットワークの時間はここに含まれません）。

メモリを増やすと、CPUも増える

Lambdaでは、CPUを直接は選べません。メモリは128MBから10,240MBまで1MB単位で設定でき、CPUはメモリに比例して割り当てられます。公式ドキュメントによると、1,769MBでvCPU 1個分です。逆算すると、128MBの関数が使えるCPUは、vCPU 1個の約7%しかありません。

ここから「メモリを増やすと、かえって安くなることがある」という話が出てきます。仕組みを理想化して考えると、処理の性質によって次のように分かれます。

• CPUで計算し続ける処理（CPUバウンド）は、メモリを倍にすると実行時間がほぼ半分になります。GB-秒は変わらないので、料金はほぼ同じまま速くなります。ただしこれはvCPU 1個分の1,769MBまでの話で、それを超えると、処理を複数のスレッドに分けていない限り速くならず、料金だけが増えます。
• 外部APIやデータベースの応答を待つ処理（I/Oバウンド）は、メモリを増やしても待ち時間は縮みません。料金はメモリに比例して増えていきます。

実際に測ると、メモリが少なすぎる領域では、ガベージコレクションが頻繁に走るなどして理想より遅くなることがあります。そこではメモリを少し増やすだけで実行時間が大きく縮み、料金まで下がる。「メモリを増やすと安くなる逆転」は、この領域で起きます。どこが一番安いかは処理の中身次第なので、結局は測るしかありません。

スマートフォンなど画面幅が狭い場合は、図を左右にスクロールできます。

測る道具は2つある

1つは、オープンソースの「AWS Lambda Power Tuning」です。Step Functionsのステートマシンとして自分のアカウントにデプロイし、同じ関数を複数のメモリ設定で繰り返し実行して、メモリごとの実行時間と料金を比べます。Lambdaの公式ドキュメントでも紹介されている道具です。ただし、関数を本当に実行します。メールを送る関数なら、実行した回数だけメールが飛びます。私のフォームで使うなら、送信先を検証用に変えた別の関数を用意する必要があります。

もう1つは、AWS Compute Optimizerです。オプトインすると、過去の利用状況からLambdaのメモリ設定を推奨してくれます。ただし公式ドキュメントによると、対象はx86_64の関数だけです。次の章のarm64に移すと、推奨は受けられなくなります。

私の関数なら、どうするか

問い合わせフォームの処理は、SESの応答を待つI/Oが中心のはずです。それでも、ウォームスタートで446msかかるのは、SESを1回呼ぶだけの処理としては長いと感じます。128MBではvCPUの7%しか使えないので、HTTPSの暗号化やSDKの処理がCPU不足で遅れている可能性があります。ここは推測で、まだ確かめていません。

メモリの使用量は最大97MBで、128MBの上限に対して余裕は3割もありません。Node.jsの版を上げれば、使用量も変わるかもしれません。料金は無視できる水準なので、256MBと512MBで測ってから決めるつもりです。仮に512MBにしても、いまの呼び出し回数なら料金はほぼゼロのままです。（追記：測った結果、コールドスタートに限っては「I/Oが中心」という見立てが外れていました。後半の結果を参照してください。）

Graviton（arm64）に移すと単価が2割下がる

Lambdaは、x86_64のほかに、AWSが自社で設計したGravitonプロセッサ（arm64）でも動かせます。東京リージョンのGB-秒単価は、x86_64の0.0000166667ドルに対し、arm64は0.0000133334ドル。ちょうど2割安くなります。公式ドキュメントは、arm64の関数は同等のx86_64の関数より、価格と性能の両面で大幅に良い結果を得られると書いています。ただ、速くなるか遅くなるかは処理によって違います。確実に見込める効果は、単価の2割引きだけと考えておくのが安全です。

移行で引っかかるのは、CPUの種類に依存する部品です。

• ネイティブモジュール：Node.jsなら、画像処理の sharp や暗号の bcrypt のように、C/C++でビルドされた部品（.node ファイル）を含むパッケージは、arm64用を入れ直します。
• Lambdaレイヤーと拡張機能：arm64版が提供されているかを確かめます。
• コンテナイメージ：arm64用にビルドし直します。

私の関数のZIPを調べると、.node ファイルは1つもありませんでした。JavaScriptとAWS SDKだけなので、arm64でもそのまま動くはずです。公式ドキュメントは、エイリアスを使って呼び出しの一部だけを新しいバージョンに流し、x86_64と比べながら切り替える方法を勧めています。

アーキテクチャは、設定画面の項目ではなく、コードの更新と一緒に変えます。CLIなら次のようになります。

aws lambda update-function-code \
  --function-name contact-form-handler \
  --zip-file fileb://function.zip \
  --architectures arm64

追記：このあと実際に測ったところ、私の関数ではarm64のほうがわずかに遅く、本番はx86_64のままにしました。詳しくは後半の結果に書いています。

コールドスタート対策は、費用対効果で選ぶ

コールドスタートを減らす方法は、大きく3つあります。

Provisioned Concurrencyは、東京リージョンのx86_64で、待機中に0.0000053835ドル/GB-秒かかります。128MBの環境を1つ、30日間待機させると、0.125GB×2,592,000秒×0.0000053835ドルで約1.74ドル。月に数回のフォーム送信を1秒速くするために、年間20ドル以上を払う計算になります。なお、Provisioned Concurrencyで動いた分の実行時間には、別の単価（東京のx86_64で0.0000125615ドル/GB-秒）がかかります。

「本当に対策が必要か」を先に問う

私は、次の順番で考えています。

1. 誰が待つのか。人が画面の前で待つ処理か、裏で動くバッチやキューの処理か。後者なら、コールドスタートの1秒はほぼ問題になりません。
2. どれくらい待たせているか。ログの初期化時間を見ます。私のフォームでは平均386ms、最大516msでした。
3. 費用のかからない対策で縮むか。初期化処理と読み込むパッケージを減らす、メモリを増やす、の2つを先に試します。
4. それでも足りず、呼び出しが集中する時間帯がはっきりしているなら、その時間帯だけProvisioned Concurrencyを入れます。

私の関数で試すのは3です。いまのZIPには、AWS SDKのSESクライアントと依存パッケージが3,336ファイル、展開すると6MB近く入っています。Node.jsのLambdaランタイムにはAWS SDK for JavaScript v3が最初から入っているので、同梱せずにそちらを使えば、ZIPは数KBになります。（追記：測ってみると、初期化時間はほとんど縮みませんでした。）また、ランタイムに入っているSDKはAWSの都合で版が更新されるので、版を固定したいならあえて同梱する、という考え方もあります。フォームが1つあるだけの関数なら、私は同梱しないほうを選びます。

地味に効く見直し

ログの保持期間を決める

Lambdaが自動で作るロググループは、保持期間が「無期限」になります。私の関数も無期限のままでした。保存量は32KBなので料金には関係しませんが、呼び出しの多い関数では、保存料金が毎月積み上がっていきます。

aws logs put-retention-policy \
  --log-group-name /aws/lambda/contact-form-handler \
  --retention-in-days 90

ログの取り込み料金も見直す価値があります。2025年5月1日から、LambdaがCloudWatch Logsに送るログは、量に応じた段階料金になりました（バージニア北部では1GBあたり0.50ドルから始まり、量が増えると0.05ドルまで下がります）。それでも、出す量そのものを減らすのが一番効きます。ログの形式をJSONにすると、アプリケーションのログとLambda自身のシステムログを、関数の設定でレベルごとに絞り込めます。たとえばアプリケーションのログをWARNにすると、WARN・ERROR・FATALだけが送られます。

aws lambda update-function-configuration \
  --function-name contact-form-handler \
  --logging-config LogFormat=JSON,ApplicationLogLevel=WARN,SystemLogLevel=INFO

ここで、システムログまでWARNにしないよう注意してください。この記事の集計に使った REPORT 行はINFOレベルのシステムログなので、WARNにすると出なくなり、実行時間を後から測れなくなります。また、JSONにするとログの書式が変わるので、ログを文字列で検索している監視があれば、先に確かめておきます。私の関数はエラーのときに console.error を出すだけなので、切り替えても困りません。

タイムアウトは実測から決める

タイムアウトは初期値の3秒のままでした。実測の最大は、実行時間1,365ms、初期化時間516msです。初期化には実行時間とは別の上限があるので、実行時間だけで見れば3秒に対して倍以上の余裕があります。SESの応答が詰まったときに3秒で打ち切ってエラーを返すのは、フォームとしては悪くない動きなので、ここは変えません。逆に、タイムアウトを必要以上に長くしておくと、相手先の障害で処理が詰まったとき、待っている時間の分だけ料金がかかり続けます。

非同期呼び出しの再試行を見直す

S3やEventBridgeなどから非同期で呼ばれるLambdaは、失敗すると初期設定で2回まで再試行されます。冪等でない処理、つまり2回実行すると結果が変わる処理が再試行されると、料金だけでなく二重の書き込みや二重のメール送信まで起きます。私のフォームはAPI Gatewayから同期で呼ばれるので、この再試行は働きません。非同期で呼ばれる関数があるなら、最大再試行回数とイベントの最大有効期間を、処理に合わせて設定し直す価値があります。

ランタイムを上げる

最後は、料金にも速度にも直接は効かないのに、つい後回しにしてしまう見直しです。Node.js 18のランタイムは2025年9月1日に非推奨になり、セキュリティパッチが提供されなくなっています。公式の表では、新しい関数を作れなくなるのが2027年7月29日、既存の関数を更新できなくなるのが2027年8月31日です。Node.js 20も、2026年4月30日に非推奨になりました。いま上げるなら、非推奨になるのが2028年4月30日の nodejs24.x が、選べる中で一番長く使えます。

私のフォームで実際にやること

どれを選んでも、料金はほぼゼロのままです。これは記事を書いた時点の計画で、実際に測った結果、アーキテクチャとメモリの判断は変えました。

本番を更新して、測り直した

計画を立てたその日のうちに、本番の関数を更新しました。ただ、本番の関数を直接何十回も呼ぶと、そのたびに私宛てのメールが届きます。そこで、本番と同じコードと同じIAMロールで検証用の関数を一時的に作り、宛先だけをAmazon SESのメールボックスシミュレーター（success@simulator.amazonses.com。送信は成功扱いになるが、実際には配達されないテスト用の宛先）に書き換えて測りました。コードの違いはこの1行だけで、SESへの送信までを本物と同じ経路で通しています。

設定は1つずつ変えて、どの変更が何に効いたのかを切り分けました。各設定で、コールドスタートを5回、その直後のウォームスタートを5回測っています。コールドスタートは、環境変数を書き換えて実行環境を作り直させることで、毎回強制的に起こしました。数値は aws lambda invoke --log-type Tail で返ってくる REPORT 行から取っています。測り終えたあと、検証用の関数とロググループは削除しました。

スマートフォンなど画面幅が狭い場合は、表と図を左右にスクロールできます。

効いたのはメモリだった

一番効いたのはメモリでした。128MBから512MBにすると、コールドスタートの実行時間は1,192msから399msに縮み、請求時間の合計も1,553msから667msと半分以下になりました。ばらつきを見ても、128MBの5回（1,451〜1,632ms）と512MBの5回（600〜710ms）は重なりません。

前半では、この関数はSESの応答を待つI/Oが中心だろうと書きました。ウォームスタートについては、その見立てどおりでした。どの設定でも実行時間は120〜200msほどで、メモリを増やしても変わっていません。ところがコールドスタートの実行は、メモリ、つまりCPUを増やすほど素直に縮みました。初回の呼び出しでは、SDKの読み込みやSESへの暗号化された接続の確立が走ります。これがCPUを使う処理で、128MB（vCPUの約7%）では足りていなかったのだと思います。コールドスタートが7割を占めるこの関数では、待ち時間の大半がここにありました。

なお、検証用の関数で測ったウォームスタート（約150ms）は、本番のログのウォームスタート（平均446ms）よりかなり速く出ています。検証では間を置かずに続けて呼んだのに対し、本番の呼び出しは数分以上の間隔が空くことが多いので、その差だと考えています。ただし、ここは確かめていません。

外れた予想が2つあった

1つ目は、SDKの同梱をやめれば初期化が速くなるという予想です。ZIPは6.4MBから1.5KBになりましたが、初期化時間は280msから285msで、ほとんど変わりませんでした（②→③）。ハンドラーの外ではSDKのクライアントを作っているだけで、実際の読み込みの重さは、ZIPのサイズよりも最初の送信時に出ていたようです。同梱をやめた効果は、デプロイが軽くなることと、ランタイム側でSDKが更新されることくらいです。

2つ目は、Graviton（arm64）です。128MBではx86_64より遅く（③→④で1,657msから1,780ms）、512MBでもx86_64の667msに対してarm64は722msでした。512MBどうしでは5回のばらつきが重なっているので、差はわずかです。1回あたりの料金はarm64のほうが13%ほど安くなりますが、金額にすると1回あたり0.000001ドルにも届きません。待ち時間をわずかでも短くしたいことと、Compute Optimizerのメモリ推奨がx86_64しか対象にしていないことから、本番はx86_64のままにしました。前半で書いた「確実に見込めるのは単価の2割引きだけ」は、速度の面では本当にそのとおりでした。

Node.js 24への切り替えは、初期化を361msから280msに縮めました。一方で、128MBのままだとコールドの実行時間が少し伸び、メモリの使用量は92MBから108MBに増えています。上限の128MBに対して余裕は2割を切るので、Node.js 24に上げるなら、メモリも一緒に見直したほうが安全です。

本番に入れた設定と料金

料金は、コールドスタート1回あたり約0.0000032ドルから約0.0000056ドルへと、1.7倍になります。月に十数回の呼び出しなら、増える額は月0.0001ドルにも届きません。その代わり、コールドスタートでお客さまを待たせる時間は、Lambdaの中だけで1.5秒台から0.7秒弱になります。この関数では迷わず払う価値のある差でした。

更新の前に、変更前の状態をバージョン1として発行しておきました。API Gatewayは最新版（$LATEST）を呼んでいるので、問題が出たときは、バージョン1と同じ設定とコードに戻せます。更新後は、本番のAPIに必須項目を空にしたリクエストを送り、メールを送らずに入力エラー（400）が返ることを確かめました。このとき、初期化は281ms、メモリの使用量は95MBでした。ログをJSON形式に変えたあとも、前半のLogs Insightsのクエリはそのまま動きます（@type、@duration、@initDuration は、JSON形式の platform.report からも取り出されます）。

本番での実際の問い合わせがある程度たまったら、前半と同じクエリで集計し直して、検証用の関数で測った数字と比べるつもりです。

サーバーレスでも、自分の関数は自分で見に行く

物理サーバーの頃は、サーバーが止まれば電話が鳴りました。サーバーレスにして、機械が壊れる心配からは解放されています。それでも、自分の書いた関数がどんな状態で動いているかは、自分で見に行かないとわかりません。今回は、数十秒で終わるクエリ1本で、7割がコールドスタートだったことも、ランタイムが非推奨のまま放置されていたことも見えました。測り直してみると、効くと思っていたSDKの軽量化とGravitonはほとんど効かず、待ち時間を半分にしたのは、メモリを128MBから512MBに上げるという一番地味な変更でした。

Lambdaのチューニングは、料金の明細を眺めるところからではなく、ログの REPORT 行を読むところから始めるのがよいと思います。呼び出しの多い関数なら、そこで初めてメモリやGravitonの話が料金に効いてきます。呼び出しの少ない関数なら、見るべきは待ち時間とランタイムの期限です。

※2026年11月時点の公開情報に基づきます。料金や仕様は変更されることがあります。関数の数値は当サイトの1関数の実測で、ほかの関数にそのまま当てはまるものではありません。料金は記事中の前提による試算です。

確認した情報

• AWS Lambda の料金 — 課金の仕組みと無料利用枠。東京リージョンの単価は、AWS Price List API（サービスコード AWSLambda、ap-northeast-1）で2026年11月13日に取得した値を使用。
• AWS Compute Blog: AWS Lambda standardizes billing for INIT Phase — 2025年8月1日からのINITフェーズの課金。
• Configure Lambda function memory — メモリの範囲、1,769MBでvCPU 1個分、Compute Optimizer（x86_64のみ）とPower Tuning。
• Selecting and configuring an instruction set architecture — arm64の価格性能と移行時の確認点。
• Improving startup performance with Lambda SnapStart — 対応ランタイム。
• Lambda runtimes — Node.js 18・20・22・24の非推奨日と、作成・更新ができなくなる日。
• AWS Compute Blog: AWS Lambda introduces tiered pricing for Amazon CloudWatch logs — 2025年5月1日からのログの段階料金。
• Log-level filtering — JSON形式とログレベルの絞り込み。
• Amazon SES: Sending test emails in Amazon SES with the simulator — 検証で使ったテスト用の宛先。
• GitHub: AWS Lambda Power Tuning — メモリ設定ごとの計測ツール。

各情報は2026年11月13日に確認しました。