【図解】Lambdaとは？わかりやすく呼んだ時だけ来る出張スタッフの例えで解説｜EC2との違い

Lambdaはサーバーレスらしいけど、サーバーが無いならどこで動いているのか分からない

EC2でプログラムを動かすのと、Lambdaを使うのとで何が違うのか分からない

作成画面の「トリガー」「実行ロール」「タイムアウト」で手が止まってしまう

こんな悩みを解決していきます！

現在はCIerで、クラウドの設計・構築をしているインフラエンジニアです。

AWSの資格は、SAA（ソリューションアーキテクト アソシエイト）とSAP（ソリューションアーキテクト プロフェッショナル）を持っています。

結論から言うと、Lambdaは「呼んだ時だけ来て、仕事をして帰る出張スタッフ」です。

仕事の手順書（プログラム）を預けておくと、合図が来た時だけスタッフが駆けつけて作業し、払うのは働いた分だけ、と覚えれば全体がつながります。

この記事で分かることは3つです。

・Lambdaとサーバーレスの意味、部品が出張スタッフのどこに当たるか
・Lambdaが動く流れと、よくある使い方・注意点
・料金のかかり方と、EC2との違い

＼ AWSを詳しく学びたい方はこちら ／

CloudTechの評判と割引クーポンを見る

Lambdaとは？わかりやすく言うと「呼んだ時だけ来る出張スタッフ」

Lambdaは、預けておいたプログラムを、合図が来た時だけ動かしてくれるサービスです。

上の図は、呼び出しのベルが鳴ると、出張スタッフが手順書を持って駆けつけ、作業をして帰っていくところです。

ふだん、スタッフはその部屋で仕事をしていません。合図が来た時だけスタッフが来て、仕事が終われば手を止める。これがLambdaの動き方です。

たとえば、お店の閉店後の片付けを、毎日決まった時だけ出張スタッフに頼む場面を思い浮かべてください。片付けのためだけに、スタッフを1日中お店にいさせておく必要はありません。

やってほしいことを手順書に書いて預けておけば、決まった合図でスタッフが来て、手順書どおりに片付けて帰ってくれます。

公式ドキュメントでは、Lambdaは「サーバーを用意したり管理したりせずにコードを動かせる、サーバーレスのコンピューティングサービス」と紹介されています。誰が何を受け持つかを表にまとめます。

やること	出張スタッフで例えると	誰がやるか
サーバーの準備・保守	スタッフの控室と道具の用意	AWS
台数の調整・増減	依頼の数に合わせてスタッフを増やす	AWS
ソフトの修正（パッチ）	道具の点検と交換	AWS
プログラム（関数）を書く	仕事の手順書を書く	自分
どの合図で動かすか決める	呼び出しのベルをどこに付けるか	自分

ポイントは、Lambdaでは、サーバーの面倒を見る仕事をまるごとAWSに渡せることです。

自分は「何をしてほしいか（手順書）」と「いつ呼ぶか（合図）」を決めるだけです。この2つの言葉は、この後の章で1つずつ見ていきます。

サーバーレスとは？サーバーが「無い」のではなく「自分で管理しない」

サーバーレスは、サーバーが無いという意味ではなく、サーバーの面倒を自分で見なくてよいという意味です。

上の図の左は、自分で建物を借りて、中のサーバーの面倒も自分で見るやり方。右は、手配する会社が裏で建物とサーバーを用意していて、自分は手順書を渡すだけのやり方を描いています。

右側にもサーバーはちゃんとあります。自分からは見えないだけで、AWSの側で動いているのです。

出張スタッフにも、控室や道具箱はあります。ただ、それを用意して片付けるのは手配する会社です。

頼む側は、控室がどこにあるかを知らなくても、スタッフに仕事を頼める。サーバーレスの「レス（無い）」は、この「自分が気にしなくていい」という意味だと考えてください。

自分で管理する場合（EC2）と、サーバーレス（Lambda）で、誰が何を受け持つかを並べます。

作業	自分で管理（EC2）	サーバーレス（Lambda）
サーバーの準備	自分	AWS
台数の調整（スケーリング）	自分	AWS
ソフトの修正（パッチ）	自分	AWS（言語の実行環境も含む）
サーバーのセキュリティ	自分	サーバー側の保守はAWS（関数に渡す許可は自分で決める）
プログラムを書く	自分	自分

