AWS Lambda よくある質問

AWS Lambda で実行するコードは「Lambda 関数」としてアップロードされます。それぞれの関数は名前、説明、エントリポイント、リソース要件などの設定情報と関連付けられています。基盤となるコンピューティングインフラストラクチャに依存しないように、コードは必ず「ステートレス」なスタイルで書く必要があります。ローカルファイルシステムのアクセス、子プロセス、その他類似のアーティファクトはリクエストの有効期限を越えて延長されず、永続的な状態はすべて Amazon S3、Amazon DynamoDB、Amazon EFS、その他のインターネットが利用可能なストレージサービスに保存されます。ネイティブライブラリも含めて、Lambda 関数にはライブラリを利用できます。

パフォーマンス向上のため、AWS Lambda は新しく関数のインスタンスを作成するのではなく、関数のインスタンスを保持してその後のリクエストに対応することがあります。Lambda で関数インスタンスを再利用する方法の詳細については、「ドキュメント」を参照してください。ただし、常にインスタンスを再利用するわけではありません。

各 Lambda 関数には、512 MB から 10,240 MB の間で、1 MB 単位で独自のエフェメラルストレージを設定することができます。エフェメラルストレージは、各関数の /tmp ディレクトリで利用可能です。

各関数は、追加費用なしで 512 MB のストレージにアクセスできます。512 MB を超えるエフェメラルストレージで関数を設定した場合、設定したストレージの容量と関数の実行時間に基づいて、1 ミリ秒単位で課金されます。比較のために、米国東部 (オハイオ) リージョンにおける AWS Fargate のエフェメラルストレージ料金は、0.000111 USD/GB-月、または 0.08 USD/GB-月となっています。Amazon EBS gp3 ストレージのボリューム料金は、米国東部 (オハイオ) では 0.08 USD/GB-月です。AWS Lambda エフェメラルストレージの料金は、0.0000000309 USD/GB-秒、または 0.000111 USD/GB-月、0.08 USD/GB-月です。詳細については、「AWS Lambda の料金」をご覧ください。

AWS Lambda コンソール、AWS Lambda API、または AWS CloudFormation テンプレートを使用して、関数の作成または更新時に、各 Lambda 関数に 512 MB から 10,240 MB の間で、1 MB 単位で独自のエフェメラルストレージを設定することができます。

はい。エフェメラルストレージに保存されるデータはすべて、AWS が管理するキーで保管時に暗号化されます。

AWS CloudWatch Lambda Insight のメトリクスを使用して、エフェメラルストレージの使用状況をモニタリングすることができます。詳細については、AWS CloudWatch Lambda Insights のドキュメントをご覧ください。

アプリケーションが耐久性のある永続的ストレージを必要とする場合、Simple Storage Service (Amazon S3) または Amazon EFS の使用を検討してください。アプリケーションが単一の関数呼び出しでコードによって必要とされるデータを格納する必要がある場合、一時的なキャッシュとして AWS Lambda エフェメラルストレージの使用を検討してください。詳細については、ウェブアプリケーションにおける AWS Lambda データストレージオプションの選択を参照してください。

はい。ただし、アプリケーションが永続的ストレージを必要とする場合、Amazon EFS または Simple Storage Service (Amazon S3) の使用を検討してください。関数に対して Provisioned Concurrency を有効にすると、関数の初期化コードは割り当て時および数時間ごとに実行され、実行中の関数のインスタンスがリサイクルされます。インスタンスがリクエストを処理した後、ログとトレースで初期化時間を確認できます。ただし、インスタンスがリクエストを処理しない場合でも、初期化は課金されます。この Provisioned Concurrency の初期化動作は、関数がリクエストを処理していないときでも、エフェメラルストレージに保存したデータと関数のやり取りに影響を与える可能性があります。Provisioned Concurrency の詳細については、関連ドキュメントを参照してください。

AWS Lambda コンソール、AWS Lambda API、または AWS CloudFormation テンプレートを使用して、関数の作成または更新時に、各 Lambda 関数に 512 MB から 10,240 MB の間で、1 MB 単位で独自のエフェメラルストレージを設定することができます。

はい。エフェメラルストレージに保存されるデータはすべて、AWS が管理するキーで保管時に暗号化されます。

AWS CloudWatch Lambda Insight のメトリクスを使用して、エフェメラルストレージの使用状況をモニタリングすることができます。詳細については、AWS CloudWatch Lambda Insights のドキュメントをご覧ください。

関数をステートレスにすることにより、AWS Lambda はイベントの受信回数に合わせスケールするのに必要な数の関数のコピーを迅速に実行できます。AWS Lambda のプログラムモデルはステートレスですが、コードは Amazon S3 または Amazon DynamoDB など他のウェブサービスを呼び出すことでステートフルなデータにアクセスできます。

はい。AWS Lambda では追加スレッドおよびプロセスの作成など、通常の言語およびオペレーティングシステムの機能が使用できます。メモリ、実行時間、ディスク、ネットワーク利用など、Lambda 関数に割り当てられたリソースは、必ず使用するすべてのスレッドまたはプロセスで共有されます。プロセスは、Amazon Linux によってサポートされている任意の言語を使用して起動できます。

Lambda では、通常の言語およびオペレーティングシステムの処理にできるだけ制限を課さないようにしています。ただし、AWS Lambda によりインバウンドネットワーク接続がブロックされること、アウトバウンド接続では TCP/IP および UDP/IP ソケットのみに対応していること、ptrace (デバッグ) システム呼び出しがブロックされることなど、無効化される処理がいくつかあります。TCP ポート 25 のトラフィックも、スパム対策のため、ブロックされます。

Node.js または Python を使用している場合は、関数の作成およびテストが可能な AWS Lambda コンソールのコードエディタを使用して関数のコードを作成し、堅牢で IDE に似た環境で関数実行結果を表示できます。コンソールの使用を開始。

お使いのローカル環境から AWS Lambda コンソールを使用して、ZIP 形式でコード (および任意の依存ライブラリ) をパッケージングしてアップロードするか、ZIP ファイルのある Amazon S3 のロケーションを指定できます。アップロードするデータは 50 MB (圧縮後) より小さくしてください。AWS Eclipse プラグインを使用すると、Java で Lambda 関数を作成およびデプロイできます。Visual Studio プラグインを使用すると、C# および Node.js で Lambda 関数を作成およびデプロイできます。

お使いのローカル環境から AWS CLI を使用して、ZIP 形式でコード (および任意の依存ライブラリ) をパッケージングしてアップロードするか、ZIP ファイルのある Amazon S3 のロケーションを指定できます。アップロードするデータは 50 MB (圧縮後) より小さくしてください。「Lambda 開始方法ガイド」で使用を開始する。

はい。AWS Lambda Console、CLI、または SDK から簡単に環境変数を作成および変更できます。環境変数の詳細については、「ドキュメント」を参照してください。

データベースのパスワードなどの機密情報については、AWS Key Management Service を使用してクライアント側で暗号化し、この暗号化した値を環境変数に暗号文として格納することをお勧めします。これらの値の復号化では、AWS Lambda 関数コードにロジックを含める必要があります

Lambda API またはコンソールを使用して、Lambda 関数に関連付けられたリソースを調整および保護できます。詳細については、ドキュメントをご覧ください。

はい。コード (フレームワーク、SDK、ライブラリ、その他) は Lambda Layer としてパッケージ化し、これを管理して複数の関数で共有できます。

AWS Lambda はお客様に代わって Lambda 関数を自動でモニタリングし、Amazon CloudWatch を使用して合計リクエスト数、アカウントレベルおよび関数レベルの同時実行使用率、レイテンシー、エラー率、リクエストのスロットリングなどのリアルタイムメトリクスを報告します。お客様は、Amazon CloudWatch コンソールまたは AWS Lambda コンソールを介して自作の各 Lambda 関数の統計情報を確認できます。Lambda 関数内でサードパーティのモニタリング API を呼び出すこともできます。
 

詳しくは「 CloudWatch メトリクスのトラブルシューティング」をご覧ください。Lambda の組み込みメトリックを使用する場合は、AWS Lambda の標準料金が課されます。

AWS Lambda は自動的に Amazon CloudWatch Logs と統合されます。これにより、各 Lambda 関数ごとにロググループが作成され、基本的なアプリケーションライフサイクルイベントのログエントリ (Lambda 関数の使用ごとに消費されるリソースのログなど) が生成されます。お客様は、自分のコードに、追加のログ出力文を簡単に挿入できます。Lambda 関数内でサードパーティのロギング API を呼び出すこともできます。詳しくは 「Lambda 関数のトラブルシューティング」をご覧ください。Amazon CloudWatch ログの料金が適用されます。

