# AgentCore Runtime V2 Is the Default: Snapshot Migration Checks

Faster session starts change what belongs in initialization, and an existing runtime does not migrate just because the default changed.

By Paras Madan | 2026-11-13

AWS made AgentCore Runtime V2 the default for new runtimes in 19 Regions on November 12. Existing runtimes remain on their current platform until migrated. The practical change is snapshot-based startup: reusable initialization can become faster, but values that should be fresh must not be copied into every restored instance.

Before moving a working agent, inspect its startup code and deployment routing. A successful cold-start benchmark does not tell you whether restored credentials, request identifiers and tool inventories remain correct.

## What changed, and what did not migrate automatically?

The [AWS announcement](https://aws.amazon.com/about-aws/whats-new/2026/11/new-agentcore-runtime-default/) says V2 supports container images up to 10 GB and sessions up to 8 vCPU and 32 GB memory. AWS reports a sub-two-second P75 session start for a 2 GB image, compared with 29.7 seconds previously. Those are AWS's measurements, not a latency guarantee for your agent.

For an explicit platform choice, use `platformVersion` with `V2`, or `V1` to retain the previous platform for a new runtime. Check Region support rather than assuming the new default applies everywhere.

The general documentation still contains wording that calls V1 the default. The newer dated announcement supersedes that statement for the Regions it lists. This is a good reason to set the platform explicitly in deployment configuration and verify the returned value rather than relying on an omitted field.

## Check platform version separately from application version

Platform V2 is not the same thing as the second configuration version of your agent. The [runtime documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html) distinguishes the startup platform from configuration history.

A read-only check for an existing deployment is:

```bash
aws bedrock-agentcore-control get-agent-runtime \
  --agent-runtime-id YOUR_RUNTIME_ID \
  --region YOUR_AWS_REGION \
  --query platformVersion
```

Replace the placeholders with the runtime and Region you actually use. This is a documented inspection command, not a claim that a deployment was tested for this article.

V2 create and update operations can take several minutes while preparing a snapshot. Wait for a terminal state instead of issuing another update because the first one has not finished. The documented failure mode for overlapping operations includes `ConflictException`.

## Decide what may safely survive a snapshot

AWS's [V2 optimization guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-v2-optimize.html) draws the important boundary between reusable initialization and request-time state. Static dependencies and model weights belong before the snapshot. Expiring credentials, current timestamps and fresh identifiers need request-time handling.

A tool catalog is a less obvious trap. If the catalog changes independently of an agent deployment, capturing it at startup freezes the old inventory. Treat the question as “Can this value remain correct for the lifetime of this deployed version?”, not merely “Is this expensive to fetch?”

The guide also warns that cryptographic-library random state can repeat after restore. Moving a call into a handler is not sufficient if it still uses a problematic cached random-number generator. Follow the documented operating-system entropy guidance for the language and libraries you deploy.

**A snapshot preserves initialized state, including initialization mistakes.** Faster startup makes that state easier to reproduce; it does not make it safe automatically.

## Use a fixture that exposes stale state

For a proposed staging test, use a synthetic support agent with no ability to send messages or change customer records. Give it a static refund-policy document and a fake tool catalog whose version can change during the test. This is a test design, not a reported benchmark.

Start several separate sessions and collect request identifiers and timestamps. Then change the fake catalog without redeploying the agent and make a new request. Record whether the agent sees the updated version, and whether independent requests remain distinguishable in the logs.

Next, exercise credential refresh using a test credential with a deliberately short lifetime. Verify the application refreshes it through the intended mechanism rather than preserving a value from startup. Do not use production secrets or log raw credentials to make this test easier.

The pass condition is not just that the agent answers. It must answer with the right configuration, use current authorization and leave records that distinguish one request from another. Measure startup time only after those correctness checks pass.

## Avoid moving production through the DEFAULT endpoint by accident

The [versioning guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agent-runtime-versioning.html) says a runtime update creates an immutable configuration version and moves `DEFAULT` to that latest version. A separately named endpoint can remain pinned until explicitly updated.

Check which endpoint production clients invoke before using an update as a staging experiment. If they use `DEFAULT`, the deployment operation and the production routing decision are coupled. A named production endpoint gives your team a clearer promotion boundary, provided its configuration is actually verified.

Keep a record of the previous version and endpoint mapping, the selected platform and the staging results. A rollback plan should identify the configuration to restore, not just say “switch back to V1.”

The useful outcome is a faster agent whose identity, authorization and configuration remain correct across restores. If the team cannot demonstrate those properties yet, the new default is a reason to review its deployment template, not a reason to rush a migration.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain infrastructure changes and deployment tradeoffs in content developers can actually use.

[Book a 30-minute call](https://cal.com/paras-madan/30min).