表のとおり、サーバーの面倒を見る仕事の多くを、AWSが受け持ってくれるのがサーバーレスです。何をさせるか、どんな許可を渡すかは、自分で決めます。

公式の比較ガイドでも、EC2を管理するとは「サーバーの準備・台数の調整・パッチ・セキュリティを受け持つこと」と説明されています。そのうち、サーバーの保守・台数の調整・パッチをAWSに任せられるのが、Lambdaのいちばんの特徴です。

Lambdaの部品を出張スタッフで例えると

関数・トリガー・イベント・実行環境は、出張スタッフの仕事の流れにそのまま当てはまります。

上の図は、出張スタッフの仕事に出てくるものを5つ並べ、Lambdaの名前を書き込んだものです。

Lambdaの画面には聞き慣れない言葉が並びますが、手順書・ベル・知らせ・スタッフ・手配する会社の5つに置き換えると、急に分かりやすくなります。

出張スタッフで例えると	Lambdaの名前	一言で
仕事の手順書	関数（Lambda関数）	1つの仕事をするための小さなプログラム
呼び出しのベル	トリガー	関数と、合図を出す場所をつなぐもの。1つの関数に複数付けられる
ベルが鳴った知らせ	イベント	何が起きたかの中身（どのファイルが置かれたか など）
駆けつけるスタッフ	実行環境	関数を動かすためにLambdaが用意する場所
スタッフを手配する会社	AWS	実行環境の用意・片付け・増減を受け持つ

手順書＝関数

関数は、1つの仕事だけを書いた手順書です。

公式ドキュメントでは、関数は「イベントに応じて動くコード」で、「1つの決まった仕事を持ち、必要な時だけ動き、終わると自動で止まる」と説明されています。「画像を小さくする」「届いたデータを記録する」のように、仕事を小さく分けて、1枚ずつ手順書にするのが基本です。

ベル＝トリガー、知らせ＝イベント

トリガーは、どこで何が起きたらスタッフを呼ぶかを決める、呼び出しのベルです。

S3にファイルが置かれた、決まった時刻になった、などの合図とスタッフをつなぎます。ベルが鳴ると、「何が起きたか」を書いた知らせ（イベント）がスタッフに渡され、スタッフはそれを見ながら手順書どおりに動きます。

スタッフ＝実行環境、手配する会社＝AWS

実行環境は、関数を動かすためにLambdaが用意する、ほかとは区切られた作業場所です。

出張スタッフでいえば、手順書を受け取って実際に手を動かす人にあたります。どこから来て、どこへ帰るのかを頼む側が気にする必要はありません。スタッフの用意も片付けも、手配する会社（AWS）の仕事だからです。

Lambdaが動く流れ｜合図→駆けつける→作業→帰る

Lambdaは、「合図が来る→スタッフが来る→手順書どおりに作業する→終わったら帰る」の順に動きます。

上の図は、1回の依頼でLambdaが動く4つのステップです。

ポイントは、1回の合図ごとに、スタッフが来て、作業して、帰ることです。合図が来ていない間、スタッフは作業をしていません。

ステップ	出張スタッフで例えると	Lambdaで起きていること
①合図が来る	ベルが鳴る	トリガーにつないだ場所でイベントが起きる
②スタッフが来る	スタッフが駆けつける	Lambdaが実行環境を用意する（あれば使い回す）
③作業する	手順書どおりに作業する	関数が、受け取ったイベントをもとに処理する
④帰る	結果を渡して帰る	処理が終わると、関数は自動で止まる

依頼が重なったら、別のスタッフが同時に来る

同じタイミングで何件も依頼が来たら、1人のスタッフが順番待ちをさせるのではなく、別のスタッフが同時に来ます。

公式ドキュメントでは、同時に処理しているリクエストごとに、別々の実行環境を用意すると説明されています。依頼の数に合わせて、実行環境の数はLambdaが自動で増やしたり減らしたりします（ただし、アカウントごとに同時に動かせる数の上限はあります）。

新しい依頼が来た時のルールは、手が空いているスタッフがいればその人に頼み、いなければ新しいスタッフを呼ぶという単純なものです。

