AWS made its next-generation Amazon Bedrock AgentCore runtime the default for new runtimes in 19 AWS Regions on November 12, 2026. Existing runtimes stay on their current version until developers move them. The update combines snapshot-based session startup, higher compute and memory ceilings, and changes intended to reduce billed memory for agents that pause between turns. (AWS announcement)
This is a default rollout and capability expansion, not a new AgentCore product launch. The immediate operational change is that creating a runtime without explicitly selecting the earlier version can now put an agent on V2.
The most consequential migration detail concerns initialization. V2 restores sessions from an initialized snapshot, so values created during startup can be copied into multiple sessions. Teams should check where they generate credentials, random seeds and session-specific state before moving production workloads.
New Runtimes Default to V2, With Explicit Version Control
AWS gives developers control through the platformVersion parameter when creating or updating a runtime:
| Deployment choice | Setting or behavior |
|---|---|
| Create a runtime using the new default in a rollout Region | V2 is selected by default |
| Move an existing runtime to the next generation | Set platformVersion to V2 |
| Keep a new runtime on the earlier generation | Set platformVersion to V1 |
| Leave an existing runtime unchanged | It remains on its current version |
AWS also directs developers to select V2 explicitly in Regions where the next generation is available but is not yet the default. Its FAQ lists no announced deprecation date for V1. (AWS announcement, AgentCore FAQ)
That makes this a migration teams can schedule. There is no need to treat the default change as an instruction to update every existing agent immediately.
I’d explicitly set the version in production deployment configuration during the transition. The reason is reproducibility: a configuration that leaves runtime selection implicit can produce different results as regional defaults change. Pinning V1 or V2 makes that infrastructure choice visible during review.
Snapshot Restores Cut AWS’s Reported Session Startup Time
V2 restores each session from a snapshot of an initialized agent. That moves reusable initialization work out of the path each new session would otherwise need to repeat.
AWS publishes this comparison in its November announcement:
| AWS-reported measurement | Previous generation | Next generation |
|---|---|---|
| Session startup at P75, using a 2 GB image | 29.7 seconds | Under 2 seconds |
P75 means the 75th-percentile startup time: roughly three-quarters of measured starts were at or below that threshold. It is not a maximum or a guarantee for every session. (AWS announcement)
AWS’s accompanying technical post describes startup as up to 15 times faster. These are first-party measurements, and the announcement does not provide enough benchmark detail to predict a particular agent’s results. Image contents, initialization work and session behavior remain important when evaluating the change. (AWS technical post)
The timing also has a specific scope: it measures session startup, not runtime deployment. AWS’s announcement gives no equivalent duration for creating or updating a runtime. A sub-two-second session restore should therefore not become a two-second deployment assumption in release planning.
For interactive agents, the useful question is how much startup contributes to the wait a user actually sees. Faster restoration can remove infrastructure delay, but model inference and tool execution still take their own time.
Higher Limits Make Heavier Sessions Possible
The next-generation runtime supports:
- Up to 8 vCPUs for session compute.
- Up to 32 GB of memory.
- Container images up to 10 GB.
AWS describes the compute and memory expansion as four times the previous generation’s scale. It names large codebase compilation, browser-driven workflows and local model loading as workloads the larger environment can accommodate. (AWS announcement, AWS technical post)
These are capacity ceilings, not a statement that every session receives or consumes the maximum allocation. The practical benefit is more room for workloads that would otherwise need to offload a heavy step to another service.
Each session still runs in its own hardware-isolated Firecracker microVM. The larger resource envelope therefore preserves the session isolation model AWS describes for AgentCore.
My view is that the resource expansion matters most when it simplifies an agent’s execution path. Keeping a compilation or browser workflow inside its session may reduce orchestration work, provided the task fits within the documented limits.
Scale-to-Zero Changes Memory Economics
AWS says idle agents scale to zero and memory is reclaimed within minutes of release. For multi-turn agents, it reports up to 68% less billed memory per session. (AWS announcement)
The distinction between billed memory and the total application bill matters. The published percentage describes a memory-billing result, not a universal reduction across an agent’s model calls, tools and other services.
Multi-turn agents are a logical target for this change because their work can be intermittent. A session might perform a burst of computation, wait for another user message, then resume. Reclaiming resources during those gaps can change the economics compared with retaining memory throughout.
The reclamation window also deserves attention. AWS says memory is reclaimed within minutes of release; it does not describe an instantaneous drop in memory charges whenever useful work pauses. I’d avoid modeling every brief gap between turns as a zero-memory interval.
A meaningful evaluation should therefore include representative pauses, session lengths and release behavior, alongside response latency. A continuously busy agent and one that spends long periods waiting may see different benefits.
Snapshot Initialization Is the Main Migration Check
AWS’s FAQ warns that values created during startup can be shared across sessions restored from the snapshot. Examples include random seeds, credentials, timestamps and open connections. Session-specific values should instead be created per session. (AgentCore FAQ)
The key distinction is between separate execution environments and unique initial state. Hardware-isolated microVMs can still begin with copies of the same captured value. Isolation does not automatically make a startup-generated identifier or credential unique to each restored session.
Frequently Asked Questions
4 questions
1Will Existing AgentCore Runtimes Automatically Switch to V2?
No. AWS says existing runtimes remain on their current version until moved. Set platformVersion to V2 when updating to select the next generation.
