Skip to content

AWS Reworks Bedrock AgentCore to Cut Idle Memory Costs and Cold-Start Delays

Short answer

AWS released a new version of the Bedrock AgentCore runtime that reclaims memory the moment an agent session stops using it, instead of billing for peak usage all session long, and holds cold-start latency near 2 seconds regardless of container size, versus up to 30 seconds on the previous runtime.

What this means for operators

If your support or sales agents run on Bedrock AgentCore, this changes two numbers you actually pay attention to: the AWS bill and how long a customer waits when an idle agent wakes back up. Previously, a long-running or bursty agent kept paying for its memory peak the whole session, and cold starts got worse as your container image or concurrency grew — a real problem for agents that sit quiet most of the day and spike during business hours. The new runtime bills closer to actual usage and keeps cold starts flat at roughly 2 seconds no matter the image size, so teams running several agents (a support triager, a lead-qualification bot, an internal ops assistant) can leave them scaled to zero between requests without the old latency penalty when a customer or rep hits them cold. It's an infrastructure change, not a new capability, but it lowers the operating cost of exactly the pattern most 10-200 person companies use: several purpose-built agents that are mostly idle.

AWS announced a new version of the runtime behind Amazon Bedrock AgentCore, the managed compute layer teams use to deploy and run AI agents without operating their own infrastructure.

The change targets two costs that show up once agents move from short chat exchanges to longer-running, often idle, production work. First, memory: the original runtime held a session's peak memory allocation until the session ended, even after the agent stopped using it, so bursty or long-running agents paid for their high-water mark the whole time they ran. The new runtime starts each session from a small memory footprint and pages in more only as the workload needs it, reclaiming memory once it goes cold. AWS says billing now tracks that reclaimed usage rather than the peak.

Second, cold starts: previously, spinning up a fresh environment got slower as container image size or concurrency grew. AWS's own testing — 5,000 cold invocations per agent across five image sizes, using an empty echo agent that calls no model or tools — found the original runtime's P75 cold-start latency rising from about 5.4 seconds to nearly 30 seconds as image size increased. The new runtime prepares and snapshots the environment once, then restores that snapshot for every new instance, holding P75 cold-start latency at roughly 2 seconds from a 200 MB image up to 2 GB, regardless of image size.

AWS frames the net effect as a higher per-unit rate but far fewer billed GB-hours, with the total bill dropping for most agents because the memory footprint shrinks more than the rate rises.

To use the new runtime, developers set the platformVersion parameter to V2 when creating or updating a runtime. AWS also listed several features still coming: committed baseline pricing (reserving a memory floor and bursting above it), larger compute and storage options, x86 microVM support, session suspend/resume with memory snapshotting, and scoped identity for unattended agents via session context keys, aimed at limiting what an agent can do when running without a human watching.

Source: AWS Machine Learning Blog

Next step

Visibility Analyzer

This is what the Visibility Analyzer measures on a real site: which answers cite you, which pages an engine cannot retrieve, and what to fix first. Free to run.

Run a free visibility audit

Free to run. No card.

Fee
Free
Length
One run, minutes

Free tier: two analyses a day, no card required.