amazon-web-services - permission - lambda policy cloudwatch




AWSラムダ呼び出しが別のラムダ関数を呼び出さない-Node.js (2)

関数を呼び出すためのすべての権限を付与した後。 私のLambda関数は別の関数を呼び出すことができません。 タイムアウトが 30 seconds timeout たびにタイムアウトが発生します。 ラムダは別のラムダ関数を取得できないようです

私のラムダは同じリージョン、同じポリシー、同じセキュリティグループにあります。また、VPCは両方のラムダで同じです。 唯一の違いは、ラムダ関数です

ここに役割の権利があります

1) AWSLambdaExecute および AWSLambdaBasicExecutionRole 作成し AWSLambdaBasicExecutionRole

2) Lambda_TEST と呼ばれる1つのラムダ関数を作成し ました

exports.handler = function(event, context) {
  console.log('Lambda TEST Received event:', JSON.stringify(event, null, 2));
  context.succeed(event);
};

3)ここに、別の関数を呼び出します。

var AWS = require('aws-sdk');
AWS.config.region = 'us-east-1';
var lambda = new AWS.Lambda();

exports.handler = function(event, context) {
 var params = {
   FunctionName: 'Lambda_TEST', // the lambda function we are going to invoke
   InvocationType: 'RequestResponse',
   LogType: 'Tail',
   Payload: '{ "name" : "Arpit" }'
 };

  lambda.invoke(params, function(err, data) {
   if (err) {
    context.fail(err);
   } else {
   context.succeed('Lambda_TEST said '+ data.Payload);
  }
 })
};

参照元: このリンク


注意

2番目の lambda を実行する lambda エグゼキュー ターで示します。

タイムアウトする理由

エグゼキューター VPC 背後で「ロック」されているため、すべてのインターネット通信がブロックされます。

その結果、パケットが宛先に到達しないように要求するため、 http(s) 呼び出しはタイムアウトになります。

そのため、 aws-sdk によって実行されるすべてのアクションがタイムアウトになります。

シンプルなソリューション

executor VPC にある 必要 がない場合-単にそれを出すだけで、 lambdaVPC なしでも同様に機能します。

lambdaVPC 内のリソースを呼び出す場合、 VPC lambda を見つける必要があります。

実際のソリューション

上記のことから、 VPC 内にあるリソースはすべてインターネットにアクセスできません- これは正しくありません -必要な設定はほとんど ありません

  1. VPC 作成します。
  2. 2つの サブネットを 作成し、1つを プライベート 、2つ目の パブリックを指定します (これらの用語については先に説明しますので、読み続けてください)。
  3. インターネットゲートウェイを 作成する-これは、 VPC をインターネットに接続する仮想ルーターです。
  4. NATゲートウェイを 作成し ます - パブリック サブネットを選択し、新しい elastic IP を作成します(このIPは VPC に対してローカルです)-このコンポーネントは、通信を internet-gateway パイプし internet-gateway
  5. 2つの ルーティングテーブルを 作成します。1つは パブリック 、もう1つは プライベート です。

    1. パブリック ルーティングテーブルで、[ ルート] に移動し、新しい ルート を追加します。

    宛先:0.0.0.0/0

    ターゲット: internet-gateway ID

    1. プライベート ルーティングテーブルで、[ ルート] に移動し、新しい ルート を追加します。

    宛先:0.0.0.0/0

    ターゲット: nat-gateway ID

    • プライベート サブネットは、ルーティングテーブルにあるサブネットです- internet-gateway ルート はありません

    • パブリック サブネットは、ルーティングテーブルにあるサブネットです- internet-gateway へのルートが 存在 internet-gateway

ここにあったものは?

次のようなものを作成しました。

これにより、 プライベート サブネットのリソースがインターネットを呼び出すことができます。 より多くのドキュメントを here 見つけることができます。


VPCに「固定」されているLambdaが他のLambdaを呼び出すことができないという同じ問題を経験しました。 私はソリューションの構造をリファクタリングすることで、NATを使用せずにこの問題に取り組んできました。

いくつかのラムダ、A、B、C、D、...があり、これらのラムダにそれぞれRDSデータベースへのクエリアクセスを持たせたいとします。 このDBにアクセスするには、データベースと同じVPCにラムダを配置する必要があります。 しかし、A、B、C、D、...の間のさまざまなラムダも互いに呼び出したいと思います。 だから、私はArpitが説明する問題に出くわします。

各Lambdaを2つのLambdaに分割することでこの問題に対処しました。1つはプロセスフローに焦点を当てています(つまり、他のラムダを呼び出し、別のラムダによって呼び出されます)。 もう1つは、データベースのクエリなど、「実際の」作業に焦点を当てています。 それで、関数A_flow、B_flow、C_flow、D_flow、...ができました。 関数A_worker、B_worker、C_worker、D_worker、...さまざまなフローラムダは特定のVPCに「固定」されていないため、他のラムダを呼び出すことができます。 さまざまなワーカーLambdaはデータベースと同じVPCにあり、DBにクエリを実行できます。

各フローラムダは、DBと対話する作業を対応するワーカーラムダに「委任」します。 ワーカーラムダの同期呼び出しを実行することにより、この委任を行います。 ワーカーラムダは、他のラムダを呼び出しません。 (プロセスフローグラフの観点では、ワーカーラムダはターミナルノードです。)私自身のシステムでは、他のフローラムダによるフローラムダの呼び出しは一般に非同期です。 ただし、必要に応じて同期することもできます。

回避策としてこのアプローチを考案しましたが、高レベルの機能設計を(a)プロセスフローと(b)DBリソースとの対話を含むより詳細な作業を明確に分離するという優れた機能があります。





amazon-iam