How to Deploy an AI Agent on AWS: Lambda vs ECS vs Fargate

There is no single right way to deploy an AI agent on AWS. The right home depends on three things: how long one agent run lasts, how much of that time is spent waiting on a model, and whether each user needs an isolated sandbox. This guide maps those questions onto AWS Lambda, Amazon ECS on AWS Fargate and Amazon Bedrock AgentCore Runtime, using AWS's published limits and prices as of October 30, 2026.

First, untangle "ECS vs Fargate"

The usual search, "Lambda vs ECS vs Fargate", mixes two layers. Amazon ECS is the orchestrator: it schedules tasks, keeps a service at its desired count, rolls out new versions and registers tasks with a load balancer. AWS Fargate is one of the compute engines ECS (and EKS) can place those tasks on, so you never manage EC2 instances. The real choice is ECS on Fargate versus ECS on EC2 capacity you manage.

For most teams shipping an agent as a container, ECS on Fargate is the sensible default. ECS on EC2 earns its extra operations work when you need GPUs, which Fargate does not offer, or when utilization is high and steady enough that instance-level discounts beat per-second billing.

Why agents are awkward to host

A typical web request finishes in milliseconds and uses CPU the whole time. An agent run breaks both assumptions:

• Unpredictable wall-clock time. A tool loop can take five seconds or forty minutes, depending on how many steps the model decides to take.
• Mostly waiting. Most of a run is spent waiting on model APIs and tools, so CPU sits idle while the clock keeps running.
• Streaming. Users expect tokens as they are generated, which means long-lived HTTP responses or WebSockets.
• State across turns. Conversation history, scratch files and tool results have to survive between requests.
• Untrusted execution. Agents that write and run code or drive a browser need stronger isolation than a shared process.

Each AWS option handles a different subset of these well.

Option 1: AWS Lambda (standard functions)

AWS Lambda is the simplest place to run an agent step. AWS's quotas page sets a hard 900-second (15-minute) timeout per invocation, memory from 128 MB to 10,240 MB (CPU scales with memory, with 1,769 MB equal to one vCPU), a 6 MB limit on synchronous request and response payloads, and up to 200 MB for streamed responses. Default concurrency is 1,000 per Region, and each function can add 1,000 execution environments every 10 seconds.

The catch for agents is billing. Lambda charges for duration from start to finish, including every second spent waiting on a model response. It also gives you no memory between invocations, so state has to live in DynamoDB, S3 or a memory service.

Use it for: single-turn agents, webhook- or queue-triggered agents that reliably finish within a few minutes, and, most of all, the tools an agent calls. Small functions behind a tool gateway are where Lambda fits best in an agent stack.

Option 2: Lambda durable functions

Durable functions are AWS's answer to the 15-minute wall. According to the Lambda documentation, a durable execution can run for up to one year. It uses checkpoints and replay: after a pause or failure, your code runs again from the top but skips steps that already completed, reusing their stored results. Wait operations suspend the function without compute charges, which suits human approvals and polling. SDKs exist for JavaScript, TypeScript, Python, Java, Go and C#.

Two constraints matter for agents. First, replay means anything non-deterministic, such as a model call, a timestamp or a random ID, must sit inside a checkpointed step, or a resumed run can take a different path. Second, quotas cap an execution at 30,000 operations and 100 MB of checkpoint storage, so a chatty agent that checkpoints every token will hit limits.

Use it for: multi-step agent workflows that pause for hours or days, such as approvals, back-office automation and research jobs. If the workflow spans many AWS services and you want a visual graph, compare it with Step Functions workflows exposed as agent tools.

Option 3: Amazon ECS on AWS Fargate

ECS on Fargate runs your agent as an ordinary long-lived container service behind a load balancer. There is no per-request execution cap, and one task can serve many concurrent sessions if your agent runtime is asynchronous. Since agents mostly wait on I/O, that multiplexing is the main economic lever.

Per AWS's pricing page, Fargate bills per second for the vCPU and memory a task requests, with a one-minute minimum, measured from the start of the image pull until the task stops. Tasks range from 0.25 to 32 vCPU, include 20 GB of ephemeral storage at no charge, and can run on Arm (Graviton) at a lower rate. Fargate Spot is listed at up to 70% off, but tasks can be reclaimed with a two-minute warning, which suits background agents better than live chat.

