AWS Lambda よくある質問

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

AWS Lambda は、ネイティブでは、Java、Go、PowerShell、Node.js、C#、Python、Ruby のコードをサポートしています。また、関数の作成にその他のプログラミング言語を使用できるようにするための Runtime API を提供しています。Node.js、Python、Java、Ruby、C#、Go、PowerShell の使用に関するドキュメントをご覧ください。

それぞれの AWS Lambda 関数は隔離された環境で実行されており、独自のリソースおよびファイルシステムビューを使用しています。AWS Lambda は Amazon EC2 と同じ技術を使用しており、インフラストラクチャおよび実行レベルでセキュリティの提供および分離を可能にしています。 詳細については、ドキュメントをご覧ください。

AWS Lambda は Amazon S3 にコードを保存し、実行時以外は暗号化します。また、AWS Lambda はコードを使用している間に追加の整合性チェックを実行します。データベースのパスワードなどの機密情報については、AWS Key Management Service を使用してクライアント側で暗号化し、この暗号化した値を環境変数に暗号文として格納することをお勧めします。これらの値を復号化するには、AWS Lambda 関数コードにロジックを含める必要があります。 詳細については、ドキュメントをご覧ください。

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

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

はい。任意のコード (フレームワーク、SDK、ライブラリなど) を Lambda Layer としてパッケージ化し、複数の関数間で簡単に管理および共有できます。

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

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

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 には柔軟なデプロイオプションが用意されています。関数を.zip ファイルアーカイブとしてパッケージ化してデプロイし、コンソール、CLI、SDK から直接アップロードすることも、コンテナイメージとしてアップロードすることもできます。どちらの方法も、同じ実行環境、スケーリング、および操作のシンプルさを提供するため、ワークフローに最適なアプローチを柔軟に選択できます。

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

AWS Lambda 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 のドキュメントを参照してください。

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

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

プロビジョニングされた同時実行により、サーバーレスアプリケーションのパフォーマンスをより細かく制御できます。有効にすると、プロビジョニングされた同時実行は、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」という料金ディメンションが追加されます。有効にすると、構成した同時実行の量と構成期間に対して料金をお支払いいただきます。Provisioned Concurrency が設定されている状態で関数を実行すると、リクエストと実行時間に対しても料金が発生します。Provisioned Concurrency 料金の詳細については、「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 サービスの要件および制限を満たしている必要があります。関数のプロパティの更新方法については、こちらをご覧ください。

いいえ。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 によって提供される事前構築済みの標準化されたダッシュボードを使用できます。デベロッパーは手動でインストルメンテーションやコードの変更を行う必要はありません。

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