LambdaをVPCに繋ぐと「なぜか外に出られない」「DBのコネクションが枯れる」といった相談が増えます。Hyperplane ENIの仕組みを押さえれば、これらは設計で回避できます。ENI・NAT・VPCエンドポイント・RDS Proxyの勘所を一次情報に沿って整理します。

「Lambdaは何もしなくてもインターネットに出られる」——これはVPCに繋いでいないときの話です。RDSやElastiCacheといったVPC内リソースにアクセスするためにLambdaをVPCへ接続した瞬間、この前提は崩れます。本記事では、VPC Lambdaの土台であるHyperplane ENIの仕組みから、コールドスタートへの影響、privateサブネット必須の理由、NATとVPCエンドポイントの使い分け、そしてDB接続（RDS Proxy）まで、現場で詰まる箇所を順に整理します。

01まず前提：Lambdaは2つのVPCを行き来する

すべてのLambda関数は、Lambdaサービスが所有・管理するVPCの中で実行されます。これは顧客からは見えないVPCで、既定ではインターネットへの経路を持っています。関数にVpcConfigを設定して自社VPCへ「接続」すると、Lambdaはその自社VPC側にネットワークインターフェイスを用意し、実行環境からそのインターフェイスへトンネルを張る形になります。

ここで重要なのは、VPCに接続した関数はLambda管理VPC経由の既定インターネット経路を失うという点です。以降の通信は、すべて接続先の自社VPCのルーティングに従います。「今まで外部APIを叩けていたのに、VPCに繋いだら急にタイムアウトするようになった」という相談の大半は、この一点に集約されます。

現場のコツ：VPC接続は「DBに繋ぐため」の設定であって「外に出るため」の設定ではありません。VPCに入れる＝インターネットから隔離される、と最初に頭を切り替えておくと、後段のNAT設計で迷いません。
Lambdaサービスの管理VPC 実行環境 (関数コード) 顧客VPC（自社アカウント） Hyperplane ENI private subnet RDS / ElastiCache VPCエンドポイント NATゲートウェイ public subnet トンネル → インターネット
図：VPC Lambdaの通信経路。実行環境はHyperplane ENIを介して顧客VPCに入り、そこからDB・VPCエンドポイント・NATへ分岐する。

02Hyperplane ENIとは何か

LambdaがVPC接続のために作るネットワークインターフェイスを、AWSはHyperplane ENIと呼びます。これは通常のENIとは性質が異なる、Lambdaサービスが自動で作成・管理するマネージドリソースです。ポイントは次の通りです。

この「組み合わせ単位で共有」という設計は地味に効きます。同じ用途の関数群を同じサブネット・同じSGに揃えると、ENIの本数が抑えられ、新規作成に伴う待ち時間も減ります。逆に関数ごとにバラバラのSGを割り当てると、ENIが乱立します。

03コールドスタートへの影響と、その正体

「VPC Lambdaはコールドスタートが遅い」という評判は、2019年以前の古い挙動を指していることが多く、現在はかなり事情が違います。以前はENIの作成・アタッチが関数の呼び出しパス上で行われていたため、コールドスタート時に十数秒かかるケースがありました。AWSの公式ブログでは、この改善によって実行時間が14.8秒から933ミリ秒へ短縮した例が示されています。

現在のHyperplaneアーキテクチャでは、ENIの作成は関数の作成時またはVPC設定の更新時に済ませてしまいます。呼び出し時は既存のENIへトンネルを張るだけなので、VPC接続そのものによるコールドスタートのオーバーヘッドは大幅に小さくなりました。

現場のコツ：今どきの「VPC Lambdaの遅さ」の主因は、ENIではなく関数コード側の初期化（DB接続確立、大きな依存ライブラリのロード、シークレット取得）であることがほとんどです。まずはX-Rayやログで初期化フェーズの内訳を測ってから対策を打ちましょう。設計・運用の全体像はLambda本番運用の実践も参照してください。

04見落としがちなENIのライフサイクル

Hyperplane ENIには、設計に影響するライフサイクル上の注意点があります。数値や時間はバージョン依存のため公式で最新を確認いただくとして、傾向として押さえておきたいのは次の3点です。

ドキュメントも明記していますが、設計上ENIの永続性に依存しないことが前提です。IaCで関数を頻繁に作り直す運用では、これらの待ち時間を織り込んでおきましょう。

05privateサブネット必須の理由と、外部通信の作り方

VPC LambdaはprivateサブネットにアタッチするのがAWSの推奨であり、実質的な必須要件です。ここでよく誤解されるのが「publicサブネットに置けばインターネットに出られるのでは？」という発想です。答えはNoです。公式ドキュメントも「関数をpublicサブネットに接続してもインターネットアクセスやパブリックIPは付与されない」と明記しています。