What you take on is operations: autoscaling policy, health checks, deploys that drain sessions, and load balancer timeouts. An Application Load Balancer's idle timeout defaults to 60 seconds, so raise it, or send keep-alive events, if a streamed answer can go quiet while the agent thinks. Public IPv4 addresses are billed separately, so put tasks in private subnets. For safer rollouts, see how ECS can now canary through VPC Lattice.

Use it for: chat and API-style agents with steady traffic, teams already running containers, and agents that need their own sidecars, custom networking or more than a few vCPUs.

Option 4: Amazon Bedrock AgentCore Runtime

Amazon Bedrock AgentCore Runtime is AWS's purpose-built agent host. You hand it a container image or a code package, and it runs each user session in its own isolated environment. The AgentCore quotas page lists a default maximum session duration of 8 hours (adjustable through the maxLifetime setting), a 15-minute idle timeout, a 15-minute cap on synchronous requests, 60 minutes for streaming and WebSocket connections, 8 hours for asynchronous jobs, and up to 2 vCPU and 8 GB per session. Container images are capped at 2 GB, and payloads at 100 MB.

The pricing model is built for I/O-bound agents. AWS says CPU billing drops to zero while a session waits on I/O, and the newer microVM v2 environment reclaims idle memory after 120 seconds. Runtime also plugs into the rest of AgentCore (Gateway for tools, Identity for OAuth to third-party services, Memory for state), which saves a lot of glue code. The trade-off is less control: fixed per-session hardware ceilings, a 25-per-second default rate for creating new sessions, and an AWS-specific deployment model.

Use it for: per-user agent sessions with spiky traffic, agents that run code or browse on a user's behalf, and teams that would rather not run their own session isolation.

Newer Lambda variants worth a look

Lambda's 2026 line-up adds three options that blur the lines above. Lambda Managed Instances run functions on EC2 capacity in your account, allow up to 90 minutes for asynchronous and event-source invocations, and cost EC2 On-Demand pricing plus a 15% management fee. Lambda MicroVMs (ARM64) live for up to 8 hours and can suspend, which suits per-user code sandboxes. Lambda Web Functions bill on active CPU time rather than wall-clock duration, with a request timeout of up to 900 seconds, and AWS's own pricing example is an LLM streaming endpoint. These are new, so check Region availability before you commit.

Decision guide

1. Every run finishes well under 15 minutes and holds no state between calls: standard Lambda. Leave headroom, because a slow model day will push you past the timeout.
2. Runs last hours or days and mostly wait for people or external systems: Lambda durable functions, or Step Functions if you want a visual workflow across many services.
3. You run a chat or API agent with steady traffic and want full control: ECS on Fargate, with an async runtime that serves many sessions per task.
4. Each user needs an isolated, stateful session, possibly running untrusted code, and traffic is spiky: AgentCore Runtime.
5. You self-host open-weight models on GPUs: not Fargate. Look at ECS on EC2 GPU instances or AgentCore's Instances compute type, which runs on EC2 capacity in your account.

Many production setups combine them: AgentCore Runtime or Fargate for the agent loop, and Lambda functions as tools behind a gateway. Our AI gateways comparison covers the layer in front of the model.

What it costs on AWS

Prices as of Oct 30, 2026, for US East (N. Virginia), taken from AWS's official pricing pages. Check the linked pages before you budget, because rates vary by Region and change over time.

• Lambda: $0.20 per million requests and $0.0000166667 per GB-second (x86). The free tier covers 1 million requests and 400,000 GB-seconds a month. Streamed response bytes beyond 6 MB per request cost $0.008 per GB.
• Lambda durable functions: $8.00 per million durable operations, $0.25 per GB of data written, and $0.15 per GB-month of retained state, on top of normal compute while the function runs. Waits carry no duration charge.
• Fargate (Linux/x86): $0.000011244 per vCPU-second and $0.000001235 per GB-second, which works out to roughly $0.0405 per vCPU-hour and $0.0044 per GB-hour. Linux/Arm is $0.0000089944 per vCPU-second and $0.0000009889 per GB-second.
• AgentCore Runtime: microVM v1 at $0.0895 per vCPU-hour and $0.00945 per GB-hour; microVM v2 at $0.1276 per vCPU-hour and $0.0169 per GB-hour on consumption pricing, billed per second with a one-second minimum. AgentCore Gateway is $0.005 per 1,000 tool invocations.

