AgentCore Runtime V2 Default: Existing Runtimes and Conflicting Docs

Where does the new default apply, and why do the docs differ?

On November 12, 2026, AWS announced that new Amazon Bedrock AgentCore runtimes use the next-generation V2 platform by default, naming 19 AWS Regions where it is the default. At the same time, the Runtime platform versions developer guide reviewed for this article still calls V1 the default, says a create request without platformVersion uses V1, and lists only 10 Regions with V2 availability. These are directly conflicting current official statements; they do not confirm actual behavior for every account or target Region.

The announcement lists US East (N. Virginia and Ohio), US West (Oregon), Canada (Central), South America (São Paulo); Europe (Frankfurt, Ireland, London, Milan, Paris, Spain and Stockholm); and Asia Pacific (Malaysia, Mumbai, Seoul, Singapore, Sydney, Thailand and Tokyo). This is the announcement’s list, rather than a rollout we verified in each account or Region.

The guide’s 10-Region list contains N. Virginia, Ohio, Oregon, Frankfurt, Ireland, Stockholm, Mumbai, Singapore, Sydney and Tokyo. Before deploying, check actual support in the target Region and the value returned for the resource, instead of relying only on conflicting descriptions of the default.

Existing runtimes require an explicit migration; keep version identifiers separate

The announcement is explicit: existing runtimes stay on their current version until you move them. If you decide to switch, set platformVersion to V2 in the applicable create or update configuration. To keep a new runtime on the previous generation, the announcement specifies V1. This describes the configuration approach; this article did not create or update any AWS resource.

V1 and V2 in platformVersion control how AgentCore prepares and starts the agent. Runtime configuration versions record configuration history, including the container image, protocol and network settings. A newly created resource begins at configuration version 1, and later configuration updates produce new immutable versions. A new runtime on platform V2 can still be configuration version 1.

The AWS CLI documentation shows --platform-version V2 for an explicit selection. For updates, the guide says omitting platformVersion preserves the current platform. For creation, however, its default conflicts with the new announcement, which makes an explicit platform selection useful.

Use a read-only query to confirm one resource’s platform

The documented CLI query is: aws bedrock-agentcore-control get-agent-runtime --agent-runtime-id YOUR_RUNTIME_ID --query platformVersion. YOUR_RUNTIME_ID is a placeholder for a resource you are authorized to access. In the correct account and Region, this query reads the platformVersion returned for the resource; it does not create or update the runtime.

This article did not run the command, access an AWS account or confirm any resource’s status. A V1 or V2 result for one resource does not by itself establish defaults or eligibility in other accounts or Regions. Check the platform value, configuration version and Region together to avoid confusing these different identifiers and scopes.

Allow time for V2 initialization and a healthy snapshot

V2 first prepares a snapshot of the initialized environment, then restores new sessions from it. The announcement says each session still runs in its own hardware-isolated Firecracker microVM and idle agents can scale to zero. Sessions scale up to 8 vCPUs and 32 GB of memory, with container images up to 10 GB.

The developer guide warns that V2 creation and updates take several minutes because of a one-time snapshot preparation overhead. This refers to preparation time, rather than a separately verified fee. AgentCore takes the snapshot on the first healthy /ping response, so report healthy only after initialization is complete. If the container does not report healthy within 120 seconds of startup, creation fails with a health-check error.

A create or update API call can return while the runtime is still CREATING or UPDATING. Read its status through GetAgentRuntime and wait for READY or a failure status ending in FAILED before the next operation. An overlapping update or delete can return ConflictException. A returned request does not establish that the runtime is ready.

Faster startup and lower billed memory have specific scopes

AWS gives a startup example for a 2 GB container image: session startup at P75, the 75th percentile, is under 2 seconds, compared with 29.7 seconds on the previous generation. It also reports up to 68% less billed memory per session for multi-turn agents, and says released memory is reclaimed within minutes. These figures have specific image, metric and usage scopes; they are not our measurements of a real workload.

Up to 68% less billed memory per session does not mean a 68% reduction in the total bill. This article did not verify specific rates, account discounts or other AWS service charges. Budget for migration using your own usage and applicable prices, rather than applying the announcement’s maximum change directly to the amount payable.

Confirm three things before planning a migration

First, identify the target account, Region and required platform. Where the announcement and guide differ, choose explicitly and confirm the value actually returned for the target resource. Second, record the platform and configuration versions separately, check that initialization can report healthy in time, and allow several minutes for V2 snapshot preparation.

Third, evaluate compatibility, startup time and cost in your own authorized environment before deciding on the next release. A runtime platform update does not replace IAM permission or regional eligibility checks. Changing a proxy exit cannot grant platform eligibility, change billing rules or prove that a Region has received the rollout.