Lambda 関数をスケールする必要はありません。AWS Lambda がお客様に代わってスケールします。関数に対してイベントが通知されるたびに、AWS Lambda は迅速にコンピューティングシステム全体から空いている容量を見つけてコードを実行します。コードがステートレスなため、AWS Lambda は時間のかかるデプロイや設定によって遅れを出すことなく必要な数だけインスタンスを実行できます。関数のスケーリングに基本的な上限はありません。AWS Lambda はイベントの受信回数に合わせて容量を動的に割り当てます。

AWS Lambda のリソースモデルでは、お客様が関数に必要なメモリ量を指定すると、それに比例した CPU パワーとその他のリソースが割り当てられます。例えば、256 MB のメモリを指定した場合に Lambda 関数に割り当てられる CPU パワーは、128 MB のメモリを指定した場合の約 2 倍となり、512 MB のメモリを指定した場合の約半分となります。詳細については、関数の設定に関するドキュメントをご覧ください。

メモリは 128 MB から 10,240 MB まで設定できます。

メモリまたはコンピューティング負荷の高いワークロードを実行しているお客様は、より多くのメモリを使用して関数を実行できるようになりました。より大きなメモリの関数は、マルチスレッドアプリケーションの実行速度を向上させ、機械学習、バッチおよび ETL ジョブ、財務モデリング、ゲノミクス、HPC、メディア処理などのデータを大量に消費し、コンピューティング負荷の高いアプリケーションに最適です。

AWS Lambda 関数は、1 回あたりの実行時間を最長 15 分に設定することができます。タイムアウトは 1 秒から 15 分までの間で任意に設定できます。

AWS Lambda は使用した分のみ料金が発生します。詳細については、「AWS Lambda の料金」ページをご覧ください。

はい。Compute Savings Plans では、Amazon EC2 と AWS Fargate での割引に加え、AWS Lambda の利用料も節約できるようになりました。Compute Savings Plans により、Duration、Provisioned Concurrency、および Duration (Provisioned Concurrency) おいて、最大 17% の割引がご利用いただけます。Compute Savings Plans の割引は、Lambda の請求にある Requests の分は対象としていません。ただし、Compute Savings Plans へのコミットメントは、標準料金の Requests に適用されます。

はい。デフォルトでは、各 AWS Lambda 関数には、最新バージョンのコードが 1 つ存在します。Lambda 関数のクライアントでは、特定のバージョンを呼び出したり、最新の実装を取得したりできます。Lambda 関数のバージョニングに関するドキュメントをお読みください。

コードのサイズに応じてデプロイ時間は異なりますが、通常 AWS Lambda はアップロードから数秒で呼び出せるようになります。

はい。自分用にコピーしたライブラリ (AWS SDK を含む) をインクルードすることで、AWS Lambda によって提供されているデフォルトのライブラリとは異なるバージョンを使用できます。

AWS Lambda は、毎月のオンデマンド機能の継続時間が一定のしきい値を超えると、割引価格帯を提供します。x86 と Arm の両アーキテクチャで動作する機能については、段階的な価格設定が可能です。Lambda の価格設定は、アカウント内で同じアーキテクチャ (それぞれ x86 または Arm)、同じリージョンで実行されるお客様の機能のオンデマンド期間の月額の総計に適用されます。AWS Organizations で統合課金を使用している場合、価格階層は、組織内のアカウント間で、同じアーキテクチャ、同じリージョンで実行されている機能の月間総所有時間に適用されます。例えば、米国東部 (オハイオ) リージョンで x86 Lambda 関数を実行する場合、同リージョンでは、月間 60 億 GB 秒までは 1GB 秒ごとに0.0000166667 USD、次の月間 90 億 GB 秒までは 1GB 秒ごとに0.0000150000 USD、月間 150 億 GB 秒以上は 1GB 秒ごとに0.0000133334 USD が支払われることになります。Requests、Provisioned Concurrency、Provisioned Concurrency Duration の料金は変わりません。詳細については、「AWS Lambda 料金」を参照してください。

はい。時間単位の Savings Plan コミットメントでカバーされる Lambda の使用量は、該当する CSP レートと割引で請求されます。この契約でカバーされていない残りの使用量は、月間の関数の合計実行時間を基に、該当する階層に対応したレートで請求されます。

イベントソースは AWS のサービスまたはデベロッパーが構築したアプリケーションで、AWS Lambda 関数の実行をトリガーするイベントの発生元です。サービスによっては、直接クラウド機能 (Amazon S3 など) を起動することで Lambda にイベントを送信します。Lambda はイベントを送信していない他のサービスのリソースをポーリングすることもできます。たとえば、Lambda は Amazon Kinesis ストリームまたは Amazon SQS キューからレコードを取得し、取得したメッセージごとに Lambda 関数を実行できます。AWS CloudTrail などの他の多くのサービスは、Amazon S3 にログインし、S3 バケット通知を使用して AWS Lambda 関数をトリガーするだけで、イベントソースとして機能できます。

イベントソースの一覧については、「ドキュメント」をご覧ください。

イベントはインプットパラメータとして Lambda 関数に送信されます。Amazon SQS、Amazon Kinesis および Amazon DynamoDB Streams などイベントがバッチで送られるイベントソースでは、お客様がリクエストするバッチサイズに応じて、1 回の呼び出しで複数のイベントがイベントパラメータに含まれます。Amazon S3 イベント通知の詳細については、「Configuring Notifications for Amazon S3 Events」をご覧ください。Amazon DynamoDB Streams の詳細については、「DynamoDB Stream デベロッパーガイド」をご覧ください。Amazon SNS を使用して Lambda 関数を呼び出す方法の詳細については、「Amazon SNS デベロッパーガイド」をご覧ください。Amazon Cognito イベントの詳細については、「Amazon Cognito」をご覧ください。AWS の各種サービスにおける AWS CloudTrail のログおよび監査 API コールの詳細については、「AWS CloudTrail」を参照してください。

AWS Lambda コンソールから関数を選択し、Amazon S3 バケットからの通知に関連付けます。または、Amazon S3 コンソールを使用してバケットの通知を AWS Lambda 関数に送信するように設定します。AWS SDK および CLI からも同じ機能が使用できます。

DynamoDB テーブルの更新に対して Lambda 関数をトリガーするには、Lambda 関数を、当該テーブルに関連付けられた DynamoDB Stream でサブスクライブします。DynamoDB Stream を Lambda 関数に関連付けるには、Amazon DynamoDB コンソール、AWS Lambda コンソールまたは Lambda の registerEventSource API を使用します。

AWS Lambda コンソールで Lambda 関数を選択して、同じアカウントによって所有されている Amazon Kinesis ストリームに関連付けます。AWS SDK および CLI からも同じ機能が使用できます。

AWS Lambda 関数に送られる Amazon Kinesis ストリームおよび DynamoDB ストリームのレコードは、シャードごとに厳密にシリアル化されます。つまり、Lambda で同じシャードに 2 つのレコードが置かれた場合、最初のレコードに対する Lambda 関数の呼び出しは、2 つ目のレコードに対する呼び出しより前に実行されることが保証されます。あるレコードに対する呼び出しがタイムアウトになったり制限されたりした場合、またはその他のエラーが発生した場合、Lambda は成功するまで (またはレコードが 24 時間の有効期限切れになるまで) 次のレコードに移動しません。シャードの異なるレコード間の順序は保証されず、各シャードの処理は並行して行われます。

AWS Lambda では、シャードなどの単一の論理パーティション上の Amazon Kinesis または Amazon DynamoDB Streams のデータに対して、最大 15 分の短い時間枠で時間ベースの集計 (カウント、最大、合計、平均など) を実行できます。これにより、ビジネスと分析ロジックを同じ関数に配置できるため、アーキテクチャを複雑化することなく、イベントベースのアプリケーション用にシンプルな分析を簡単に設定できます。Lambda では、イベントのタイムスタンプに基づいて、最大 15 分のタンブリングウィンドウで集計できます。Amazon Kinesis Data Analytics では、柔軟な処理の選択と、重複のない 1 回限りの処理による堅牢なフォールトトレランス、および複数の論理パーティションにまたがるデータストリーム全体に対して実行できる分析をサポートするより複雑な分析アプリケーションを構築できます。KDA では、イベント時間または処理時間のいずれかを使用して、複数のタイプの集計ウィンドウ (タンブリングウィンドウ、スタガーウィンドウ、スライディングウィンドウ、セッションウィンドウ) のデータを分析できます。
 

	AWS Lambda	Amazon KDA
