サポートエンジニアがよく見る AWS Lambda についてのお悩み事

こちらは、Lambda のランタイムを変更した際に一時的に Lambda の処理が止まってしまうのではないか、ということを懸念されてよくお問い合わせいただく質問です。

結論から申し上げますと、ダウンタイムは発生しません。

AWS のドキュメント にも以下のように記載がありますが、通常 1 分未満の移行期間が発生して、この期間に発生したリクエストに関しては新旧いずれかの Lambda 関数が実行されます。

Q: 自作の AWS Lambda 関数は、コードや設定を変更してもそのまま使用できますか?

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

こちらもランタイム関連でよくいただくお問い合わせです。残念ながら自動で更新はされません。

Lambda には 「ランタイム更新モード」というものがあり、「自動」「関数の更新」「手動」のいずれかを選択します。これはデフォルトで「自動」となっています。
ここが「自動」になっていることで、Lambda のランタイムが Python 3.11 から Python 3.12 に自動的に上がるのではないか、というご質問をいただくことがあります。

しかし、Lambda では Python 3.11 から Python 3.12 へのメジャーバージョンの自動更新は行いません。

前提として、Lambda では Python 3.11、Python 3.12 といったランタイムのことを「メジャーバージョン」としています。
また、Python 3.12.v12 などのパッチバージョンを「ランタイムバージョン」としています。なお、ここでいうパッチとは、セキュリティのアップデートやバグ修正、パフォーマンスの強化などを目的にランタイムバージョンに対して差分を反映することを指しています。

そして、「ランタイム識別子」というものがあり、それらはプログラミング言語のメジャーリリースに対応しています。
具体的には、Python 3.11 ランタイムであれば「ランタイム識別子」は python3.11、Python 3.12 ランタイムであれば「ランタイム識別子」python3.12 となります。

この前提を知らないと、ドキュメント の以下の部分を読んで「メジャーバージョンを自動で更新してくれるんだ」と勘違いしてしまう可能性があります。

マネージドランタイムを使用する関数の場合、Lambda はデフォルトでランタイム更新を自動的に適用します。自動ランタイム更新により、Lambda はランタイムバージョンにパッチを適用する運用上の負担を取り除きます。大抵のお客様には、自動更新が最適な選択肢です。このデフォルトの動作は、ランタイム管理設定を構成することで変更できます。

ランタイムバージョンが Python 3.12.v12 などのパッチバージョンを指していることが理解できていれば判断できるかと思いますが、そういった事前知識がないとこのようなご質問をいただくことになるのも仕方がないかなと思います。ですが、これを機に覚えていただければ嬉しいです！なお、Python を例に出しましたが、Node.js や Ruby などのランタイムでも同様です。

そのため、Python などのランタイムのバージョンを変更したい場合には、お客様にて事前に検証をしていただいた上で、「ランタイム設定を編集」の箇所からランタイムを変更していただく必要があります。

ちなみに、「ランタイム更新モード」が「自動」になっている場合にはランタイムバージョンにパッチを適用する運用上の負担を取り除くことができるので、基本的には特に変更せずに自動のままにしておくのが良いでしょう。

こちらもよくいただくご質問です。ドキュメント にも以下の記載がある通り、サポートが切れてしまったランタイムであっても無期限に実行することができます。

ランタイムが廃止された後も、関数を無期限に呼び出すことができます。ただし、AWS は、引き続き関数がセキュリティパッチを受け取り、テクニカルサポートの利用資格を維持するためにも、サポートされているランタイムへの関数の移行を強くお勧めします。

一方で、セキュリティパッチの自動適用はされなくなり、一定期間後には Lambda 関数の更新もできなくなります。そのため、お客様自身でセキュリティパッチを当てることもできなくなります。また、サポートの範囲外となってしまうという大きなデメリットもあるため、よほど特別な事情がない限りは、可能な限り新しいランタイムに変更することを推奨します。

こちらはランタイムを変更したところ、ソースコード上で何らかのエラーが発生した場合にいただくお問い合わせです。
これに関してはいくつか原因があると思いますが、例えば以下のようなことが考えられます。

• 現在使っているライブラリが新しいランタイムに対応していない。

• 現在使っているソースコードの書き方が新しいランタイムでは使えない。

• ランタイムで使っている OS が Amazon Linux 2 から Amazon Linux 2023 に変更されており、もともと Amazon Linux 2 に依存する実装がされている。

上記のような場合にはランタイムを変更した場合にエラーが発生する可能性があります。
そのため、Lambda のランタイムを変更する場合には、「ランタイムの変更によってエラーが発生しないかどうか」を事前にお客様の環境で検証していただき、問題ないと判断した場合にランタイムを変更するようにしていただくことが良いかと思います。

