AWS's New AgentCore Runtime Cuts Agent Cold Starts 15-Fold

Amazon Web Services rewrote the compute layer behind Amazon Bedrock AgentCore, cutting the slowest cold starts from nearly 30 seconds to about two, according to a Sept. 18 post on the AWS Machine Learning blog credited to five AWS engineers on the AgentCore Runtime team.

AgentCore is the serverless microVM layer AWS sells for hosting AI agents: a customer hands it a container image, and it handles isolation, scaling to zero, and billing per session. The company's own changelog entry says the new version, called V2, is available now in five regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland) and Asia Pacific (Tokyo).

What a P75 cold start looked like before Sept. 18

AWS measured cold starts at the 75th percentile across 5,000 cross-region invocations, calling agents hosted in US West (Oregon) from US East (N. Virginia). On the original runtime, a 200-megabyte container image started in about 5.4 seconds at that percentile; a 2-gigabyte image took close to 30 seconds. On V2, both sizes started in roughly 1.9 to 2.0 seconds, a gap the company says holds regardless of image size or how many sessions are running at once. Once an agent's code starts running, the blog post separately measured a median 34-millisecond response on a simple echo test.

How a snapshot replaces the boot sequence

The speedup comes from a change in how AWS prepares a new session rather than a faster boot. The AgentCore team's post describes four separate mechanisms working together. First, memory is demand-paged: a session starts with a small resident footprint and pages in more only as the agent's code asks for it, instead of reserving the full container image up front. Second, V2 captures a snapshot of an agent's environment once, after the container passes its health check, with one-time initialization work already baked in; every later session restores from that snapshot instead of repeating the full startup sequence. Third, the runtime strips transient caches and padding from the snapshot before storing it, which AWS says is why restore time stays flat as the underlying image grows from 200 megabytes to 2 gigabytes, since a snapshot built from a bigger image is not much bigger itself. Fourth, the billing meter was rebuilt to match the new memory behavior, described below.

The approach is closer to how a modern operating system handles virtual memory than to how AWS's older serverless products, such as Lambda, have historically billed: Lambda charges for a fixed amount of allocated memory for the full duration of a function's execution, whether or not the function is using it. AgentCore V2's memory reclamation is meant to avoid that overpayment specifically for the long-lived, unevenly active sessions an AI agent produces, where a burst of tool calls might need several gigabytes for a few seconds and then sit mostly idle waiting on a model response.

Billing shifts from peak memory to memory actually used

The older runtime billed a session for whatever memory ceiling it was configured with, held for the life of the session even if the agent stopped using most of it. V2 uses what AWS calls elastic memory: a session starts with a small resident footprint, pages in more memory on demand, and has memory reclaimed the moment it goes idle, with the bill following those changes over the session's lifetime rather than tracking a peak set at session start. AWS frames this as a rate change rather than a straightforward discount: a higher per-gigabyte-hour rate applied to far fewer gigabyte-hours, since idle memory no longer sits on the meter. The company did not publish a worked-out bill comparison for a typical workload, so which agents actually save money depends on how much of their allotted memory sat unused under V1. An agent that runs hot the entire session, using close to its full memory allocation throughout, could plausibly end up paying more per gigabyte-hour than it did before, even though AWS is marketing the change as a cost cut.

What AWS did not say

The blog post carries no customer names or adoption figures, and Unite.AI's write-up the same day made no attempt to check the claims against a competing agent-hosting product from Google Cloud or Microsoft Azure. Both of AWS's own numbers, the cold-start percentiles and the billing description, come from the vendor's own test setup rather than an independent benchmark. V1 is not being retired: it stays the default, and a developer has to set a platformVersion field to V2 on a runtime, new or existing, to get the faster starts.

AgentCore itself is young. AWS made the original AgentCore runtime generally available roughly a year ago, so V2 is the first major rework of the compute layer rather than a mature product's routine update. Whether the elastic-memory billing actually lowers costs for a given team will show up in AWS invoices before it shows up in another blog post.

Container image size	V1 cold start (P75)	V2 cold start (P75)
200 MB	~5.4 seconds	~1.9-2.0 seconds
2 GB	~30 seconds	~1.9-2.0 seconds

Source: AWS Machine Learning blog, accessed Sept. 21, 2026.

AWS is not the only cloud vendor racing to make its own agent-hosting layer cheaper to run; a Sept. 11 update to AWS's Lambda-based Pydantic AI integration tackled a related problem, making sure a timed-out agent run resumes instead of re-billing from the first step. AWS has also been iterating on the human side of agent operations, adding two-way Slack chat to its DevOps Agent the week before.