Running AI Agents on AWS: Bedrock, ECS, and Lambda Trade-offs

“Which AWS service should run our agents” is a question I get from almost every team that’s moved past a prototype, and the honest answer is “it depends on the shape of the workload,” which is unsatisfying until you actually break the shape down. Bedrock, ECS, and Lambda aren’t competing general-purpose options — they’re suited to different agent workload shapes, and picking based on which one you already know instead of which one fits the workload is how teams end up fighting their infrastructure.

Match Compute to Workload Shape First

Before comparing services, characterize the workload honestly along two axes: how bursty is the traffic, and how long does a single agent run take.

• Bursty and short (a chat-turn agent, an on-demand classification call): traffic is unpredictable, individual invocations finish in seconds, and you want to pay for exactly what you use with nothing idling.
• Bursty and long (an agent that kicks off a multi-minute research or analysis task on demand): unpredictable arrival, but each run needs more time and more working memory than a typical request/response call.
• Steady and long-running (an agent loop that’s effectively always working through a queue, or a multi-hour autonomous task): predictable sustained load where idle capacity actually gets used, not wasted.

That mapping does most of the decision work before you even look at pricing:

• Lambda fits bursty-and-short well. Pay-per-invocation with nothing to manage is exactly right when load is unpredictable and each run is brief.
• ECS (or Fargate) fits steady-and-long-running well. A persistent service can hold state in memory across a running agent loop, isn’t bound by a hard invocation timeout, and its cost only looks bad if you provision for peak and idle most of the time — which is a scaling-policy problem, not an inherent flaw of the compute model.
• Bedrock’s managed agent capabilities fit teams that want the orchestration and tool-calling loop itself managed, trading some architectural control for not having to run that infrastructure at all — a reasonable trade when the team’s differentiation is in the agent’s domain logic, not in owning the execution substrate.

Bursty-and-long is the awkward middle, and it’s usually where teams pick wrong: it looks like a Lambda use case because traffic is bursty, but Lambda’s execution model fights it.

Cold Starts and Timeouts Aren’t Edge Cases for Agent Loops

An agent loop’s typical pattern is fundamentally different from a stateless API handler: it makes several sequential model calls, waits on tool round-trips, and can idle unpredictably on external I/O between steps. That interacts badly with two constraints that are easy to ignore for typical Lambda workloads but become central for agents.

Cold starts matter more for agents because a cold start compounds with the model call latency instead of hiding beside it. A stateless API handler with a small cold start against one with none is a bad look on its own; an agent that’s already waiting seconds per model call barely notices a bit more latency from a single cold start. But if your agent’s architecture spins up a fresh Lambda invocation per step in a multi-step loop rather than holding one invocation open across a session, those cold starts stack up across the whole run in a way that’s easy to miss in isolated benchmarking and obvious in production latency.

Timeouts are the harder constraint. Serverless functions have a hard execution ceiling, measured in minutes, not hours. An agent loop designed against that ceiling has to be structured so a single invocation does one bounded unit of work — one step, or a small number of steps — and hands off to a durable trigger (a queue, a step function, a scheduled re-invocation) for the next unit, rather than trying to hold the whole multi-hour task inside one running process. That’s the same checkpoint-and-resume architecture that long-running agents need regardless of compute choice, but on Lambda it’s not optional — the platform enforces it whether you designed for it or not. ECS doesn’t impose that ceiling, which is exactly why steady, long-running agent loops tend to fit it more naturally.

Comparing Cost Across Volume, Not Just Per-Call Price

The trap in comparing these services on cost is looking at a single number — price per invocation, or price per hour of compute — instead of how each pricing model behaves as volume changes.

• At low volume, pay-per-invocation compute wins by construction: idle capacity you’re not using costs nothing. Provisioned throughput or a persistently running task, sized for load that isn’t there yet, is money spent on capacity nobody’s calling.
• At high, steady volume, the inverse holds: a persistently running or provisioned option amortizes its fixed cost across a large number of invocations, while pure pay-per-call pricing starts compounding against you precisely because you’re calling it constantly.
• The crossover point is workload-specific, not a fixed number you can borrow from someone else’s blog post — it depends on your actual call volume, average run duration, and how spiky your traffic is. This is the kind of analysis I built Akesis to help teams run against their own cloud spend rather than eyeballing a pricing page: model your actual usage pattern against each pricing structure before committing to one.

The practical habit worth building: revisit this comparison as volume grows, rather than treating the initial choice as permanent. A workload that clearly justified Lambda at launch can just as clearly justify moving to ECS a year later, and that’s a sign the original decision was right for its time, not a sign it was wrong.

Key Takeaways

• Characterize the workload’s burstiness and run duration before choosing a compute model — Lambda for bursty-and-short, ECS for steady-and-long-running, managed Bedrock agent capabilities when you want the orchestration loop itself handled for you.
• Design agent loops to survive a hard execution timeout on serverless compute by structuring each invocation as one bounded unit of work that hands off durably to the next, rather than assuming the whole task fits in one running process.
• Account for cold starts compounding across multi-step agent loops, not just as an isolated per-invocation number.
• Compare cost across your actual volume curve, not a single price point — the cheaper option at low volume is often the more expensive one at high, steady volume, and the crossover is specific to your workload.