The Pulse
AWS Rebuilds AgentCore Runtime Around Elastic Memory and Snapshots
AWS has released a new version of Amazon Bedrock AgentCore Runtime that reclaims unused session memory and restores prepared snapshots for more predictable cold starts. The company says the runtime reaches about two seconds at the 75th perc
AI.info Team ·
AWS Targets the Two Costs That Complicate AgentCore
AWS is changing the execution model behind Amazon Bedrock AgentCore Runtime, addressing a tension between serverless economics and the startup delays that can appear when production agents use large containers or arrive in bursts.
The new runtime, announced on September 18, 2026, reclaims memory as sessions stop using it and starts new instances from prepared snapshots rather than initializing each environment from scratch. AWS says the changes are designed to keep AgentCore's scale-to-zero model while making cold starts less dependent on container size and concurrency.
AgentCore Runtime already offers isolated execution environments, automatic scaling and consumption-based billing. The older design could retain memory until a session ended, however, meaning a long-running or bursty agent could continue paying for a high-water mark after its workload had fallen. Cold starts also became slower as images grew and more sessions arrived at once.
Two Seconds Across Images From 200 MB to 2 GB
AWS tested the new and original runtimes with an empty echo agent that returned its input without calling a model or tool. The test used a Python client on an Amazon Elastic Compute Cloud instance in us-west-2 calling agents in us-east-1 over the public internet. AWS sent 5,000 cold invocations per agent across five image sizes and both runtime versions.
In that setup, the new runtime produced a 75th-percentile cold-start latency of about two seconds for images ranging from 200 MB to 2 GB. AWS says the original runtime rose from roughly 5.4 seconds for the smallest image to nearly 30 seconds for the largest.
The measurements include the network round trip between regions, so they are not a pure reading of the platform's internal startup time. AWS also separates runtime startup from the time an agent spends reasoning and calling models. In the echo test, the agent's own code ran in about 34 milliseconds at the 75th percentile, leaving startup as the main source of delay in that particular benchmark.
The result is an AWS measurement, not an independent comparison with other agent-hosting services. It does show the specific problem AgentCore is designed to address: image size has a much smaller effect on the new runtime's initial response.
AgentCore Loads Once, Then Restores
The new runtime changes how AWS prepares each session. When a runtime is created or updated, AgentCore launches the container, waits for it to become healthy and captures a snapshot after one-time initialization has completed. Loading model artifacts and retrieving static configuration can therefore happen before an individual session begins.
New instances restore that prepared state instead of repeating the entire initialization sequence. AWS also says it trims caches and transient memory from the snapshot, keeping the restored profile roughly steady as the container image grows.
The approach resembles the snapshot-based startup described in the AgentCore developer documentation. The documentation says the newer V2 platform starts agents from a snapshot to keep cold starts consistent across concurrency levels and image sizes.
Memory Billing Moves Closer to Actual Use
Memory management is the other major change. The new runtime begins with a smaller resident footprint, pages memory in as the workload touches it and reclaims memory when the application releases it or cached data goes cold.
Under the earlier model, allocated memory remained associated with the session until termination. AWS says the new model instead tracks changes over the session's lifetime. Customers pay a higher rate for the memory service, but AWS argues that lower memory consumption can reduce the total bill for agents that spend long periods idle or alternate between bursts and pauses.
That trade-off will depend on an agent's allocation pattern. A continuously busy workload may have less unused memory to reclaim, while an agent that waits between tool calls or handles irregular events has more opportunity to reduce its footprint. AWS presents the new pricing behavior as a way to charge for memory actually in use rather than for the largest amount a session has previously held.
V2 Is Available Now, With More Controls Planned
Developers can enable the new runtime by setting the platformVersion parameter to V2 when creating or updating an AgentCore Runtime. AWS has also published samples and a load-test example for evaluating cold-start behavior in a customer's own account.
The release is not the end of AWS's AgentCore Runtime roadmap. AWS lists committed baseline discounts for steady sessions, larger memory and storage configurations, x86 microVM support, suspend-and-resume sessions with memory snapshotting and scoped identities for unattended agents as planned capabilities.
Those additions point to a split in how production teams may use the service. Bursty agents can continue using scale-to-zero consumption, while steady workloads may eventually choose a reserved memory floor. Long-running and specialized workloads can also use the separate AgentCore runtime instances, which AWS made generally available in August for managed EC2-based execution, sessions lasting up to 14 days and GPU-capable infrastructure.
For the release available on September 18, the concrete change is narrower: AgentCore Runtime V2 restores a prepared environment, reclaims memory during a session and asks developers to opt in through one platform-version setting.