Hyperplane ENIにはパブリックIPが割り当てられないため、Internet Gatewayへの直接経路があっても戻りの通信が成立しません。VPC Lambdaを外部に出す唯一の正攻法は、privateサブネットに置き、NATゲートウェイ経由でegressすることです。構成要素は次の通りです。

疎通確認は、関数からhttps://aws.amazon.com/などへHTTP GETして200が返るか、あるいはTask timed outになるかで判定できます。タイムアウトするなら、まずルートテーブルとNATを疑ってください。NAT自体のコスト設計はNATゲートウェイのコスト設計が詳しいです。

06NATに全部流すな：VPCエンドポイントの使い分け

NATゲートウェイを置くと外に出られますが、AWSサービス宛の通信までNAT経由にすると、処理データ量に応じた課金が積み上がります。VPC Lambdaが叩く先がS3・DynamoDB・SQS・Secrets Manager・KMSといったAWSサービスに限られるなら、VPCエンドポイントを使ってトラフィックをAWSネットワーク内に閉じ込めるのが定石です。NATの請求から外れ、経路もシンプルになります。

実際、Secrets Managerから資格情報を取得する構成では、VPC LambdaはSecrets ManagerのインターフェイスVPCエンドポイントが必要です（AWSのRDS Proxyチュートリアルでも明記されています）。判断軸は次の決定表で整理できます。

現場のコツ：「S3ゲートウェイエンドポイントだけ入れてNATに流し続けている」パターンが最も多いです。Secrets ManagerやKMSはインターフェイスエンドポイント化するとNATの処理量課金が目に見えて減ります。ただしインターフェイスエンドポイントにも時間・処理量課金があるので、トラフィックが少ない小規模環境ではNAT併用のほうが安いこともあります。数値は公式の料金ページで最新を確認してください。エンドポイント越しの名前解決を有効にするため、enableDnsSupport／enableDnsHostnamesとプライベートDNSの設定も忘れずに。

07DB接続の勘所：なぜLambda＋RDSはRDS Proxyなのか

VPC Lambdaから直接RDS/Auroraに繋ぐと、コネクション枯渇という古典的な問題に当たります。Lambdaは同時実行数ぶんだけ実行環境が並列に立ち上がるため、各環境が個別にDB接続を張ると、瞬間的にDBの最大接続数を食い潰します。トラフィックのスパイクでDBがtoo many connectionsを返す、という事故はこれが原因です。

ここでRDS Proxyが効きます。RDS ProxyはLambdaとDBの間に立ち、コネクションプールを保持・再利用します。多数のLambda実行環境からの接続を、少数の実DB接続に集約してくれるわけです。AWS公式のチュートリアルも、LambdaからRDSへ書き込む構成をRDS Proxy経由で組んでいます。実装上の勘所は次の通りです。

RDS Proxyの詳細な設定・フェイルオーバー挙動はRDS Proxyによるコネクション管理で、DB自体の選定はAuroraとRDSの選定で掘り下げています。

08よくある詰まりチェックリスト

現場で繰り返し遭遇する詰まりを、切り分け順に並べます。

アカウント横断でVPC設定を統制したい場合は、IAM条件キー（lambda:VpcIds / lambda:SubnetIds / lambda:SecurityGroupIds）でガードレールを敷けます。「全関数を特定VPCに強制」「特定サブネットを禁止」といった制御が可能です。組織的な統制はマルチアカウント統制もあわせてご検討ください。

—まとめ

VPC Lambdaは「DBに繋ぐための設定」であり、その瞬間にインターネットへの既定経路を失います。Hyperplane ENIはサブネット＋SGの組み合わせ単位で共有され、現在はコールドスタートへの影響も小さい——ただしPending/Inactiveといったライフサイクルは設計に織り込む必要があります。外部通信はprivateサブネット＋NAT、AWSサービス宛はVPCエンドポイントで振り分け、DB接続はRDS Proxyでコネクション枯渇を抑える。この4点を押さえれば、VPC Lambdaの設計は堅くなります。数値・料金・上限はバージョン依存のため、実装時は必ず公式ドキュメントで最新を確認してください。実際の設計・移行でお困りの際は導入事例もご覧いただき、お問い合わせください。

—参考(一次情報)

VPC LambdaとDB・外部連携の設計でお困りなら、お問い合わせください。既存VPC構成を踏まえた現実的な設計をご一緒します。

相談する
← ブログ一覧へ戻る