

AWS LambdaをVPC内に配置する際の注意点
はじめまして。プラットフォーム技術部の山崎です。
オンプレ環境のEOSL対応から始まったAWSリプレースプロジェクトで、インフラ周りの設計構築を担当しています。そこで得たナレッジをご紹介していきます。
今回はAWS LambdaのVPC内ヘの配置についてです。手軽にできるものと思っていたら、環境設定でいくつか考慮すべきことがありましたので、配置する際の注意点をまとめます。
VPC内にLambdaを置くケース
まずはじめに、Amazon Web Serviceの公式見解では、LambdaをVPC内に置くメリットは基本的にないというスタンスです。しかし、Amazon EC2やAmazon RDSなど、VPC内にあるリソースとLambdaで内部通信する場合はVPC内への配置が必要となります。例えば外部公開しないADサーバーとLambdaで認証情報をやりとりする、など。


VPC内に配置する際の注意点
主に5つです。
LambdaをVPC内に配置すると、Lambda実行時にENI(仮想ネットワークインターフェース)が付与されるようになります。それに伴い考慮すべきことがあります。
セキュリティグループの設定
Lambdaに対してセキュリティグループが設定できるようになります。
EC2/RDS等のVPC内リソースのセキュリティグループにて、Lambdaからのアクセスを許可しましょう。設定内容はLambdaのセキュリティグループや、Lambda専用サブネットを作成していたらそのサブネットなど、環境により適切な方法で設定します。
Lambdaのセキュリティグループは必要に応じて設定しますが、API Gatewayなど呼び出し元が特定できない場合はデフォルトのままとすることもあります。
IAMロールの設定
Lambda自身がENIを作成/削除できるようにするため、Lambdaに対してIAM(Identity and Access Management)権限を付与します。既にIAMポリシーとして「AWSLambdaVPCAccessExecutionRole」が用意されているので、Lambda用のIAMロールを作成する際にこのポリシーをあてて設定することも可能です。
所属サブネットの残りのIP
当然ながらVPCサブネットのプライベートIPアドレスを浪費するので、サブネット内の残りのIP数が枯渇しないよう注意してください。AWSのベストプラクティスでは、他のAWSリソースに影響が出ないようLambda専用のサブネットを用意することを推奨しています。冗長化のため、Lambdaも他のAWSリソースと同様マルチAZ(アベイラビリティゾーン)で構成します。
起動スピードが若干遅くなる
Lambda実行時、ENIを作成しLambdaに付与する時間(数秒~数十秒程度)がかかります。
ただし、時間がかかるのは初回のLambda実行時のみで、それ以降は基本的には付与されているENIを使いまわします。Lambda実行リクエストが一定時間なければENIは自動削除されます。
なお、遅延時間分はLambda実行時間にはカウントされないため、その分の料金は計上されません。
- どうしても初回遅延が許容できないというのであれば、定期的にダミーのLambda実行をしてENIを自動削除させない、といった方法も考えられますが、仕組みは自身で構築する必要があります
- VPC外でも、厳密に言うとENI作成ほどではありませんがLambda初回実行時は若干時間がかかります。「コンテナ」と呼ばれるLambda実行環境を作成するためです
外部ネットワークと通信する際は、、、
ここが一番のポイントです。外部ネットワークと通信する際は、NATゲートウェイ等の設定が必要です。VPC内にあるLambda(ENI)にはパブリックIPが付与されないので、外部ネットワークと通信することができません。そのため、VPC内のパブリックサブネットにNATゲートウェイもしくはNATインスタンスを設定します。結果、Lambdaの送信元IP(グローバルIPアドレス)は固定されることになります。
NATゲートウェイの場合は、冗長化を考慮するとAZ毎に設定が必要になるため、NATゲートウェイのコストが2,3倍となることも考えられます。


まとめ
VPC内にLambdaを置く場合は通信関連の考慮が必要になり、場合によってはランニングコストが増えるかもしれません。「お金がかかるのでNATゲートウェイを使用しない」という方針で設計すると、このようなケースでどうしても必要になることもありますので、アプリケーションや認証関連でLambdaを内部通信させる必要があるのか、事前に把握しておくとよいと思います。