AgentCore vs Bedrock Agents vs Roll-Your-Own on Fargate
- Pratik Kulkarni
- AWS , Cloud Architecture
- 25 Jun, 2026
- 04 Mins read
There are three realistic ways to run an AI agent on AWS, and they sit on a spectrum from “AWS does almost everything” to “you do almost everything.” Bedrock Agents has AWS define and orchestrate the agent. Amazon Bedrock AgentCore runs an agent you build, in any framework, on managed infrastructure. Rolling your own on Lambda or Fargate gives you full control and full responsibility. The right answer depends on how much of your agent’s design you need to own.
The Three Options at a Glance
Bedrock Agents is the most managed. You define instructions, attach action groups and knowledge bases, and AWS handles the orchestration loop — deciding when to call a tool, when to retrieve, when to respond. You move fast if your use case fits the model, but you orchestrate the AWS way.
AgentCore is the middle path. You write the agent in LangGraph, CrewAI, LlamaIndex, Strands, or a custom loop, and AWS runs it on a serverless, session-isolated runtime with managed memory, a tool gateway, identity, and observability. You keep your framework and model; AWS keeps the platform. See What Is Amazon Bedrock AgentCore? for the full overview.
Roll-your-own on Fargate (or Lambda) is the most control and the most work. You deploy your agent as a container or function and build everything around it: session state, a checkpointer, a credential store, tracing. Nothing constrains your design, but you own the whole platform.
The Decision Table
| Dimension | Bedrock Agents | AgentCore | Roll-Your-Own (Fargate/Lambda) |
|---|---|---|---|
| Framework freedom | None — AWS orchestrates | Any (LangGraph, CrewAI, Strands…) | Any |
| Model freedom | Bedrock models | Any model, in or outside Bedrock | Any |
| Ops burden | Lowest | Low — managed services | Highest — you build it |
| Session isolation | Managed | Per-session microVM | You implement |
| Memory | Managed | Managed (short + long-term) | You implement |
| Time to production | Fastest (if you fit) | Fast | Slowest |
| Cost model | Model tokens (amplified by orchestration loop) + KB/Lambda | Active consumption (no idle CPU charge) | Always-on or per-invocation |
| Lock-in | Highest | Low — your code is portable | Lowest |
Pick Bedrock Agents When…
The fit: a standard “instructions + tools + knowledge base” agent on Bedrock models, where you’d rather not own orchestration code at all. Think an internal Slack bot that answers from runbooks, files tickets, and checks account status — instructions, a knowledge base, and a couple of action groups, shipped in days.
It’s more flexible than it first appears: custom orchestration (a Lambda that defines your own control flow), multi-agent collaboration, and human-in-the-loop via return of control all exist beyond the default ReAct loop.
The limit: you’re tied to Bedrock-hosted models, and you author any non-default orchestration in Lambda and console config rather than a framework. The day you need a control flow the default loop won’t express, you’re writing that Lambda — and most of the “no code to maintain” advantage goes with it.
Pick AgentCore When…
The fit: you’ve already built an agent — or want to build it in a real framework — and you want it in production without assembling the platform. Think a LangGraph prototype with a few pilot customers whose data can’t mix: the framework carries over untouched, per-session microVMs supply the tenant isolation you’d otherwise hand-build, and the checkpointer, credential vault, and tracing come managed. It’s also the answer when you want a model outside Bedrock, or a specific framework’s control flow Bedrock Agents won’t give you.
The limit: AgentCore isolates sessions but doesn’t decide which user maps to which — you still own user-to-session mapping and lifecycle in your own backend.
Pick Roll-Your-Own When…
The fit: a hard requirement managed services can’t meet — a mandated network topology, a compliance regime that dictates exactly where state lives, latency targets that need a self-hosted model on EC2, or an existing Fargate platform your agents must fit into. You accept the operational cost because the control is non-negotiable. We cover this path in the LangGraph-on-Fargate deployment guide; it’s the honest baseline AgentCore is measured against.
The limit: you’re now maintaining session state, credentials, and tracing as a second product — the exact burden the other two remove. Worth revisiting if the constraint that forced your hand ever relaxes.
The Cost Angle
Bedrock Agents bills the underlying model tokens — and its orchestration loop can consume more tokens than a single call would — on top of any knowledge base and Lambda costs; roll-your-own tends toward paying for capacity you’ve provisioned whether or not it’s busy. Neither accounts for idle time the way AgentCore does: AgentCore Runtime bills only for active resource consumption — during the 30–70% of an agent’s runtime spent waiting on LLM responses or tool calls, there’s no CPU charge. For I/O-heavy agents, that’s a structural advantage over always-on Fargate.
Key Takeaways
- Bedrock Agents: fastest if your use case fits AWS’s orchestration; least flexible.
- AgentCore: keep your framework and model, hand AWS the platform; best balance for most teams taking a real agent to production.
- Roll-your-own: full control, full responsibility; choose it when a hard requirement leaves no alternative.
- Decide by what you must own. If you don’t need to own the orchestration, AgentCore usually wins on time-to-production without the lock-in of Bedrock Agents.