公式ドキュメントでも、すぐ使える実行環境があればそれで処理し、無ければ新しく作ると説明されています。1人目が作業中に次の依頼が来たら、2人目が呼ばれる。空いている人がいれば使い回し、いなければ増やすという決まりで、依頼の数に合わせて人数が自動で変わります。

前の依頼のことは、覚えている保証がない

Lambdaは、1回作業を終えたスタッフ（実行環境）を、次の依頼に使い回すことがあります。ただし、前の依頼の中身が残っている保証はありません。

毎回ちがうスタッフが来るかもしれない、と考えておくのが安全です。次の依頼でも使いたいデータは、S3の倉庫やデータベースに置いておきます。

初めて呼んだ時は、来るまで少し時間がかかることがある

スタッフを新しく呼ぶ時は、作業場所の準備から始めるぶん、使い回しの時より時間がかかることがあります。これをコールドスタート（新しい作業場所を準備してから動くこと）と呼びます。

最初の呼び出しや、依頼が重なって新しいスタッフを呼ぶ時に、少し反応が遅く感じることがあるのはこのためです。すぐに動けるスタッフを前もって待機させておく設定（プロビジョニングされた同時実行）もありますが、待機させておく分は追加の料金がかかります。最初は気にしすぎず、「1回目は少し遅いことがある」と知っておけば十分です。

もっと詳しく知りたい方や、ハンズオンで学びたい方は、CloudTech（クラウドテック）もチェックしてみてください。

＼ 詳しく知りたい方はこちら ／

CloudTechの評判と割引クーポンを見る

Lambdaでできること｜よくある使い方3つ

Lambdaは、「何かが起きたら、短い仕事を片付ける」場面で使われます。

上の図は、いちばん定番の使い方です。大きな倉庫（S3）に荷物が届くとベルが鳴り、スタッフが来て荷物を加工し、別の倉庫へ運びます。

たとえば、写真がアップロードされたら、小さい見本の画像（サムネイル）を作って別の場所に置く、といった仕事です。

合図の出し方を変えれば、いろいろな仕事を任せられます。よく使われる3つを表にまとめます。

合図（トリガー）	出張スタッフで例えると	使い方の例
S3にファイルが置かれた・消された	倉庫に荷物が届いたらベルが鳴る	画像を小さくする・届いたデータを記録する
決まった時刻・一定の間隔	目覚まし時計で毎日決まった時間に呼ぶ	毎朝の集計・定期的な片付け
Webのボタンが押された	お店の呼び鈴が押されたら来る	フォームの受付・Webの裏側の処理

倉庫に荷物が届いたら（S3）

いちばん定番なのが、S3にファイルが置かれた・消された時に動かす使い方です。

公式のチュートリアルにも、S3のトリガーでサムネイル画像を作る例があります。写真を置くたびに人が手作業で縮小しなくても、置いた瞬間にスタッフが来て、小さい画像を作っておいてくれるわけです。

決まった時刻に（EventBridge Scheduler）

2つ目は、毎朝決まった時刻、一定の間隔ごと、のように時刻で動かす使い方です。

ベルの役をするのは、EventBridge Scheduler（決まった時間にLambdaを呼び出す目覚まし時計のような仕組み）です。毎日の集計や、古いデータの片付けなど、決まった時間にやる仕事を任せられます。1回だけ決まった日時に動かす、という呼び方もできます。

ボタンが押されたら（Webの裏側）

3つ目は、Webサイトのボタンが押されたら動かす使い方です。

問い合わせフォームの送信ボタンが押されたら、内容を受け取って保存する、といった仕事です。Webから呼ぶときは、API Gateway（Webからの依頼を受け付ける窓口のようなサービス）などをトリガーにします。ボタンを押す人がいない時間は、スタッフも来ません。

3つの使い方を並べると、倉庫に荷物が届いた時・目覚まし時計が鳴った時・お店の呼び鈴が押された時と、合図の出どころはバラバラです。

それでも、どれもベルの付け先が違うだけで、スタッフの動き方は同じです。手順書を預け、ベルをつなぎ、合図が来たら作業して帰る。この流れさえ押さえれば、新しい使い方にも応用できます。

倉庫（S3）の使い方そのものは、S3の記事で解説しています。

S3と組み合わせるときの注意

気をつけたいのが、スタッフを呼んだ倉庫に、作業結果を書き戻してしまうケースです。