タンブリングウィンドウ	有	有
スタガーウィンドウ	無	有
スライディングウィンドウ	無	有
セッションウィンドウ	無	有
エンリッチメント	無	有
共同入力テーブルと参照テーブル	無	有
入力ストリームの分割	無	有
正確に 1 回の処理	無	有
最大時間枠	15 分	制限なし
集計範囲	パーティション/シャード	ストリーム
時間セマンティクス	イベント時間	イベント時間、処理時間

AWS Lambda コンソールで Lambda 関数を選択し、Amazon SNS トピックに関連付けます。AWS SDK および CLI からも同じ機能が使用できます。

Amazon SES コンソールで、Amazon SES が AWS Lambda 関数にお客様のメッセージを配信するように、受信ルールを設定できます。AWS SDK および CLI でも同じ機能を利用できます。

まず、Amazon SNS 通知を送信するようにアラームを設定します。次に、AWS Lambda コンソールで Lambda 関数を選択し、Amazon SNS トピックに関連付けます。Amazon CloudWatch アラームの設定の詳細については「Amazon CloudWatch デベロッパーガイド」をご覧ください。

AWS Lambda コンソールで、Amazon Cognito アイデンティティプールに関連付けられたデータセットが同期されたときにトリガーされる関数を選択します。AWS SDK および CLI からも同じ機能が使用できます。Amazon Cognito を使用してユーザーのデバイスとデータの共有および同期化を実行する方法の詳細については、「Amazon Cognito」をご覧ください。

AWS Lambda の invoke API でカスタムイベントを使用して、Lambda 関数を呼び出すことができます。関数の所有者または所有者が許可を与えた他の AWS アカウントのみ関数を呼び出すことができます。詳しくは、「Lambda デベロッパーガイド」をご覧ください。

AWS Lambda は、数ミリ秒以内にイベントを処理するように設計されています。Lambda 関数の作成後、更新後、または関数が最近使用されていない場合はレイテンシーが高くなります。

AWS Lambda で実行するコードをアップロードして、そのコードを AWS Mobile SDK に含まれている AWS Lambda SDK を使用して、モバイルアプリケーションから呼び出します。直接 (同期) 呼び出しによってリアルタイムでデータの取得またはチェックを行うか、非同期呼び出しを使用できます。また、Amazon API Gateway を使用してカスタム API を定義し、任意の REST で互換性のあるクライアントを使用して Lambda 関数を呼び出すこともできます。AWS Mobile SDK の詳細は、「AWS Mobile SDK」ページを参照してください。Amazon API Gateway の詳細は、「Amazon API Gateway」ページを参照してください。

HTTPS を通して Lambda 関数を呼び出すには、Amazon API Gateway を使用してカスタムの RESTful API を定義します。これにより関数のためのエンドポイントが設定され、GET、PUT、POST などの REST の呼び出しに応答できます。Amazon API Gateway と AWS Lambda を合わせて使用する方法の詳細をご覧ください。

AWS Mobile SDK 経由で呼び出された AWS Lambda 関数は、呼び出し側のデバイスおよびアプリケーションに関する情報を「context」オブジェクトを介して自動的に取得します。

アプリケーションが Amazon Cognito ID を使用している場合、エンドユーザーは、各種の共通ログインプロバイダー (Amazon、Facebook、Google、およびその他の OpenID Connect 互換サービスなど) を使用して認証を受けることができます。ユーザー ID は、Amazon Cognito ID 形式で自動的かつ安全に Lambda 関数に渡されます。その場合、Lambda 関数は、その ID を使用して Amazon Cognito からユーザーデータにアクセスできます。ユーザー ID は、Amazon DynamoDB またはその他のウェブサービスに対してデータの保存または取得を行うためのキーとして Lambda 関数に渡される場合もあります。

AWS Lambda は、Alexa Skills Kit (Alexa の音声駆動型機能 ("スキル") の作成を容易にするためのセルフサービス API、ツール、ドキュメント、コードサンプルのコレクション) に組み込まれています。作成する新しい Alexa スキルの Lambda 関数コードをアップロードすれば、残りの作業 (Alexa の音声対話に応えてコードを実行し、お客様に代わって自動的にコンピューティングリソースを管理する) は AWS Lambda で実行されます。詳細については、Alexa Skills Kit のドキュメントをご覧ください。

Amazon S3 バケット通知とカスタムイベントに関しては、コードにエラーがある場合や、サービスまたはリソースの上限を超えた場合、AWS Lambda は関数の実行を 3 回試行します。Amazon DynamoDB ストリームおよび Amazon Kinesis Streams などお客様に代わって AWS Lambda がポーリングする指定イベントソースに関しては、デベロッパーのコードにエラーがある場合、Lambda はデータの有効期限が切れるまで実行を試行します。Amazon Kinesis および Amazon DynamoDB コンソール、AWS Lambda が関数に向けて生成した Amazon CloudWatch メトリクスを使用して進行状況をモニタリングできます。エラーまたは実行スロットリング率に基づいて、Amazon CloudWatch アラームを設定することもできます。

Lambda ベースのアプリケーション (サーバーレスアプリケーションとも言います) はイベントによってトリガーされる関数で構成されています。一般的なサーバーレスアプリケーションは、Amazon S3 へのオブジェクトアップロード、Amazon SNS 通知、API アクションなどのイベントによってトリガーされる 1 つまたは複数の関数からなります。これらの関数はスタンドアローンでもよく、DynamoDB テーブルや Amazon S3 バケットなどの他のリソースを利用することも可能です。最も基本的なサーバーレスアプリケーションは単なる関数です。

サーバーレスアプリケーションは AWS Serverless Application Model (AWS SAM) を使用してデプロイし、管理できます。AWS SAM は、AWS でサーバーレスアプリケーションを表現するためのルールを規定する仕様です。この仕様は、今日 AWS CloudFormation によって使用されている構文と合致し、一連のリソースタイプ (「サーバーレスリソース」と呼ばれます) として AWS CloudFormation 内でネイティブにサポートされています。これらのリソースによって、AWS のお客様は CloudFormation を使用し、既存の CloudFormation API を使用して簡単にサーバーレスアプリケーションを構成し、デプロイできます。

AWS Serverless Application Repository を使用して、AWS コミュニティ内のデベロッパー、企業、パートナーが公開するサーバーレスアプリケーションのコレクションから選択できます。アプリケーションを見つけたら、Lambda コンソールから直接アプリケーションを設定してデプロイできます。

AWS CodePipeline と AWS CodeDeploy を使用して、サーバーレスアプリケーションのリリースプロセスを自動化できます。CodePipeline は、サーバーレスアプリケーションのリリースに必要なステップをモデル化、視覚化、自動化できる継続的デリバリーサービスです。CodeDeploy は、Lambda ベースのアプリケーション用のデプロイ自動化エンジンを提供します。CodeDeploy を使用すると、カナリアや線形デプロイなどの確立されたベストプラクティスの方法論に従ってデプロイメントを調整し、新しくデプロイされたコードが安全で安定しており、本番環境に完全にリリースされる準備ができていることを確認するのに必要なガードレールを構築できます。
 

サーバーレス CI/CD の詳細については、こちらの「ドキュメント」を参照してください。

まずは AWS Lambda コンソールにアクセスし、いずれかの設計図をダウンロードしてください。ダウンロードしたファイルには、AWS SAM ファイル (アプリケーションの AWS リソースを定義する)、および .ZIP ファイル (関数のコードを含む) が含まれます。次に AWS CloudFormation コマンドを使用して、ダウンロードしたサーバーレスアプリケーションをパッケージ化してデプロイできます。詳細については、「ドキュメント」を参照してください。

AWS Step Functions を使用すると、一連の AWS Lambda 関数を特定の順序で調整できます。複数の Lambda 関数を連続して呼び出して出力を代わる代わる渡したり、同時に渡したりできます。Step Functions では実行中は状態が維持されます。

X-Ray 権限を Lambda 関数の実行ロールに追加し、関数の "トレースモード" を「有効」に変更すると、AWS X-Ray による追跡用に Lambda 関数を有効化できます。 Lambda 関数で X-Ray が有効になると、AWS Lambda は、関数の呼び出し時に発生した Lambda サービスのオーバーヘッドについて、X-Ray にトレース情報を提供します。これにより、Lambda サービスのオーバーヘッド、関数の初期化時間、および関数の実行時間などの情報が提供されます。さらに、Lambda デプロイパッケージに X-Ray SDK を含めて、独自のトレースセグメントの作成、トレースへの注釈付け、または Lambda 関数から行われたダウンストリーム呼び出しのトレースセグメントの表示を行うことができます。X-Ray SDK は現在、Node.js および Java で利用可能です。詳しくは「 Lambda ベースのアプリケーションのトラブルシューティング」をご覧ください。AWS X-Ray の料金が適用されます。

