クラウド

AWS Lambdaとは？サーバーレスの仕組みと動かし方の基本

2026/10/17 シリーズ「AWS 入門」 第6回 / 全7回

🤖 AIを使用して執筆

関数を作るときに決めること：コード、メモリと時間、権限、ログ

関数のコードの入口は、ハンドラーと呼ぶ関数である。Lambda は、関数が呼び出されるたびにハンドラーを動かし、イベントと、その呼び出しについての情報（コンテキスト）を渡す¹³。Python なら、次の形になる。

def lambda_handler(event, context):
    # event から処理するデータを読み、処理をする
    return {"status": "ok"}

コードを動かす言語ごとの環境を、ランタイムと呼ぶ。Lambda は Node.js、Python、Java などのランタイムを用意しており、Go や Rust のようなほかの言語は、OS だけのランタイムの上で動かす¹⁴。関数は、コンソール（AWS をブラウザから操作する画面）で作れる。Java や C# のようにコンパイルする言語では、手元で作ったデプロイパッケージ（コードと必要なライブラリをまとめたファイル）をアップロードする。コンソールでは、テスト用のイベントを作って関数を動かし、応答とその呼び出しのログをその場で見られる¹⁵。

関数には、次の設定を決める。

• メモリ： 128 MB から 10,240 MB までの間で決める。CPU の力は、メモリの量に比例して割り当てられ、1,769 MB で vCPU 一つ分になる¹⁶。
• タイムアウト： 一回の呼び出しで動ける時間の上限である。既定は 3 秒で、最長 900 秒（15 分）まで延ばせる¹⁷。
• 実行ロール： 関数がほかの AWS のサービスを使う権限は、IAM（AWS の権限を管理するサービス）のロールとして関数に付ける。ロールは、使ってよい操作をまとめた権限の組で、関数に付けるものを実行ロールと呼ぶ¹⁸。S3 のファイルを読み書きする関数なら、その操作を実行ロールで許す。コンソールで関数を作るときは、ログを書く権限だけを持つロールを、Lambda に作らせることもできる¹⁵。
• ログ： 関数が出力したログは、実行ロールに権限があれば、Lambda が CloudWatch Logs（AWS のログを集めて保存するサービス）に送る。既定では、/aws/lambda/ に関数の名前を続けたロググループ（ログをまとめる単位）に入る。CloudWatch Logs でログが見えるまで、5〜10 分かかることがある¹⁹。

何に使い、料金をどう数えるか

Lambda で何ができるかは、関数を何に呼ばせるかで決まる。関数を呼ぶものは、コンソールの「トリガーを追加」などで関数につなぐ²⁰。

料金は、呼び出しの回数と、関数が動いた時間をメモリの量と掛け合わせた GB 秒で数える²⁴。たとえば、メモリが 512 MB（0.5 GB）の関数が 1 回 0.2 秒で終わるなら、100 万回呼んで 0.5 × 0.2 × 100 万 ＝ 10 万 GB 秒になる。無料利用枠には、毎月 100 万回の呼び出しと 40 万 GB 秒が含まれる²⁴ので、回数も GB 秒も枠に収まる。呼び出しが無い時間には、この二つの料金はかからない。動かしているあいだ料金がかかり続ける EC2 のインスタンスとの、大きな違いである。

三つの呼び出し方と、失敗したときにやり直す側

同期呼び出しでは、呼んだ側が関数の終わりを待ち、結果を受け取る。非同期呼び出しでは、Lambda がイベントをキューに入れてすぐに応え、あとで関数を動かす²⁵。前の表の API Gateway は同期で、S3 と EventBridge Scheduler は非同期で関数を呼ぶ²²¹⁰²⁰。イベントソースマッピングは、Lambda が自分で読みに行って関数を呼ぶ仕組みである。読む先は、AWS のキューのサービスである SQS や、Kinesis のようなストリーム（記録を発生した順に流し続け、読む側が順に読むサービス）で、それらの記録（レコード）を何件かずつまとめて（バッチで）関数に渡す²⁵²¹。

失敗したときにやり直す側は、呼び出し方で違う。

非同期呼び出しで、やり直しても失敗したイベントは、Lambda が捨てる。デッドレターキュー（処理できなかったイベントを預けておく別のキュー）か、失敗時の送り先を設定しておけば、捨てられたイベントや失敗の記録を後から調べられる¹²。

どの呼び出し方でも、同じイベントが関数に二度以上届くことがある。