荷物が届くとベルが鳴る倉庫に、スタッフが加工した荷物を置くと、それがまた「荷物が届いた」という合図として扱われます。すると、スタッフが呼ばれ続けるループが起きる恐れがあります。

もっと詳しく知りたい方や、ハンズオンで学びたい方は、CloudTech（クラウドテック）もチェックしてみてください。

＼ ハンズオンで学びたい方はこちら ／

CloudTechの評判と割引クーポンを見る

Lambdaの注意点｜1回の作業時間には上限がある

Lambdaは1回の作業時間に上限があり、最長でも15分です。

上の図は、1回の作業に使える時間を、ものさしで表したものです。

出張スタッフの契約には「1回の依頼で働けるのは何分まで」という決まりがあり、時間を過ぎると、作業の途中でも打ち切られて帰ってしまいます。この決まりをタイムアウトと呼びます。

見落としやすいのが、何も設定しないと上限は3秒になっていることです。

設定を変えれば1秒きざみで長くできますが、それでも最大は900秒（15分）です。15分を超えるような長い仕事は、そもそもLambdaに頼む仕事ではありません。

では、どんな時に時間切れが起きやすいのでしょうか。公式ドキュメントが挙げている、よくある原因を表にまとめます。

時間切れの原因	出張スタッフで例えると
S3からのダウンロードがいつもより大きい・遅い	倉庫から運ぶ荷物がいつもより重い
呼び出した別のサービスの返事が遅い	電話で問い合わせた先がなかなか出ない
渡された内容で計算が重くなる	その日の依頼だけ手順が多い

公式ドキュメントは、タイムアウトをふだんの作業時間ぎりぎりに設定すると、思わぬ打ち切りが起きやすいとも注意しています。

試すときは小さなファイルだけでなく、本番で来そうな大きさのデータでも動かして、余裕のある時間にしておきましょう。

設定	出張スタッフで例えると	決まること
タイムアウト	1回の依頼で働ける時間	初期値は3秒。1秒きざみで最大15分まで
メモリ	スタッフに渡す道具の大きさ	メモリを増やすと、計算する力（CPU）も比例して増える

メモリは、スタッフに渡す道具の大きさのようなものです。Lambdaでは、メモリを大きくすると、それに比例して計算する力（CPU）も多く割り当てられます。

ただし、メモリを大きくすると作業時間あたりの料金も変わるので、大きければ大きいほどよい、というわけではありません。長く動かし続ける仕事はEC2のほうが向いている、という話も含めて、料金とEC2との違いはこの後の章で見ていきます。

Lambdaの実行ロールとは？スタッフに貸す通行証

実行ロールは、Lambdaがほかのサービス（S3など）を触るために貸す通行証です。

上の図の左では、通行証を首から下げたスタッフが倉庫の門を通っています。右のスタッフは通行証を持っていないので、門の前で止められています。

出張スタッフも、通行証が無ければ、よその倉庫には入れません。Lambdaも同じで、S3の荷物を読んだり置いたりするには、それを許可する通行証が要ります。

IAMの記事では、IAMロールを「業者に貸す、作業の間だけ使える通行証」として説明しました。実行ロールは、その通行証を、出張スタッフ（Lambda）に貸すものです。

実行ロール	出張スタッフで例えると	ポイント
何か	スタッフに貸す通行証	AWSのサービスやリソースに触る許可を与えるIAMロール
いつ使われる	呼ばれて作業する時に下げていく	関数が呼ばれると、Lambdaがこのロールを引き受ける
最初に付く許可	日報を書くことだけ	画面から作ると、ログを書く最小限の許可で自動作成される
足すもの	入りたい倉庫の分だけ	S3などを触るなら、必要な許可を足す

「呼ぶ許可」と「入る許可」は別もの

もう1つ混ざりやすいのが、S3がスタッフを呼ぶための許可と、スタッフがS3に入るための許可は別だということです。

S3がLambdaを呼べるようにする許可は、関数の側に付ける「誰がこの関数を呼んでよいか」の決まり（リソースベースのポリシー）に書きます。画面でS3のトリガーを作れば、この許可は自動で足されるので、ふだんは意識しなくても大丈夫。一方、関数がS3の荷物を読んだり置いたりするなら、実行ロールにもS3の許可が要ります。