はい。数千のリレーショナルデータベースへの同時接続を管理する高可用性データベースプロキシである Amazon RDS Proxyを使用して、リレーショナルデータベースに接続する、高度にスケーラブルで安全な Lambda ベースのサーバーレスアプリケーションを構築できます。現在、RDS プロキシは MySQL および Aurora データベースをサポートしています。Amazon RDS コンソールまたは AWS Lambda コンソールから RDS プロキシの使用を開始できます。RDS プロキシから完全マネージド型の接続プールを使用するサーバーレスアプリケーションは、RDS プロキシの料金に従って請求されます。

仕様は、Apache 2.0 でオープンソース化されています。これにより、お客様およびその他関係者は、商業利用可能なライセンスを使って AWS SAM を採用し、構築、デプロイメント、モニタリング、および管理ツールに組み込むことができます。GitHub の AWS SAM リポジトリにはこちらからアクセスしてください。

AWS Lambda では、関数をコンテナイメージとしてパッケージ化してデプロイできるようになりました。お客様は、コンテナツールの柔軟性と使いやすさ、および AWS Lambda の俊敏性と操作の単純さを活かしてアプリケーションを構築できます。

AWS が提供する Lambda のベースイメージから始めるか、お好みのコミュニティまたはプライベートエンタープライズイメージの 1 つを使用することから始めることができます。次に、Docker CLI を使用してイメージを作成し、それを Amazon ECR にアップロードしてから、AWS マネジメントコンソール、AWS CLI、AWS SDK、AWS SAM、AWS CloudFormation などの使い慣れたすべての Lambda インターフェイスとツールを使用して関数を作成します。

Lambda が提供するイメージに加えて、サードパーティーの Linux ベースイメージ (Alpine や Debian など) を Lambda にデプロイできます。AWS Lambda は、Docker Image Manifest V2 Schema 2 (Docker バージョン 1.10 以降で使用) または Open Container Initiative (OCI) 仕様 (v1.0 以降) のイメージマニフェスト形式に基づいてすべてのイメージをサポートしています。また、最大 10 GB のサイズのイメージをサポートしています。

AWS Lambda は、お客様が拡張できるさまざまなベースイメージを提供します。また、お客様は、最大 10GB のサイズの好みの Linux ベースのイメージを使用することもできます。

Docker Image Manifest V2 Schema 2 (Docker バージョン 1.10 以降で使用) または Open Container Initiative (OCI) 仕様 (v1.0 以降) のコンテナイメージマニフェスト形式のいずれかをサポートしている限り、任意のコンテナツールを使用できます。例えば、ネイティブコンテナツール (docker run、docker compose、Buildah、Packer) を使用して、関数をコンテナイメージとして定義し、Lambda にデプロイできます。

Lambda レイヤーとコード署名を除くすべての既存の AWS Lambda 機能は、コンテナイメージとしてデプロイされた関数で使用できます。デプロイされると、AWS Lambda はイメージを変更不可能として扱います。お客様は、ビルドプロセス中にコンテナレイヤーを使用して、依存関係を含めることができます。

現時点では使用できません。AWS Lambda にデプロイされると、イメージは変更不可能になります。サービスはイメージにパッチを適用したり更新したりしません。ただし、AWS Lambda は、Lambda 管理環境に基づく、サポートされているすべてのランタイムのキュレートされたベースイメージを公開します。このような公開されたイメージは、AWS Lambda マネージドランタイムの更新とともにパッチが適用され、更新されます。DockerHub または Amazon ECR Public から最新のベースイメージをプルして使用し、コンテナイメージを再構築して、Amazon ECR を介して AWS Lambda にデプロイできます。これにより、イメージを本番環境にデプロイする前に、更新されたイメージとランタイムをビルドしてテストできます。

ZIP アーカイブを使用して作成された関数とコンテナイメージを使用して作成された関数には、主に次の 3 つの違いがあります。

1. ZIP アーカイブを使用して作成された関数の最大コードパッケージサイズは解凍時に 250 MB であり、コンテナイメージを使用して作成された関数の最大イメージサイズは 10 GB です。 
2. Lambda は、コンテナイメージとして定義された関数の基になるコードストレージとして Amazon ECR を使用するため、基になるイメージが ECR から削除されると、関数を呼び出せない場合があります。 
3. ZIP 関数には、最新のランタイムセキュリティとバグ修正のために自動的にパッチが適用されます。コンテナイメージとして定義された関数は変更不可能であり、顧客は関数にパッケージ化されたコンポーネントに対して責任を負います。お客様は、利用可能な最新のパッチを使用して、セキュリティとバグ修正のために AWS によって定期的に更新される AWS 提供のベースイメージを活用できます。

いいえ。AWS Lambda は、コンテナイメージとしてパッケージ化された関数のパフォーマンスプロファイルが、通常 1 秒未満の起動時間を含め、ZIP アーカイブとしてパッケージ化されたものと同じであることを保証します。

関数をコンテナイメージとしてパッケージ化して AWS Lambda にデプロイするのに追加料金は発生しません。コンテナイメージとしてデプロイされた関数を呼び出すときは、リクエストと実行期間に対して通常価格をお支払いいただきます。詳細については、「AWS Lambda の料金」をご覧ください。 コンテナイメージを Amazon ECR に保存する場合は、標準の ECR 料金で請求されます。詳細については、「Amazon ECR の料金」をご覧ください。

Lambda Runtime Interface Emulator は、Lambda ランタイム API のプロキシで、コンテナイメージとしてパッケージ化された Lambda 関数をローカルでテストできます。これは、HTTP リクエストを JSON イベントに変換し、Lambda Runtime API をエミュレートする軽量のウェブサーバーです。これにより、cURL や Docker CLI などの使い慣れたツールを使用して関数をローカルでテストできます (コンテナイメージとしてパッケージ化された関数をテストする場合)。また、追加のコンピューティングサービスでのアプリケーションの実行も簡素化されます。Lambda へのデプロイに必要な JSON イベントの代わりに、コンテナイメージに Lambda Runtime Interface Emulator を含めて、HTTP リクエストをネイティブに受け入れるようにすることができます。このコンポーネントは、Lambda オーケストレーター、またはセキュリティと認証の設定をエミュレートしません。Runtime Interface Emulator は、GitHub でオープンソース化されています。ローカルマシンにダウンロードしてインストールして始めることができます。

実行中の Lambda サービスの Lambda Runtime API は、JSON イベントを受け入れ、応答を返します。Lambda Runtime Interface Emulator を使用すると、コンテナイメージとしてパッケージ化された関数が、cURL などのツールを使用したローカルテスト中に HTTP リクエストを受け入れ、同じインターフェイスを介して関数にローカルでそれらを表示できます。docker run コマンドまたは docker-compose up コマンドを使用して、Lambda アプリケーションをローカルでテストできます。

エミュレーターを使用して、関数コードが Lambda 環境と互換性があり、正常に実行され、期待される出力を提供するかどうかをテストできます。例えば、さまざまなイベントソースからのテストイベントを模擬的に実施できます。また、これを使用して、Lambda Extensions API に対してコンテナイメージに組み込まれている拡張機能とエージェントをテストすることもできます。

お客様は、Runtime Interface Emulator をコンテナイメージへのエントリポイントとして追加するか、サイドカーとしてパッケージ化して、コンテナイメージが JSON イベントではなく HTTP リクエストを受け入れるようにすることができます。これにより、追加のコンピューティングサービスでコンテナイメージを実行するために必要な変更が簡素化されます。お客様は、選択した環境のすべてのセキュリティ、パフォーマンス、および同時実行のベストプラクティスに従うようにする責任があります。RIE は AWS Lambda が提供するイメージに事前にパッケージ化されており、AWS SAM CLI でデフォルトで利用できます。ベースイメージプロバイダーは、ドキュメントを使用して、ベースイメージに同じエクスペリエンスを提供できます。

以下の要件を満たしている場合は、コンテナ化されたアプリケーションを AWS Lambda にデプロイできます。

