Compare AWS Lambda Event, Lambda Web Functions, and AgentCore Runtime using real performance and cost measurements.
This article is part of the Building an E-commerce AI Agent with AWS Serverless series:
- Understanding AI Agents
- Choosing the Right Runtime (here)
- Building Product Search and RAG
- Conversation Memory and Context Management
- Connecting the Agent to Your Webshop
- Security, Privacy, and Observability
- The Sample Application
Source code: https://github.com/ServerlessLife/ecommerce-ai-agent
Building an AWS Serverless AI Agent
Why serverless?
The usual reasons for choosing serverless still apply to AI agents:
- Pay only for what you use
- Autoscale
- No servers or containers to manage
- High availability
But there is an even more important reason. In recent years, AWS has built a wide range of services specifically for developing and running AI agents. Most of the components we need are already available, allowing us to build solutions much faster.
Is serverless expensive? For a regular serverless project, the answer is that it is usually cheaper if you count the total cost of ownership. But here the answer is different. LLM costs will likely be much higher than the cost of running the agent itself. So the price is not that important.
But what matters much more is fast time to market. Imagine building 100 prototypes, but only one succeeds. With serverless, you would pay almost nothing for the projects that failed. You would pay only for the one that succeeded.
That's the real power of serverless: building and testing ideas faster, with minimal upfront costs, and scaling only the ones that succeed.
Picking a runtime
AWS offers three serverless options for running a custom AI agent: traditional AWS Lambda (Lambda Event), Lambda Web Functions, and Amazon Bedrock AgentCore Runtime.
Classic Lambda Event Function billing is optimized for fast responses with high CPU usage. But AI agents are the opposite. They are slow because LLMs are slow, and they don't use much CPU because they mostly just stream the LLM response. That's why it's so important that AgentCore and Lambda Web Functions have separate CPU and memory billing.
AWS Lambda Event
Traditional AWS Lambda is the simplest option. Each invocation runs the agent, handles LLM and tool calls, and returns a response. Streaming is supported through Lambda Function URLs or compatible API Gateway REST API integrations.
The main limitation is billing. Lambda charges for configured memory over the entire invocation duration, including time spent waiting for external services. CPU allocation is proportional to configured memory. For example, if our agent takes 10 seconds to answer but spends 8 seconds waiting for an LLM, we still pay for all 10 seconds.
Each concurrent invocation needs a separate execution environment. AWS may reuse environments between requests, but we cannot rely on this to preserve conversation state. We therefore need external storage for conversation history.
Lambda has a maximum invocation duration of 15 minutes.
Despite these limitations, Lambda Event is often the cheapest option for short, occasional requests. It is also an excellent choice for background tasks such as ingestion, embedding generation, and data processing.
AWS Lambda Web Functions
Unlike traditional Lambda, Lambda Web separates CPU and memory billing. Each execution environment has 2 Arm64 vCPUs and up to 2 GB of memory. We pay for the CPU time the application and runtime actively consume, not for CPU time spent waiting for an LLM or external API. Memory is billed based on consumption over the lifetime of the execution environment, including idle time between requests. Requests and data transfer are charged separately.
Another important advantage is concurrency. A single execution environment can handle multiple concurrent HTTP requests. While one conversation waits for an LLM response, the same environment can process other conversations.
However, there are some limitations:
Memory remains billable while the environment is active.
In my measurements, an environment remained alive for approximately six minutes after the last response, increasing costs. This duration is not documented by AWS.
Conversation state still needs external storage because requests are not tied to dedicated environments.
Maximum request duration is 15 minutes.
Lambda Web can be more cost-effective than traditional Lambda under sustained concurrent workloads, especially when requests spend most of their time waiting for I/O. Actual savings depend on concurrency, memory consumption, and environment lifetime.
Amazon Bedrock AgentCore Runtime
Amazon Bedrock AgentCore Runtime is designed specifically for AI agents. It offers two compute options: serverless microVMs and EC2-backed Instances.
AgentCore Runtime MicroVMs
With MicroVMs, each conversation session gets its own isolated execution environment, with dynamically allocated resources up to 2 vCPUs and 8 GB of memory.
AgentCore uses consumption-based billing with separate CPU and memory charges. When the agent waits for an LLM or tool and no background processing uses CPU, CPU charges can fall to zero.
Memory is billed separately and includes the entire runtime environment, which is different comparing to Lambda Web Function.
Stateful sessions are AgentCore's main advantage. The same process can remain alive between messages, allowing us to keep the Strands agent and conversation history.
By default, idle sessions terminate after 15 minutes, although this is configurable. For our agent, reducing the timeout to a few minutes may significantly lower costs. The maximum session lifetime is 8 hours. Persistent storage is therefore still necessary to resume conversations after a session expires.
Top comments (0)