EC2 で「1台借りて、OS を入れて、アプリを動かす」ところまでは分かった。ところが設計図を見ると、サーバーが1台も描かれていないのに処理が動いている構成が出てきます。 「ファイルが置かれたら Lambda が動く」「API の裏は Lambda」と言われても、そのプログラムがどこで動いていて、止めなくてよいのか、何でも Lambda で書けるのかが分からない。
この記事は、AWS Lambda を イベント駆動 の「呼ばれたときだけ動く関数」として理解し、制約と向き不向きを、EC2・コンテナと並べて整理します。
この記事の結論
- AWS Lambda は、イベントが届いたときだけ関数（コード）を実行し、終わったら止まるコンピューティングのサービスです。
- Lambda ではサーバーの用意・OS の管理・台数の増減を AWS が担い、利用者はコードと設定と権限を持ちます。
- 標準の Lambda 関数の実行時間は最大 15 分（900 秒）で、長く続く処理や常に待ち受ける処理には向きません。
- 料金は呼び出しの回数と実行時間による従量課金で、動いていない時間には実行の料金がかかりません。
- EC2・コンテナ・Lambda の違いは、どこまでを自分で持ち、どこからを AWS に任せるかの違いです。
AWS Lambda とは（何のためにあるか）
AWS Lambda は、サーバーを用意・管理せずにコードを実行できるサービスです。公式ドキュメントは「サーバーのプロビジョニングや管理をせずにコードを実行できるコンピューティングサービス」と説明しています。 書いたプログラムのまとまりを 関数 と呼び、何かが起きたとき（イベント）にその関数が呼ばれます。
たとえるなら、EC2 は「店を1軒借りて、店員を常に置いておく」形です。客が来なくても店は開いていて、家賃がかかります。 Lambda は「仕事が入ったときだけ来てくれる出張の職人」に近い形です。依頼が入ると現れて仕事をし、終われば帰ります。待っている時間の人件費は払いません。
たとえ話から正確な言葉に戻すと、こうなります。
- イベント … 関数を呼ぶきっかけ。S3 にファイルが置かれた、API に要求が来た、決まった時刻になった、キューにメッセージが入った、など。
- 関数 … イベントを受け取って処理するコード。Python・Node.js・Java など、Lambda が用意する実行環境（ランタイム）の上で動きます。
- 実行環境 … 関数を動かす入れ物。AWS が用意し、使い終わったら片付けます。利用者はその中の OS やサーバーを触りません。
このように、サーバーの管理を利用者から切り離した作り方を サーバーレス と呼びます。サーバーが存在しないのではなく、「利用者がサーバーを持たない」という意味です。 需要に応じて自動で並列に増えるので、突然の要求の増加にも、台数を自分で増やさずに対応できます。
Lambda はどう動くのか（イベントから終わりまで）
Lambda の1回の動きは、「イベントが届く → 実行環境が用意される → 関数が動く → 結果を返すか、どこかへ書き出して終わる」の順です。
EVENT TO RESULT1回の動き
イベントが届いたときだけ動き、終われば止まる
-
イベント
S3 に置かれた・API に要求が来た
-
実行環境
AWS が用意する入れ物
-
関数
書いたコードが動く
-
結果
返す・保存して終わる
イベントを出す側と、受け取り方
関数を呼ぶ側にはいくつかの型があります。
- 直接呼ぶ … Amazon API Gateway が HTTP の要求を受けて Lambda を呼ぶ。Web の API の裏側によく使われます。
- 通知で呼ぶ … S3 のイベント通知で、ファイルが置かれるたびに関数を呼ぶ。サムネイル作成や、形式の変換のような軽い処理に向きます。
- 時刻で呼ぶ … Amazon EventBridge のスケジュールで、毎朝・毎週のように決まった時刻に呼ぶ。
- キューや流れを読みに行く … Amazon SQS のキューや DynamoDB Streams のような流れは、Lambda 側が読みに行って関数を呼びます。この仕組みを イベントソースマッピング と呼びます。
権限は2方向ある
Lambda の権限は、向きの違う2つに分かれます。ここを取り違えると、設定したのに動かない原因になります。
- 関数が何をしてよいか … 関数に 実行ロール（IAM ロール） を割り当て、S3 や DynamoDB を触る許可を与えます。アクセスキーをコードに書く必要はありません。
- 誰が関数を呼んでよいか … S3 や別のサービスから呼ばせるときは、関数の側のリソースベースポリシーで呼び出し元を許可します。
IAM のユーザーとロールの考え方は、先に IAM の記事で押さえておくと読みやすくなります。
READ ALSO — 学習中向け・段1 入口
IAM とは何か｜ユーザー・ロール・ポリシーを「誰が・何に・何をしてよいか」で読み解く
最初の1回だけ遅いことがある
しばらく呼ばれていない関数を呼ぶと、実行環境を用意するぶん、最初の1回だけ応答が遅れることがあります。これを コールドスタート と呼びます。 応答の速さが大事な関数では、あらかじめ実行環境を温めておく プロビジョンド同時実行 という設定で遅れを減らせます。
CHECK 1ここまでの確認
Lambda の関数が動き出すきっかけとして、正しい説明は?
答えと解説
答え: 2. S3 へのアップロードや API の呼び出しなどのイベントが届いたときに、関数が呼ばれる
Lambda は「イベントが来たら関数を呼ぶ」形です。常に動いているサーバーを自分で持たないのが EC2 との違い。「どう動くのか」の章を読み直してください。
Lambda で知っておく制約は何か
Lambda は「短く終わる処理を、呼ばれたぶんだけ動かす」前提で作られています。その前提が、上限の値に表れています。 次の値は、2026年9月時点の AWS Lambda 開発者ガイドで確認した標準の関数の値です。上限は変わることがあるので、使う前に公式のクォータのページで確認してください。
| 項目 | 標準の関数の値 | 何を意味するか |
|---|---|---|
| 実行時間（タイムアウト） | 既定 3 秒、最大 900 秒（15 分） | 1回の実行が 15 分を超える処理は、そのままでは最後まで動かない |
| メモリ | 128 MB〜10,240 MB（1 MB 単位） | メモリを増やすと、割り当てられる CPU も比例して増える |
| 一時領域（/tmp） | 既定 512 MB、最大 10,240 MB | 実行中に一時ファイルを置ける場所。実行環境と一緒に消える |
| 同時に動かせる数 | アカウントとリージョンごとの上限（クォータ）がある | 上限は引き上げを申請できる。重要な関数には予約済み同時実行で枠を確保できる |
Lambda でつまずきやすい3つ
- 15 分を超える処理を1つの関数に詰め込み、途中でタイムアウトして止まる
- /tmp に置いたファイルが次の呼び出しでも残っている前提で作る（実行環境はいつ片付けられるか分からない）
- VPC に接続した関数から外のインターネットへ出ようとして、NAT ゲートウェイの経路が無くタイムアウトする
3つめは VPC の経路の話です。VPC に接続した Lambda は、プライベートサブネットから NAT ゲートウェイを通って外へ出ます。サブネットと経路の考え方は VPC の記事で扱っています。
処理が長くなるときは、1つの関数を大きくするのではなく、処理を小さな関数に分けて順につなぎます。つなぎ役には AWS Step Functions や、途中経過を記録して再開できる Lambda の durable functions があります。 また、Lambda には Lambda Managed Instances のように、実行の形と上限が標準の関数と異なる形態もあります。上の表は標準の関数の値として読んでください。
CHECK 2ここまでの確認
標準の Lambda 関数で、1回の実行が 30 分かかる処理を動かそうとしたときに起きることは?
答えと解説
答え: 1. タイムアウトの上限（15 分）を超えるので、そのままでは最後まで動かない
標準の関数のタイムアウトは最大 900 秒（15 分）です。メモリを増やすと CPU は増えますが、上限の時間は延びません。「知っておく制約」の章を読み直してください。
Lambda に向く処理・向かない処理とは
制約を裏返すと、向き不向きが見えてきます。判断の軸は3つです。
- 1回の処理は短いか … 15 分以内に終わる単位に切れるか。
- 呼ばれ方は散発的か … 要求が来たり来なかったりするか。常に一定の量が流れ続けるか。
- 状態を持つか … 前の呼び出しの続きを、関数の中に覚えておく必要があるか。
FITS OR NOT向き不向き
短く・散発的で・状態を持たない処理が Lambda に向く
向く処理
- ファイルが届いたときの変換S3 のイベント通知で1件ずつ
- API の裏の短い処理API Gateway から呼ばれて返す
- 決まった時刻の集計EventBridge のスケジュール
向かない処理
- 15 分を超える一括処理標準の関数の上限を超える
- 接続を持ち続ける処理常に待ち受ける場所が要る
- 実行環境を作り込むアプリOS の設定や常駐ソフトが前提
向く処理の典型は、S3 に置かれたファイルを1件ずつ変換する処理、API の要求を受けてデータベースを読み書きして返す処理、毎朝のレポート作成のような定期の処理です。 どれも「来たら動いて、すぐ終わる」形で、来ない時間には料金がかかりません。
向かない処理は、何時間もかかる一括処理、利用者と接続を張りっぱなしにする処理、特定の OS の設定や常駐のソフトウェアを前提にしたアプリです。 こうした処理は、コンテナや EC2 のように「動き続ける場所」を持つほうが素直です。 また、常に大量の要求が途切れず流れる場合は、呼び出しごとに課金される形が割高になることもあります。料金の比べ方は料金の考え方の記事を参照してください。
READ ALSO — 未経験向け・段1 入口
AWS の料金の考え方｜従量課金・無料利用枠・止め忘れを「電気代」で理解する
EC2・コンテナと何が違うのか
EC2・コンテナ・Lambda の違いは、どこまでを自分で持ち、どこからを AWS に任せるかの違いです。下の積み木の図で、色の付いた段が「自分で持つ」範囲です。
WHAT YOU OWN自分で持つ範囲
EC2 → コンテナ → Lambda の順に、自分で持つ段が減る
EC2
- 物理サーバーと設備
- OS とパッチ
- 実行環境・イメージ
- 台数・起動と停止
- コード・設定・権限
コンテナ（Fargate）
- 物理サーバーと設備
- OS とパッチ
- 実行環境・イメージ
- 台数・起動と停止
- コード・設定・権限
Lambda
- 物理サーバーと設備
- OS とパッチ
- 実行環境・イメージ
- 台数・起動と停止
- コード・設定・権限
自分で持つAWS に任せる
| 観点 | EC2 | コンテナ（ECS の Fargate など） | Lambda |
|---|---|---|---|
| 自分で持つもの | OS・ミドルウェア・アプリ・台数 | コンテナイメージ・タスクの数と大きさ | コード・設定・実行ロール |
| 動いている時間 | 起動している間ずっと | タスクが動いている間 | 呼ばれて処理している間だけ |
| 1回の処理の長さ | 制限なし（止めるまで動く） | 制限なし（止めるまで動く） | 標準の関数は最大 15 分 |
| 増やし方 | 台数を自分で決める（Auto Scaling の設定） | タスクの数を設定で増減する | 呼び出しに応じて自動で並列に増える |
| 料金の単位 | 起動している時間 | タスクに割り当てた CPU・メモリと時間 | 呼び出しの回数と実行時間 |
EC2 は自由度が最も高く、そのぶん OS のパッチ当てや台数の管理も自分の仕事です。 コンテナは「実行環境ごと箱に詰めて持ち込む」形で、動かす場所の管理を Fargate などに任せられます。Lambda はさらに進めて、動いていない時間そのものを持たない形です。 なお、Lambda の関数はコンテナイメージとして配ることもできますが、その場合も実行の仕組みは Lambda のままで、15 分の上限などの制約は変わりません。
どれが優れているかではなく、処理の形に合うかで選びます。「短く、散発的で、状態を持たない」なら Lambda、「動き続ける」ならコンテナか EC2、「OS まで作り込みたい」なら EC2、が出発点です。 コンテナ基盤の中での選び方（ECS か EKS か）まで含めた判断は、次の記事で扱います。
READ ALSO — 実務向け・段3 基盤
ECS か EKS か、それとも EC2 か Lambda か｜コンテナ基盤の判断を「何を自分で持ちたいか」で決める
CHECK 3ここまでの確認
EC2 と比べたときの Lambda の特徴として正しいものは?
答えと解説
答え: 2. OS やサーバーの台数は AWS が持ち、利用者はコードと設定と権限を持つ
EC2 は OS から上を自分で持ちます。Lambda はサーバーの管理を AWS が担い、利用者はコード・設定・実行ロールに集中します。「EC2・コンテナと何が違うのか」の章を読み直してください。
参照ソース
- What is AWS Lambda?（AWS Lambda 開発者ガイド） — Lambda の定義（サーバーを管理せずにコードを実行する）とイベント駆動の説明（2026年9月時点）
- Lambda quotas（AWS Lambda 開発者ガイド） — タイムアウトの最大 900 秒、同時実行数のクォータ、Lambda Managed Instances の例外（2026年9月時点）
- Configure Lambda function timeout（AWS Lambda 開発者ガイド） — タイムアウトの既定 3 秒と最大値（2026年9月時点）
- Configure Lambda function memory（AWS Lambda 開発者ガイド） — メモリの範囲 128〜10,240 MB と、CPU がメモリに比例して割り当てられること（2026年9月時点）
- Configure ephemeral storage for Lambda functions（AWS Lambda 開発者ガイド） — /tmp の既定 512 MB と最大 10,240 MB（2026年9月時点）
- Lambda concurrency（AWS Lambda 開発者ガイド） — 同時実行と予約済み同時実行の考え方（2026年9月時点）
- Lambda execution role（AWS Lambda 開発者ガイド） と Resource-based policies（同） — 権限の2方向（実行ロールと呼び出し元の許可）（2026年9月時点）
- Lambda event source mappings（AWS Lambda 開発者ガイド） — SQS や DynamoDB Streams を Lambda が読みに行く仕組み（2026年9月時点）
- Lambda durable functions（AWS Lambda 開発者ガイド） — 途中経過を記録して再開する長い手順の書き方（2026年9月時点）
