まず、requireを必要とするかを理解することです。 NodeJSで動作します。この
これで、接続が必要になると、永久に接続が可能になり、再度必要になることはありません。毎回新しい接続を作成してデータベースを圧倒したくないので、これは探しているものと一致します。
しかし、問題があります...
ラムダコールドスタート
Lambda関数を初めて呼び出すと、関数が含まれているコンテナーが起動し、約5分間存続します。一度に1つのリクエストを行う限り、毎回同じコンテナにヒットする可能性が非常に高くなります（保証はされませんが）。しかし、同時に2つのリクエストがある場合はどうなりますか？次に、別のコンテナが、以前のウォームアップされたコンテナと並行してスピンアップされます。データベースに別の接続を作成したところ、2つのコンテナがあります。さて、3つの同時リクエストがあるとどうなるでしょうか？はい！もう1つのコンテナ。これはもう1つのDB接続に相当します。
Lambda関数への新しいリクエストがある限り、デフォルトでは、需要を満たすようにスケールアウトされます（アカウントの制限を尊重して、実行を必要な数の同時実行に制限するようにコンソールで構成できます）
単に要求するだけでは、データベースへの接続が一定量であることを安全に確認することはできません。 関数の呼び出し時のコード。良いことは、これがあなたのせいではないということです。これがLambda関数の動作です。
...もう1つのアプローチは
ElasticCache などの実際のキャッシュシステムに必要なデータをキャッシュするには 、 例えば。次に、1つのLambda関数をCloudWatchイベント それは特定の時間の頻度で実行されます。次に、この関数はDBにクエリを実行し、結果を外部キャッシュに保存します。このようにして、DB接続が一度に1つのLambdaによってのみ開かれるようにします。これは、CloudWatchイベントを尊重し、トリガーごとに1回だけ実行されることが判明したためです。
編集 ：OPがコメントセクションにリンクを送信した後、言及された記事が言いたいことを明確にするために、さらにいくつかの情報を追加することにしました
記事から：
そして、これはまさにあなたがしていることです。そしてこれはうまくいきます！ただし、問題は、同時にN個の接続（ラムダリクエスト）がある場合です。制限を設定しない場合、デフォルトでは、最大1000個のLambda関数を同時にスピンアップできます。これで、次の5分間にさらに1000のリクエストを同時に行うと、以前の呼び出しですでに開かれていて、コンテナがまだ生きているため、新しい接続を開かない可能性が非常に高くなります。