Amazon Bedrock AgentCore Runtime V2 Makes Cold Starts Predictable, but the Bill Still Needs Proof

Amazon launched Amazon Bedrock AgentCore Runtime V2 with a striking claim: cold starts stay near two seconds across container images ranging from 200 MB to 2 GB.

That result challenges a familiar serverless compromise. Teams can scale an agent to zero and save money, but the next user often waits while its environment starts. Keeping instances warm reduces that delay, yet it also preserves capacity that may sit idle.

Runtime V2 attacks both sides of that tradeoff. AWS says it restores prepared snapshots instead of rebuilding each environment. It also reclaims unused memory while a session remains alive, rather than billing against the session’s earlier high point.

The announcement matters because production agents behave differently from conventional request handlers. They can wait on models, call tools, process files, and retain working state across a long sequence of requests. A runtime designed around brief web transactions can waste resources when those pauses dominate the session.

AWS is positioning V2 against that infrastructure mismatch, not merely against another agent framework. The central contest is snapshot-based, usage-sensitive execution versus environments that remain warm or retain peak allocations for predictable performance.

Microsoft and Google already offer their own answers to container startup latency. Microsoft uses prewarmed session pools, while Google recommends minimum instances and startup CPU acceleration. Amazon’s new argument is that teams should not need permanently warm capacity to obtain consistent startup behavior.

The numbers are promising, but they come from AWS’s own benchmark. Buyers still need workload-level evidence covering real initialization code, burst traffic, memory pressure, regional capacity, and total application latency.

What Amazon Bedrock AgentCore Runtime V2 Actually Changes

Runtime V2 changes when agent environments perform initialization and how long allocated memory remains chargeable.

Amazon Bedrock AgentCore Runtime is the managed compute layer within AgentCore. It hosts an agent or tool inside an isolated microVM, which is a lightweight virtual machine with separate CPU, memory, and filesystem resources.

AWS announced V2 on September 18, 2026. Developers can select it by setting platformVersion to V2 when creating or updating a runtime. V1 remains the default according to the current runtime architecture.

The first major change concerns initialization. When a developer creates or updates a V2 runtime, AgentCore starts the container and waits for its health check. The platform then captures a prepared snapshot of that running environment.

Future instances restore the snapshot instead of repeating the entire startup sequence. One-time work, such as loading libraries, retrieving static configuration, or preparing model artifacts, can therefore happen before the first live request arrives.

Snapshotting is not new by itself. AWS Lambda SnapStart also restores initialized execution environments to reduce startup delays. AgentCore applies the approach to longer-lived, isolated agent sessions with custom containers and stateful interactions.

The second change concerns memory accounting. V1 retained allocated memory until a session ended, even when the agent released buffers or stopped touching cached data. Usage could therefore follow the highest memory allocation reached during that session.

V2 starts with a smaller resident footprint and pages in memory as the workload touches it. AWS says the platform reclaims memory after the application releases it or the data becomes cold.

The current usage rules state that idle memory in V2 is reclaimed automatically after 120 seconds. A 128 MB minimum applies to memory billing, while system overhead also counts toward measured usage.

CPU already followed a consumption-oriented model. When an agent waits for a model, tool, database, or external API, CPU charges can fall to zero if no background process remains active. V2 extends that elasticity more meaningfully to memory.

These changes matter most when one session moves through sharply different phases. A document agent might allocate memory while parsing a large file, release those buffers, and then spend minutes waiting on model calls.

Under a high-watermark model, the parsing phase can shape memory usage for the rest of the session. Under V2, AWS says later usage can fall after that temporary allocation disappears.

AgentCore sessions still require careful lifecycle management. A microVM can run for up to eight hours, and the default inactivity timeout can stop its compute earlier. Applications must also preserve durable information outside ephemeral session memory.

The launch therefore does not turn an agent container into unlimited persistent infrastructure. It changes the efficiency and startup behavior of the managed environment while retaining AgentCore’s session boundaries.

That distinction creates the real tension. AWS is promising the responsiveness associated with prepared capacity while retaining the economics of scale-to-zero execution.

Why Agent Workloads Broke the Old Memory Model

The old model became inefficient because agent sessions stay alive across alternating bursts of computation, memory growth, and external waiting.

A conventional web request usually has a short, understandable lifecycle. It arrives, runs application code, accesses a database, returns a response, and releases its execution environment.

An agent can behave more like a temporary worker. It receives a goal, calls a model, invokes several tools, downloads material, creates intermediate files, waits for approvals, and resumes later.

Those stages place different demands on the runtime. Tool calls can leave CPU nearly idle. Document processing can create brief memory peaks. Interactive conversations punish startup delays, while unattended tasks prioritize cost over immediate response.

