AWS Lambdaの主要機能とデプロイ制御

AWS Lambdaはイベントを受け取って関数を実行するサービスです。呼び出し元や処理対象に応じて、キューをまとめて読み取る、入力データを選別する、処理を非同期にする、プライベートネットワークへ接続する、といった機能を組み合わせます。さらに、関数コードを再利用可能なレイヤーに分けたり、バージョンとエイリアスでリリースを制御したりできます。

機能名だけでなく、イベントを誰が読み取るか、失敗時に何が再試行されるか、成功したデータがどのように処理済みになるかを区別することが設計の要点です。

イベントソースマッピングでストリームやキューを処理する

イベントソースマッピング (event source mapping) は、Lambdaがストリームやキューからレコードを取得し、1件または複数件をバッチとして関数へ渡す連携設定です。代表的なソースには、Amazon SQS、Kinesis Data Streams、DynamoDB Streamsがあります。Amazon MSKやセルフマネージドKafka、Amazon MQ、Amazon DocumentDBなどにも対応するマッピングがあります。

API Gatewayからの同期リクエストのように、呼び出し元がその場で関数を呼ぶ連携とは異なり、イベントソースマッピングではLambda側のポーラーがソースを読み取ります。たとえば、工場のセンサー値がKinesis Data Streamsへ連続して届く場合、レコードをまとめて関数へ渡すことで、1レコードごとの呼び出しに比べて処理効率を上げられます。SQSでは、キューに蓄積した作業要求をLambdaが読み出して処理します。

ポーリングとバッチ処理

ポーラーはイベントソースを読み取り、設定に応じてバッチサイズとバッチウィンドウを使って関数呼び出しをまとめます。バッチサイズは一度に渡す最大レコード数、バッチウィンドウはレコードが届き始めてからバッチを呼び出すまで待てる時間です。どちらかの条件に達すると、その時点のレコードをバッチとして関数へ渡します。ウィンドウがゼロの場合は、サイズやサービスのポーリング動作に従って呼び出されます。

利用できるバッチサイズやウィンドウの上限は、SQS、Kinesis、DynamoDB Streamsなどソースごとに異なります。イベントペイロードの上限、処理時間、許容できる待ち時間も考慮して調整します。バッチを大きくすれば呼び出し回数が減る場合がありますが、一部のレコードで失敗したときに影響する範囲や再処理量が増えることがあります。

少なくとも1回の配信と重複処理

イベントソースマッピングの処理は、一般に少なくとも1回の配信です。関数がレコードを処理した後、完了状態の更新がソースに反映される前に障害が起きるなどすると、同じレコードが再度届く場合があります。バッチ処理で一部が失敗し、失敗した部分が再試行される場合にも、成功済みのレコードが再び含まれる可能性があります。

成功したデータを処理済みにする仕組みはソースによって違います。

• SQS: バッチ処理が成功すると、Lambdaは処理対象のメッセージをキューから削除します。失敗したメッセージは可視性タイムアウト後に再び配信され、再試行されることがあります。
• Kinesis Data Streams / DynamoDB Streams: メッセージを削除するのではなく、読み取り位置（チェックポイント）が進みます。ストリーム上のレコード自体は保持期間中残ります。失敗箇所から再試行する設定では、同じレコードが再度渡る可能性があります。

副作用のある処理では、重複して実行しても結果が壊れない冪等性を設計します。たとえば、注文番号などイベント内の一意な識別子を使って処理済み記録を照合し、同じ識別子の更新を二重に確定しないようにします。識別子の保存や照合には追加のストレージ、読み書き、実装が必要です。重複を許容できる処理か、重複排除のコストをかけるべき処理かを要件に沿って判断します。

処理順序の要件もソースに依存します。ストリームではシャード内の順序が考慮されるため、あるレコードの失敗によって同じシャードの後続処理が遅れる場合があります。バッチ全体を再試行するか、部分バッチ応答を使って失敗レコードだけを再試行するかも、ソースと設定に応じて検討します。