1. コンテナイメージは Lambda Runtime API を実装していること。Lambda Runtime API を実装する一連のソフトウェアパッケージである Runtime Interface Clients (RIC) をオープンソース化し、Lambda 互換になるように任意のベースイメージをシームレスに拡張できるようにしました。
2. コンテナイメージは、読み取り専用ファイルシステムで実行できること。関数コードは、512 MB の書き込み可能な /tmp ディレクトリストレージにアクセスできること。書き込み可能なルートディレクトリを必要とするイメージを使用している場合は、/tmp ディレクトリに書き込むようにイメージを設定します。
3. 関数コードの実行に必要なファイルは、デフォルトの Lambda ユーザーが読み取ることができること。Lambda は、セキュリティのベストプラクティスに従う、最小権限を持つデフォルトの Linux ユーザーを定義していること。アプリケーションコードが、他の Linux ユーザーによって実行が制限されているファイルに依存していないことを確認する必要があります。
4. コンテナイメージは Linux ベースのコンテナイメージであること。

Java 向け AWS Lambda SnapStart を使用すると、関数の起動を 10 倍高速化できます。オンデマンド関数の場合、初期化フェーズ (AWS Lambda が関数のコードをロードし、外部の依存関係を初期化する) が起動レイテンシーの最大の要因であり、最初の起動時に発生します。Lambda SnapStart を使用すると、Lambda は、関数を最初に呼び出すときではなく、関数のバージョンを公開するときに、1 回限りの初期化関数コードを事前に初期化します。その後、Lambda はスナップショットを取得し、初期化された実行環境のメモリとディスクの状態をキャッシュします。関数を呼び出したとき、そして関数がスケールアップしたとき、Lambda は関数をゼロから初期化するのではなく、キャッシュされたスナップショットから関数を再開します。

Lambda SnapStart は、Lambda API、AWS マネジメントコンソール、AWS Command Line Interface (CLI)、AWS SDK、AWS Cloud Development Kit (CDK)、AWS CloudFormation、AWS Serverless Application Model (SAM) を使用して新規および既存の Java 関数に設定できるシンプルな関数レベルの設定です。Lambda SnapStart を設定すると、それ以降に公開されるすべての関数バージョンで、Lambda SnapStart が提供する起動時のパフォーマンスの向上というメリットが得られます。Lambda SnapStart の詳細については、「ドキュメント」を参照してください。

Lambda SnapStart は、1 回限りの初期化コードの実行中に発生する可変レイテンシーを低減することで、Java 関数の起動時間を最大 10 倍高速化するパフォーマンス最適化機能です。Lambda SnapStart は、お客様のアプリケーションまたはアカウント内のすべての関数に幅広く機能し、追加費用はかかりません。お客様が Lambda SnapStart を使用して関数のバージョンを公開すると、関数のコードは最初の呼び出し時に初期化されるのではなく、事前に初期化されます。その後、Lambda は初期化された実行環境のスナップショットを取得し、低レイテンシーでアクセスできるように階層型キャッシュに永続化します。関数が最初に呼び出され、その後スケールされるとき、Lambda はゼロから初期化するのではなく、キャッシュされたスナップショットから関数を再開し、起動レイテンシーを低く抑えます。Lambda SnapStart は起動レイテンシーを低減しますが、ベストエフォート型の最適化として機能し、コールドスタートの排除を保証するものではありません。レイテンシー要件が厳しく、起動時間が 2 桁 (ミリ秒) 必要なアプリケーションでは、PC を使用することをお勧めします。

Lambda SnapStart は、Java 11 ランタイムをサポートしています。今後の Java のバージョンについては、リリース後に対応予定です。Lambda がサポートしているすべてのランタイムについては、Lambda ランタイムのドキュメントを参照してください。

いいえ。Lambda SnapStart と PC を同時に、同じ機能で有効にすることはできません。

はい。Lambda SnapStart 機能を設定して、仮想プライベートクラウド (VPC) 内のリソースにアクセスすることは可能です。VPC を使用した関数の設定方法の詳細については、Lambda のドキュメントを参照してください。

いいえ。現時点では、x86 アーキテクチャで実行される関数に対してのみ Lambda SnapStart を設定することができます。

いいえ。現時点では、Amazon EFS で Lambda SnapStart を有効にすることはできません。

現時点では、512 MB を超える大きなエフェメラルストレージ (/tmp) を使用して Lambda SnapStart を有効にすることはできません。

はい。お客様のコードが状態の一意性を仮定している場合、スナップショット操作 (クローンやレジュームされるなど) に対するお客様のコードの耐障害性を評価する必要があります。Lambda SnapStart での一意性の考慮についての詳細は、Lambda SnapStart による VM スナップショットでの一意性の理解に関するドキュメントとブログを参照してください。

はい。スナップショット作成 (チェックポイント) 前やスナップショット再開後に、ランタイムフックを使って独自のソフトウェアロジックを実装することが可能です。詳しくは、Lambda SnapStart のドキュメントをご覧ください。

いいえ。Lambda SnapStart を有効にするための追加料金は発生しません。関数に対するリクエストの数とコードの実行時間に応じて、現在の Lambda の料金に基づいて課金されます。実行時間に対する課金は、関数やランタイムフックのハンドラーのコードに加え、そのハンドラーの外部に記述されている初期化コードの実行に対しても適用されます。なお、AWS Lambda はセキュリティパッチを適用した実行環境を定期的にリサイクルし、初期化コードを再実行することがあります。詳細については、Lambda のプログラミングモデルに関するドキュメントをご参照ください。

Lambda SnapStart では、公開された関数バージョンが呼び出しを受信し続ける限り、過去 3 回分の公開された関数バージョンの初期化実行環境のスナップショットが保持されます。公開された関数バージョンに関連するスナップショットは、14 日以上非アクティブな状態が続くと失効します。

スナップショットは、Lambda サービスが所有および管理するお客様独自の AWS Key Management Service (KMS) キーでデフォルトで暗号化されます。また、お客様が所有および管理する KMS キーを使用してスナップショットを暗号化することも可能です。

Lambda SnapStart で許可される最大初期化時間は、お客様が関数に設定した実行タイムアウト時間と一致します。関数に設定可能な実行タイムアウトの上限は 15 分です。

プロビジョニングされた同時実行により、サーバーレスアプリケーションのパフォーマンスをより詳細に制御できます。有効にすると、プロビジョニングされた同時実行は、2 桁のミリ秒で応答するように機能を初期化し、ハイパー対応状態になります。

AWS マネジメントコンソール、Lambda API、AWS CLI、AWS CloudFormation を使用して、関数の同時実行を設定できます。Provisioned Concurrency を最も簡単に活用するには、AWS Auto Scaling を使用します。Application Auto Scaling を使用してスケジュールを構成したり、需要の変化に応じて Auto Scaling で Provisioned Concurrency のレベルをリアルタイムで自動的に調整したりできます。Provisioned Concurrency の詳細については、「ドキュメントを参照」してください。

Provisioned Concurrency を使用するためにコードを変更する必要はありません。既存のすべての関数とランタイムでシームレスに動作します。Provisioned Concurrency を使用する場合、Lambda の呼び出しや実行モデルに変更はありません。

Provisioned Concurrency では、関数の初期化を維持するために、「Provisioned Concurrency」という料金ディメンションが追加されます。有効にすると、構成した同時実行の量と構成期間に対して料金をお支払いいただきます。Provisioned Concurrency が設定されている状態で関数を実行すると、リクエストと実行時間に対しても料金が発生します。Provisioned Concurrency 料金の詳細については、「AWS Lambda 料金」を参照してください。

Provisioned Concurrency は、ウェブまたはモバイルバックエンド、同期的に呼び出される API、インタラクティブなマイクロサービスなど、レイテンシーの影響を受けやすいアプリケーションの構築に最適です。アプリケーション固有のリクエストに基づいて、適切な量の同時実行を簡単に構成できます。需要が高いときは同時実行の量を増やして、需要が低下したときは下げるか、完全にオフにすることができます。

関数の同時実行が構成されたレベルに達すると、その後の関数の呼び出しでは、通常の Lambda 関数のレイテンシーとスケールの特性が生じます。構成されたレベルを超えてスケールアップしないように関数を制限できます。そうすることで、関数が設定された Provisioned Concurrency のレベルを超えないようにします。これは、需要が予想量を超えたときに、アプリケーションの望ましくない変動を防ぐためのメカニズムです。

AWS Lambda では、x86 ベースまたは Arm ベースのプロセッサで関数を実行することができます。AWS Graviton2 は Amazon Web Services により 64-bit の Arm Neoverse コアを使用してカスタム構成されたプロセッサで、クラウドワークロードに、向上した料金パフォーマンスを提供するものです。お客様は、サーバーのプロビジョニングや管理をすることなくコードを実行し、オートスケーリング、高可用性、消費したリソースの分だけ支払うという、AWS Lambda と同じメリットを得ることができます。