V1 already offered session isolation, scale-to-zero behavior, and consumption-based CPU charging. However, its memory handling retained allocations after their useful phase had passed.

Consider a coding agent reviewing a large repository. It might load an index, inspect build output, hold several tool responses, and then release most of that data before waiting for the model.

The memory peak still affected later usage under the original runtime. Longer sessions magnified the consequence because an early allocation could remain attached to the session’s footprint.

AWS says it studied allocation patterns across billions of sessions when tuning V2. That statement indicates broad internal telemetry, but the company has not published the distribution, methodology, or representative workload mix behind the analysis.

Reclaiming cold memory aligns the meter more closely with an agent’s changing workload. It also creates a new operational question: how quickly can paged-out data return when an agent unexpectedly needs it again?

AWS describes memory as loaded on demand, reclaimed when released, and reclaimed when it becomes cold. The public announcement does not provide detailed page-fault latency or thresholds for every workload pattern.

That omission matters for agents with large reusable caches. Reclaiming a cache can lower measured memory, but rebuilding it later may consume CPU, increase latency, or repeat network transfers.

Developers will need to separate genuinely disposable allocations from data that improves subsequent turns. A lower memory graph does not automatically mean a faster or cheaper complete workflow.

The architecture also places more importance on application behavior. Software that releases temporary buffers gives the platform an opportunity to reclaim memory. A process that retains references indefinitely cannot expect the runtime to infer that the data is unnecessary.

Long agent sessions make this discipline valuable. AWS documentation says each microVM session receives isolated compute, memory, and filesystem resources. A stopped session can later receive new compute, but ephemeral state disappears unless the application uses persistent session storage or another durable service.

That design protects separation between users, but it prevents developers from treating in-process memory as a permanent knowledge store. Conversation records, learned preferences, and reusable facts require durable storage outside the microVM.

The distinction is particularly important for knowledge-heavy agents. Teams also need a searchable operational record covering prompts, source documents, test results, and runtime changes. A maintained engineering knowledge base can preserve that context beyond an individual execution session.

Runtime V2 does not remove those architectural responsibilities. It makes the temporary compute layer more elastic, which raises the value of separating transient working data from durable organizational knowledge.

Snapshot Restore Rewrites the Cold-Start Tradeoff

The headline improvement comes from restoring a trimmed, initialized snapshot whose size stays relatively stable as the container image grows.

A cold start is the period before a newly created environment becomes ready to handle application work. It can include pulling an image, provisioning compute, starting the process, loading dependencies, and running initialization code.

Cold starts become especially visible when traffic arrives after a service has scaled to zero. They also appear during sudden bursts when existing environments cannot handle every new session.

Large agent containers can make the problem worse. They may include language runtimes, browser dependencies, agent frameworks, document parsers, machine-learning libraries, and internal tools.

Runtime V2 changes this path. AgentCore initializes the environment when a runtime version is prepared, captures its state, and restores that state for future instances.

AWS says the platform also removes caches and transient memory that a restored instance does not need. That trimming is intended to stop snapshot size from increasing with the full resident footprint of a larger container.

The company’s launch benchmark sent 5,000 cold invocations per agent across V1 and V2. The test covered five image sizes under default account quotas.

V2 recorded a P75 cold-start latency of about two seconds from a 200 MB image through a 2 GB image. P75 means that 75 percent of measured starts completed at or below the reported time.

V1 behaved differently in the same AWS test. Its P75 result increased from roughly 5.4 seconds for the smallest image to nearly 30 seconds for the largest.

Those numbers make the mechanism more interesting than a simple percentage improvement. AWS is claiming that image size stops being a meaningful driver of restore latency across the tested range.

The benchmark also used an echo application whose code ran in about 34 milliseconds at P75. That setup isolates infrastructure startup, but it does not resemble the complete execution path of a sophisticated agent.

Real agents often spend several seconds on each model call. They may also contact remote tools, retrieve context, authenticate users, or establish network connections after the environment becomes ready.

A two-second platform start does not mean a two-second answer. It means the infrastructure contributes a smaller and more predictable delay before agent code receives its first request.

That predictability can matter more than the average. Product teams can design loading states, timeouts, and first-token expectations more confidently when startup latency stays within a narrow range.

AWS suggests starting a session when a user opens an interface, before that person submits the first prompt. Greeting text and typing time can then hide much of the remaining startup interval.

That tactic is practical, but it also changes demand. Opening an interface could create sessions that never receive a message, so teams should measure abandoned sessions and unnecessary environment creation.

Snapshots introduce deployment considerations as well. Initialization captured before the snapshot should not embed expired credentials, unsafe randomness, or user-specific state.

