For a decade, “cold start” was the word that made serverless architects wince. A function would sit idle, a request would arrive, and the platform would spend anywhere from a few hundred milliseconds to several seconds spinning up a fresh execution environment before a single line of application code ran. By late August 2026, that wait has shrunk to a fraction of what it was even two years ago. Independent 2026 benchmarks now put AWS Lambda cold starts for Python and Node.js in the 100-500 millisecond range, Google Cloud Functions 2nd gen slightly ahead at roughly 80-400 milliseconds, and a July 2026 engineering study on snapshot-based restore techniques showing median cold-start latency dropping from 145 milliseconds to just 28 milliseconds. Fork-based restore models pushed that figure down further, to around 12 milliseconds in test conditions.
The story is not just about raw speed. It is about how AWS, Google, and Microsoft are quietly rewiring the internals of serverless computing, and about a billing change that turned a once-invisible latency tax into a line item enterprises now have to budget for. Here is what the data shows, why it matters, and where the cold-start race goes from here.
The Benchmarks Nobody Expected After a Decade of Lambda
AWS Lambda has been running production workloads since 2014, and for most of that history, cold starts were treated as an accepted cost of going serverless. Teams built entire architectural patterns, provisioned concurrency, warm-up pings, keep-alive schedulers, just to dodge the penalty. The 2026 numbers suggest that era is winding down. According to benchmarks compiled by Prime Technologies Global in April 2026 and referenced across multiple independent serverless comparisons, AWS Lambda now delivers cold starts in the 100-500 millisecond band for its two most common runtimes, Python and Node.js. That is a meaningful drop from the multi-second waits some teams still associate with Lambda from years past.
Google’s numbers land even lower in the same tests. Cloud Functions 2nd gen, which runs on the same underlying infrastructure as Cloud Run, showed cold starts around 80-400 milliseconds for Python and Node.js workloads in 2026 comparative testing. Azure Functions brought up the rear among the three hyperscalers, with benchmarks reporting roughly 200-600 milliseconds for the same runtime pair, confirming a latency gap that has persisted through several Azure Functions generations.
None of these numbers happened by accident. They reflect a multi-year engineering push around a single technique: snapshotting a warm execution environment and restoring it on demand instead of booting one from scratch.
What a Cold Start Actually Costs You
A cold start is the delay between an event triggering a serverless function and that function being ready to execute business logic. The platform has to allocate compute, pull the deployment package or container image, initialize the language runtime, and run any startup code (database connections, SDK clients, dependency injection) before the actual handler fires. For a lightweight Node.js function that startup sequence might take 200 milliseconds. For a Java application loading a Spring context, it could take five seconds or more.
That gap matters differently depending on the workload. An API endpoint behind a mobile app eats the delay as user-facing lag. A batch job triggered by an S3 upload barely notices. A real-time chat backend or a payment authorization flow, by contrast, cannot tolerate a five-second pause without breaching its own service-level agreement. The 2026 benchmark data on Google Cloud’s blog and similar sources increasingly measure not just average cold-start time but tail latency: the 60th, 95th, and 99th percentile figures, plus time-to-first-byte and total time from invocation to ready state. That shift itself is a signal. Providers are no longer satisfied with a good median if the P99 still spikes into multi-second territory for a fraction of requests.
Snapshotting: The Trick Behind the New Numbers
The core technique driving the improvement is snapshotting. Instead of starting a language runtime and application from a completely blank state every time, the platform boots the environment once, lets it initialize fully (JVM warmed up, connections established, classes loaded), then freezes that state to disk or memory as a snapshot. When a new cold start is needed, the platform restores from the snapshot rather than re-running the entire boot sequence.
The July 2026 engineering study on snapshot-based serverless platforms benchmarked this approach across five production-representative workloads and found that snapshot restore cut median cold-start latency from 145 milliseconds down to 28 milliseconds, roughly a fivefold improvement over booting fresh each time. The same research pushed further into fork-based restore models, citing REAP-style fork mechanisms that brought median cold-start latency down to around 12 milliseconds, a number that starts to approach ordinary network round-trip latency rather than looking like an infrastructure penalty at all.
Under the hood, AWS’s Lambda platform has relied on Firecracker, its open source microVM technology, since the service moved off traditional container isolation years ago. Firecracker’s lightweight virtualization is a large part of why Lambda can spin up isolated execution environments as quickly as it does, and the snapshotting techniques discussed in 2026 research build directly on top of that microVM foundation rather than replacing it.
AWS Lambda SnapStart Goes Beyond Java
AWS’s own implementation of this idea, Lambda SnapStart, has been the clearest public demonstration of what snapshotting buys you. The feature originally targeted Java, historically the slowest cold-starting mainstream runtime because of JVM class loading and initialization overhead. Benchmark data circulating in 2026 shows Java 21 functions without SnapStart still posting median cold starts of roughly 2 to 5 seconds, with P99 latency stretching to 6 to 10 seconds under load. Enable SnapStart on the same function, and median cold-start latency drops to an estimated 90 to 140 milliseconds, with P99 falling to 200 to 400 milliseconds. That is close to a 20x reduction in the worst-case tail.
Enabling SnapStart on a Java-based Lambda function requires only a configuration change, not a code rewrite, which is part of why adoption has climbed through 2026 among teams running JVM-based microservices on Lambda. A typical AWS SAM template change looks like this:
Resources:
MyJavaFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: java21
Handler: com.example.Handler::handleRequest
SnapStart:
ApplyOn: PublishedVersions
AutoPublishAlias: liveTeams running Lambda alongside container-based workloads on ECS or EKS increasingly treat SnapStart-enabled functions as the default for latency-sensitive JVM services, reserving container platforms for workloads that need sustained throughput rather than bursty, event-driven execution. For teams new to the platform, the basic setup mechanics are covered in our AWS Lambda serverless tutorial.
Google Cloud Functions and Cloud Run: The Quiet Leader
Google’s serverless compute story in 2026 centers on Cloud Functions 2nd gen and Cloud Run sharing an underlying execution model. For lightweight function invocations, that shared foundation is producing the fastest cold starts among the three major clouds in independent 2026 testing, at roughly 80 to 400 milliseconds for Python and Node.js. Google has not published the same level of granular SnapStart-style marketing around this performance the way AWS has, but the benchmark results place Cloud Functions ahead of both Lambda and Azure Functions for equivalent runtime and workload profiles.
Cloud Run itself tells a more complicated story once you move from lightweight function handlers to full container images. Because Cloud Run starts an entire container rather than a lightweight function package, cold starts for container-backed services on Google’s platform typically run 1 to 2 seconds, especially for larger images or heavier runtimes like full JVM or .NET Docker images. That gap between “function cold start” and “container cold start” shows up across every provider, not just Google, and it is becoming one of the more important distinctions architects have to reason about when choosing a serverless compute model.
Azure Functions Still Trails the Pack
Microsoft’s serverless platform continues to lag AWS and Google on raw cold-start numbers. 2026 benchmarks put Azure Functions at roughly 200 to 600 milliseconds for Python and Node.js on Consumption-plan hosting, a gap that has held steady across several recent Azure Functions releases despite continued investment in the platform’s scaling engine, documented in Microsoft’s own Azure Functions scaling guidance. Azure App Service and Azure Container Apps, Microsoft’s alternative hosting models, show similarly mixed results, with cold starts depending heavily on plan tier and whether “Always Ready” instances are configured.
The practical takeaway for teams standardized on Azure is that the platform’s cold-start story still leans on pre-warmed or Premium-tier instances rather than the snapshot-restore techniques AWS has shipped for Java. Enterprises running mixed clouds for cost or compliance reasons continue to weigh those latency differences against Azure’s other strengths in identity, networking, and enterprise tooling.
Container-Backed Serverless Tells a Different Story
Not every serverless workload runs as a lightweight function, and the cold-start conversation changes shape once containers enter the picture.
Fargate’s Always-On Trade-Off
AWS Fargate takes a different approach entirely. Because Fargate tasks stay running once a service is live, rather than scaling to zero between requests, the platform effectively has no cold start in normal operation. The trade-off is cost: teams pay for at least one running task continuously, even during periods of no traffic, unlike function-based platforms that bill only for actual invocations.
Cloud Run and Container Apps Scale to Zero
Cloud Run and Azure Container Apps, by contrast, both support scaling down to zero instances when idle, which reintroduces a cold start on the next incoming request. 2026 comparisons put that reintroduced cold start in the 1 to 3 second range on consumption-style plans for both platforms, a noticeably larger penalty than the sub-second numbers lightweight functions now achieve. Teams choosing between these models are effectively trading cost efficiency at zero traffic against consistent low latency, and the right answer depends heavily on traffic shape rather than any single benchmark number.
Runtime Choice Now Matters More Than Provider Choice
One of the more striking findings in 2026 cold-start research, laid out in detail in a widely circulated AWS engineering benchmark writeup, is how much the choice of programming language now outweighs the choice of cloud provider. Compiled languages with minimal runtime initialization overhead, namely Go and Rust, post cold starts in the 50 to 100 millisecond range at the median across the datasets referenced in current benchmarking work, while interpreted and managed runtimes carry a heavier tax unless snapshotting is applied.
| Runtime | P50 Cold Start | P99 Cold Start | Notes |
|---|---|---|---|
| Rust | 50-80 ms | 100-200 ms | Fastest overall in 2026 benchmarks |
| Go | 50-100 ms | 150-250 ms | Near-zero runtime initialization |
| Node.js 22 | 200-350 ms | 600 ms-1 s | Solid general-purpose choice |
| Python 3.13 | 200-400 ms | 800 ms-1.2 s | Fastest scripting runtime tested |
| Java 21 (no SnapStart) | 2-5 s | 6-10 s | Still slow without snapshotting |
| Java 21 + SnapStart | 90-140 ms | 200-400 ms | Roughly 20x tail-latency cut |
For teams building latency-sensitive event-driven systems, that data point reshapes the usual build decision. Rewriting a service in Go or Rust purely for cold-start reasons can now beat waiting on a provider-level fix, particularly for workloads that cannot use SnapStart-style snapshotting because they run on Python, Node.js, or a provider that has not shipped an equivalent feature yet.
The Billing Twist: Cold Starts Now Show Up on the Invoice
Cold starts stopped being a purely technical concern once AWS started billing for them. On August 1, 2025, AWS began charging for the initialization phase of Lambda functions, a phase that had previously been free. That change means the milliseconds a function spends cold-booting are no longer invisible on a bill, and for high-volume, frequently-cold workloads the shift has been significant.
| Metric | Before Aug 1, 2025 | After Aug 1, 2025 |
|---|---|---|
| Lambda initialization phase billing | Not billed | Billed as compute time |
| Cost per 1M cold starts (cited example) | ~$0.80 | ~$17.80 |
| Optimization incentive | Low urgency | Direct line-item pressure on FinOps teams |
That roughly 22x jump in the cited example turned cold-start optimization from a pure performance exercise into a cost-control exercise, which is part of why interest in SnapStart, provisioned concurrency, and faster-booting runtimes has accelerated through 2026 rather than plateauing. Cloud cost teams tracking this shift alongside broader FinOps cost-management practices now treat cold-start rate as a metric worth watching on the same dashboard as raw compute spend.
The Fork-Based Frontier: REAP and Sub-15ms Restores
The most aggressive numbers in current research come from fork-based restore models, an approach that goes a step beyond straightforward snapshot restore. Rather than restoring an entire frozen environment image from storage, fork-based systems keep a warm parent process running and spin up new execution contexts by forking from that live process, similar in spirit to how traditional Unix process forking works, but applied to serverless microVM restore paths.
The July 2026 study referenced earlier cites REAP-style fork mechanisms achieving median cold-start latency around 12 milliseconds, a number low enough that it starts to disappear into ordinary request-handling noise rather than reading as a distinct infrastructure penalty. That research remains largely in the academic and early-engineering-adoption stage rather than shipped as a mainstream managed-service feature across AWS, Google, or Microsoft as of August 2026, but it points at where the next generation of platform-level cold-start improvements is likely headed.
A Decade of Chasing Zero: How We Got Here
Serverless computing’s entire pitch, since AWS Lambda’s original 2014 launch, has rested on abstracting away server management in exchange for event-driven, pay-per-invocation pricing. Cold starts were always the visible crack in that abstraction, the moment where “serverless” quietly reminded you that servers were very much involved. Early mitigation strategies were blunt: scheduled warm-up pings to keep functions active, provisioned concurrency to pre-allocate warm capacity at a fixed cost, or simply avoiding Lambda for latency-critical paths altogether.
Firecracker’s introduction as AWS’s microVM technology marked the first major infrastructure-level attempt to close the gap, trading heavier virtual machine boot times for lightweight, purpose-built isolation that could start in a fraction of the time. Snapshotting, and now fork-based restore, represent the next layer built on top of that foundation, moving the industry from “start fast” to “don’t really start at all, just resume.” The 2026 numbers are the clearest evidence yet that this multi-year investment is paying off in numbers developers can actually measure.
Competitive Landscape: AWS vs Google vs Azure in the Cold Start Race
Multiple 2026 sources converge on a similar rank order even when their absolute numbers differ slightly by test methodology: AWS Lambda and Google Cloud Functions 2nd gen now deliver broadly comparable cold-start latency for lightweight functions, while Azure Functions and container-backed serverless deployments generally lag, particularly for larger container images and heavier runtimes.
| Provider / Service | Typical Cold Start (Python/Node.js) | Position |
|---|---|---|
| Google Cloud Functions 2nd gen | 80-400 ms | Fastest lightweight function cold start |
| AWS Lambda | 100-500 ms | Close second, ahead on Java via SnapStart |
| Azure Functions (Consumption) | 200-600 ms | Persistent gap vs AWS and GCP |
| Google Cloud Run (container) | 1-2 s | Fast for a container platform, slower than functions |
| Azure Container Apps | 1-3 s | Similar scale-to-zero penalty to Cloud Run |
| AWS Fargate | Effectively none | Always-on tasks avoid cold start, cost more at idle |
AWS’s edge case is Java, where SnapStart gives Lambda a distinct advantage that neither Google nor Microsoft currently matches with an equivalent managed feature at the same level of maturity. Google’s edge is breadth across Python and Node.js by default, without requiring any special configuration. Teams comparing edge-adjacent options, such as Cloudflare Workers against Lambda@Edge, generally find that V8 isolate-based edge runtimes sidestep the cold-start conversation almost entirely by design, at the cost of a more constrained execution environment than full Lambda or Cloud Functions offer.
Market Impact: What This Means for How Teams Build
The practical effect of sub-200 millisecond cold starts is that serverless stops being disqualified from workload categories it used to sit out. Real-time bidding, chat backends, payment authorization steps, and other latency-sensitive event-driven systems that previously required always-on containers or provisioned concurrency workarounds are increasingly viable on plain, pay-per-invocation serverless functions, provided teams pick the right runtime and enable the right snapshotting features.
That shift also changes how architecture teams evaluate the broader agentic and AI-adjacent workloads now landing on serverless platforms. AWS’s own push into this space, including the recent Bedrock AgentCore general availability, depends on fast, cheap function invocation to make agent tool calls economically viable at scale, which is part of why cold-start engineering investment has accelerated alongside the broader AI infrastructure buildout rather than as a separate initiative.
For FinOps and platform teams, the billing change adds a second, less glamorous effect: cold-start rate becomes a monitored metric rather than a background nuisance. Expect more platform teams to add cold-start percentage and cold-start cost to their standard cloud dashboards over the next few quarters, the same way they already track compute utilization and idle spend.
Predictions: Where Cold Start Latency Goes Next
- SnapStart-style snapshotting expands beyond Java on AWS Lambda to cover additional managed runtimes, narrowing the gap that currently favors JVM workloads specifically.
- Google and Microsoft respond with their own branded snapshot-restore features rather than relying solely on generic platform improvements, once AWS’s Java advantage becomes a competitive talking point in enterprise sales cycles.
- Fork-based restore techniques like REAP move from academic benchmarks into limited managed-service previews at one or more hyperscalers within the next 12 to 18 months, though full general availability will likely take longer.
- Cold-start cost becomes a standard line item in cloud cost reports, following AWS’s 2025 billing change, pushing more workloads toward Go and Rust specifically to minimize both latency and spend simultaneously.
- The gap between function-based and container-based serverless cold starts persists, keeping Fargate-style always-on models relevant for workloads that cannot tolerate any scale-to-zero penalty regardless of how fast restore times get.
Frequently Asked Questions
What is a serverless cold start?
A cold start is the delay between a serverless function being triggered and it becoming ready to run application code, caused by the platform allocating compute, loading the runtime, and executing any startup initialization before the handler fires.
How fast are AWS Lambda cold starts in 2026?
2026 benchmarks put standard AWS Lambda cold starts for Python and Node.js in the 100-500 millisecond range. Java functions with SnapStart enabled drop to roughly 90-140 milliseconds median, versus 2-5 seconds without it.
Is Google Cloud Functions faster than AWS Lambda?
For lightweight Python and Node.js functions, 2026 benchmarks show Google Cloud Functions 2nd gen slightly ahead of Lambda, at roughly 80-400 milliseconds versus 100-500 milliseconds. AWS holds an edge for Java workloads because of SnapStart.
Why did AWS start charging for Lambda cold starts?
On August 1, 2025, AWS began billing the initialization phase of Lambda functions, a phase that had previously been free. For frequently-cold workloads, this can raise costs significantly, with one cited example showing the cost of a million cold starts rising from about $0.80 to $17.80.
Does Rust or Go avoid cold starts entirely?
No runtime avoids cold starts entirely, but Go and Rust post the lowest cold-start times among mainstream serverless runtimes in 2026 benchmarks, at roughly 50-100 milliseconds median, because they lack the heavier initialization overhead of managed runtimes like the JVM.
What is Lambda SnapStart and how does it work?
SnapStart is an AWS Lambda feature that initializes a function once, takes a snapshot of the fully warmed execution environment, and restores from that snapshot on subsequent cold starts instead of booting from scratch. It is enabled through a configuration setting rather than a code change and currently targets Java runtimes.
Do container-based serverless platforms like Cloud Run have cold starts?
Yes. Cloud Run and Azure Container Apps both scale to zero when idle, which reintroduces a cold start on the next request, typically 1-3 seconds depending on image size and runtime. AWS Fargate avoids this by keeping tasks running continuously, at the cost of paying for idle capacity.
What comes after snapshotting for reducing cold starts?
Current research points to fork-based restore models, which spin up new execution contexts by forking from an already-warm parent process rather than restoring a full snapshot image. A July 2026 study cited median cold-start latency around 12 milliseconds using this approach, though it remains largely in early research and engineering-adoption stages rather than shipped as a mainstream managed feature.
