AWS ラムダでセキュリティ関連の問題が発生していますが、これを解決する正しい方法がわかりません。
別の EC2 インスタンス B のデータベースにアクセスする EC2 インスタンス A を考えてみます。インスタンス B の DB へのアクセスをインスタンス A のみに制限したい場合は、セキュリティ グループを変更し、カスタム TCP ルールを追加して、インスタンス A のパブリック IP。したがって、AWS がすべてを処理し、DB サーバーは他の IP アドレスからアクセスできなくなります。
インスタンス A をラムダ関数に置き換えます。インスタンスではないため、明確な IP アドレスはありません。では、ラムダ関数のみへのアクセスを制限し、他のトラフィックをブロックするにはどうすればよいでしょうか?
Lambda ジョブで IP を決定し、インスタンス B のセキュリティ グループを動的に更新し、完了したらセキュリティ グループをリセットします。
VPC 内で実行される Lambdaがサポートされるまでは、これが唯一のオプションです。そのサポートは、今年後半に発表されました。以下の引用は、上記の参照リンクからのものです。
多くの AWS のお客様は、Amazon Virtual Private Cloud 内でマイクロサービスをホストしており、Lambda 関数からそれらにアクセスできるようにしたいと考えています。おそらく、ルックアップ データを使用して MongoDB クラスターを実行するか、Amazon ElastiCache を Lambda 関数のステートフル ストアとして使用したいが、これらのリソースをインターネットに公開したくないでしょう。
ターゲット VPC 内に 1 つ以上のセキュリティ グループを設定し、Lambda からのインバウンド トラフィックを受け入れるように設定し、それらをターゲット VPC サブネットにアタッチすることで、このタイプのリソースにすぐにアクセスできるようになります。次に、Lambda 関数を作成するときに、VPC、サブネット、およびセキュリティ グループを指定する必要があります (それらを既存の関数に追加することもできます)。また、Elastic Networking に関連するいくつかの EC2 関数にアクセスするためのアクセス許可を (その IAM ロールを介して) 関数に付与する必要があります。
この機能は、今年後半に利用可能になる予定です。ローンチ時に詳細情報 (およびウォークスルー) を提供します。