Static configuration may fit well. Time-sensitive secrets and per-session identity should be obtained through restore-safe mechanisms. Health checks must also represent a genuinely prepared environment, not merely a listening network port.

The snapshot model therefore shifts some work from request time to deployment time. Teams gain faster instance creation, but they must audit what becomes part of the captured state.

AWS Is Pressuring the Prewarmed Pool Model

Amazon’s competitive claim is not simply faster containers; it is consistent startup without requiring every team to fund permanently warm capacity.

Cloud providers already offer several ways to reduce cold-start latency. Most approaches trade idle resources, operational tuning, or application constraints for faster responses.

Microsoft’s Azure Container Apps offers dynamic sessions. These use pools of prewarmed environments that can allocate isolated sessions in milliseconds.

That model suits code interpreters and workloads that need disposable sandboxes. Its speed comes from having ready environments available before a request arrives.

Google Cloud Run takes a broader container approach. Developers can configure minimum instances to keep containers warm, and startup CPU boost can accelerate initialization.

Keeping minimum instances reduces exposure to cold starts, but idle instances can add cost. Startup CPU boost improves the initialization path without eliminating the need to load and start an application.

Amazon’s V2 design occupies a different point. It prepares a runtime snapshot once, strips unnecessary state, and restores isolated instances as sessions arrive.

The comparison is not absolute. Prewarmed pools can deliver lower allocation latency than the roughly two-second P75 result AWS reported. They can also provide a clearer capacity floor during predictable demand.

Snapshots preserve stronger scale-to-zero economics when traffic is intermittent. Their value rises when a team has many agents that remain unused for long periods but must respond consistently when invoked.

This contest mirrors a long-running serverless question. Should customers pay to keep capacity ready, or should the platform make just-in-time creation predictable enough that warm capacity becomes optional?

Agent workloads make the question sharper. A company might operate hundreds of specialized agents, while only a small portion handle work at any moment. Keeping every environment warm would waste capacity.

Burst traffic creates the opposite concern. If many sessions start together, the platform must restore snapshots quickly without introducing a concurrency penalty.

AWS says V2 keeps cold-start latency consistent regardless of concurrency. However, the published benchmark description emphasizes image sizes and default quotas. It does not disclose every concurrency level or regional condition.

Teams evaluating AgentCore should compare complete service-level objectives, not one startup number. Useful measures include tail latency, time to first model token, restored cache behavior, failed starts, and performance during abrupt traffic spikes.

They should also compare total resource consumption. A prewarmed pool has visible idle capacity, while a snapshot-based service can hide costs in restoration, memory paging, networking, or repeated initialization after deployment changes.

Portability remains another factor. AgentCore accepts containerized applications and supports frameworks including LangGraph, CrewAI, and Strands Agents. Yet its runtime controls, session APIs, identity layer, and billing model are AWS-specific.

Microsoft and Google also encourage integration with their surrounding identity, monitoring, storage, and AI services. The competitive decision therefore extends beyond cold starts.

An enterprise already standardized on one cloud may value operational consistency more than a benchmark advantage. A team building a latency-sensitive agent platform may instead test every runtime directly.

AWS still gains an important sales argument. V2 lets it claim that scaling to zero no longer requires startup latency to grow with the container image.

If independent workloads reproduce that result, cloud buyers will expect rival platforms to explain why warm pools or minimum instances remain necessary for comparable applications.

The Benchmark Is Strong, but Narrow

AWS has shown a credible infrastructure improvement, but it has not yet established lower total cost or predictable application latency for every production agent.

The first limitation is source independence. AWS designed the runtime, selected the test configuration, executed the benchmark, and published the results.

The accompanying test code allows customers to reproduce the experiment in their accounts. That is useful, yet reproducibility still depends on region, quotas, container design, traffic shape, and the timing of each run.

The second limitation is percentile choice. P75 provides a better view than an average, but latency-sensitive services often plan around P95 or P99 results.

A stable two-second P75 can coexist with slower tail events. The announcement does not provide the complete distribution needed to evaluate strict user-facing objectives.

The third limitation is workload simplicity. An echo test helps isolate platform startup, but production containers perform more initialization and make more external connections.

Snapshot capture can bake in some initialization. It cannot guarantee that every database connection, credential exchange, network route, or external dependency is immediately usable after restoration.

The fourth issue is cost interpretation. AWS says V2 charges a higher resource rate than V1, while most agents should consume sufficiently less memory to lower their total bill.

That is a company projection, not a universal outcome. A memory-stable agent that rarely releases allocations may receive limited savings while paying the higher V2 rate.

An agent with temporary memory spikes has a stronger case. Savings should improve when large buffers disappear early and the remaining session spends substantial time at a small footprint.