• 同期呼び出しでは、 失敗したとき、コードが最後まで動いたのか、途中まで動いたのか、まったく動かなかったのかが、呼んだ側には分からない。AWS は、やり直すなら、同じイベントを何度処理しても同じ処理が二重に行われないようにコードを書くよう求めている²⁶。
• 非同期呼び出しでは、 再試行のほかに、キューの結果整合性によって、エラーが無くても同じイベントが届くことがある¹²。
• イベントソースマッピングでは、 各レコードを少なくとも 1 回処理し、同じレコードを二度処理することがある。バッチの一部だけが失敗しても、既定ではバッチ全体を処理し直すので、成功していたレコードももう一度届く²¹。SQS から読む場合は、失敗したメッセージだけをもう一度読まれるようにする部分バッチ応答を設定できる²⁸。AWS は、関数を冪等にすることを強く勧めている²¹。

冪等にするとは、同じ依頼を何度受けても一度と同じ結果にすること

AWS が自社のサービスの作り方を公開している Amazon Builders’ Library で、Malcolm Featonby は、冪等な操作を、依頼を送り直したり再試行したりしても、余計な変化（副作用）を起こさない操作と定義している²⁹。たとえば EC2 のインスタンスを起動する処理が、失敗した EBS ボリューム（インスタンスにつなぐディスク）の作成を再試行して、ボリュームが二つできてしまうのは望ましくない。Amazon が好む方法は、呼ぶ側が一意な依頼の識別子を付けて送ることを、API の仕様に含めることだという。同じ識別子で再試行された依頼には、最初に成功した依頼への応答と同じ意味の応答を返す²⁹。

Lambda の関数では、イベントの中にある一意な値が、この識別子になる。取引の ID や、キューのメッセージの ID などである。AWS の公式の Q&A サイト re:Post は、処理を始める前に、その値を冪等性の記録として、DynamoDB（AWS のデータベースのサービス）に条件付きの書き込み（決めた条件を満たすときだけ書き、満たさなければ書かずに知らせる書き方）で書く方法を示している。書けなかったら、別の呼び出しが、その値をすでに処理しているか、処理し終えている³⁰。

ただし、正しく書くのは見かけより難しい。先の呼び出しが、記録を「処理中」にしたまま途中で止まることがある。そのときに処理中の記録を見て成功として終えると、処理を終える呼び出しがどこにもなくなる。Powertools for AWS Lambda の冪等性の機能は、こうした場合も扱う。関数の入力から作ったキーと結果を保存し、同じキーで再び呼ばれたら、保存しておいた成功の結果を返す。処理中の記録があればエラーを返してやり直させ、処理が例外で失敗したら記録を消す。処理中の記録には、関数に残っている時間から決めた期限を付けておき、期限を過ぎた処理中の記録は、止まった呼び出しが残したものとみなして処理し直す³¹³⁰。処理し直すと、止まる前に終わっていた操作をもう一度行うことがある。Featonby は、冪等性の記録を書くことと依頼に伴うすべての変更を、全部行うか何も行わないかのどちらかになる一つの操作にする必要があると書いている。記録だけが残ったり、変更だけが残ったりしないためである²⁹。また、Powertools の記録は既定で 1 時間で有効期限が切れ、その後に届いた同じ入力は、新しい依頼として処理される³¹。非同期呼び出しのイベントは最長 6 時間キューに置かれることがある³²ので、記録を残す時間は、同じイベントが届きうる期間に合わせて決める。

Lambda のベストプラクティスも「冪等なコードを書く」を挙げ³³、AWS の Well-Architected フレームワークの信頼性の柱は、データを変える操作を冪等にすることを求めている³⁴。

同時実行と、混み合ったとき

同時に処理している呼び出しの数である同時実行は、既定ではリージョン（AWS が世界の各地に置くデータセンターのまとまり）ごとに、アカウントのすべての関数を合わせて 1,000 までで、それを使い切ると、呼び出しが断られる（スロットリング）¹¹。非同期呼び出しで断られたイベントは、三つの呼び出し方の表のとおり Lambda が最長 6 時間やり直す¹²。呼び出しが急に増えたとき、一つの関数の実行環境は、10 秒ごとに最大 1,000 ずつ増える³⁵。

同時実行は、関数ごとに調整できる。

