Your team runs a simple agent in AWS Lambda. Someone proposes moving it to Amazon Bedrock AgentCore. What would AgentCore give the agent that Lambda does not, and when is Lambda still the better choice?

Lambda runs a function for up to 15 minutes with no memory between calls; everything an agent needs around that, you build. AgentCore is built for agents: Runtime gives each user session its own microVM for up to 8 hours and does not bill CPU while the agent waits on the model; Memory keeps conversation and long-term facts; Gateway turns APIs and Lambda functions into MCP tools; Identity and Policy handle whose credentials the agent uses and what it may do, checked outside the model. Lambda stays the better choice for short, stateless, single-user tasks where those parts are not needed.

1. Side by side

2. Where the money goes

Most of an agent's time is waiting for the model. A 60-second session that computes for 6 pays about 6 seconds of vCPU on AgentCore Runtime, plus memory for the session. Memory has its own meter: short-term events are billed at a 12 KB minimum, so writing a whole turn as one event instead of 3 small ones cuts that line by about two thirds.

3. When to stay on Lambda

• A single tool call or classification that finishes in seconds.
• No per-user state, or state already in DynamoDB.
• Low traffic, where a function is simpler to reason about.

Lambda functions are not wasted when moving: Gateway can expose them as tools the AgentCore agent calls.

4. Portability

AgentCore works with any framework (LangGraph, Strands Agents, the OpenAI Agents SDK) and any model, so the agent code stays yours. See Agent and Agent Memory.

What interviewers want: Lambda's time limit and statelessness, per-session microVM isolation, CPU not billed during model waits, memory, tools, identity and policy as the parts otherwise built by hand, the memory event minimum, and an honest case for staying on Lambda.