AWS Lambda
サーバーの管理なしにコードを実行できるサーバーレスコンピューティングサービスで、リクエスト数と実行時間に基づく完全従量課金制を採用している
概要
AWS Lambda は、サーバーのプロビジョニングや管理を一切行わずにコードを実行できるサーバーレスコンピューティングサービスです。S3 へのファイルアップロード、API Gateway への HTTP リクエスト、DynamoDB のデータ変更など、多数の AWS サービスからのイベントをトリガーとして関数を自動実行します。主要な言語ランタイムに対応し、コンテナイメージでのデプロイも可能です。課金はリクエスト数と実行時間に基づく従量制で、無料利用枠も設けられています。適用条件と単価は AWS Lambda の公式料金ページで確認してください。2026 年 9 月時点の AWS 公式ドキュメントでは、1 回の呼び出しの実行時間上限は 15 分、関数に割り当てられるメモリの上限は 10,240 MB です。
同期・非同期・イベントソースマッピングの使い分け
Lambda の呼び出しモデルは 3 種類あり、ワークロードの性質に応じて適切に選択する必要があります。同期呼び出しは API Gateway 経由の HTTP リクエストが代表例で、呼び出し元がレスポンスを待ちます。レイテンシが直接ユーザー体験に影響するため、コールドスタートの抑制が重要になります。非同期呼び出しは S3 イベント通知や SNS トピックからのトリガーで使われ、Lambda がイベントをキューに受け取って順次処理します。失敗時は自動でリトライされ、それでも失敗した場合はデッドレターキュー (SQS または SNS) に送信できます。イベントソースマッピングは SQS キューや Kinesis ストリームからメッセージをバッチで取得する方式で、バッチサイズやバッチウィンドウを調整することでスループットとコストのバランスを制御します。同時実行数は 2026 年 9 月時点の AWS 公式ドキュメントによるとリージョンあたりデフォルト 1,000 で、引き上げリクエストにより数万規模まで拡張できるとされています。
コールドスタートの原因と対策
コールドスタートは、関数の実行環境が新規に作成される際に発生する遅延です。原因はランタイムの初期化、デプロイパッケージの展開、関数コード外の初期化処理 (DB 接続の確立など) にあります。対策として最も確実なのは Provisioned Concurrency で、事前に指定した数の実行環境を温めておくことでコールドスタートの発生を抑えられます。ただし待機中も課金が発生するため、常時トラフィックがある API バックエンドなど、レイテンシ要件が厳しいケースに限定するのが合理的です。Java ランタイムでは SnapStart 機能が利用でき、初期化済みのスナップショットから復元することでコールドスタート時間を短縮できます。Azure Functions でも同様のコールドスタート課題が知られており、インスタンスを常時ウォームに保てるプランの選択が対策として挙げられます。実行時間の上限などプラン別の仕様は変更されることがあるため、比較する際は Microsoft の公式ドキュメントで最新の値を確認してください。
Step Functions との連携とデプロイ戦略
単一の Lambda 関数で完結しないワークフローには Step Functions が有効です。複数の Lambda 関数を順序制御・並列実行・条件分岐・エラーハンドリング付きで連携させるステートマシンを定義でき、リトライポリシーやタイムアウトも宣言的に設定できます。たとえば画像アップロード後に「サムネイル生成 → メタデータ抽出 → DB 登録 → 通知送信」を一連のワークフローとして管理するケースが典型的です。デプロイには AWS SAM や Serverless Framework を使った IaC 管理が推奨されます。SAM テンプレートで Lambda 関数、API Gateway、DynamoDB テーブルをまとめて定義し、CI/CD パイプラインに組み込むことで、コードの変更からデプロイまでを自動化できます。関数のバージョニングとエイリアスを活用すれば、カナリアデプロイやブルー/グリーンデプロイも実現可能です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。