• 予約済みの同時実行は、アカウントの同時実行のうち一部を、その関数のために取っておく。取っておいた数は、その関数の上限にもなる¹¹。
• プロビジョニングされた同時実行は、決めた数の実行環境を前もって準備しておき、コールドスタートの遅れを減らす¹¹。準備しておく数と時間には、呼び出しが無くても料金がかかる²⁴。

手順をつなぐなら、関数から関数を同期で呼ばない

処理が複数の手順に分かれるとき、関数から次の関数を同期で呼び、終わりを待つ形は、AWS のブログが避けるべき形として挙げている。2021 年に James Beswick は、呼んだ関数が終わりを待つあいだも料金がかかり続け、エラーの処理も複雑になると説明し、代わりに関数のあいだに SQS のキューを置くか、Step Functions を使うよう勧めた³⁶。

AWS Step Functions は、2016 年 12 月に公開された、処理の手順をつなぐサービスである³⁷。どの手順をどの順に行い、どこで分かれるかを、ステートマシンと呼ぶワークフローとして定義する³⁸。手順が失敗すると、既定ではワークフロー全体が失敗するが、手順ごとに再試行の回数と間隔を設定できる³⁹。

Step Functions を使っても、冪等性はいらなくならない。ワークフローの種類のうち Standard は、各手順を一回だけ動かすが、再試行を設定した手順は、失敗すると二回以上動く。もう一つの種類の Express は、非同期で動かすと少なくとも一回で、同じ実行が二回以上動くことがある⁴⁰。

AWS は 2025 年 12 月に、Lambda の耐久性のある関数（durable functions）も出した⁴¹。処理の途中の結果を記録しておき、途中で止まると、最初から動き直しつつ、終わった手順は記録した結果を使って飛ばす。最長 1 年動ける⁴²。AWS は、処理が主に Lambda の中で閉じるなら耐久性のある関数を、複数の AWS のサービスをつなぐなら Step Functions を勧めている⁴³。

Lambda が向かない処理

Lambda と Step Functions が向かない処理もある。2023 年 3 月に Prime Video の Marcin Kolny は、配信の映像と音声の品質を監視するサービスを、Step Functions と Lambda で手順ごとに分けた形から、ECS（コンテナを動かす AWS のサービス）と EC2 で動く一つのアプリケーションにまとめ、インフラの費用を 90% 以上減らしたと報告した。手順が進むたびに Step Functions の料金がかかり、手順のあいだで映像を S3 に置いて受け渡す費用も高かった。Kolny は、どちらの形を使うかは場合ごとに決めるべきだと結んでいる⁴⁴。Adrian Cockcroft は、これは Prime Video を作る多くのサービスのうち一つの話で、サーバーレスで素早く作り、負荷が高く続くようになったらコンテナで作り直すという、自分が勧めてきた進め方そのものだと書いた⁴⁵。

Yan Cui も、新しく作るシステムの多くでは、まずサーバーレスで作る進め方が正しいとしたうえで、向かない場合を挙げている。毎秒 1,000 件を超えるような規模では、API Gateway と Lambda の運用費は、ECS でコンテナを動かすよりずっと高くなりうる。15 分より長くかかり、小さな処理に分けて並列に動かすこともできない処理と、とても低い遅延が要る処理も、合わない例に挙げている⁴⁶。

Lambda の関数は、同じイベントが二度届いても困らないように書く

AWS Lambda では、サーバーを用意も管理もしない。ハンドラーを書き、メモリとタイムアウトと実行ロールを決めた関数を、ファイルの到着や時刻、キュー、HTTP のリクエストに呼ばせ、料金は呼び出しの回数と GB 秒で払う。関数がいつ、何回呼ばれるかは、呼び出し方で決まる。非同期呼び出しとイベントソースマッピングでは Lambda が、同期呼び出しでは呼んだ側が再試行し、非同期呼び出しではエラーが無くても同じイベントが届くことがある。その結果、同じイベントが関数に二度以上届きうる。

そのため、Lambda の関数を書くときに要るのは、同じイベントを何度処理しても結果が一度と同じになる、冪等な関数である。イベントの中の一意な値を冪等性の記録として条件付きで書き、処理を終えた記録があれば、何もせずに正常に終える。処理中の記録なら、期限までは成功として終えずにやり直させ、期限を過ぎていれば処理し直す。手順をつなぐときは、関数から関数を同期で呼ばず、再試行を設定できる Step Functions などを使う。そのうえで、再試行を設定した手順と、非同期の Express のワークフローで動かす処理は、冪等にしておく。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。