Lambda＋固定IP利用におけるデメリット

この記事はAWS LambdaとServerless Advent Calendar 2022 の12日目の記事です。

セキュリティ要件や対向する外部システムの制約でアクセス元を制限するため、固定IP化する必要があります。
せっかく、Lambdaを使ったサーバレス構成でシステムを構築して、リソースと運用を効率化したくても、いくつも制約が生じてしまいます。

VPC Lambdaの制約は解消しつつありますが、非VPCでLambdaを利用して固定IPが利用できるようになるといいなと思い、現状の制約をまとめてみました。

なお、AWS Dev Day Japan 2022で登壇した際の資料に運用中のシステム構成、Lambda＋Neptuneとの組み合わせで発生した問題などを記載しています。また、VPC Lambda + Neptune以外に、資料記載のサービスでは、VPC Lambda + RDS Proxy + Auroraの構成のシステムも運用しています。

VPC Lambda + NAT Gateway

LambdaをVPC内に配置し、NAT GatewayでElastic IPを払い出す必要があります。
LambdaをVPCに配置した場合の制約としては、以下がありましたが、現在は解消されています。

• VPC Lambdaのコールドスタートが遅い：　2019/9のアップデートで解消
• LambdaとRDBMSの相性が悪い問題：　　2019/12の『Amazon RDS Proxy』のリリースにより解消

但し、以下の制約があるため、構成が複雑になります。

• 高可用性を確保するため、複数のアベイラビリティゾーンにVPCを作成し、Lambdaを紐づける必要がある
• 同じく、NAT Gatewayもアベイラビリティゾーン毎に作成する必要がある

また、以下の事象を運用中のサービスで経験しています。
VPC Lambdaが直接の原因かは不明ですが、AWS SDKでの再試行回数やタイムアウトを調整する必要があります。

• VPC LambdaからVPCエンドポイント経由でのAWSサービス、NAT Gateaway+Internet Gateway経由でのインターネットへのアクセスにおいて、ネットワークが不安定（ETIMEDOUT、ECONNRESETが散見される）
• AWS StepFunctionsからのLambdaの非同期実行で空振り発生（VPC Lambda+Neptuneで発生。AWS Dev Day Japan 2022資料参照）

NAT GatewayとVPCのコスト

最も我々が憂慮している問題はコストです。
グラフは運用中のシステムのコストですが、NAT Gatewayのコスト（EC2 その他がNAT Gateway）が全体の約20%、VPCは約15%を占めています。

NAT Gatewayは、時間単位＋データ転送量で課金されます。
NAT Gatewayに紐づけられたElastic IPも、時間単位で課金されます。
VPCも、VPC Privatelinkを使用している場合も時間単位で課金されます。

まとめ

Lambdaを使ったサーバレス構成で、固定IP化した場合のデメリットをまとめました。
VPC＋NAT Gatewayで構成が複雑になり、時間単位での課金のため、トラヒックが少ない時間帯も含め、本来のサーバレス構成で効率化できたはずの、リクエストに応じたComputeの従量課金＋データベースへの課金以外にネットワーク利用に伴う時間単位の固定費が必要になります。

VPC＋NAT Gatewayの構成にすることが目的ではない場合に、不要な制約やコストがかからないようなアップデートが出てくるといいなと思います。