また、ランタイムの変更による下位互換性については保証されていないという点については ドキュメント にも記載がありますのでご一読ください。

Lambda が Lambda API を介して関数を実行する リクエストを受け取ると、Lambda はまず実行環境を準備します。このステップでは、Lambda は関数のコードをダウンロードします。次に、指定されたメモリやランタイムなどを使用して実行環境を作成します。その上で、ソースコードを実行します。

出典: Operating Lambda: パフォーマンスの最適化 – Part 1


上図のように、書かれたソースコードを実行する前の準備段階（上図の青色の部分）を「コールドスタート」と呼びますが、このコールドスタートがあることで、Lambda 関数の実行に想定しているよりも多くの時間がかかるという場合にこのお問い合わせをいただくことがあります。
ご紹介する方法で全て解決できるとは限りませんが、問題を解決する 1 つの方法として「プロビジョニングされた同時実行数の設定」をしていただくことで解決できる可能性があります。
プロビジョニングされた同時実行数の設定を事前に行っておくことで、上図の「Execute initialization code」の部分までの処理をせずに、上図のオレンジ色の「Execute handler code」と書かれた部分、つまり Lambda 関数のハンドラー内に書かれたソースコードを実行する部分から Lambda 関数を実行することができるようになるため、その分実行が早くなるというわけです。

コールドスタート関連ではもう1つ、上記のコールドスタートを意図的に発生させたいけどどうすればいいか、というお問い合わせもたまにいただきます。
コールドスタートが発生したケースと、発生しなかったケースでどのくらい処理にかかる時間に差が出るのかということを検証したい場合などに気になりますよね。

これはシンプルな方法がありまして、マネジメントコンソールにて対象となる関数の「一般設定」にある「説明」を更新いただくことで実現可能です。
Lambda の実行環境は、Lambda 関数の設定変更、もしくはソースコードの変更により破棄されます。そのため、関数の動作に直接の影響がない「説明」を更新いただくことで、関数の動作を変えることなくコールドスタートを発生させることが可能となります。

具体的には「設定」タブから「一般設定」を選択して「編集」ボタンを押すことで説明の編集が可能です。

こちらのお問い合わせは、Lambda のコンソール画面に表示されるトリガーの上限数があるかを確認するために起票されることがあります。また、 Lambda 関数にトリガーを追加しようとしたところ「The final policy size is bigger than the limit」というエラーが発生したという場合でも関連質問としてお問い合わせいただくことがあります。

まず、 Lambda のコンソールに表示されるトリガーについては Lambda 関数のリソースベースのポリシーを参照して表示されています。また、1 つの Lambda 関数に設定できるトリガーの個数については現時点では上限が定義されていません。

一方で、ドキュメント にも記載がある通り、 Lambda 関数のリソースベースのポリシーについては、 20 KBの上限が設定されており、トリガーを追加していくと、いずれこの 20 KB の上限に抵触する可能性が出てきます。

この上限に抵触した場合には「The final policy size is bigger than the limit」のエラーが発生しますが、その場合には re:Post 記事 にもあるように「*」（ワイルドカード) を使用し、重複しているポリシーステートメントを削除することでエラーを回避することを検討してみてください。
なお、上記のワイルドカードを使用したリソースベースポリシーの設定を行った場合には、対象を一意に把握することができないためトリガーは表示されなくなりますが「トリガーの動作そのものに影響はない」という点も知っておくと、なお良いと思います！

Amazon VPC 内のリソースへのアクセスを許可した Lambda 関数 ( VPC Lambda )を利用した Lambda 関数を削除した後に、アタッチしていたネットワークインターフェース (ENI) を削除できないというお問い合わせもよくいただきます。
VPC Lambda を利用している場合には、 Lambda 関数 に ENI が自動でアタッチされますが、この ENI を後で削除しようとしても削除ができない、ということがよく起こります。

これは、他の Lambda 関数で 同じENI を使っているということが原因なので、この状況に遭遇した場合には「他の Lambda 関数で ENI が使われているか」という点をまずは確認しましょう。
ちなみに「他の Lambda 関数で 同じENI を使っている」という状況がなぜ起こるのかというと、こちらのドキュメントにある通り、同じサブネットとセキュリティグループの組み合わせを使用するアカウント内の他の Lambda 関数も、同じ ENI を使用できます。Lambda は可能な限り既存の ENI を再利用して、リソースの使用率を最適化し、新しい ENI の作成を最小限に抑えるようになっているため「他の Lambda 関数で 同じENI を使っている」という状況が発生します。

なお、ENI の使用状況を確認するために使うツールとしては、Lambda ENI Finder があります。Lambda ENI Finder の具体的な利用方法については、こちらの re:Post 記事 をご参照いただき、お客様にて ENI の使用状況をご確認ください。