Teams should test both versions against identical traces. They should record memory usage by second, CPU consumption, session duration, restore latency, model costs, storage costs, and network transfer.

Billing telemetry also requires caution. AWS says monitoring data can be delayed and may differ from authoritative billing records because of aggregation and reconciliation.

The fifth concern is cache churn. If V2 reclaims data that an agent soon needs again, the workload may spend additional time reconstructing that data.

AWS’s 120-second idle-reclamation rule provides one visible threshold, but it does not fully explain how every memory category behaves. Developers should test turn spacing that crosses the threshold.

The sixth concern involves snapshot correctness. Applications often initialize random number generators, credentials, network clients, temporary files, and background threads during startup.

A restored process must not reuse unsafe state across isolated sessions. Teams should verify how their libraries behave after restoration and ensure per-session identity arrives after the snapshot boundary.

AgentCore provides isolated microVMs, but the application still owns user-to-session mapping. A client backend must prevent one user from supplying or reusing another user’s session identifier.

Operational failures also remain possible. Quotas, regional capacity, unhealthy containers, faulty health checks, and downstream service limits can all dominate the user experience.

None of these questions invalidates V2’s benchmark. They define the gap between a promising platform result and a production decision.

The right conclusion is conditional. V2 looks especially attractive for bursty agents with large images, expensive initialization, temporary memory peaks, and long periods of model or tool waiting.

Agents with steady memory, permanently active demand, specialized processors, or strict subsecond requirements need a broader comparison. AWS itself is preparing larger compute options and baseline commitments for some of those workloads.

Three Signals That Will Decide Whether V2 Wins

The next test is whether customer measurements confirm stable startup latency, lower total bills, and safe snapshot behavior outside AWS’s controlled benchmark.

The first signal is the shape of independent latency results. Developers should publish P50, P75, P95, and P99 cold starts across several regions and traffic patterns.

Image size should remain part of those tests, but concurrency matters just as much. A useful evaluation would launch sudden waves of isolated sessions after a runtime has scaled to zero.

If tail latency remains stable as image size and concurrency grow, AWS’s core claim becomes much stronger. Large containers would no longer force teams to keep spare environments running.

If P95 and P99 results vary widely, the two-second P75 headline will have less operational value. Teams with interactive agents would still need warm capacity or aggressive session precreation.

The second signal is measured cost across complete sessions. V2’s higher resource rate means the economic result depends on how much memory the runtime actually reclaims.

Teams should replay workloads with known phases. A representative test might parse a large document, release its buffers, perform several model calls, wait beyond 120 seconds, and then resume.

If metered memory falls after the parsing phase and stays low, V2 supports AWS’s cost argument. If consumption remains near the earlier peak, the expected savings weaken.

The comparison should include more than Runtime charges. Model inference, observability, storage, network transfer, container storage, browser sessions, and tool services can dominate the final bill.

That broader view prevents a small runtime saving from being presented as a dramatic application-level reduction. It also reveals whether faster startup encourages teams to create unnecessary sessions.

The third signal is AWS’s delivery of the capabilities listed as coming soon. The roadmap includes committed baseline discounts, larger compute and storage, x86 microVM support, greater lifecycle control, and session-scoped identity.

Each item addresses a current boundary. Larger environments expand eligible workloads. x86 support reduces migration friction for dependencies that cannot move easily to another architecture.

Suspend and resume controls would help agents continue beyond a single compute lifecycle. Scoped identity would clarify what unattended agents can access when no person is actively supervising them.

If AWS delivers these capabilities with clear documentation and stable behavior, Runtime V2 becomes a broader platform rather than a targeted cold-start optimization.

Delays would expose the limits of the current release. Some persistent, specialized, or unattended workloads would still require other AgentCore compute options or external infrastructure.

Developers can begin with a controlled V1-to-V2 test. They should keep the agent code, model calls, traffic trace, region, and observability settings constant.

The decision should rest on five outputs: startup percentiles, session failure rate, memory usage over time, complete workflow latency, and the final cloud bill.

Interactive products should also test AWS’s early-session tactic. Starting the environment when a user opens a chat can hide startup time, but abandoned sessions must remain visible in the analysis.

Production agents increasingly spend more time waiting, retaining state, and coordinating tools than executing continuous CPU work. That makes conventional container economics a poor fit for many workloads.

Amazon Bedrock AgentCore Runtime V2 offers a technically coherent answer. It prepares work once, restores a smaller snapshot, and releases memory as the session’s needs fall.

The remaining question is empirical: does Amazon Bedrock AgentCore Runtime V2 preserve those advantages under your containers, traffic bursts, dependencies, and security controls?

Run the same workload on both platform versions, retain the full latency distribution, and inspect the bill after reconciliation. That evidence should decide the migration, not the launch headline.