実行環境/ライフサイクル（VPC内Lambdaのネットワーキング）難易度 高無料
開発者が「VPC内で動作するLambda関数は、呼び出しのたびに新しいENI（Elastic Network Interface）をアタッチ・デタッチするため、VPC外の関数に比べて常に大きなコールドスタート遅延が発生し続ける」と主張している。この主張の妥当性について最も適切な説明を選べ。（単一選択）
- A現行のVPC Lambdaは、同一のサブネット/セキュリティグループの組み合わせを持つ実行環境間でENIを共有・再利用する仕組み（共有ENIプール）を採用しており、呼び出しのたびに新規ENIを作成するわけではないため、ENI起因のコールドスタート遅延は大幅に軽減されている
- B開発者の主張どおり、VPC内Lambdaは現行の仕様でも呼び出しのたびに新しいENIを作成・アタッチしており、常に大きなコールドスタート遅延が発生し続ける
- C共有ENIプールの導入により、VPC内Lambdaのコールドスタート遅延は完全にゼロになり、VPC外の関数と全く同じ初期化時間になった
- DENIの共有・再利用の仕組みにより、VPC内LambdaはNATゲートウェイを経由しなくても直接インターネット上のリソースへアクセスできるようになった
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
2019年以前は、VPC内Lambdaはセキュリティグループ/サブネットの組み合わせごとに呼び出し時にENIを都度作成する設計であり、 これが大きなコールドスタート要因になっていた。しかし現行のVPC Lambdaのネットワーキングモデル（Hyperplane ENIによる共有ENIプール）では、 同一のVPC設定（サブネット・セキュリティグループの組み合わせ）を持つ実行環境間でENIが共有・再利用されるようになっている。
- 同じVPC設定の関数・実行環境がスケールしても、呼び出しのたびに新規ENIを作成するわけではなく、共有ENIプールから割り当てるため、 ENI作成に起因するコールドスタート遅延は大幅に削減されている。
- ただし、そのVPC設定（サブネット/セキュリティグループの組み合わせ）に対する初回のENI準備や、 関数自体の初期化（ランタイム初期化・ハンドラーのグローバルスコープ処理）に起因するコールドスタートは依然として発生し得る。
- また、ENIはプライベートIPのみを持つため、VPC内Lambdaがインターネット上のリソースへアクセスするには NATゲートウェイ等を経由するルーティング設計が別途必要である点は変わらない。
- B古いモデル（2019年以前）の説明であり現行仕様と異なる。現行は共有ENIプールによりENI起因のコールドスタートは大幅に軽減されている。
- C過大な解釈。ENI起因の遅延は大幅に軽減されたが、ランタイム初期化やハンドラーのグローバルスコープ処理に起因するコールドスタートは依然として発生し得る。
- DENI共有はコールドスタート対策の仕組みであり、ネットワーク経路の設計とは別の話。ENIはプライベートIPのみを持つため、インターネットアクセスには依然としてNATゲートウェイ等の経路設計が必要。
ひっかけ： 「VPC内Lambdaは呼び出しのたびに必ずENIを新規作成する（B）」は現行の仕組みでは正しくない古い前提に基づく誤解。
共有ENIプールの導入によりENI起因のコールドスタートは大幅軽減されたが、「コールドスタートが完全にゼロになる」わけではない点（C）も過大解釈であり両極端な選択肢に注意する。
公式ドキュメント・関連AWS Compute Blog ― Improved VPC networking for AWS Lambda functions↗AWS Lambda Developer Guide ― Configuring a Lambda function to access resources in a VPC↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）