AWS announces AgentCore V2 as the default for new runtimes in 19 regions
Edited and reviewed by AI Ping Editorial Team
3-line summary
- AWS says new AgentCore runtimes default to V2 in 19 regions, including Seoul and Tokyo.
- Existing runtimes stay on their current version. AWS’s developer guide still listed V1 as the default when checked.
- In AWS’s 2 GB image test, the 75th-percentile session startup time fell from 29.7 seconds to under two seconds.
Amazon Web Services said on November 12 that it was making V2 the default for new Amazon Bedrock AgentCore runtimes in 19 regions, including Northern Virginia, Seoul and Tokyo. The runtime is the managed environment where an AI agent receives requests and runs its code and tools. The announcement changes what teams get when they create an environment. An existing runtime stays on its current generation until its operator moves it.
When AWS introduced V2 in September, customers had to select the platform version in a supported region. The new notice lists the regions where AWS says that choice now defaults to V2. AWS’s developer guide still listed V1 as the default when checked on November 13. The announcement describes an explicit version choice on creation or update, and AWS’s runtime lookup API has a field that reports which platform version a runtime uses.
Starting from a saved state
V2 prepares an agent’s environment before serving requests and saves a snapshot of the initialized state. When a new session needs to start, the service restores that state. For an agent that loads a large library or a local model, part of the preparation can happen at deployment time. Each session still runs in a dedicated microVM with its own CPU, memory and filesystem resources.
AWS reported a startup time of under two seconds on V2 for a 2 GB container image, compared with 29.7 seconds on V1. Both figures describe the 75th percentile of session startup times. That leaves room for slower starts and excludes the time an agent spends waiting for a model or tool to answer. The September engineering write-up describes a test with an agent that echoed its input without calling a model or tool. The measurement included a network round trip from the western United States to the eastern region hosting the agent. An individual V2 session can use up to eight virtual CPUs and 32 GB of memory. The developer guide lists a 10 GB limit for compressed container images and specifies a higher minimum memory setting for images larger than 2 GB.
Memory use and the bill
V2 can reclaim memory within minutes after an agent releases it. AWS says this can reduce billed memory per session by up to 68 percent for agents that handle multiple turns. A service that pauses between questions has a different usage pattern from one that keeps its CPU and memory busy throughout a job. The reduction AWS cites measures billed memory, one part of the runtime bill.
AWS lists a V2 consumption rate of $0.1276 per virtual CPU-hour and $0.0169 per GB-hour of memory. The equivalent V1 rates on the same page are $0.0895 and $0.00945. The new generation has higher unit rates, so the bill also depends on how much CPU time and memory the session uses. The pricing documentation includes system overhead in billed usage and specifies a minimum billable amount of memory.
Deploying a V2 runtime
New and existing runtimes take different paths to V2. On an existing deployment, the platform change triggers snapshot preparation as part of the update. AWS’s guide says creating or updating a V2 runtime can take several minutes before it is ready. The container has 120 seconds after startup to report itself healthy. The time to prepare and deploy a runtime and the time to open a new session after deployment are separate measurements.
The developer guide also distinguishes reusable setup, such as loading libraries, from work that needs to happen on each request. State created during setup is present in each instance restored from the snapshot. Request identifiers and timestamps that need to be fresh are examples of values the agent should calculate during request handling.
AWS tracks the platform generation separately from revisions to a runtime’s deployment configuration. Updating the configuration creates a new revision and moves the default endpoint to it. Teams can also point a separate endpoint at a particular revision. The November announcement covers the default for newly created runtimes in the listed regions. Moving an existing runtime to V2 remains a separate update.
Sources
- November 12 AgentCore Runtime default and regional rollout — AWS
- November 12 AgentCore Runtime compute and memory changes — AWS
- September AgentCore Runtime V2 launch and benchmark conditions — AWS
- AgentCore microVMs, platform versions and deployment — AWS Documentation
- AgentCore Runtime V2 startup and request handling — AWS Documentation
- Amazon Bedrock AgentCore pricing — AWS
- GetAgentRuntime response fields — AWS Documentation