向き	出張スタッフで例えると	どこに付ける
S3 → Lambda（呼ぶ）	倉庫がベルを鳴らしてよいか	関数のリソースベースのポリシー（画面でトリガーを作ると自動）
Lambda → S3（入る）	スタッフが倉庫に入ってよいか	関数の実行ロール（自分で足す）

もっと詳しく知りたい方や、ハンズオンで学びたい方は、CloudTech（クラウドテック）もチェックしてみてください。

＼ 詳しく学びたい方はこちら ／

CloudTechの評判と割引クーポンを見る

Lambdaの料金はどこにかかる？

Lambdaの料金は、呼ばれた回数と、作業していた時間にかかります。

上の図は、Lambdaの料金がかかる2つのものと、待っている間はメーターが止まっていることを表したものです。

出張スタッフに払うのは、「何回来てもらったか」と「現場で何分働いたか」の分です。呼んでいない間に、待ち時間の分を払うことはありません。

かかるもの	出張スタッフで例えると	ポイント
呼ばれた回数（リクエスト）	出張に来てもらった回数	呼ぶたびに数えられる
作業していた時間	現場で働いた時間	コードが動いていた時間の分
メモリの大きさ	渡した道具の大きさ	メモリの大きさによって、作業時間あたりの料金が変わる

ここで大事なのは、呼ばれていない間は、回数と作業時間の料金がかからないことです。

1日に数回しか動かない仕事なら、その数回の分だけで済みます。一方のEC2は、動いている間ずっと料金がかかるのが基本。この違いは、次の章で表にして比べます。

LambdaとEC2の違い｜「出張スタッフ」と「建物を借りて常駐」

EC2は建物を借りてスタッフを常駐させる、Lambdaは呼んだ時だけスタッフに来てもらう、という違いです。

上の図の左では、建物に常駐スタッフがいて、夜も灯りが点いています。右は、ふだんは誰もいない部屋に、ベルが鳴った時だけ出張スタッフが来る様子を描いています。

いつでもすぐ動けるのが常駐、使った分だけで済むのが出張。どちらが偉いわけではなく、仕事に合わせて使い分けます。

EC2で建物を借りる考え方は、EC2の記事で解説しています。

くらべる点	EC2（建物を借りて常駐）	Lambda（出張スタッフ）
サーバーの面倒	自分で見る（準備・台数の調整・パッチ・セキュリティ）	保守・台数の調整・パッチはAWSが見る
お金のかかり方	動いている間ずっと（何もしていなくても）	呼ばれた回数と作業時間の分だけ
1回の作業時間	動かしている限り動き続ける	最長15分（初期値は3秒）
向いている仕事	ずっと動かしておく仕事	何かが起きた時の短い仕事

どちらを選べばいい？

迷ったら、「その仕事は、何かが起きた時に短く終わるか」を考えてください。

ファイルが届いたら加工する、毎朝集計する、のように合図がはっきりしていて15分以内に終わる仕事はLambdaに向いています。Webサイトを1日中動かし続けるような仕事や、計算環境を自分で細かく決めたい仕事なら、EC2を選びましょう。

公式の比較ガイドも、EC2の管理には手間がかかると認めたうえで、計算環境を細かく管理したい用途なら、その手間は見合うことが多いと書いています。

つまり、手間を減らしたいならLambda、自分で細かく決めたいならEC2。出張スタッフと常駐スタッフのどちらが正しいかではなく、仕事の性質で選ぶものだと覚えておいてください。

もっと詳しく知りたい方や、ハンズオンで学びたい方は、CloudTech（クラウドテック）もチェックしてみてください。

＼ 手を動かして覚えたい方はこちら ／

CloudTechの評判と割引クーポンを見る

まとめ｜Lambdaは呼んだ時だけ来る出張スタッフ

Lambdaは、手順書を預けておけば、合図が来た時だけ駆けつけて作業してくれる出張スタッフです。

迷ったときは、「これはスタッフを常駐させる仕事か、呼んだ時だけ来てもらう仕事か」を考えてみてください。

それだけで、EC2とLambdaのどちらを使うか、Lambdaの画面で何を決めればいいかが見えてくるはずです。

建物（EC2）・大きな倉庫（S3）・入館管理（IAM）は、EC2の記事・S3の記事・IAMの記事で復習できます。

もっと詳しく知りたい方や、ハンズオンで学びたい方は、CloudTech（クラウドテック）の評判記事もどうぞ。