AWS LambdaとSnapStart
AWS Community Builders Serverlessカテゴリの端くれの@Kanahiroです。2024年にこんな記事を寄稿させていただいたくらいにはAWS Lambdaのことをコンテナを動かす何かだと思っています
2026-09-02、ついにコンテナイメージのLambdaでもSnapStartが利用可能となりました
SnapStartのうれしみ
AWS Lambdaのコールドスタートは有名な話ですが、コンテナイメージを動かす際、体感ですがだいたい2秒くらいのコールドスタートが発生します。我慢出来なくはないですが、リクエストスパイク時にはもう少し速く動いて欲しい感じです。
SnapStartはいわゆる「INITフェーズ」完了時の状態をキャッシュするので、以後の実行時にはINITフェーズをスキップすることが出来ます（厳密にはそこまでの代物ではないことが後でわかる）。なのでコールドスタートの短縮が見込まれます。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtime-environment.html
料金
SnapStartは追加課金が発生する機能です。計算式の説明などはややこしいので以下のクラメソさんのすばらしい記事を参照してください。
やってみる
コンソールでSnapStartを選択可能になっているので、PublishedVersionsを選択すればよさそうです。
設定前
X-Rayでフェーズごとの所要時間を見てみると、INITフェーズで~1000ms程度を要していました（複数の結果を観測した値）。コールドスタートの体感2秒ともそこそこ整合しています。
設定後
コンテナイメージでSnapStartを活用するために、以下の手順が必要でした
- SnapStartを有効化する
- バージョンを発行する
- AWS管理のコンテナイメージではなかったので、Dockerfileに
LABEL com.amazonaws.lambda.feature.snapstart="Allow"を追記
以上により、INITフェーズがRESTOREフェーズに置き換わるようになりました。
所要時間は200ms~700msの範囲で、400msくらいが平均になりそうでした。つまりすごくざっくり500msくらい短縮されるかもしれない感じです。INITフェーズの時間をまるまるスキップできるということではなく、キャッシュを読み出すRESTOREフェーズに置き換わる、ということのようです。ほぼ体感値みたいな数値ですし、環境によって結果は異なるでしょうが、SnapStartがどれくらいのものなのかは参考になりそうです。SnapStartは追加料金の発生する機能ですから、費用対効果がどれくらいかは考えて有効化すべきです。
終わりに
ついに来た、という感じです。というのは、Lambdaのインスタンスの起動時に一度だけ実行したい準備のような処理というはよくあるためです。コンテナイメージでも、SnapStartをうまく使って独自の初期化処理をINITフェーズ内で終わらせるようなテクニックを利用してパフォーマンス向上を狙っていきましょう。