イベントフィルタリングで関数に渡すレコードを選ぶ

イベントフィルタリングは、イベントソースマッピングの設定に含まれる機能です。JSON形式のフィルターパターンを定義し、条件に一致したレコードだけを関数へ渡します。ポーラーが条件を評価するため、関数コードに不要なレコードを渡して判定する必要が減ります。これにより、不要な関数実行や独自の振り分けコードを減らし、実行コストや処理の複雑さを抑えられます。

たとえば、配送ステータスの変更イベントから「配達完了」だけを後続処理する場合、イベント内のステータス値に対するフィルターを設定できます。関数は対象イベントだけを受け取って、顧客向け通知や集計を実行します。イベントのJSON構造やフィルターに指定できる演算子には制約があるため、対象ソースごとの公式仕様に従ってパターンを作ります。

フィルターに一致しなかったレコードがどう扱われるかは重要です。

ソース	フィルターに一致しないレコードの扱い
SQSなどのキュー	対象外として処理されず、キューから削除されます。後からフィルター条件を変えても、そのメッセージは戻りません。
Kinesis Data Streams / DynamoDB Streams	関数には渡されず、読み取り位置が先へ進みます。ストリームから即時削除されるわけではなく、保持期間に従って期限切れになります。

したがって、イベントフィルタリングは「条件に一致しないデータを保管して後で処理する」機能ではありません。必要なデータまで捨てないよう、フィルターパターンを検証し、監査や再処理に必要な場合は別の保存・配信経路を用意します。

非同期呼び出しと失敗時の処理

Lambdaの非同期呼び出しでは、呼び出し元は関数の実行完了を待ちません。Lambdaサービスがイベントを受け付けると、内部のキューに保存し、後から関数を実行します。呼び出し元が受け取る応答はイベントの受付を示すもので、関数処理の成功を保証する応答ではありません。

Amazon S3の通知やAmazon SNSからのイベントなどが非同期呼び出しの例です。たとえば、音声ファイルのアップロードを受けてLambdaが波形プレビューを作る構成では、アップロードを受け付けた側はプレビュー生成の完了まで待たず、Lambdaが別途処理を進めます。

再試行とイベント保持

関数の実行がエラーで終わる場合、非同期呼び出しは既定で最大2回再試行されます。通常、最初の再試行まで約1分、次の再試行まで約2分待ちます。スロットリングやLambdaサービス側のエラーでは、別のバックオフ動作で再試行されることがあります。イベントをキューに保持する最大期間（最大イベント経過時間）も設定でき、既定値は6時間です。再試行回数や保持時間は非同期呼び出し設定で調整します。

再試行されるため、ハンドラーの処理が途中まで成功していた場合には、同じイベントによる副作用が重複する可能性があります。イベントに基づく更新を冪等にし、どの失敗を再試行するかを設計します。また、失敗が解消されないイベントを長時間保持し続けると、後続処理や調査を遅らせることがあります。

非同期呼び出しが失敗した後のイベント送信先には、デッドレターキュー (DLQ) と イベント送信先 (destination) があります。SQSまたはSNSをDLQとして指定すると、最終的に処理できなかった元イベントを隔離し、後から調査・再処理できます。非同期呼び出しの送信先は、成功時と失敗時の両方を設定でき、SQS、SNS、EventBridgeイベントバス、別のLambda関数などを選べます。送信先のレコードには呼び出しや実行結果に関する情報が含まれ、DLQが主に元イベントを保持する点が異なります。成功時の通知をSNSへ送る構成も可能です。

