Lambda 関数の料金体系や、コールドスタート問題について触れることがあったのでまとめた。
Slack での対話を Supabase（PostgreSQL + pgvector） に蓄積し、将来の ファインチューニング や RAG に使える形式で保存する プロジェクト で Lambda 関数を組み込んだ時に調べた内容。
Lambdaの料金は、処理時間とリクエスト回数によって算出される。 処理時間が大きくなるほどコストは安くなるが、リクエスト回数による料金は増減せず一定。
また、リージョン・為替・改定で請求額が変わる。 下記は 2026 年 3 月 22 日の情報で、最新は AWS Lambda 料金 を参照。
| アーキテクチャ | 時間 | GB秒あたり（USD） | リクエスト 100万件あたり（USD） |
|---|---|---|---|
| x86 | 最初の 60 億 GB秒/月 | 0.0000166667 | 0.20 |
| x86 | 次の 90 億 GB秒/月 | 0.000015 | 0.20 |
| x86 | 150 億 GB秒/月 以上 | 0.0000133334 | 0.20 |
| Arm | 最初の 75 億 GB秒/月 | 0.0000133334 | 0.20 |
| Arm | 次の 112.5 億 GB秒/月 | 0.0000120001 | 0.20 |
| Arm | 187 億 5 千万 GB秒/月 以上 | 0.0000106667 | 0.20 |
| メモリ (MB) | 1 ミリ秒あたりの料金 |
|---|---|
| 128 | USD 0.0000000021 |
| 512 | USD 0.0000000083 |
| 1,024 | USD 0.0000000167 |
| 1,536 | USD 0.0000000250 |
| 2,048 | USD 0.0000000333 |
| 3,072 | USD 0.0000000500 |
| 4,096 | USD 0.0000000667 |
| 5,120 | USD 0.0000000833 |
| 6,144 | USD 0.0000001000 |
| 7,168 | USD 0.0000001167 |
| 8,192 | USD 0.0000001333 |
| 9,216 | USD 0.0000001500 |
| 10,240 | USD 0.0000001667 |
Cloud Watch でログを見ることで使用メモリを確認できる。
| REPORT RequestId: 217b229e-b6e4-48b3-9879-e2a3ee04b5ff | Duration: 7.29 ms | Billed Duration: 8 ms | Memory Size: 256 MB | Max Memory Used: 107 MB |
|---|
コスト削減のための運用方法としては、 Max Memory Used をもとに、次のメモリ上限にサイズ更新するなどしてアッパーを定めると良い。
これにより OOM (Out Of Memory) を避けて安定性を保ちつつ、コスト削減をすることができる。
Lambda の使用したアプリケーションにおいては、コールドスタート問題を考える必要がある。特に、応答時間が重要なアプリケーションではこの問題を無視することはできない。
コールドスタートは、Lambdaの実行環境が更新される下記のタイミングで発生する。
この時、AWSは以下の手順を踏む必要がある。
これらのプロセスは時間を要するため、リクエスト処理の遅延に繋がる。
これが コールドスタート と呼ばれる現象。
今回のプロジェクトでは応答速度は問題にならなかったので、特に対策はしていない。
Lambda の実行方式 (同期・非同期) はトリガーとなるサービスによって異なる。
Lambda の 内部キュー とは、非同期実行を実現するためにイベントを一時的に保持するための箱のようなものを指す。
LambdaのキューはSQSのようにユーザーが直接利用できるようなものではなく、Lambdaのサービスに組み込まれた内部的なキューのため、開発者がアクセスしたり、管理したりすることはない。
例えば S3 にデータがアップロードされたのをトリガーに Lambda 関数が実行されるユースケースを考える。
Lambdaで発生するエラーは、大きく分けて下記の二つに分類される。
→ Node.js の場合は こちら を参照
＜API で直接 Lambda 関数を実行させた場合＞
関数からのエラーレスポンスは直接APIの呼び出し元に返される。
エラーハンドリングが比較的容易なため、レスポンス内容に応じてログ出力やリトライ処理などを行う必要がある。
関数実行時のエラーは 400 番台または 500 番台が返却されない。すなわち、Lambda関数の実行は失敗しているもののステータスコードでは 200 番台が返却されることがあるため、「ステータスコードが 200 番台だった場合は正常レスポンスとみなし後続処理を続ける」といった実装をしてしまうと、実際にはエラーが起きていたとしてもそのエラーに永遠と気付けない。
＜AWS サービスのイベントをトリガーに Lambda 関数を実行させた場合＞
関数実行時のエラーは直接トリガー元には通知されないため、エラーを正確にキャッチするためには工夫が必要。(CloudWatch Logs のみ自動で実行ログが送られる)
＜Lambda 関数を直接 API で呼び出した場合のリトライ処理＞
リトライ処理は Lambda 側ではされず、呼び出し元でレスポンスに応じてログを出したりリトライしたりする必要がある。
＜イベントをトリガーに Lambda 関数が実行された場合のリトライ処理＞
非同期処理の場合は Lambda がリトライ処理を2回まで実行してくれる。
Lambdaが自動的にリトライしてくれるエラーはあくまで再試行によって解決可能なエラーのみ。
- Lambda関数の実行タイムアウト
- Lambdaサービスが一時的に高い負荷によりリクエストを処理できない場合
- Lambda関数がトリガーされたが必要なリソースが一時的に利用できない場合
etc...
