AWS Makes AgentCore V2 Default as Startup Tokens Can Repeat

If you create an Amazon Bedrock AgentCore agent without naming a platform version, it may run on Runtime V2, where a token, ID or key generated at startup repeats in every session. AWS made it the default for new runtimes on November 12 in 19 Regions. V2 starts each session by restoring one memory snapshot of your initialized agent. AWS's V2 optimization guide says snapshot-safe builds of cryptographic libraries "don't reseed after a restore" on AgentCore, and that Node.js crypto.randomUUID() and crypto.randomBytes() "can repeat across instances, even when you call them in your handler." Pin platformVersion in infrastructure code, move per-session values into the request handler, and redo the cost forecast, because V2's list rates are about 43% higher per vCPU-hour and 79% higher per GB-hour than V1's.

What Changed on November 12?

New AgentCore runtimes now default to V2, and existing runtimes stay where they are. The What's New post says existing runtimes stay on the current version "until you move them." You set platformVersion to V2 to migrate one, or to V1 to keep a new runtime on the old platform. The default applies in five Regions in the Americas (including both US East Regions and US West Oregon), seven in Europe and seven in Asia Pacific.

V2 itself is not new. AWS announced it on September 18, and the release notes have added Regions and features every few weeks since. What changed this week is that an agent you never consciously moved can land on it.

The case for V2 is strong, and it is worth stating before the caveats. AWS says sessions on a 2 GB image start in about 2 seconds at P75, against nearly 30 seconds on V1. Sessions can scale to 8 vCPU and 32 GB, container images can be 10 GB instead of 2 GB, and AWS says V2 bills for the memory an agent uses rather than holding its peak allocation. Those cold-start figures come from AWS's own test of an empty echo agent, as Unite.AI noted when V2 launched, so a real agent with real dependencies will see different numbers. For a team running a large image, though, a 2 second cold start is a real improvement.

One inconsistency should push you to set the field yourself. On November 13, the platform versions section of the AgentCore developer guide still read "V1 is the default" and "if you omit platformVersion when you create a runtime, the runtime uses V1." The announcement says the reverse. You should not find out which one your account follows from an incident. CloudFormation's AWS::BedrockAgentCore::Runtime resource now has a PlatformVersion property that updates without interruption, so there is no tooling excuse in CloudFormation. Unite.AI reported in September that CloudFormation and the CDK could not set it at launch, so check that your CDK and Terraform provider versions expose it before you assume they do.

---

Why Can a Snapshot Repeat Your Agent's Random Values?

A snapshot restore copies one frozen memory image into every new instance, so anything random that was already in memory is copied too. AWS's guide puts it directly: "every instance created from that snapshot starts with an identical copy of the memory captured at snapshot time. This includes the internal state of random number generators inside cryptographic libraries, and any keys, tokens, or identifiers your agent created during initialization." AgentCore takes one snapshot per agent version and reuses it until you create or update the agent, so a value baked in at startup lives as long as that version.

The guide lists this as a current limitation: "On AgentCore Runtime, snapshot-safe builds of cryptographic libraries don't reseed after a restore. This applies to both direct code deployments and container deployments." Its workarounds:

1. Generate secrets, keys, tokens and session identifiers while handling a request, never at startup.
2. Even inside the handler, take random bytes from the operating system: Python's secrets or os.urandom, Go's crypto/rand, or a read of /dev/urandom. The guide says not to use random values from a library such as OpenSSL, "because they can repeat across instances."
3. In Node.js, read /dev/urandom. The crypto module uses OpenSSL, and AWS names crypto.randomBytes(), crypto.randomUUID() (also with disableEntropyCache: true), crypto.randomInt(), crypto.getRandomValues() and packages built on them, such as uuid, as sources whose values can repeat.

Python has its own trap. The guide notes that the random module "is likewise seeded at startup, so restored instances repeat the same sequence." Python's uuid.uuid4() and secrets are fine when called per request.

The Node.js case is the one most teams will miss, because moving the call into the handler does not fix it. Look for anything your agent treats as unique: session tokens, OAuth state values and PKCE verifiers, idempotency keys sent to payment or ticketing APIs, encryption nonces, and request IDs your logs and dedupe logic rely on. If two sessions can produce the same idempotency key, a downstream API can treat the second customer's request as a retry of the first.

Which Other Startup Values Go Stale After a Restore?

Time, credentials and identity all freeze at snapshot time, and the guide's table covers each. A timestamp captured at startup is fixed at the moment of the snapshot. time.monotonic() does not advance across a restore, so "a duration measured from a startup reference is wrong without looking wrong." Credentials loaded at startup can expire before an instance starts, so refresh them in the handler.

Instance identity breaks your observability. Every restored instance reports the hostname localhost and PID 1, which AWS warns "collapses metrics, log streams, and lock owners across the fleet." If your logging library tags lines with hostname and PID, every session now looks like one process. Google's Agent Substrate has a related quirk: it drops database and MCP connections at suspend.

Configuration can freeze too. AWS's example is a tool catalog fetched from AgentCore Gateway at startup, which looks like an ideal thing to cache but freezes the agent's tool inventory at snapshot time. Open sockets do not survive a restore, though client setup such as endpoint and credential resolution does, so the first call after a restore reconnects. Do not bind to a fixed source port, which can collide with that reconnection.

The rule AWS gives is simple enough to put in a code review checklist: compute a value at startup only if it stays the same for the life of the snapshot, and compute it in the handler if it varies per request or can expire.

How Did Lambda Handle the Same Problem?

