Lambda

Lambda とは

AWS Lambda は、サーバーの管理なしにコードをイベント駆動で実行するサーバーレスコンピューティングサービスである。API リクエスト、S3 イベント、DynamoDB Streams、スケジュールなどのトリガーで関数が起動し、実行時間に応じて課金される。

特徴

Lambda は OS、パッチ、スケーリングを AWS が管理するため、サーバー管理が不要だ。API リクエスト、S3 イベント、DynamoDB Streams などのトリガーでイベント駆動的に起動し、同時実行数に応じて自動スケールする。課金はリクエスト数と、割り当てメモリ量 × 実行時間 (GB 秒・1 ミリ秒単位) の従量制で、メモリを増やすと同じ処理時間でも単価が上がる。1 回の呼び出しで実行できるのは最大 15 分 (900 秒) までだ。

設計時に効いてくる上限は 3 つある。メモリは 128 MB から 10,240 MB まで 1 MB 刻みで指定し、CPU はメモリに比例して割り当てられる (1,769 MB でおよそ 1 vCPU)。書き込める領域は /tmp だけで既定 512 MB、最大 10,240 MB まで広げられる。同時実行数はリージョンごとのクォータで既定 1,000、引き上げ申請で数万まで伸ばせる (作成したばかりのアカウントは既定より低い枠から始まり、使用実績に応じて自動で引き上げられる)。

SAM での定義

SAM での定義の例を示す。

GetUser:
  Type: AWS::Serverless::Function
  Properties:
    Handler: index.handler
    Runtime: nodejs22.x
    MemorySize: 256
    Timeout: 30
    Events:
      Api:
        Type: HttpApi
        Properties:
          Path: /users/{id}
          Method: GET
    Policies:
      - DynamoDBCrudPolicy:
          TableName: !Ref UsersTable
    Environment:
      Variables:
        TABLE_NAME: !Ref UsersTable

Lambda 関数の実装

Lambda 関数の実装のコード例を示す。

import { APIGatewayProxyEventV2, APIGatewayProxyResultV2 } from 'aws-lambda';

export const handler = async (event: APIGatewayProxyEventV2): Promise<APIGatewayProxyResultV2> => {
  const id = event.pathParameters?.id;
  const user = await db.get({ TableName: process.env.TABLE_NAME!, Key: { id } });
  if (!user.Item) return { statusCode: 404, body: 'Not Found' };
  return { statusCode: 200, body: JSON.stringify(user.Item) };
};

トリガー

トリガーを以下にまとめる。

トリガー	用途
API Gateway	REST / HTTP API
S3	ファイルアップロード時の処理
DynamoDB Streams	テーブル変更の処理
SQS	非同期メッセージ処理
EventBridge	スケジュール実行、イベントルーティング
CloudWatch Logs	ログのフィルタリング

コールドスタート

コールドスタートを図で示す。

コールドスタート: 実行環境の初期化 (100ms〜数秒)
  → 初回リクエストのレイテンシが増加

対策:
  - Provisioned Concurrency: 事前にウォームアップ
  - SnapStart (Java 11 以降 / Python 3.12・3.13 / .NET 8): 初期化済みスナップショットから復元
  - 軽量ランタイム: Node.js, Python (Go, Rust はさらに高速)

Provisioned Concurrency と SnapStart は同じ関数で併用できない。Provisioned Concurrency はランタイムを問わず効くが待機させる実行環境の分だけ費用がかかる。SnapStart は対象ランタイムが限られ、EFS や 512 MB を超える一時ストレージとも併用できない。どちらも使えない場合は、初期化処理をハンドラー外に置いて実行環境の再利用で効かせる、依存関係を削ってパッケージを軽くする、といった地道な短縮が残る。

ECS との使い分け

前節のコールドスタートは「呼び出しのたびに実行環境を用意する」という Lambda の実行モデルから生じる。常駐プロセスを前提とする ECS と並べると、モデルの差がそのまま使い分けの基準になる。

実行モデルの違い	Lambda	ECS (Fargate)
実行環境の用意	呼び出しのたびに用意され、処理後は凍結される	起動したタスクを常駐させる
1 リクエストの上限	15 分	上限なし
同時実行の増え方	同時実行数の分だけ実行環境が増える (増えた分はコールドスタートになる)	タスク数を Auto Scaling で増やす
メモリ上の状態	実行環境が再利用されれば残るが、残る保証はない	タスクが動いている間は保持できる
待ち時間の扱い	外部 API の応答待ちも実行時間として課金される	待ち時間の有無に関わらずタスクの確保時間で課金される

15 分を超える処理、常駐プロセス、メモリ上のキャッシュを前提にした設計は ECS 側が向く。逆に、呼び出しがまばらで待機中のコストを払いたくない処理は Lambda が有利になる。

実務での活用方法は関連書籍にも詳しい。