By ByteBot
AWS shipped AgentCore Runtime V2 on September 18 — and if your agents are still running on V1, there is one number worth your attention: cold starts dropped from up to 30 seconds to under 2 seconds, flat, regardless of container image size. That 93% improvement is not a benchmark tweak. It changes whether bursty agent deployments are viable at all.
What V1 Actually Cost You
The V1 cold start problem was straightforward and expensive. A 2 GB container image could take 30 seconds to start. A 200 MB image took 5.4 seconds. The only practical solution was keeping agents warm continuously — paying for idle compute around the clock to avoid making users wait. For bursty workloads, that math did not work.
V1 also allocated memory at peak and held it throughout the session, even when nothing was happening. You paid for reservation, not usage.
How V2 Fixes It
The architecture change is a snapshot-and-restore model. When you create a V2 runtime, AWS prepares and snapshots the execution environment once — including your agent’s code and all dependencies. Every subsequent cold start resumes from that snapshot instead of running full initialization.
The result: a P75 cold start of 1.9 to 2.0 seconds for images from 200 MB to 2 GB. Container image size is no longer a startup variable. Platform overhead also drops from roughly 100 ms to 34 ms.
The trade-off is a one-time cost: creating a V2 runtime now takes around 3.5 minutes because the snapshot is prepared upfront. That is acceptable for deployment pipelines. It is the per-session latency that matters in production, and that is now consistently fast.
The Billing Change Nobody Is Talking About
The cold start story gets the headlines. The memory billing change is more impactful for teams running agents at scale.
V2 uses consumption-based billing: memory is allocated on demand and reclaimed when sessions go idle. Pricing is $0.1276 per vCPU-hour and $0.0169 per GB-hour — but on actual usage, not peak reservation. If your agents spend half their time waiting on external APIs, you pay for roughly half the memory you would have paid for under V1.
AWS acknowledges the per-unit rates are higher, but the reduced footprint lowers actual bills for bursty workloads. If you were over-provisioning memory defensively under V1 — and most teams were — this is the more material improvement.
Lambda MicroVMs vs AgentCore Runtime: Stop Treating These as Competitors
With both services now running on Firecracker microVMs, there is genuine confusion about which to pick. The answer depends on one question: who runs the code — your agent, or your users?
AgentCore Runtime is for running your agent. Lambda MicroVMs are for giving users or LLM-generated code their own isolated execution environments. These are different problems.
| Dimension | AgentCore Runtime | Lambda MicroVMs |
|---|---|---|
| OS access | Restricted (managed) | Full Linux VM |
| Fleet management | AWS handles it | You handle it |
| Billing | CPU-only (I/O excluded) | vCPU + memory/second |
| Region coverage | 15 regions | 5 regions |
| Built-in protocols | MCP, A2A, HTTP | None |
| Best for | Agent reasoning layer | Per-user code sandboxes |
If you are building a coding assistant, the right answer is both. AgentCore Runtime handles the reasoning and conversation; Lambda MicroVMs sandbox per-user code execution. Results flow back to the agent as tool output. Forcing either service to do the other’s job creates unnecessary complexity.
Migrating: One Field, One Gotcha
The migration path is a single parameter change on CreateAgentRuntime or UpdateAgentRuntime:
platformVersion: "V2"Existing agents can update in place without rebuilding. One thing to verify first: module-level code in your agent now runs at snapshot time, not at session start. Side effects at module level — open database connections, file handles, anything stateful — get baked into the snapshot and shared across sessions. Keep those inside function bodies.
Note for IaC teams: Terraform and AWS Controllers for Kubernetes do not yet expose platform_version in their providers. You will need to use the SDK or CLI directly until those issues are resolved.
What to Watch Next
AWS has committed to several V2 follow-on capabilities: suspend/resume with memory snapshots (pause an agent mid-task, resume exactly where it stopped), committed baseline discounts for predictable workloads, x86 microVM support (currently arm64 only), and session context keys for scoped identity on unattended agents.
The suspend/resume feature is the one worth tracking. Long-horizon agents that run for hours or days are the next practical frontier, and reliable pause/resume is the infrastructure primitive that makes them viable. V2’s cold start fix was the prerequisite. Suspend/resume is what comes next.
The AgentCore samples repository includes a load test that validates cold start latency from your own AWS account — worth running before you commit latency budgets.
