AWS Stops Charging Agent Sessions for Their Memory Peak

AWS has made the next generation of Amazon Bedrock AgentCore Runtime generally available. The consequential change is not a new agent abstraction. It is a billing and execution model better suited to sessions whose memory use rises, falls and then waits.

AgentCore Runtime V2 starts with a smaller memory profile, allocates more memory when the application needs it, and reclaims memory once it is released or becomes cold. AWS says idle memory is reclaimed after 120 seconds. Under the previous model, a session’s memory high-water mark could remain economically relevant until that session ended. V2 instead makes the memory curve during the session part of the cost calculation.

That is a material change for long-running AI applications. A session may build a temporary retrieval buffer, hold intermediate tool results, wait for a model response, or spend time between human interactions. Its peak memory demand may be real, but it may not be representative of the resources it needs for the rest of its lifetime. Charging as though the peak remains present turns transient working state into a persistent infrastructure cost.

What changed—and what did not

V2 is generally available as of September 18, 2026. Customers select it by setting platformVersion to V2. Nothing migrates automatically: V1 remains the default when that field is omitted. At launch, V2 is available in Northern Virginia, Ohio, Oregon, Ireland and Tokyo. AWS CloudFormation and the AWS CDK do not yet support setting platformVersion.

The new runtime also changes startup behavior. AWS prepares an environment once, takes a snapshot after startup initialization, and restores that snapshot for new instances rather than rerunning the full initialization path. This reduces dependence on container image size for cold starts in AWS’s published test.

But V2 is not a blanket cost reduction, and its cold-start result is not an end-to-end application latency claim. AWS lists V2 at $0.1276 per vCPU-hour and $0.0169 per GB-hour, compared with $0.0895 and $0.00945 for V1. The unit rates are higher. A workload only saves money if lower billable resource-hours—especially reclaimed memory-hours—more than offset those rates.

The new unit of analysis is the memory curve

Teams often model an AI service through requests, tokens, model calls, average session duration and occasionally peak concurrency. Those remain useful measures. They are no longer sufficient for deciding between these two runtime versions.

The relevant question is not simply, “How much memory does this service need?” It is: “For how long does it need each increment of memory, and when does that memory become releasable?” A workload that reaches a high allocation briefly, releases it, and then remains alive for several minutes has a different V2 case from one that holds near-peak state continuously. Two services with the same peak memory and session length can therefore have sharply different bills.

“V2 makes transient memory an operating variable. Treating peak allocation as the entire workload description will now hide both costs and savings.

This is particularly relevant where a runtime coordinates uneven work. Retrieval stages can materialize documents and embeddings; tool execution can produce large intermediate objects; multi-step workflows can retain context while waiting on external systems. The correct response is not to assume that every such workload should move to V2. It is to measure whether its live memory actually falls between bursts, and whether application code releases no-longer-needed state promptly enough for reclamation to matter.

Snapshot startup requires an application review

Snapshot restoration changes a second operating boundary: what is safe to do at startup. Values created during initialization are inherited by instances restored from the snapshot. AWS therefore instructs customers to keep request-specific, expiring and unique values out of startup code.

This is a practical engineering constraint, not an edge case. A credential fetched during initialization may expire. A request identifier created there is no longer unique per request. A timestamp expected to represent current work may instead describe the prepared environment. Initialization should establish reusable code and stable configuration; request handling should create values whose correctness depends on a particular request, instance or moment in time.

That division also creates a useful test target. Before enabling V2, teams should enumerate initialization side effects and classify each one: stable and shareable; refreshable after restoration; or required only in the request path. The migration is not complete when a deployment succeeds. It is complete when restored instances retain no stale startup state that changes application behavior.

Read the cold-start benchmark narrowly

AWS’s published benchmark is encouraging but deliberately bounded. The company invoked an empty echo agent cold 5,000 times for each version and image size. For images from 200 MB to 2 GB, V2 produced approximately two-second P75 cold starts, while V1 ranged from about 5.4 seconds to nearly 30 seconds.

The measurement included a public-internet round trip from an EC2 client in us-west-2 to runtimes in us-east-1. It excluded model and tool work. It therefore says something specific about platform startup under that setup—not about the response time a user will experience from a production agent with retrieval, model inference, downstream APIs and its own initialization behavior.

The useful lesson is methodological. Measure a cold-start distribution for the real image and region arrangement, then separate platform startup from application initialization, model work and tool latency. A single “first response” number conceals the component that needs attention.

A migration decision should be empirical

V2 gives teams a more elastic runtime option, but it also removes the excuse to compare runtimes using only list prices or container size. The decision should be made from production-shaped traces.

• Record memory allocation and release over the full session lifetime, not only peak resident memory.
• Measure how long memory remains idle after bursts; AWS states that V2 reclaims idle memory after 120 seconds.
• Compare billable vCPU-hours and GB-hours under V1 and V2 rates for representative traffic mixes.
• Test cold starts separately from model and tool execution, across the image sizes and regions actually used.
• Audit startup code for cached credentials, timestamps, random values, request identifiers and other state that cannot safely be inherited.

For workloads with bursty memory and long-lived sessions, the potential change is substantial: the runtime can stop treating a temporary buffer as a charge that lasts until termination. For workloads that sustain high memory or CPU use, V2’s higher rates may dominate. AWS has not made this a universal savings claim. Neither should customers. The right comparison is a memory-and-time profile, paired with a startup-state review—not a version label and a hopeful estimate.