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

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 ログの料金が適用されます。

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

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

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

はい。デフォルトでは、各 AWS Lambda 関数には、最新バージョンのコードが 1 つ存在します。Lambda 関数のクライアントでは、特定のバージョンを呼び出したり、最新の実装を取得したりできます。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 レートと割引で請求されます。この契約でカバーされていない残りの使用量は、月間の関数の合計実行時間を基に、該当する階層に対応したレートで請求されます。

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

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

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

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 リポジトリにはこちらからアクセスしてください。

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

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

関数をコンテナイメージとしてパッケージ化して 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 でオープンソース化されています。ローカルマシンにダウンロードしてインストールして始めることができます。

お客様は、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 ベースのコンテナイメージであること。

AWS SnapStart を使用すると、レイテンシーの影響を受けやすいアプリケーションの起動パフォーマンスを、数秒からわずか 1 秒未満にまで改善できます。SnapStart は、関数の初期化されたメモリ (およびディスク) 状態のスナップショットを作成し、このスナップショットをキャッシュして低レイテンシーアクセスを実現することで機能します。その後に関数が呼び出されると、Lambda は最初から初期化するのではなく、この事前に初期化されているスナップショットから実行環境を再開し、起動レイテンシーを改善します。回復力のために、Lambda はスナップショットのキャッシュされたコピーを維持し、ランタイムアップグレードやセキュリティパッチなどのソフトウェア更新を自動的に適用します。

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

Lambda SnapStart は、1 回限りの初期化コードの実行中に発生する可変レイテンシーを低減することで、関数の起動時間を高速化するのに役立つパフォーマンス最適化機能です。Lambda SnapStart は起動レイテンシーを低減しますが、ベストエフォート型の最適化として機能し、コールドスタートの排除を保証するものではありません。レイテンシー要件が厳しく、起動時間が 2 桁 (ミリ秒) 必要なアプリケーションでは、PC を使用することをお勧めします。

Lambda SnapStart は、Java 11 (およびそれ以降)、Python 3.12 (およびそれ以降)、.NET 8 (およびそれ以降) を含め、複数のランタイムをサポートしています。今後のランタイムのバージョンについては、リリース後にサポートされる予定です。Lambda がサポートしているすべてのランタイムについては、Lambda ランタイムのドキュメントを参照してください。

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

はい。Lambda SnapStart は、x86 と Arm の両方のアーキテクチャで実行される関数のために設定できます。

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

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

はい。関数バージョンがアクティブな期間中、最低 3 時間、その後は 1 ミリ秒ごとに、スナップショットのキャッシュについて課金されます。料金は関数に割り当てたメモリ量により異なります。また、Lambda がスナップショットを復元して実行環境を再開するたびに課金されます。料金は関数に割り当てたメモリの量によって異なります。SnapStart の料金の詳細については、「AWS Lambda の料金」にアクセスしてください。

SnapStart の料金は、スナップショットを最大 14 日間しかキャッシュできないサポートされている Java マネージドランタイムには適用されません。

すべての Lambda 関数と同様に、SnapStart 関数にも所要時間の料金が適用されます。SnapStart を使用する関数の場合、所要時間には、ランタイムのロードにかかる時間、ランタイムフックで実行されるコード、および回復力のためにスナップショットコピーを作成する際に実行される初期化コードが含まれます。

Python および .NET 向けの Lambda SnapStart を使用すると、関数がアクティブである限り、関数のスナップショットはアクティブなままになります。Java 関数の場合、公開された関数に関連付けられたスナップショットは、14 日を超える期間にわたって非アクティブな状態が続くと失効します。

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

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

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

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

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

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

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

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

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

関数の 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 は、関数のインスタンスを多数並行して実行できるよう設計されています。ただし、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 のスケーリングレートにより、追加の設定やツールなしでこのようなユースケースに容易に対応できます。さらに、同時実行スケーリングの上限は関数レベルの上限です。つまり、アカウント内の各関数は他の関数とは独立してスケールします。

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

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

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

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

関数設定の一部としてサブネットとセキュリティグループを指定することで、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 は、デプロイ時に次の署名チェックを行えます。

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

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

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 の料金ページ」を参照してください。

CloudWatch Application Signals はアプリケーションパフォーマンスモニタリング (APM) ソリューションであり、デベロッパーとオペレーターは、Lambda を使用して構築されたサーバーレスアプリケーションの状態とパフォーマンスを簡単にモニタリングできるようになります。重要なアプリケーションメトリクス、相関トレース、Lambda 関数とその依存関係とのやり取りに、Application Signals によって提供される事前構築済みの標準化されたダッシュボードを使用できます。デベロッパーは手動でインストルメンテーションやコードの変更を行う必要はありません。

Lambda コンソールの [設定] タブの [モニタリングと運用ツール] セクションで 1 回クリックするだけで、関数で Application Signals を有効にできます。Application Signals を有効にすると、CloudWatch コンソールでビルド済みのダッシュボードやサービスマップなどを表示し、サーバーレスアプリケーションのパフォーマンスと状態を分析できます。詳細については、Lambda デベロッパーガイドと Application Signals デベロッパーガイドをご覧ください。Lambda 関数で Application Signals を使用した場合に発生する料金の詳細については、CloudWatch の料金ページをご覧ください。

CloudWatch Logs Live Tail はインタラクティブなログストリーミングおよび分析機能であり、ログをリアルタイムで可視化できるため、Lambda 関数の開発とトラブルシューティングが容易になります。これにより、開発者はコードや設定の変更をリアルタイムですばやく簡単にテストして検証できるようになり、Lambda を使用してアプリケーションを構築する際の、作成-テスト-デプロイのサイクル (「内部開発ループ」とも呼ばれます) が加速されます。Live Tail エクスペリエンスにより、オペレーターや DevOps チームが Lambda 関数コードの障害や重大なエラーをより効率的に検出およびデバッグできるようになり、Lambda 関数エラーのトラブルシューティング時の平均復旧時間 (MTTR) が短縮されます。

Lambda 関数で Live Tail を使用するには、Lambda コンソールにアクセスし、コードエディターの [CloudWatch Live Tail を開く] ボタンをクリックします。詳細については、Lambda デベロッパーガイドをご覧ください。Lambda 関数で Live Tail を使用した場合に発生する料金の詳細については、CloudWatch の料金ページをご覧ください。

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

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

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

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

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

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

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

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

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

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

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