AWS Lambda
開発者ガイド

AWS Lambda イベントソースマッピング

Lambda 関数およびイベントソースは AWS Lambda の主な構成要素です。イベントソースはイベントを発行するエンティティであり、Lambda 関数はそのイベントを処理するカスタムコードです。サポートされているイベントソースは、AWS Lambda で使用できるように事前設定された AWS サービスです。この設定はイベントソースマッピングといい、イベントソースを Lambda 関数にマッピングします。これにより、イベントが発生した場合に Lambda 関数の自動呼び出しが可能になります。

各イベントソースマッピングは、発行するイベントのタイプおよびイベント発生時に呼び出す Lambda 関数を識別します。その後、特定の Lambda 関数がイベント情報をパラメータとして受信し、Lambda 関数コードはイベントを処理します。

AWS リソースイベントを含むカスタムアプリケーションを作成し、Lambda 関数を呼び出すこともできます。詳細については、「AWS Command Line Interface での AWS Lambda の使用」を参照してください。

イベントマッピング情報をどこに維持するか迷うことがあるかもしれません。 AWS Lambda 内のイベントソース内に維持すればいいのでしょうか? 次のセクションでは、これらイベントソースのカテゴリごとにイベントソースマッピングについて説明します。このセクションでは、Lambda 関数の呼び出し方法および Lambda 関数の呼び出しを許可するアクセス権限の管理についても説明します。

AWS サービス向けのイベントソースマッピング

ポーリングベースの AWS サービス (Amazon Kinesis Data Streams および DynamoDB ストリーム、または Amazon SQS キュー) を除いて、サポート対象の AWS サービスはイベントを発行し、また Lambda 関数を呼び出すことができます (プッシュモデルといいます)。プッシュモデルは、以下に注意してください。

  • イベントソースマッピングは、イベントソース内に保持されます。イベントソース内の関連 API サポートを使用して、イベントソースマッピングを作成および管理できます。たとえば、Amazon S3 はバケット通知設定 API を提供します。この API を使用して、発行するバケットイベントと呼び出す Lambda 関数を識別するイベントソースマッピングを設定できます。

  • Lambda 関数はイベントソースで呼び出されるため、リソースベースのポリシーを使用してイベントソースに必要なアクセス許可を付与する必要があります。詳細については、「AWS Lambda のリソースベースのポリシーを使用する」を参照してください。

以下の例では、このモデルの仕組みを示しています。

例 – Amazon S3 がイベントをプッシュし、Lambda 関数を呼び出す

オブジェクト作成バケットイベントごとに、AWS Lambda 関数を呼び出すとします。バケットの通知設定に必要なイベントソースマッピングを追加します。

図はフローを示しています。

  1. ユーザーはバケット内にオブジェクトを作成します。

  2. Amazon S3 がオブジェクト作成イベントを検出します。

  3. Amazon S3 がバケット通知設定に記述されたイベントソースマッピングに従って Lambda 関数を呼び出します。

  4. AWS Lambda は Lambda 関数に添付されたアクセス権限ポリシーを検証して、その Amazon S3 に必要なアクセス権限があることを確認します。アクセス権限ポリシーの詳細については、「AWS Lambda アクセス許可」を参照してください。

  5. AWS Lambda によって添付されたアクセス権限ポリシーが確認されると、Lambda 関数が実行されます。Lambda 関数はパラメーターとしてイベントを受け取ることに留意してください。

AWS ポーリングベースのサービス向けのイベントソースマッピング

AWS Lambda は、次のポーリングベースのサービスをサポートしています。

Lambda がイベントを読み取るサービス

イベントソースマッピングを設定したら、AWS Lambda によってイベントソースがポーリングされ、Lambda 関数が呼び出されます。イベントソースマッピングは AWS Lambda 内で管理されます。AWS Lambda にはイベントソースマッピングを作成、管理するための API が用意されています。詳細については、「CreateEventSourceMapping」を参照してください。

AWS Lambda には、Kinesis および DynamoDB ストリーム、または Amazon SQS キューをポーリングして、レコードを読み取るアクセス権限が必要となります。これらのアクセス許可は、Lambda 関数の作成時に指定したロールに関連付けられたアクセス許可ポリシーを使用して、実行ロールを経由して付与します。AWS Lambda には Lambda 関数を呼び出すためのアクセス許可は不要です。

次の図では、Kinesis ストリームにレコードを書き込むカスタムアプリケーションおよび AWS Lambda がストリームをポーリングする方法を示しています。AWS Lambda がストリームで新規レコードを検出すると、Lambda 関数を呼び出します。

Kinesis ストリームにレコードを書き込むカスタムアプリケーションがあるとします。ストリームで新しいレコードが検出されると、Lambda 関数が呼び出されるようにします。Lambda 関数と必要なイベントソースマッピングを AWS Lambda に作成します。

図は、以下のシーケンスを示します。

  1. カスタムアプリケーションは Amazon Kinesis ストリームにレコードを作成します。

  2. AWS Lambda はストリームのポーリングを継続し、サービスによってストリームに新しいレコードが検出されると Lambda 関数を呼び出します。AWS Lambda は、どのストリームをポーリングし、どの Lambda 関数を呼び出すかを、AWS Lambda でユーザーが作成したイベントソースマッピングに基づいて判断します。

  3. AWS Lambda によって Lambda 関数が実行されます。

この例では Kinesis ストリームを使用しますが、DynamoDB ストリームを使用するときも同様です。

カスタムアプリケーションのイベントソースマッピング

イベントを発行して処理するカスタムアプリケーションがある場合は、これらのイベントを処理する Lambda 関数を作成できます。この場合、事前設定は必要ありません。つまり、イベントソースマッピングをセットアップする必要はありません。代わりに、イベントソースは AWS Lambda の Invoke API を使用します。アプリケーションおよび Lambda 関数が異なる AWS アカウントによって所有されている場合、Lambda 関数を所有する AWS アカウントは Lambda 関数に関連付けられるアクセス権限ポリシーでクロスアカウント権限を許可する必要があります。

次の図は、アカウントでカスタムアプリケーションが Lambda 関数を呼び出す方法を示しています。この例では、カスタムアプリケーションは Lambda 関数を所有するアカウントと同じアカウント認証情報を使用しているため、関数を呼び出すためにアクセス権限を追加する必要はありません。

次の例では、ユーザーアプリケーションおよび Lambda 関数は、さまざまな AWS アカウントによって所有されています。この場合、Lambda 関数を所有する AWS アカウントは、Lambda 関数に関連付けられたアクセス権限ポリシーに、クロスアカウントアクセス権限がある必要があります。詳細については、「AWS Lambda アクセス許可」を参照してください。