AWS が設計した Arm ベースのプロセッサアーキテクチャを採用した Graviton2 による AWS Lambda 関数は、ウェブやモバイルのバックエンド、データ、ストリーム処理など、さまざまなサーバーレスワークロードに対して、x86 プロセッサで動作する関数と比較して最大 34% のより良い料金パフォーマンスを実現します。低レイテンシー、最大 19% のパフォーマンス向上、20% のコスト削減、そして AWS で現在利用可能な中で最高の電力効率を実現した Graviton2 関数は、ミッションクリティカルサーバーレスアプリケーションを強化することができます。お客様は、Graviton2 プロセッサをターゲットとした既存および新規の関数を設定することができます。また、Graviton2 上で動作する関数は、zip ファイルまたはコンテナイメージとしてデプロイすることができます。

AWS マネジメントコンソール、AWS Lambda API、AWS CLI、AWS CloudFormation を使って、関数のアーキテクチャフラグを「arm64」に設定することで、Graviton2 上で関数を動作するように設定できます。

x86 ベースの関数と Arm ベースの関数の間に変更はありません。AWS マネジメントコンソールや zip ファイル、コンテナイメージなどでコードをアップロードするだけで、AWS Lambda はインフラストラクチャのプロビジョニングや管理を必要とせず、トリガーされたときにコードを自動的に実行します。

アプリケーションは、両方のアーキテクチャで動作する関数を含むことができます。AWS Lambda では、関数の現在のバージョンのアーキテクチャ (「x86_64」または「arm64」) を変更することができます。一度、特定のバージョンの関数を作成すると、アーキテクチャは変更できません。

Python、Java、Node などのインタプリタ型言語は、アーキテクチャ固有のコンポーネントを使用するライブラリを参照するコードでない限り、一般的に再コンパイルの必要はありません。その場合は、arm64 用のライブラリを用意する必要があります。詳細は「AWS Graviton を開始する」のページをご参照ください。非インタプリタ型言語の場合は、arm64 をターゲットにしたコードのコンパイルが必要です。最近のコンパイラは arm64 向けにコンパイルされたコードを生成しますが、テストのためには arm ベースの環境にデプロイする必要があります。Graviton2 での Lambda 関数の使い方については、「ドキュメント」を参照してください。

いいえ、各関数のバージョンは単一のコンテナイメージしか使用できません。

はい。レイヤーと拡張機能は、「x86_64」または「arm64」互換のアーキテクチャを対象とすることができます。関数やレイヤーのデフォルトのアーキテクチャは「x86_64」です。

起動時は、お客様は Python、Node.js、Java、Ruby、.Net Core、Custom Runtime (provided.al2)、OCI Base イメージを使用することができます。詳細については、「AWS Lambda ランタイム」をご覧ください。

AWS Graviton2 プロセッサによる AWS Lambda 関数は、x86 ベースの Lambda 関数と比較して 20% 安くなっています。Lambda の無料利用枠は、x86 および Arm ベースのアーキテクチャによる AWS Lambda 関数に適用されます。

各ワークロードはそれぞれ異なりますので、お客様には関数をテストして、料金パフォーマンスの向上を見て、判断されることをお勧めします。そのためには、AWS Lambda Power Tuning ツールを使用することをお勧めします。料金パフォーマンス向上の可能性があるワークロードをテストする際には、ウェブやモバイルのバックエンド、データ、ストリーム処理から始めることをお勧めします。

Amazon Elastic File System (Amazon EFS) for AWS Lambda を利用することで、ユーザーはプロビジョニングやキャパシティー管理なしに、オンデマンドで拡張できるフルマネージド型で伸縮自在な NFS ファイルシステムを使用し、さまざまな規模で大容量のデータを安全に読み書きすることができます。従来、デベロッパーは、S3 やデータベースからローカルの一時ストレージにデータをダウンロードするためのコードを関数に追加していましたが、512MB までに制限されていました。EFS for Lambda を使えば、デベロッパーはデータを処理するために一時ストレージにデータをダウンロードするコードを書く必要はありません。

デベロッパーは、コンソール、CLI、または SDK を使用して、既存の EFS ファイルシステムを EFS アクセスポイント経由で Lambda 関数に簡単に接続することができます。関数が最初に起動されると、ファイルシステムは自動的にマウントされ、関数コードで利用できるようになります。詳細については、ドキュメントを参照してください。

はい。Amazon EFS 用のマウントターゲットは、VPC 内のサブネットに関連付けられています。その VPC にアクセスするために AWS Lambda 関数を設定する必要があります。

EFS for Lambda は、機械学習アプリケーションの構築や大規模な参照ファイルやモデルのロード、大量のデータの処理やバックアップ、Web コンテンツのホスティング、社内のビルドシステムの開発などに最適です。また、Step Functions のワークフロー内で、ステートフルマイクロサービスアーキテクチャ内の呼び出し間の状態を保持したり、サーバーレスアプリケーションとインスタンスやコンテナベースのアプリケーション間でファイルを共有したりする際にも、EFS for Lambda を使用することができます。

はい。AWS Lambda 関数と Amazon EFS ファイルシステム間で送信されるデータの暗号化には、業界標準の Transport Layer Security (TLS) 1.2 を使用しています。

ユーザーは Amazon EFS をプロビジョニングすることで、保存したデータを暗号化することができます。保管中に暗号化されたデータは書き込み中に透過的に暗号化され、読み取り中は透過的に復号されるため、アプリケーションを変更する必要はありません。また、暗号化キーは AWS Key Management Service (KMS) によって管理されるため、安全なキー管理インフラストラクチャを構築および維持する必要はありません。

AWS Lambda の Amazon EFS は追加料金なしで使用できます。AWS Lambda の標準料金をお支払いいただくことで、Amazon EFS を使用することができます。同一のアベイラビリティーゾーンで Lambda と EFS を使用している場合はデータ転送料金はかかりません。しかし、VPC ピアリングを利用してクロスアカウントアクセスを行うと、データ転送料金が発生します。詳細については、「料金」をご覧ください。

いいえ。各 Lambda 関数は 1 つの EFS ファイルシステムにのみアクセスすることができます。

はい。Amazon EFS は Lambda 関数、ECS と Fargate コンテナ、EC2 インスタンスをサポートしています。同じファイルシステムを共有し、IAM ポリシーとアクセスポイントを使用して、各関数、コンテナ、インスタンスがアクセスできるものを制御できます。 

はい。Lambda 関数は、ブラウザ、curl、任意の HTTP クライアントを使用して呼び出すことができる組み込みの HTTPS エンドポイントである関数の URL を用いて設定することができます。関数の URL は、HTTPS アクセス可能な関数の構築を開始する簡単な方法です。

AWS マネジメントコンソール、AWS Lambda API、AWS CLI、AWS CloudFormation、AWS Serverless Application Model を介して、お客様の関数用の関数の URL を設定することができます。関数の URL は、関数の $LATEST 非修飾バージョン、または任意の関数エイリアスで有効にすることができます。関数の URL の設定の詳細については、ドキュメントを参照してください。

Lambda 関数の URL は、デフォルトでは IAM 認可で保護されます。パブリックエンドポイントを作成したり、関数のビジネスロジックの一部としてカスタム認可を実装する予定がある場合は、IAM 認可を無効にすることを選択できます。

Lambda URL にナビゲートしてウェブブラウザから、HTTP ライブラリを使用してクライアントアプリケーションのコードから、または curl を使用してコマンドラインから、関数を簡単に呼び出すことができます。

はい。Lambda 関数の URL は、関数や関数のエイリアスで有効にすることができます。エイリアスが指定されていない場合、URL はデフォルトで $LATEST を指します。関数の URL は、個々の関数のバージョンを対象とすることはできません。

カスタムドメイン名は、現在、関数の URL でサポートされていません。Amazon CloudFront ディストリビューションと CNAME を作成し、カスタムドメインを CloudFront ディストリビューション名にマッピングすることで、関数の URL でカスタムドメインを使用することができます。そして、お客様の CloudFront ディストリビューションのドメイン名を、オリジンとしてお客様の関数の URL にルーティングするようにマッピングします。

はい、関数の URL は、VPC 内の Lambda 関数を呼び出すのに使用できます。

関数の URL は追加料金なしで使用できます。AWS Lambda の標準料金をお支払いただきます。詳細については、AWS Lambda の料金をご覧ください。