AWS has solved this problem before on Lambda, which shows what AgentCore does not yet do. Marc Brooker and five co-authors described it in the 2021 paper Restoring Uniqueness in MicroVM Snapshots, which identifies two risks in cloning memory snapshots: saved memory can hold secrets such as keys, and clones must regain uniqueness for UUIDs, secrets and nonces.

Lambda SnapStart's uniqueness guidance shows the platform-side answer. On restore, Lambda "reseeds the kernel random number generator from /dev/random and /dev/urandom with fresh entropy." It ships a SnapStart-compatible OpenSSL build (openssl-snapsafe-libs), lists minimum AWS-LC versions that maintain randomness automatically, offers runtime hooks that run after a restore, and provides an open-source SpotBugs scanner for Java code that assumes uniqueness.

AgentCore V2 has the fast starts and, so far, only part of that safety net. Its build warmup lifecycle hook runs memory and disk calls while AWS prepares the snapshot, which helps load time. The V2 guide describes no after-restore hook and states plainly that snapshot-safe crypto libraries do not reseed. Until AWS changes that, the fix lives in your code.

---

Will Runtime V2 Cost You More or Less?

V2 charges higher unit rates and bets that you will bill fewer units, so the answer depends on how much memory your agent holds while it waits. Rates from the AgentCore pricing page, checked November 13, 2026:

Rate	V1	V2 consumption	V2 committed baseline
CPU, per vCPU-hour	$0.0895	$0.1276	$0.0997
Memory, per GB-hour	$0.00945	$0.0169	$0.0132

At those rates, V2 needs about 30% fewer billed vCPU-hours and about 44% fewer billed GB-hours than V1 just to break even on each meter. AWS's blog frames it as "You pay a higher rate but on far fewer GB-hours." V2 reclaims memory throughout a session, and the pricing page says idle memory is reclaimed after 120 seconds and CPU is not charged during I/O wait.

AWS's own V2 example shows the stakes: a customer support session with 60 seconds of active CPU at 1 vCPU costs $0.002127 for CPU and $0.004576 for memory, $0.006703 in total. By my arithmetic on the same page's rates, that memory charge is about 0.27 GB-hours. V2 wins that example only if V1 would have billed roughly 0.55 GB-hours or more for the same session, about twice as much. An agent that idles between turns with most of its memory released should clear that bar. An agent that keeps a large in-memory index or cache resident for the whole session may not, and on the consumption rate it will pay more. If you already priced AgentCore against Google and Microsoft, the V1-era comparison needs re-running on these rates.

That second kind of agent is what the committed baseline is for. A resource configuration sets a baseline from 0.25 vCPU and 1 GB up to 2 vCPU and 8 GB, lets sessions burst to four times the baseline, and bills the baseline plus any burst at the lower committed rate until the session ends. One detail will bite a CI pipeline: on update, AWS replaces the resource configuration with whatever your request contains, and omitting resourceConfigurations puts the runtime back on consumption pricing. An image-only update that leaves the field out quietly changes your rate.

Deployment timing changes too. A V1 runtime reaches READY in seconds. A V2 create or update runs for several minutes while AWS prepares the snapshot, your container must report healthy within 120 seconds, and an old snapshot can take up to 8 hours to delete while existing sessions finish. Deploy scripts with short timeouts will fail.

What to Do Before Your Next Agent Ships

Pin the platform version first, then audit the code, then price it.

This Week:

1. Add an explicit platformVersion to every AgentCore runtime in your CloudFormation, CDK and Terraform code, and fail the pipeline when it is missing. Pick V1 for anything you have not audited.
2. Inventory what you already run. aws bedrock-agentcore-control get-agent-runtime --agent-runtime-id <id> --query platformVersion returns the platform for each runtime; list any created since November 12.
3. Have each Node.js agent owner search for crypto.randomUUID, crypto.randomBytes, crypto.randomInt, getRandomValues and imports of uuid, and replace them with reads from /dev/urandom wherever the value must be unique.

This Month:

4. Write a restore test. Deploy the agent to a staging V2 runtime, open 20 sessions, and have each return one value generated at startup and one generated in the handler. Any duplicate fails the build. Run it again after every dependency upgrade.
5. Move credentials, timestamps, elapsed-time references and any Gateway tool catalog into the handler. Replace hostname and PID in log and metric labels with a per-request ID.
6. Run one representative agent on V2 consumption pricing for two weeks and compare the CPUUsed-vCPUHours and MemoryUsed-GBHours metrics against its V1 bill.

Before You Migrate a Production Runtime:

7. If the agent holds memory for the whole session, size a committed baseline from those metrics and carry the same resourceConfigurations value in every update call.
8. Raise deploy timeouts to cover a multi-minute CREATING or UPDATING state, and poll get_agent_runtime until it reports READY or a failed status.

The Bottom Line

Snapshot restore buys fast cold starts at the cost of uniqueness, and Lambda paid that cost inside the platform with kernel reseeding, patched crypto builds and restore hooks. AgentCore V2 currently leaves it to the agent developer, and since November 12 it is the default you get when you leave the field out. Audit and pin your agents now; the restore test you write will keep working if AWS ships reseeding later.

Set platformVersion explicitly in every template before your next deploy.

Continue Reading

• Google Agent Runtime's $510 Meter Beats AgentCore's $846
• AWS Agents Run 14 Days. The Session Is the Only Wall.
• Agent Substrate on GKE Drops Database and MCP Connections at Suspend
• E2B vs Modal vs Daytona: Idle Time Sets Sandbox Bills
• Microsoft Starts Billing for Copilot Harness on December 1
• Rotate Your Bedrock Keys If You Used These Nine AI Platforms