ある大規模なSaaSプロバイダーが、Lambda関数で10万種類のテナント設定をJSON形式（合計サイズ約800 MB）でS3に保存しており、Lambda起動時に全設定ファイルをS3からダウンロードして初期化している。その結果、コールドスタートに40〜60秒かかっており、Lambdaのタイムアウト（デフォルト3秒）で頻繁に失敗している。コードの変更を最小限にしてコールドスタートを10秒以内に抑え、かつ月次コストを現状より増加させないアーキテクチャ変更として最も適切なものはどれか。

正解: A

根本的な問題は「起動時に800 MBの設定全量をロードしている」という設計にある。実際の処理では特定のテナントIDに対応する設定だけが必要であるため、DynamoDBに移行してGetItemで必要なアイテムだけを取得するように変更することで、初期化コストを劇的に削減できる。DynamoDBのGetItemはミリ秒単位で応答し、オンデマンドモードなら未使用時のコストはゼロである。選択肢B（/tmpキャッシュ）は2回目以降のコンテナ再利用時には有効だが、コンテナ再利用はLambdaが保証するものではなく、特にコールドスタート（新規コンテナ起動）では毎回800 MBのダウンロードが発生する。問題文の「コールドスタートに40〜60秒」という問題の根本解決にならない。選択肢Dのメモリ増量は処理速度を改善するが、800 MBのダウンロードそのもののボトルネックはネットワーク帯域にあるため、10秒以内という目標を達成できるかは保証できず、メモリコストも増大する。選択肢CのLambdaレイヤーはデプロイ時に/opt以下に展開されるが、1つのレイヤーは最大250 MB（展開後）という制限があるため800 MBのデータを格納できない。