# Lambda の仕組み
Lambda 関数は、Lambda アプリケーションの構築に使用する基本的な構成要素です。関数を記述するには、Lambda プログラミングモデルを構成する主要な概念とコンポーネントを理解することが不可欠です。このセクションでは、Lambda を使用してサーバーレスアプリケーションの構築を開始するために必要な基本的な要素について説明します。
+ **[Lambda 関数と関数ハンドラー](#gettingstarted-concepts-function)** – Lambda 関数は、イベントに応答して実行されるコードの小さなブロックです。関数は標準 (最大 15 分) または[耐久性](durable-functions.md) (最大 1 年) の場合があります。関数は、アプリケーションの構築に使用する基本的な構成要素です。関数ハンドラーは、Lambda 関数コードが処理するイベントオブジェクトのエントリポイントです。
+ **[Lambda 実行環境とランタイム](#gettingstarted-concepts-runtime)** - Lambda 実行環境は、関数の実行に必要なリソースを管理します。[耐久性のある関数](durable-functions.md)の場合、実行環境には自動状態管理およびチェックポイント機能が含まれます。ランタイムは、関数が実行される言語固有の環境です。
+ **[イベントとトリガー](#gettingstarted-concepts-event)** – 特定のイベントに対応して他の AWS のサービス が関数を呼び出すことができます。耐久性のある関数の場合、イベントは一時停止したワークフローの再開をトリガーすることもできます。
+ **[Lambda のアクセス許可とロール](#gettingstarted-concepts-permissions)** - 関数にアクセスできるユーザーと、関数が操作できる他の AWS のサービス を制御します。耐久性のある関数には、状態管理と拡張実行のための追加のアクセス許可が必要です。
**ヒント**
サーバーレス開発をより一般的に理解することから開始する場合、「*AWS サーバーレスデベロッパーガイド*」の「[従来の開発とサーバーレス開発の違いの概要](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html)」を参照してください。
## Lambda 関数と関数ハンドラー
Lambda では、**関数**はアプリケーションの作成に使用する基本的な構成要素です。Lambda 関数は、ユーザーがウェブサイトのボタンをクリックしたり、Amazon Simple Storage Service (Amazon S3) バケットにファイルがアップロードされたりなど、イベントに応答して実行されるコードです。耐久性のある関数を使用すると、コードはステップ間で実行を一時停止できて、状態が自動的に維持されるため、注文処理やコンテンツモデレーションなどの長時間のワークフローに最適です。関数は、次のプロパティを持つ自己完結型プログラムの一種として考えることができます。
Lambda **関数ハンドラー**は、イベントを処理する関数コード内のメソッドです。イベントに応答して関数が実行されると、Lambda は関数ハンドラーを実行します。関数の実行の原因となったイベントに関するデータは、ハンドラーに直接渡されます。Lambda 関数のコードには複数のメソッドまたは関数を含めることができますが、Lambda 関数には 1 つのハンドラーしか含めることができません。
Lambda 関数を作成するには、関数コードおよびその依存関係をデプロイパッケージにバンドルします。Lambda は、[.zip ファイルアーカイブ](configuration-function-zip.md)と[コンテナイメージ](images-create.md)の 2 種類のデプロイパッケージをサポートします。
+ 関数には特定のジョブまたは目的が 1 つある
+ 特定のイベントに応答して必要な場合にのみ実行される
+ 完了すると自動的に実行が停止される
## Lambda 実行環境とランタイム
Lambda 関数は、安全で隔離された*[実行環境](lambda-runtime-environment.md)*内で実行されます。Lambda により、ユーザーに代わってこれが管理されます。[耐久性のある関数](durable-functions.md)の場合、実行環境には状態管理およびワークフロー調整用に追加コンポーネントが含まれています。この実行環境では、関数の実行に必要なプロセスおよびリソースが管理されます。関数が最初に呼び出されると、Lambda は関数を実行するために新しい実行環境を作成します。関数の実行が完了すると、Lambda は実行環境をすぐに停止しません。関数が再度呼び出された場合、Lambda は既存の実行環境を再利用できます。
Lambda 実行環境には、*ランタイム*も含まれています。このランタイムは、Lambda と関数の間でイベント情報やレスポンスを中継する言語固有の環境です。Lambda は、最も人気のあるプログラミング言語向けに多数の[マネージドランタイム](lambda-runtimes.md#runtimes-supported)を提供します。または、ユーザー独自のランタイムを作成することもできます。
マネージドランタイムの場合、Lambda はランタイムを使用する関数にセキュリティ更新プログラムおよびパッチを自動的に適用します。
## イベントとトリガー
Lambda コンソール、[AWS CLI](https://aws.amazon.com/cli/)、[AWS Software Development Kit (SDK)](https://aws.amazon.com/developer/tools/) のいずれかを使用し、Lambda 関数を直接呼び出すこともできます。本番稼働用アプリケーションでは、特定のイベントに応じて、関数が別の AWS のサービス によって呼び出されるのが一般的です。例えば、項目が Amazon DynamoDB テーブルに追加されるたびに関数を実行する必要があるとします。
関数がイベントに応答するようにするには、**トリガー**を設定します。トリガーは関数をイベントソースに接続します。関数には複数のトリガーを設定できます。イベントが発生すると、Lambda は JSON ドキュメント形式のイベントデータを受信し、コードが処理できるオブジェクトに変換します。イベントに次の JSON 形式を定義すると、Lambda ランタイムはこの JSON ドキュメントをオブジェクトに変換してから関数のハンドラに渡します。
**Example カスタム Lambda イベント**
```
{
"Location": "SEA",
"WeatherData":{
"TemperaturesF":{
"MinTempF": 22,
"MaxTempF": 78
},
"PressuresHPa":{
"MinPressureHPa": 1015,
"MaxPressureHPa": 1027
}
}
}
```
Amazon Kinesis や Amazon SQS といったストリーミングサービスとキューサービスでは、標準トリガーの代わりに[イベントソースマッピング](invocation-eventsourcemapping.md)を使用します。イベントソースマッピングは、ソースをポーリングして新しいデータを検索し、レコードをまとめてバッチ処理し、バッチイベントで関数を呼び出します。詳細については、「[イベントソースマッピングと直接トリガーの違い](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference)」を参照してください。
トリガーの仕組みを理解するには、[Amazon S3 トリガーの使用](with-s3-example.md)に関するチュートリアルから始めるか、トリガーの使用に関する一般的な概要と Lambda コンソールを使用したトリガーの作成手順を「[他のサービスの統合](lambda-services.md)」で確認してください。
## Lambda のアクセス許可とロール
Lambda の場合、設定する必要がある[アクセス許可](permissions-granting-access.md)には 2 つの主なタイプがあります。
+ 関数が他の AWS のサービスにアクセスするために必要なアクセス許可
+ 他のユーザーや AWS のサービスが関数にアクセスするために必要なアクセス許可
次のセクションでは、これらのアクセス許可タイプの両方について説明し、最小特権のアクセス許可を適用するためのベストプラクティスについて説明します。
### 関数がその他の AWS リソースにアクセスするためのアクセス許可
多くの場合、Lambda 関数はその他の AWS リソースにアクセスし、アクションを実行する必要があります。例えば、関数は DynamoDB テーブルから項目を読み取ったり、オブジェクトを S3 バケットに保存したり、Amazon SQS キューに書き込んだりすることがあります。これらのアクションを実行するために関数に必要なアクセス許可を付与するには、*[実行ロール](lambda-intro-execution-role.md)*を使用します。
Lambda 実行ロールは特別な種類の AWS Identity and Access Management (IAM) [ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)のであり、*ポリシー*で定義された特定のアクセス許可が関連付けられているアカウントで作成する ID です。
すべての Lambda 関数には実行ロールが必要であり、1 つのロールが複数の関数によって使用できます。関数が呼び出されると、Lambda は関数の実行ロールを引き受け、ロールのポリシーで定義されたアクションを実行するアクセス許可が付与されます。
Lambda コンソールで関数を作成するとき、Lambda は関数に対して自動的に実行ロールを作成します。ロールのポリシーは、Amazon CloudWatch Logs にログ出力を書き込むために、関数に基本的なアクセス許可を付与します。その他の AWS リソースにアクションを実行するためのアクセス許可を関数に付与するには、ロールを編集して追加のアクセス許可を追加する必要があります。アクセス許可を追加する最も簡単な方法は、AWS [マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)を使用することです。マネージドポリシーは AWS によって作成および管理され、多くの一般的なユースケースにアクセス許可を付与します。例えば、関数が DynamoDB テーブルに CRUD オペレーションを実行する場合、[AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) ポリシーをロールに追加できます。
### 他のユーザーとリソースが関数にアクセスするためのアクセス許可
Lambda 関数にアクセスするために他の AWS のサービスアクセス許可を付与するには、*[リソースベースのポリシー](access-control-resource-based.md)*を使用します。IAM では、リソースベースのポリシーがリソース (この場合は Lambda 関数) にアタッチされ、リソースにアクセスできるユーザーおよび許可されるアクションを定義します。
別の AWS のサービスがトリガーを介して関数を呼び出すには、関数のリソースベースのポリシーが、そのサービスに `lambda:InvokeFunction` アクションを使用するためのアクセス許可を付与する必要があります。コンソールを使用してトリガーを作成した場合、Lambda はユーザーに代わってこのアクセス許可を自動的に追加します。
他の AWS ユーザーに関数へのアクセス許可を付与するには、別の AWS のサービスまたはリソースの場合とまったく同じ方法で、関数のリソースベースのポリシーでこれを定義できます。ユーザーに関連付けられている *[ID ベースのポリシー](access-control-identity-based.md)*を使用することもできます。
### Lambda のアクセス許可のベストプラクティス
IAM ポリシーを使用してアクセス許可を設定する際、タスクの実行に必要なアクセス許可のみを付与することが[セキュリティ上のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)です。これは*最小特権*の原則と呼ばれます。関数にアクセス許可の付与を開始するには、AWS マネージドポリシーの使用を選択できます。マネージドポリシーは、タスクを実行するためにアクセス許可を付与するうえで最も迅速で簡単な方法ですが、不要なアクセス許可が他にも含まれる場合もあります。初期の開発からテストおよび本番稼働に移行する際は、独自の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義することで、必要なアクセス許可のみに減らすことをお勧めします。
リソースベースのポリシーを使用し、関数にアクセスするためのアクセス許可を付与するときにも、同じ原則が適用されます。例えば、関数を呼び出すアクセス許可を Amazon S3 に付与する場合、S3 サービスに一括のアクセス許可を付与するのではなく、個々のバケットまたは特定の AWS アカウントのバケットへのアクセスを制限することが、ベストプラクティスです。