The announced default and the observed behavior
The November announcement changes the version assigned to a new runtime when platformVersion is omitted; it does not automatically migrate existing runtimes. V2 had been available since September 18, 2026, but initially required an explicit version setting.
In the developer's November 13 test, creating a runtime through the CLI without --platform-version produced V1. The Tokyo console also preselected V1, while marking V2 as "recommended." AWS's documentation on how AgentCore Runtime works still identified V1 as the default.
Those observations did not establish whether the announced change was rolling out gradually. The author also could not confirm whether AWS had given advance notice of the default change.
Updating existing agents and rolling back
AWS's AgentCore FAQ says an existing agent moves to V2 on its next update through the API, console, CLI or infrastructure as code, unless that update explicitly sets platformVersion to V1. Agents left untouched remain on V1. The FAQ also says users can return an agent to V1 at any time, and AWS has announced no V1 deprecation date.
In the hands-on evaluation, updating the runtime was sufficient to migrate from V1 to V2 through each of three paths: the CLI, Management Console and CloudFormation. The migrations took about 3 to 3.5 minutes. Invocations continued to succeed during the updates, and the author observed no interruption to running sessions before or after migration.
All three methods also supported a return from V2 to V1. Those rollbacks took between a few seconds and 17 seconds. These results describe the tested agent and environment, rather than a guarantee for every deployment.
What the Tokyo test measured
The evaluation used a roughly 43.5 MB linux/arm64 container image containing a small HTTP server written with Python's standard library. The agent spent 20 seconds initializing before serving requests, then returned both startup-generated values and values generated for individual requests. Testing took place on November 13, 2026, in ap-northeast-1, with public networking.
Runtime creation was much slower on V2. The explicitly selected V1 runtime reached READY in about 1.4 seconds, while the runtime created without a version setting used V1 and took about 1.2 seconds. Explicit V2 creation took about 199 seconds. V2 prepares a snapshot of the initialized agent, and AWS documentation says its creation and update operations take minutes.
For a set of 10 invocations, each using a new session, V1 recorded a median elapsed time of 0.60 seconds, with a range of 0.43 to 1.24 seconds. V2's median was 1.79 seconds, with a range of 1.63 to 3.68 seconds. The first V2 call accounted for the 3.68-second maximum.
The author's broader summary also reported a V1 cold start of about 23.7 seconds in some cases, compared with roughly 0.4 to 1.2 seconds in others. V2 generally took about 1.6 to 2.2 seconds, apart from its first call. The measurements therefore did not show V2 beating every V1 invocation.
Snapshot behavior was also visible in the returned data: multiple V2 sessions shared values generated at startup, as well as the value produced by Python's random function inside the handler. AWS documentation cautions that snapshot restoration changes how developers need to structure agent code.
AWS's performance and pricing figures
V2 starts sessions by restoring an already-initialized agent from a snapshot. At launch, AWS reported 75th-percentile cold-start times of about 1.9 to 2.0 seconds for V2, versus about 5.4 to 30 seconds for V1, across container images ranging from 200 MB to 2 GB.
The AWS Machine Learning Blog described measurements covering 5,000 cold starts, with requests sent from EC2 in us-west-2 to an echo agent in us-east-1. The November announcement separately cited a 29.7-second P75 for V1 and a sub-2-second P75 for V2 with a 2 GB image. The hands-on author did not independently verify those AWS figures.
The pricing page lists consumption rates of $0.0895 per vCPU-hour and $0.00945 per GB-hour of memory for V1, compared with $0.1276 per vCPU-hour and $0.0169 per GB-hour for V2. AWS's blog says reduced billed GB-hours outweigh the higher rates for most agents, lowering their bills. The evaluation did not verify billing amounts.
Resource controls and deployment limits
V2 supports a committed resource baseline through resourceConfigurations. AWS's November 2026 release notes specify configurations ranging from 0.25 vCPU with 1 GB of memory to 2 vCPU with 8 GB. During peak activity, a session can burst to as much as four times its baseline, subject to a maximum of 8 vCPU and 32 GB. The committed baseline carries a lower rate than consumption pricing.
The test author could configure resourceConfigurations through the API, but found no corresponding option on the console's update screen or in the CloudFormation template at the time. The console also indicated that the "Instances" compute type was unavailable with V2.
How V2's availability expanded
Amazon Bedrock AgentCore became generally available on October 13, 2025, in nine AWS Regions, including Tokyo, according to AWS What's New. V2 followed on September 18, 2026, initially in us-east-1, us-east-2, us-west-2, eu-west-1 and ap-northeast-1.
October release notes documented a 4 KB environment-variable limit for V2 and added support for session context keys and FUSE mounts. November notes listed a 10 GB container image limit, 250 concurrent connections per session, resourceConfigurations and a build-time warmup hook.
The November release notes also named nine additional V2 Regions: Canada (Central), Europe (London), Europe (Milan), Europe (Paris), Europe (Spain), Asia Pacific (Malaysia), Asia Pacific (Seoul), Asia Pacific (Thailand) and South America (São Paulo). The November 12 default-version announcement cited availability in 19 Regions, including Tokyo.
