AgentCore Runtime V2 adds memory reclamation and snapshot-based startup, with cold starts of about two seconds in AWS tests

AWS launched Amazon Bedrock AgentCore Runtime V2 on September 18, updating memory management and cold starts for agent sessions. The new version continues to isolate sessions using microVMs, but now loads memory on demand and reclaims freed or cold pages, reducing persistent resource usage after brief spikes during long-running tasks. It is initially available in five regions, including Tokyo. [Official announcement](https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/)

The startup process moves initialization to snapshot creation: the platform starts the container, waits for health checks to pass, and then saves the execution environment. New instances are restored from the snapshot, reducing repeated loading of packages and static configuration. AWS says it removes unnecessary transient state so that snapshot size does not grow in step with the container image. [Architecture overview](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)

With this design, application testing should cover whether configuration obtained during initialization needs refreshing and whether network connections can be reestablished after restoration. The official figures alone do not validate these workload characteristics. Teams should also measure the time until the environment is ready separately from the time to the first useful response to assess the improvement users actually experience.

The official tests isolate platform overhead using an agent that simply returns its input without calling models or tools. A client in the western United States made cross-region calls to the eastern United States, with 5,000 cold calls for each combination of version and image size. Across images ranging from 200 MB to 2 GB, the new version's 75th-percentile latency was about two seconds, compared with approximately 5.4 to 30 seconds for the previous version. These figures include cross-region network round trips but exclude inference and tool execution, so they should not be treated as response times for complete agent tasks. [Test methodology](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)

To deploy the new version, set `platformVersion` to `V2` when creating or updating a Runtime. The September 15 release notes for AWS's Go SDK added this field for creating, updating, and retrieving Runtimes, allowing deployment code to explicitly select and verify the platform version. Teams with existing systems should first confirm that their SDK supports the field, then use representative tasks to compare startup latency distributions and memory usage. [How to enable it](https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/), [SDK release notes](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2026-09-15)

Costs also need to be recalculated. AWS says the new version has a higher memory unit rate, with total savings expected to come from consuming fewer GB-hours. Agents with large amounts of resident data may therefore see different benefits. Support for x86, session pause and resume, and more granular lifecycle controls remain planned features. [Feature limitations](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)

Current documentation still treats session state as ephemeral, requiring separate persistence arrangements to retain it after termination. An initialization snapshot is not a backup of task progress; engineers should design recovery procedures around currently available capabilities. [Session documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html)