宛先やDLQを、失敗した同じ処理へ無条件に戻すと、エラーを解消しないまま再投入を繰り返す設計になり得ます。また、処理後の出力が再び同じLambdaを起動するイベント源へ書き込まれる場合も、自己増殖する呼び出しループを招くことがあります。入力と出力を分ける、S3通知のプレフィックス/サフィックスで対象を絞る、失敗イベントを隔離先へ送る、再試行回数とイベント保持時間を適切に設定する、といった対策を組み合わせます。Lambdaの標準再試行は無制限ではありませんが、関数が新たなイベントを繰り返し作れば呼び出しは継続し、料金や下流負荷が増えるおそれがあります。

Lambda関数をVPC内のリソースへ接続する

Lambda関数は、初期状態では利用者が管理するVPCの中に配置されていません。Lambdaのサービス管理環境からAWSサービスなどへ接続できますが、利用者のVPCにあるプライベートなデータベースや内部システムへアクセスさせるには、関数にVPC設定を追加します。

関数のVPC設定では、接続先VPC内のサブネットとセキュリティグループを指定します。Lambdaは関数からVPCへ接続するためのネットワークインターフェイスを作成・管理します。冗長性を考慮して異なるアベイラビリティゾーンのサブネットを選択できますが、選択したすべてのサブネットとセキュリティグループの組み合わせで通信経路が整っている必要があります。

セキュリティグループは、関数がVPC内のどのポートや宛先へ通信できるかを制御します。接続先のデータベースやサービス側のセキュリティグループでも、Lambda側からの通信を許可する必要があります。AWSサービスへVPC内からプライベート接続する場合は、要件に応じてVPCエンドポイントも利用できます。

Lambdaの実行ロールには、VPC接続用ネットワークインターフェイスを作成、参照、削除するためのEC2ネットワーク権限が必要です。AWS管理ポリシー AWSLambdaVPCAccessExecutionRole を使う方法があります。関数の実行ロールは、実行中に関数が他のAWSサービスへアクセスする権限も制御します。

VPCに接続したLambdaがインターネットへ接続できるかは、サブネットの経路やNATの有無などで決まります。パブリックサブネットを選んだだけでは、LambdaにパブリックIPアドレスが割り当てられず、インターネットへのアウトバウンド経路は得られません。 外向き通信が必要なら、通常はプライベートサブネットからNATゲートウェイへルーティングするか、アクセス先に対応したVPCエンドポイントを使います。

Lambda関数URLでHTTPSエンドポイントを提供する

Lambda関数URL (Function URL) は、Lambda関数へ直接HTTPSエンドポイントを割り当てる機能です。単一の関数をWebhookや小規模なHTTP APIとして公開する用途では、API Gatewayより少ない設定で始められます。一方、ルーティング、リクエスト検証、認証方式、キャッシュ、使用量制御などのAPI機能が必要なら、API Gatewayが適しています。

関数URLには次の認証タイプがあります。

• AWS_IAM: IAM認証を使用します。呼び出し側はAWS Signature Version 4で署名したリクエストを送り、呼び出し権限を持つIAMプリンシパルで認証します。関数のリソースベースポリシーなどで許可も必要です。
• NONE: URLを利用する呼び出しでIAM署名による認証を要求しません。公開APIとして使う場合は、誰が関数を実行できるか、不要な呼び出しをどう防ぐかを慎重に設定します。

認証タイプの設定だけで認可全体が決まるわけではありません。関数URLを呼び出すには関数のリソースベースポリシーに適切な許可が必要です。NONEを選んだからといって、リソースポリシーや公開範囲を確認せずに済むわけではありません。また、必要に応じてCORSを設定し、ブラウザーからのクロスオリジン要求を制御します。

関数URLではCloudWatchメトリクスを使って要求数やエラーを監視できます。関数自体の Invocations や Errors などと合わせて確認すると、URL経由のアクセス状況や失敗を追いやすくなります。不特定多数から呼び出せる構成では、メトリクスとアラームを使って急増やエラーを検知し、コストと下流サービスへの負荷を管理します。

Lambdaレイヤーで共有コンポーネントを分離する

