実行環境/ライフサイクル難易度 標準無料
開発者が実装したLambda関数は、呼び出しのたびにハンドラー内でDB接続クライアントとAWS SDKクライアントを新規生成しており、トラフィックが多い時間帯にレイテンシとDB接続数の増大が問題になっている。呼び出し間で再利用可能なリソースを再利用し、パフォーマンスを改善する実装として最も適切なものを選べ。（単一選択）
- ADB接続クライアントとSDKクライアントの初期化コードをハンドラー関数の外（グローバルスコープ）に移動し、実行環境がウォーム状態で再利用される際にそのまま再利用されるようにする
- Bハンドラー関数内で毎回新しいクライアントを生成する実装のまま、関数のメモリ割り当てだけを増やしてCPU性能を上げる
- C関数のタイムアウト値を最大の15分に設定し、1回の呼び出しの中でより多くの処理時間を確保できるようにする
- D関数をVPCから切り離し、パブリックサブネットからのみアクセスできるように再設計する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
Lambdaの実行環境（execution environment）はInit・Invoke・Shutdownの3フェーズからなるライフサイクルを持つ。 コールドスタート時にInitフェーズでランタイムの初期化・拡張機能の初期化・ハンドラーファイルのグローバルスコープのコード実行が行われ、 その後に実行環境は一定時間（ウォーム状態）維持され、後続の呼び出しで再利用される。
- DB接続クライアントやAWS SDKクライアントをハンドラー関数の外（グローバルスコープ）で初期化しておくと、 Initフェーズで一度だけ生成され、後続のウォーム実行では再生成せずにそのまま再利用される。
- これによりウォーム実行時のレイテンシが下がり、DBへの新規接続確立回数も抑えられ、接続枯渇のリスクを軽減できる。
- ハンドラー関数内で毎回生成すると、ウォーム実行であっても呼び出しのたびに接続確立コストが発生し、この最適化の恩恵を受けられない。
- Bメモリ増加でCPU割当は上がるが、毎回接続を生成するロジック自体は変わらず、接続確立コストとDB接続数増大の根本原因は解消しない。
- Cタイムアウト値は1回の呼び出しあたりの最大実行時間の上限を変えるだけで、呼び出しごとの接続再生成という問題には無関係。
- DVPC設定の有無は接続クライアントの再利用戦略とは別軸の話であり、ハンドラー内での再生成という実装上の問題を解決しない。
ひっかけ： 「コールドスタートを完全になくす」ことと「ウォーム実行時の再利用を最適化する」ことは別の話。本問は実行環境の再利用（execution context reuse）を活かす実装パターンが論点であり、
プロビジョンド同時実行（コールドスタート自体の排除）とは区別すること。
公式ドキュメント・関連AWS Lambda Developer Guide ― Lambda execution environment↗AWS Lambda Developer Guide ― Best practices for working with AWS Lambda functions↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）