Build1 publisher3 min readPublished
AWS stops billing AgentCore sessions at their peak memory
The V2 runtime allocates session memory on demand and hands it back mid-run, and it restores each new instance from a snapshot of an already prepared environment. AWS measured P75 cold starts of 1.9 to 2.0 seconds on images from 200 MB to 2 GB.
The Engineer · Build desk
What happened
- AWS has made the next generation of AgentCore Runtime, the serverless microVM compute inside Amazon Bedrock AgentCore, available to customers.
- Sessions now open on a small memory profile, allocate more on demand, and give back memory that is no longer actively used instead of holding it until the session ends.
- The runtime prepares the agent environment once and snapshots it, and every new instance restores from that snapshot rather than repeating the full startup sequence.
- AWS reported a P75 cold start of 1.9 to 2.0 seconds for container images from 200 MB to 2 GB in its own testing, against 5.4 to 30 seconds on the first-generation runtime.
- The new runtime is live in five regions: us-east-1, us-east-2, us-west-2, eu-west-1 and ap-northeast-1.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Teams running agents that spike and then idle stop paying the high-water mark for the rest of the session, and the size of that saving depends entirely on whether their agent's memory use actually drops between spikes.
- constraint Memory a session already paid for is no longer guaranteed to be there for the next step, so an agent that spikes, idles, and returns to the same data pays fetch latency on the way back up.
- decision Trimming the container image stops being the lever on start time, so teams that stripped dependencies to shave seconds off boot can put them back and argue about the warm-path gap instead.
Restore cost tracks the snapshot, not the layers inside the container image [4]. So the published start times flatten across a tenfold range of image size, and the saving is not spread evenly. At the 2 GB end, 30 seconds down to 2.0 is a 15x cut [1]. At the 200 MB end, 5.4 down to 1.9 is about 2.8x, or 3.5 seconds of wall clock [2]. The spread across image sizes goes from 24.6 seconds to 0.1 second [4].
The published figure is a P75, so one start in four lands above it. It is also a test AWS ran on an agent AWS chose [5]. For the number to transfer, your image has to sit inside the 200 MB to 2 GB band, your arrival pattern has to look like the concurrency AWS tested, and the percentile your users complain about has to be the 75th rather than the tail.
There is a second figure in AWS's blog post worth holding next to it. Sessions depend on hardware-enforced isolation, and a session that lands on an already-initialized environment starts in under 100 milliseconds [10]. Snapshot restore is roughly 19 times that [3]. For a long-running agent that paused for human input and now has to resume, two seconds is still two seconds.
The billing change is about when memory goes back. In the first runtime, a session held memory from the moment it allocated it until the session ended, because nothing reclaimed it along the way, so a bursty agent kept paying for its high point the whole time it ran [8]. The same post makes the case for that behaviour: holding allocated memory pays off when the memory serves later work without incurring the latency to fetch it again [9]. Reclaim it, and the next step fetches again. AWS's post does not say how the platform decides that memory is no longer actively used. If your agent sits near its ceiling for most of a session, billing on actual usage bills close to the peak anyway [2].
Adoption is one field: set platformVersion to V2 when creating or updating a runtime [7]. That is a cheaper migration than most platform changes, which is not something I get to write often. Thousands of teams are already running production agents on the first version [12], and V2 keeps the properties they bought: serverless, session isolation, scale to zero, pay only for what you use [11]. Billing follows resource usage, with no standing charge for capacity provisioned just in case and nothing owed for idle CPU waiting on I/O [13]. The announcement points to the AgentCore pricing page for rates [14].
What to watch
- Whether AWS publishes tail latency for snapshot restores, and under stated concurrency, instead of a P75 alone.
- Whether the reclamation rule is documented precisely enough to predict a bill for agents whose language runtime holds heap between spikes.
- Whether V1 gets a deprecation date now that platformVersion has a second value.