Lambdaレイヤーは、ライブラリ、依存関係、カスタムランタイム、設定ファイルなどをZIP形式でパッケージし、複数のLambda関数から共有する機能です。共通で使う認証処理やデータ形式ライブラリをレイヤーにまとめれば、各関数のデプロイパッケージに同じファイルを重複して含めずに管理できます。

1つの関数に関連付けられるレイヤーは最大5つです。関数のデプロイパッケージだけでなくレイヤーも全体のパッケージサイズ制限に含まれるため、レイヤーに分けるだけでLambdaのサイズ上限をなくせるわけではありません。依存ライブラリの更新時には、レイヤーの新しいバージョンを発行し、利用する関数の設定も更新します。ランタイムやCPUアーキテクチャとの互換性も確認してください。

レイヤー機能がない場合は、共有ライブラリを関数ごとのZIPパッケージへそれぞれ含める必要があります。レイヤーに分離すると更新や再利用がしやすくなる一方、関数が利用するレイヤーのバージョンも依存関係として管理する必要があります。

バージョンとエイリアスでリリースを管理する

Lambdaの $LATEST は、関数コードや設定を更新するたびに変化する作業用のバージョンです。関数を発行 (publish) すると、その時点のコードとバージョン対象の設定が番号付きバージョンとして保存されます。発行済みバージョンは変更できません。修正や設定変更を反映するときは、変更後の $LATEST から別のバージョンを発行します。

バージョンを分けると、以前のコードを保持したまま新しいコードを並行して試せます。呼び出し元が $LATEST を指定するのか、番号付きバージョンやエイリアスを指定するのかで、どのコードへ到達するかが決まります。過去のコードが残っているだけで自動的に旧バージョンへ戻るわけではありません。

エイリアスは、関数のバージョンを指す可変の名前です。たとえば staging や production といった環境名を割り当て、呼び出し元にはバージョン番号の代わりにエイリアスのARNを設定できます。エイリアスの参照先を変更すれば、呼び出し元の設定を変えずに利用バージョンを切り替えられます。

加重エイリアスによるカナリアリリース

エイリアスには2つのバージョンを指定し、追加のバージョンへ流す重みを設定できます。現行バージョンを90%、新バージョンを10%にすると、本番要求の一部を新コードへ送り、メトリクスやエラー率を観察できます。これはカナリアリリースの基本形です。指定した比率は呼び出し単位の振り分け比率で、短時間の実要求数が厳密に同じ比率になることを保証するものではありません。

例として、商品検索APIがLambdaのバージョン5を本番利用しているとします。新しい検索ロジックをバージョン6として発行し、staging エイリアスをバージョン6へ向ければ、テスト環境から新しいコードを確認できます。検証後、API Gatewayの本番統合先は production エイリアスのARNを呼び出すようにし、まずバージョン5を90%、6を10%に設定します。エラーや遅延に問題がなければ、重みを段階的に新バージョンへ移し、最後にバージョン6を100%にします。

問題が起きたら、エイリアスの参照先や重みをバージョン5へ戻してロールバックできます。API Gatewayのステージ名とLambdaのエイリアスは別の仕組みです。どのAPI GatewayステージがどのLambdaエイリアスARNを呼ぶのかを明示し、検証経路と本番経路を取り違えないようにします。重みの変更を自動化し、CloudWatchアラームに基づく停止・ロールバックを行う場合は、CodeDeployなどのデプロイ機能も利用できます。

クォータと実行環境の上限

Lambdaには、同時実行数、デプロイパッケージ、ネットワークインターフェイス、関数設定、実行時間などにクォータや上限があります。アカウント・リージョンごとの同時実行クォータやストレージクォータのようにService Quotasから増枠を申請できるものがある一方、関数ごとの最大タイムアウトなど増枠できない固定上限もあります。「クォータ」と呼ばれる項目すべてを申請で引き上げられるわけではありません。

特に押さえる設定と設計上の意味は次のとおりです。

