私はラムダ関数を2つ持ち、これらの関数はすべて共通の関数を持っています。それは一般的なので、コードの大部分はその共通の機能にあります。したがって、その特定の関数に対して別のラムダ関数を考えることは論理的です。AWSラムダサービスの他のラムダからラムダを呼び出すことは良い考えですか？
しかし、それは私が費用の将来について考えるとき私を落胆させた。つまり、あるラムダを呼び出すと、自動的に別のラムダが呼び出されます。したがって、1つのイベントで2つの異なるリソースが雇用されます。私は費用対効果がないようです。そうですか？
これはいつも行われています。私はラムダをさまざまな要因に基づいて呼び出す追加のラムダを決定的に実行するスケジュールを立てていました。
しかし、共通の「機能」が何をしているのか、それがコストだけでなくパフォーマンスにもどのように影響するのかを覚えておく必要があります。
サーバーレスのアプリケーションやアプリケーション内のサーバーレスコンポーネントを設計する際には、2つの主な考え方があります。 AWSラムダ、アズール関数、Googleクラウド関数などを、マイクロサービスに本当に「マイクロ」を入れる「1つの関数」ソリューションと考えることができます。または、ラムダを関数の論理的なグループとして使用することができます（私はまだあなたのアプリの1つの関数と考えています）。両方とも完全に有効なアプローチであり、おそらくデバッグ中の頭痛の軽減につながります。）
複数のLambdaに共通の機能を持っている場合は、別のLambdaに到達する前にコード内で処理することを検討してください。それはパッケージやライブラリのようなものです。たとえばNode.jsでは、NPMを使用してその共通関数をインポートするだけで、1つの場所から保守して、必要に応じて何かを更新することができます。
文字通り「クラウド関数」を使用せず、すべての関数を新しいラムダに分割しないようにしてください。
ラムダには最低100万円に切り上げられるため、最低料金が発生することに注意してください。だから、あなたが本当に速く走るいくつかの共通の機能を呼んでいるなら、私はそれを新しいラムダに分けません。あなたはもっとお金を払うつもりですが、あなたのパフォーマンスもまた妨げられます。
あなたの走行距離は他にも変わります。クラウド機能は、まったく新しい次元を考えてくれます。彼らは非常に便利ですが、慎重に計画されていなければ、実際にパフォーマンスを低下させ、コストを増加させる可能性があります。