AWS Lambdaのコールドスタートが「遅延の問題」から「コストの問題」に変わった。2025年8月、AWSがINITフェーズを課金対象に変更したことで、放置すればクラウドコストが静かに膨らむ。SnapStartだけでJavaの起動遅延を2,000msから200msへ削減できる。ARM64への切り替えでコストは最大34%下がる。何をどの順番でやるか、優先度順に整理した。
AWS Lambdaのコールドスタートとは?2025年8月から課金が変わった理由
AWS Lambdaは、一定時間リクエストがないと実行環境(コンテナ)を破棄してゼロの状態に戻る。これがスケール・トゥ・ゼロアーキテクチャだ。次のリクエストが来たときに環境をゼロから立ち上げる処理を「コールドスタート」と呼ぶ。
コールドスタートのINITフェーズでは、次の3つの重い処理が順番に実行される。
2025年8月の課金仕様変更:ZIPベースのマネージドランタイムでは、従来は無課金だったINITフェーズがGB-秒として課金対象になった。コールドスタートは全呼び出しの1%未満でしか発生しないが、高トラフィック環境では無視できないコスト要因に変わった。
ランタイム別コールドスタート時間の比較【2026年最新】
選択するプログラミング言語が、コールドスタート時間を決定的に左右する。下表はp50(中央値)の目安だ。
| ランタイム | p50遅延 | 2026年の状況 |
|---|---|---|
| Rust / Go | 50〜100ms | 最速。パフォーマンス最優先のAPI基盤に最適 |
| Python 3.12/3.13 | 200〜400ms | SnapStart対応拡大で大幅改善が期待できる |
| Node.js 22/24 | 200〜400ms | Node.js 20は2026年8月以降に新規作成ブロック |
| Java 21(SnapStartなし) | 2,000〜5,000ms | JVM起動コストが致命的。SnapStart適用が必須 |
Node.js 20ユーザーへの警告:2026年4月30日に標準サポートが終了し、同年8月31日以降は新規Lambda関数の作成がブロックされる。Node.js 24ではコールバックベースのハンドラが廃止されているため、コードのリファクタリングも必要だ。移行計画を今すぐ立ててほしい。
最強の解決策「Lambda SnapStart」を今すぐ有効にする
Lambda SnapStartは、Firecracker microVMのメモリとディスクの状態をスナップショットとしてキャッシュし、コールドスタート時にゼロから起動せずスナップショットをリストアする技術だ。重いINITフェーズをほぼスキップできる。
| ランタイム | 通常のコールドスタート | SnapStart適用後 | 削減率 |
|---|---|---|---|
| Java 21 | 約2,000ms | 約200ms | 約90%削減 |
| Python 3.12+ | 約500ms | 約200ms | 約60%削減 |
| .NET 8+ | 約1,500ms | 約400ms | 約73%削減 |
2024年末にPython 3.12以上・.NET 8以上への対応が拡大された。追加コストは10万コールドスタートあたり約$18/月と極めて低く、ROIは圧倒的に優れている。
SnapStart導入時の2つの注意点:
- 初期化時に生成したUUIDや乱数シードがスナップショットに固定化され、一意性を保証できなくなるリスクがある。AWSが提供するRestoreフックで状態を再初期化すること
- リストア時にDB接続(TCP)が切断状態になっている可能性があるため、ハンドラ内で接続の有効性を確認・再接続するロジックが必須
SnapStart vs Provisioned Concurrency:どちらを選ぶべきか?
コールドスタートを100%排除できるProvisioned Concurrency(プロビジョニングされた同時実行)という選択肢もある。ただしコストが大きく異なる。
| SnapStart | Provisioned Concurrency | |
|---|---|---|
| コールドスタート削減 | 最大90%削減 | 100%完全排除 |
| 月額コスト(目安) | 約$18 / 10万回 | 約$150 / 月(512MB×10並列) |
| 課金タイミング | コールドスタート時のみ | 待機中も時間課金 |
| 適用すべき場面 | ほぼすべてのWeb API・非同期処理 | P99遅延500ms以内のSLAが絶対条件 |
決済システムやリアルタイム通信など、p99レイテンシに極めて厳格なSLAが要求されるケース以外はSnapStartで十分だ。コスト効率の観点でSnapStartを基本戦略とし、Provisioned Concurrencyは最終手段として使おう。
インフラ・コードレベルの実践的な対策3選
① ARM64(Graviton2)に切り替える
x86_64からARM64に変更するだけで、価格パフォーマンスが最大34%向上し、初期化時間が15〜40%短縮される。コンパイル依存のネイティブライブラリがなければ設定変更のみで完了する。コードを1行も書かずに得られる改善としては最大級だ。
② 初期化コードをグローバルスコープに移動する
SDKクライアントの初期化やDB接続確立は、ハンドラ関数の外側(グローバルスコープ)で行う。コールドスタートのINITフェーズで一度だけ実行され、ウォームスタート時はメモリ内のインスタンスが再利用される。
// ✅ グローバルスコープで初期化(ウォームスタート時に再利用)
const dynamodb = new DynamoDB.DocumentClient();
const ssm = new SSM();
exports.handler = async (event) => {
// dynamodbはすでに初期化済み → ウォームスタートで瞬時に応答
const result = await dynamodb.get({ TableName: 'users', Key: { id: event.id } }).promise();
return result;
};
③ デプロイパッケージを軽量化する
esbuildなどのバンドルツールでZIPサイズを削減すると、コールドスタートが40〜60%改善する。50MBから10MBへの削減だけで、ダウンロードと展開にかかる時間が大幅に短縮される。使っていない依存ライブラリを棚卸しすることから始めよう。
VPCでLambdaを動かすと遅くなる?よくある誤解を解く
「LambdaをVPCに入れるとコールドスタートが激遅になる」という認識は、2026年現在では古い情報だ。2019年以前はENI作成に10秒以上かかる問題があったが、現在のHyperplane ENIアーキテクチャでは通常50ms未満のオーバーヘッドに抑えられている。
ただし、RDSなどのリレーショナルDBへの接続確立コストは残る。VPC内でRDSを使う場合はAmazon RDS Proxyを活用してコネクションプーリングを行うことを推奨する。
まとめ:2026年のコールドスタート対策アクションプラン
2025年8月のINITフェーズ課金開始で、コールドスタートはパフォーマンスとコストの両面で放置できない問題になった。対策の優先順位はシンプルだ。
よくある質問
Lambda SnapStartはすべてのランタイムで使えますか?
2026年現在、SnapStartはJava(11・17・21)、Python 3.12以上、.NET 8以上に対応しています。RustやGoなど起動が元々速いランタイムや、Node.jsには未対応です。Node.jsではARM64移行とパッケージ軽量化を組み合わせて対応しましょう。
Node.js 20のLambda関数はいつまで動きますか?
2026年4月30日に標準サポートが終了し、同年8月31日以降は新規関数の作成がブロックされます。既存関数は引き続き動作しますが、セキュリティパッチが提供されなくなります。Node.js 22または24への移行を早急に進めてください。Node.js 24ではコールバック型ハンドラが廃止されているためコード修正が必要です。
LambdaをVPCに配置するとコールドスタートが遅くなりますか?
現在はなりません。2019年以前はENI作成に10秒以上かかる問題がありましたが、Hyperplane ENIの導入により現在のオーバーヘッドは通常50ms未満です。VPC配置自体がコールドスタートの主因になることは稀で、「VPCは遅い」という認識は古い情報です。
SnapStartのコストはどれくらいかかりますか?
10万回のコールドスタートあたり約$18/月(スナップショットのキャッシュ料金+リストア料金)が追加でかかります。Provisioned Concurrencyの月額$150前後と比較すると圧倒的に安く、ROIが高い選択肢です。まずSnapStartを試して、それでも遅延が許容できない場合にのみProvisioned Concurrencyを検討しましょう。
ARM64(Graviton2)への移行でコードの修正は必要ですか?
純粋なPythonやNode.jsコードであれば、LambdaコンソールやIaC(Terraform・SAM)でアーキテクチャをarm64に変更するだけで完了します。ただしC拡張を使うPythonパッケージ(NumPy等)やx86専用のバイナリを含む場合は、arm64向けのビルドが別途必要です。依存ライブラリを確認してから移行を進めましょう。

コメント