項目	設計上の意味
同時実行数	同時に実行中の呼び出し数に上限がある。アカウント・リージョンのクォータや関数単位の予約設定を確認し、下流サービスへ過剰な負荷をかけないようにする。
デプロイパッケージ	ZIP形式とコンテナイメージ形式で上限が異なり、ZIP関数ではレイヤーもサイズ計算に含まれる。正確な制限は更新されるため、現行のLambdaクォータを参照する。
VPCネットワーク	Lambdaが使うネットワークインターフェイスはVPCのネットワーク資源とクォータに関係する。VPC接続する関数数やサブネット設計を含めて確認する。
メモリ	関数に割り当てるメモリ量を設定する。LambdaではCPUを独立した設定値として直接指定せず、割り当てメモリに応じてCPU性能も変化する。
一時ストレージ	/tmp の容量を設定できるが、永続ストレージではない。実行環境の再利用や終了を前提にデータを残さない。
タイムアウト	1回の実行に設定できる最大時間は900秒（15分）。関数がそれを超えて動作し続けることはできない。
レイヤー数	1関数に関連付けられるレイヤーは最大5つ。レイヤーと関数パッケージの合計サイズ制限も確認する。

実行時間が15分を超える処理や長時間稼働するワーカーは、Lambdaのタイムアウトを超えて実行できません。AWS Batch、ECS/Fargate、Step FunctionsとLambdaの組み合わせなど、長時間処理や複数段階のワークフローに合う実行方式を選びます。

同時実行数、メモリ、タイムアウト、デプロイパッケージの具体値や申請可否は、リージョン、アカウント、パッケージ種別、機能によって異なり、更新されることがあります。運用前にService QuotasとLambdaの公式クォータ一覧を確認してください。

試験で押さえるポイント

• イベントソースマッピングはLambda側がSQSなどをポーリングし、レコードをまとめて関数へ渡す。API Gatewayの同期呼び出しやLambda非同期呼び出しとは別の連携方式。
• イベントソースマッピングは少なくとも1回の処理になり得る。再試行による重複を考慮し、必要な処理は冪等にする。
• バッチサイズとバッチウィンドウはソースごとに上限や動作が異なる。SQSでは成功したメッセージが削除され、ストリームではチェックポイントが進み、レコード自体は保持期間中残る。
• フィルターパターンは関数呼び出し前に評価される。除外されたSQSメッセージは削除され、ストリームのレコードは関数に渡されず保持期間までストリームに残る。
• 非同期呼び出しはイベントの受付と関数処理完了が別である。関数エラーは既定で2回再試行されるが、イベントの重複や処理ループを考慮し、DLQ、送信先、最大イベント経過時間を設計する。
• LambdaをVPCに接続するにはサブネット、セキュリティグループ、ネットワークインターフェイス管理権限を設定する。パブリックサブネットに置くだけではインターネット接続は成立しない。
• 関数URLは AWS_IAM と NONE を選べる。NONEでも関数へのアクセス許可と公開範囲をリソースポリシーで確認する。
• レイヤーは関数間で共有するライブラリやカスタムランタイムに使い、1関数につき最大5つまで関連付けられる。
• 発行済みバージョンは不変で、エイリアスはバージョンを指す可変の名前。加重エイリアスは最大2バージョンへトラフィックを振り分け、カナリアリリースやロールバックに使える。
• Lambdaの最大実行時間は900秒。メモリに応じてCPUが割り当てられ、上限や増枠可否は項目ごとに確認する。

公式ドキュメント

• Lambdaイベントソースマッピング
• Lambdaイベントソースマッピングのフィルタリング
• Lambdaの非同期呼び出しエラー処理
• Lambdaの非同期呼び出し送信先
• Lambda関数のVPCアクセス
• Lambda関数URL
• Lambdaレイヤー
• Lambdaのバージョン
• Lambdaのエイリアスとトラフィックシフト
• Lambdaのクォータ
• AWS Lambda料金