Illustrative comparison

This is our arithmetic on AWS's list prices, not a benchmark. Assume 100,000 agent sessions a month. Each lasts 10 minutes of wall-clock time, uses about 1 minute of real CPU, and needs 1 vCPU and 2 GB of memory. Model tokens are excluded.

• Standard Lambda at 2,048 MB: 100,000 × 600 s × 2 GB = 120 million GB-seconds, or about $2,000 a month, because Lambda bills all the waiting.
• One Fargate task per session: 600 s × ($0.000011244 + 2 × $0.000001235) is about $0.0082 per session, or about $823 a month, before image-pull time and the one-minute minimum.
• A shared Fargate service: one always-on 1 vCPU / 2 GB task costs about $36 a month (730 hours). The real total depends on how many concurrent sessions one task can hold, which only a load test will tell you.
• AgentCore Runtime: charging CPU only for the active minute and memory for the full 10 minutes gives about $0.0046 per session on v1 rates and $0.0078 on v2, or roughly $464 to $776 a month. Memory reclaim on v2 can lower that. AWS's own worked example puts a customer-support agent at $0.006703 per session.

The bigger point: for most agents, model tokens cost far more than compute. Choose the host for limits and operations, then optimize the model bill, as covered in our Claude API vs Bedrock vs Vertex AI comparison.

Illustrative setup patterns

These snippets are illustrative and untested. They show the shape of each option, not a complete deployment.

A streaming Lambda handler in Node.js wraps the handler so tokens can be written as they arrive: export const handler = awslambda.streamifyResponse(async (event, responseStream) => { for await (const chunk of runAgent(event)) responseStream.write(chunk); responseStream.end(); });

A minimal Fargate task definition for an agent service on Graviton, with a stop timeout that gives in-flight sessions time to finish during deploys: {"family":"agent","requiresCompatibilities":["FARGATE"],"networkMode":"awsvpc","cpu":"1024","memory":"2048","runtimePlatform":{"cpuArchitecture":"ARM64","operatingSystemFamily":"LINUX"},"taskRoleArn":"arn:aws:iam::<account>:role/agent-task","containerDefinitions":[{"name":"agent","image":"<account>.dkr.ecr.us-east-1.amazonaws.com/agent:1.4.2","portMappings":[{"containerPort":8080}],"stopTimeout":120}]}

For AgentCore Runtime, the HTTP contract is small. Your container listens on port 8080, answers POST /invocations with the agent's response and GET /ping with a health status, and is built for ARM64.

Security and IAM essentials

• One role per agent, least privilege. Every tool call runs with the Lambda execution role, the ECS task role or the AgentCore runtime role, so scope it to the exact tables, buckets and APIs the agent needs.
• Keep secrets out of the model's reach. Store keys in AWS Secrets Manager or Parameter Store and fetch them inside tools, never in prompts or environment variables the agent can print. Our guide to stopping AI coding agents from leaking secrets goes deeper.
• Private networking. Run Fargate tasks in private subnets (each task gets its own network interface and security group in awsvpc mode) and use VPC endpoints for AWS APIs.
• Isolate untrusted code. If the agent executes code or browses, give each session its own sandbox, such as an AgentCore session or a Lambda MicroVM, rather than a shared container.
• Cap the blast radius. Set per-session timeouts, iteration limits and spending alarms, so a looping agent stops before it runs up a bill.

Verdict

Choose by how long a run lasts, not by which service is fashionable. If runs finish in a few minutes, standard Lambda is the cheapest to operate and easiest to secure, but it bills for every second you spend waiting on a model. For runs that wait on people for hours or days, durable functions are now the native fit. If you already run containers and have steady chat traffic, ECS on Fargate gives you the most control and, with a multiplexing runtime, the best unit cost. AgentCore Runtime is the strongest default for new per-user agents that need isolation and long sessions, because its pricing doesn't charge for CPU while the agent waits, though you give up some control to get there.

Sources

• AWS Lambda quotas
• AWS Lambda pricing
• Lambda durable functions (AWS documentation)
• AWS Fargate pricing
• AWS Fargate product page
• Amazon Bedrock AgentCore pricing
• Quotas for Amazon Bedrock AgentCore