Lambda@Edge を使用すると、世界中の AWS ロケーションでコードを実行できます。サーバーのプロビジョニングや管理の必要がなく、エンドユーザーへの応答で発生するネットワークレイテンシーを最低限に抑えることができます。Node.js または Python コードを AWS Lambda にアップロードし、Amazon CloudFront リクエスト (ビューワーのリクエストがあったとき、リクエストがオリジンに転送されたときやオリジンから戻ってきたとき、エンドユーザーに返される直前など) に応答してトリガーされるよう関数を設定するだけで、作業が完了します。コンテンツのリクエストを受信すると、世界中の AWS ロケーションでコードが実行できるようになり、CloudFront のリクエストボリュームに応じてグローバルにスケールされます。詳細についてはドキュメントを参照してください。

Lambda@Edge を使用するには、AWS Lambda にコードをアップロードし、Amazon CloudFront リクエストに応答してトリガーされるよう関数のバージョンを関連付けます。コードで Lambda@Edge サービスの上限を指定する必要があります。Lambda@Edge で CloudFront イベントによるグローバルな呼び出しに使用できるコードは、現在のところ Node.js および Python のみです。詳細についてはドキュメントを参照してください。

Lambda@Edge は、レイテンシーが問題となるようなユースケース向けに最適化されています。エンドビューワーが世界中に分布している場合などが当てはまります。処理の決定に必要なすべての情報は、CloudFront エッジの関数内やリクエスト内で使用できるようになります。つまり、ユーザー特性 (ロケーションやクライアントデバイスなど) に基づいてコンテンツの処理方法を決定する必要があるユースケースでは、中央サーバーにルーティングし直さなくても、ユーザーの近くで実行および処理ができるようになります。

グローバルな呼び出しを行うために、既存の Lambda 関数を CloudFront イベントに関連付けることができます。ただし、関数が Lambda@Edge サービスの要件および制限を満たしている必要があります。関数のプロパティの更新方法については、こちらをご覧ください。

以下のような Amazon CloudFront イベントに応答して機能が自動的にトリガーされます。

• ビューワーのリクエスト - このイベントは、インターネット上のエンドユーザーまたはデバイスが CloudFront に対して HTTP(S) リクエストを行い、そのユーザーに最も近いエッジロケーションにリクエストが到達したときに発生します。
• 閲覧者の応答 – このイベントは、エッジにある CloudFront サーバーが、リクエストを実行したエンドユーザーまたはデバイスに応答する準備ができたときに発生します。
• オリジンのリクエスト - このイベントは、リクエストされたオブジェクトを CloudFront エッジサーバーがキャッシュに保持しておらず、ビューワーのリクエストをバックエンドのオリジンウェブサーバー (Amazon EC2、Application Load Balancer、Amazon S3 など) に送信する準備ができたときに発生します。
• オリジンの応答 - このイベントは、エッジの CloudFront サーバーがバックエンドのオリジンウェブサーバーから応答を受け取ったときに発生します。

違いは、API Gateway と Lambda がリージョンのサービスであることです。Lambda@Edge と Amazon CloudFront を使用すると、エンドビューアーの所在に基づき多くの AWS ロケーションにわたってロジックを実行できます。

AWS Lambda はレプリケーションと冗長性を使用して、サービス本体およびサービスによって実行される Lambda 関数の両方で高い可用性を実現するように設計されています。メンテナンス時間や定期的なダウンタイムはありません。

はい。Lambda 関数を更新すると、通常 1 分未満の短い移行期間が発生します。この期間中に発行されたリクエストは、古いバージョンと新しいバージョンのどちらによって処理されるか保証されません。

いいえ。AWS Lambda は、関数のインスタンスを多数並行して実行できるよう設計されています。ただし、AWS Lambda には各リージョンのアカウントごとに同時実行数に関するデフォルトの安全性のためのスロットルが設定されています (デフォルトの安全性のためのスロットルの制限に関する情報については、こちらにアクセスしてください)。また、個々の AWS Lambda 関数の最大同時実行数を制御して重要な関数に関するアカウントの同時実行上限サブセットを予約したり、ダウンストリームリソースへのトラフィックレートを制限したりできます。

同時実行数の制限を引き上げるリクエストを送信する場合、Service Quotas を使用して上限の引き上げをリクエストできます。

同時実行数の上限値を超えると、同期的に呼び出されている AWS Lambda 関数はスロットリングエラー (エラーコード 429) を返します。非同期に呼び出された Lambda 関数は、15～30 分程度は、トラフィックの急激な上昇によるものとして許容されますが、それ以降の着信イベントはスロットリングの対象となり拒否されます。Lambda 関数が、Amazon S3 イベントに対する応答として呼び出された場合、AWS Lambda によって拒否されたイベントは、S3 によって保持され、24 時間再試行されます。Amazon Kinesis ストリームおよび Amazon DynamoDB ストリームからのイベントは、Lambda 関数が正常に実行されるか、データが期限切れになるまで再試行されます。Amazon Kinesis および Amazon DynamoDB ストリームでは、24 時間データが保持されます。

デフォルトの最大同時実行制限は、アカウントレベルで適用されます。ただし、個々の関数に上限を設定することもできます (予約済み同時実行の詳細については、こちらをご覧ください)。

同期的に呼び出される各 Lambda 関数は、10 秒ごとに最大 1000 回の同時実行速度でスケールできます。Lambda のスケーリングレートはほとんどのユースケースに適していますが、トラフィックのバーストが予測可能または予測できない場合に特に理想的です。例えば、SLA ベースのデータ処理では、処理需要を満たすために、予測可能でありながら迅速なスケーリングが必要です。同様に、最新ニュース記事やフラッシュセールを配信すると、短期間で予測できないレベルのトラフィックが発生する可能性があります。Lambda のスケーリングレートにより、追加の設定やツールなしでこのようなユースケースに容易に対応できます。さらに、同時実行スケーリングの上限は関数レベルの上限です。つまり、アカウント内の各関数は他の関数とは独立してスケールします。

同期呼び出しの Lambda 関数が失敗すると、例外が返されます。非同期的に呼び出される Lambda 関数は、少なくとも 3 回再試行されます。Amazon Kinesis ストリームおよび Amazon DynamoDB ストリームからのイベントは、Lambda 関数が正常に実行されるか、データが期限切れになるまで再試行されます。Kinesis および DynamoDB ストリームでは、少なくとも 24 時間データが保持されます。

配信不能キューとして設定できるのは、Amazon SQS キューまたは Amazon SNS トピックです。

非同期呼び出しに対する再試行ポリシーを超えた場合は、イベントが配置される「配信不能キュー」(DLQ) を設定できます。設定済みの DLQ がない場合は、イベントが拒否されることがあります。ストリームベースの呼び出しについての再試行ポリシーを超過した時点で、データは既に期限切れになっており、拒否されると考えられます。

Lambda 関数に他のリソースにアクセスするための権限を与えるには、IAM ロールを使用します。AWS Lambda は、この IAM ロールの権限で Lambda 関数を実行します。これにより、Lambda 関数が使用できる AWS リソースを完全かつ安全に管理できます。役割についての詳細は、「AWS Lambda のセットアップ」をご覧ください。

AWS Lambda 関数にメッセージを送信するよう Amazon S3 バケットを設定すると、アクセスを許可するリソースポリシールールが作成されます。Lambda 関数のリソースポリシーとアクセス制御の詳細については、「Lambda デベロッパーガイド」をご覧ください。

アクセスコントロールは、Lambda 関数のロールによって管理されます。Lambda 関数に割り当てるロールによって、AWS Lambda が代わりにポーリングできるリソースが決まります。詳細については、「Lambda デベロッパーガイド」をご覧ください。

アクセスコントロールは、Lambda 関数のロールまたはキュー自体に設定するリソースポリシーによって管理できます。 両方のポリシーがある場合は、2 つのうちより厳しいアクセス許可が適用されます。

関数設定の一部としてサブネットとセキュリティグループを指定することで、Lambda 関数を使用して VPC 内のリソースにアクセスできます。個別の VPC のリソースに対するアクセスを設定された Lambda 関数では、デフォルトの設定としてインターネットにアクセスできなくなっています。これらの機能にインターネットを許可するには、インターネットゲートウェイを使用します。デフォルトでは、Lambda 関数は IPv4 経由でデュアルスタック VPC 内のリソースと通信します。IPv6 経由でデュアルスタック VPC 内のリソースにアクセスするように関数を設定できます。VPC で設定された Lambda 関数の詳細については、VPC を使用した Lambda プライベートネットワークを参照してください。

