AWS Lambda cold start на Java в 2026 — SnapStart реально помогает или маркетинг?

[Kutz]

Поднимаю тему, потому что не нашёл свежих честных данных по SnapStart именно в проде. У нас Spring Boot 3 + Lambda, cold start доходит до 8-12 секунд без SnapStart. С SnapStart в тестах получаем 120-180 ms. Но при включении в прод вылезли странности с состоянием — приложение иногда «помнит» данные из предыдущего снапшота. Кто-нибудь уже решил эти грабли?

[smith_zhenya]

Проблема со state — это известная штука. SnapStart делает snapshot JVM после инициализации, и если у тебя в статических полях или синглтонах есть что-то, что должно быть уникальным при каждом запуске (UUID, timestamp, random seed) — оно будет одинаковым во всех клонах. Решение: реализуй интерфейс CRaC (Coordinated Restore at Checkpoint). Там есть beforeCheckpoint() и afterRestore() — в beforeCheckpoint() закрывай соединения и сбрасывай состояние, в afterRestore() пересоздавай.

[asyncmonk]

Мы прошли через это с Quarkus. CRaC работает, но добавляет бойлерплейт. Альтернатива — перейти на GraalVM native image. Cold start у нас стал ~50 ms совсем без SnapStart, но билд занимает 15 минут и некоторые рефлекшн-штуки ломаются. Для нового кода отлично, легаси портировать больно.

[carv]

@smith_zhenya, Есть ещё третий путь — просто платить за Provisioned Concurrency. У нас 10 инстансов с PC, стоит примерно $180/мес дополнительно, но cold start проблема исчезла полностью. Для B2B где важен SLA — это оправдано. Для consumer-продукта с непредсказуемым трафиком — уже надо считать.

[Sdgator]

Кстати, AWS в начале 2026 обновил биллинг: теперь INIT-фаза тарифицируется отдельно. Если у тебя Java-функция с 2-секундным холодным стартом и миллион инвокаций в месяц — это +$400-600 только за инициализацию. Многие об этом не знают до первого счёта. Проверяйте метрику Init Duration в CloudWatch.

[asynclover]

@asyncmonk, По моему опыту SnapStart реально работает, не маркетинг. Главное — правильно реализовать CRaC-хуки и не держать в инициализации ничего, что зависит от времени или случайности. Ещё рекомендую явно выставлять JAVA_TOOL_OPTIONS=-XX:+TieredCompilation -XX:TieredStopAtLevel=1 — это само по себе срезает холодный старт на 30-40% без SnapStart.

[jpearce]

@Kutz, со state после restore это действительно неочевидно, пока не столкнёшься. У нас был кейс с Jackson ObjectMapper в static поле — маппер кешировал TypeFactory, и после restore некоторые классы не резолвились при первом запросе, пока не сделали lazy reinit в afterRestore(). CRaC-хуки решают, но их надо пройтись по всему коду инициализации, это не быстро на большом проекте.

[Planed]

@asyncmonk, с GraalVM native agree — новый код пишется под него нормально если избегать рефлекции, но на Spring-легаси с кучей библиотек это лотерея. Особенно больно когда в рантайме падает что-то, что на JVM работало годами. Нам помог reachability metadata репозиторий от GraalVM community — там уже есть конфиги для большинства популярных библиотек, не надо самим генерить reflect-config.json на каждый чих.

[cordoba]

По поводу биллинга INIT-фазы — это реально неприятный сюрприз. Логика у AWS понятна: раньше cold start был бесплатным, сейчас они тарифицируют реальные ресурсы. Но разница между Java с 10-секундным инитом и Go-функцией с 50 мс получается космическая при одинаковом трафике. Один из аргументов в пользу либо SnapStart+CRaC, либо смены рантайма — не ради скорости отклика, а буквально ради счёта.