AWS Lambda のコード署名により、信頼性と整合性を管理できます。それにより、承認されたデベロッパーからの未変更のコードのみが Lambda 関数にデプロイされていることを確認できます。フルマネージドコード署名サービスである AWS Signer を使用して、コードアーティファクトにデジタル署名を行い、Lambda 関数を設定してデプロイ時に署名を検証できます。AWS Lambda のコード署名は、現在、ZIP アーカイブとしてパッケージ化された関数でのみご利用いただけます。

AWS Signer コンソール、Signer API、SAM CLI、または AWS CLI を介して、Signing Profile を使用して、デジタル署名されたコードアーティファクトを作成できます。詳細については、「AWS Signer のドキュメント」をご覧ください。

AWS マネジメントコンソール、Lambda API、AWS CLI、AWS CloudFormation、および AWS SAM を介してコード署名設定を作成することにより、コード署名を有効にできます。コード署名設定は、承認された署名プロファイルを指定し、署名チェックが失敗した場合にデプロイを警告するか拒否するかを設定するのに役立ちます。コード署名設定を個々の Lambda 関数にアタッチして、コード署名機能を有効にすることができます。このような関数は、デプロイ時に署名の検証を開始します。

AWS Lambda は、デプロイ時に次の署名チェックを行えます。

• 破損した署名 – これは、署名後にコードアーティファクトが変更された場合に発生します。
• 不一致の署名 – これは、コードアーティファクトが承認されていない署名プロファイルによって署名された場合に発生します。
• 期限切れの署名 – これは、署名が設定された有効期限を過ぎている場合に発生します。
• 取り消された署名 – これは、署名プロファイルの所有者が署名ジョブを取り消した場合に発生します。

詳細については、「AWS Lambda ドキュメント」をご覧ください。

はい。関数にコード署名設定をアタッチすることで、既存の関数のコード署名を有効にできます。これは、AWS Lambda コンソール、Lambda API、AWS CLI、AWS CloudFormation、および AWS SAM を使用して実行できます。

AWS Lambda のコード署名を使用する際、追加費用は発生しません。AWS Lambda の標準料金をお支払いただきます。詳細については、「料金」をご覧ください。

AWS Lambda には、デフォルトでシンプルで強化されたロギング機能を提供するために、Lambda 関数ログを JSON 構造化形式でネイティブにキャプチャする機能、コードを変更せずに Lambda 関数ログのログレベルフィルタリングを制御する機能、Lambda がログを送信する Amazon CloudWatch ロググループをカスタマイズする機能など、高度なログ制御が用意されています。

独自のロギングライブラリを使用しなくても、Lambda 関数ログを JSON 構造化形式でキャプチャできます。JSON 構造化ログにより、大量のログエントリの検索、フィルタリング、分析が容易になります。コードを変更することなく、Lambda 関数ログのログレベルフィルタリングを制御できます。これにより、エラーのデバッグやトラブルシューティング時に大量のログを精査することなく、Lambda 関数に必要なログの粒度レベルを選択できます。また、Lambda がログを送信する Amazon CloudWatch ロググループを設定できるため、アプリケーション内の複数の関数からのログを 1 か所に簡単に集約できます。その後、セキュリティ、ガバナンス、保持ポリシーをすべての機能に個別に適用するのではなく、アプリケーションレベルでログに適用できます。

AWS Lambda API、AWS Lambda コンソール、AWS CLI、AWS サーバーレスアプリケーションモデル (SAM)、および AWS CloudFormation を使用して、Lambda 関数の高度なログ制御を指定できます。詳細については、高度なログ制御に関する「リリースブログ記事」または、「 Lambda デベロッパーガイド」をご覧ください。

はい、独自のロギングライブラリを使用して JSON 構造化形式の Lambda ログを生成できます。ロギングライブラリが Lambda のネイティブ JSON 構造化ロギング機能とシームレスに連携するように、Lambda は関数によって生成され、すでに JSON でエンコードされているログを二重エンコードしません。Powertools for AWS Lambda ライブラリを使用して、JSON 構造化形式の Lambda ログをキャプチャすることもできます。

Lambda で高度なログ制御を使用しても追加料金はかかりません。Amazon CloudWatch Logs による Lambda ログの取り込みとストレージについては、引き続き課金されます。ログ料金の詳細については「CloudWatch の料金ページ」を参照してください。

Maven や Gradle といった標準的なツールを使用して Lambda 関数をコンパイルできます。構築プロセスにおいては、AWS SDK に応じた Java コードのコンパイルに使用する構築プロセスと同様のプロセスを行う必要があります。Java コンパイラツールをソースファイルで実行し、クラスパスで推移従属性を使用した AWS SDK 1.9 以降をインクルードします。詳細については、「ドキュメント」を参照してください。

Lambda では Amazon Linux build of openjdk 1.8 を利用できます。

はい。NPM パッケージ、およびカスタム作成パッケージを使用できます。詳細はこちらをご覧ください。

はい。Lambda の組み込みサンドボックスを使用すれば、バッチ (shell) スクリプト、他の言語ランタイム、ユーティリティルーチン、実行可能ファイルを実行できます。詳細はこちらをご覧ください。

はい。アップロードする ZIP ファイルには、静的リンクのネイティブモジュール、および rpath が Lambda 関数のルートディレクトリを指すように指定してコンパイルした動的リンクモジュールを含めることができます。詳細はこちらをご覧ください。

はい。Node.js の child_process コマンドを使用して、お客様の関数にインクルードされたバイナリ、またはお客様の関数から確認できる Amazon Linux の実行可能ファイルを実行できます。別の方法として、node-ffmpeg などのコマンドラインバイナリをラップする NPM パッケージがいくつか存在しています。詳細はこちらをご覧ください。

Node.js で記述した Lambda 関数は、JavaScript コードと依存ライブラリを ZIP 形式でパッケージ化するだけでデプロイできます。お使いのローカル環境から ZIP ファイルをアップロードするか、ZIP ファイルのある Amazon S3 のロケーションを指定できます。詳細については、「ドキュメント」を参照してください。

はい。pip を使用して必要な Python パッケージをインストールできます。

C# Lambda 関数は、ソリューションエクスプローラで [Publish to AWS Lambda] を選択することで、Visual Studio IDE を使用して作成できます。あるいは、[# Lambda CLI tools patch] がインストールされている dotnet CLI から「dotnet lambda publish」コマンドを直接実行することもできます。これにより、C# ソースコードとすべての NuGet 依存関係、および発行済みの独自の DLL アセンブリを含む ZIP が作成され、ランタイムパラメータ「dotnetcore1.0」を使用して AWS Lambda に自動的にアップロードされます。

PowerShell Lambda デプロイパッケージは、PowerShell スクリプト、PowerShell スクリプトで必要な PowerShell モジュール、PowerShell Core をホストするために必要なアセンブリで構成される ZIP ファイルです。PowerShell の AWSLambdaPSCore PowerShell モジュールは PowerShell Gallery からインストールできますので、これを使用して、PowerShell Lambda デプロイパッケージを作成します。

AWS CLI または Lambda コンソールを介して Go の実行可能なアーティファクトを ZIP ファイルとしてアップロードし、go1.x ランタイムを選択します。Lambda を用いることで、コードのビルドとパッケージ化に Go のネイティブツールを使用できます。詳細については、ドキュメントを参照してください。 

Ruby で記述した Lambda 関数をデプロイするには、Ruby コードと gem を ZIP ファイルとしてパッケージ化します。お使いのローカル環境から ZIP ファイルをアップロードするか、ZIP ファイルのある Amazon S3 のロケーションを指定できます。

こちらで、サポートされているバージョンの一覧をご確認いただけます。

いいえ。AWS Lambda は、サービスのユーザー全員に、単一バージョンのオペレーティングシステムとマネージド型言語ランタイムを提供しています。自分で言語ラインタイムを持ち込んで Lambda で使用することは可能です。

AWS Lambda は AWS CloudTrail と統合されています。AWS CloudTrail では、お客様のアカウントでの API の使用状況を記述したログファイルを Amazon S3 バケットに記録および配信できます。

Amazon Step Functions を使用することで、Lambda 関数の複数の呼び出しを調整できます。複数の Lambda 関数を順次呼び出して出力を代わる代わる渡すことも、同時に呼び出すこともできます。詳細については、「ドキュメント」を参照してください。

はい。AWS Lambda は Advanced Vector Extensions 2 (AVX2) 命令セットをサポートしています。パフォーマンスを向上させるためにこの命令セットをターゲットにするようにアプリケーションコードをコンパイルする方法の詳細については、「AWS Lambda デベロッパー向けドキュメント」をご覧ください。