Amazon Bedrock AgentCore - architecture, components, and pricing

Amazon Bedrock AgentCore - architecture, components, and pricing

If you want the wider context, AgentCore is the managed runtime layer beneath the AWS Loom platform and one of the answers to agent sprawl. Here we focus on AgentCore itself: its architecture and its cost.

What is Amazon Bedrock AgentCore?

Bedrock AgentCore is a set of managed, composable AWS services for building, deploying, and operating AI agents in production. The key word is composable: it is not one monolithic “agent product”, but several independent services you can use together or selectively. Each one can be adopted on its own, with no commitment to the whole.

Two things worth settling up front:

• AgentCore is framework-neutral. It works with Strands Agents, LangGraph, CrewAI, Google ADK, and others. It does not force a single SDK.
• AgentCore is model-neutral. You do not have to use Bedrock models - you can point it at a model outside AWS. Bedrock is the default, not a requirement.

In practice, AgentCore is an “agent infrastructure as a service” layer: you bring your agent logic and get a ready-made runtime, tool access, memory, identity, and telemetry, without standing that up yourself on EC2 or EKS.

The sources we reference: the Amazon Bedrock AgentCore page and the AgentCore documentation.

AgentCore components

AgentCore consists of several services you can combine as needed. Here is what each one does.

The most important architectural observation: Runtime and Observability are the foundation you will use almost every time. The rest is optional and chosen per use case. A simple Q&A agent may need only Runtime + Observability. An agent that reaches internal systems and remembers context adds Gateway, Memory, and Identity. That is exactly what “composable” means.

How the components fit together

A typical flow for a production agent looks like this:

1. Runtime runs the agent logic (written in e.g. Strands) in an isolated session.
2. The agent calls a model - by default through Amazon Bedrock, optionally a model outside AWS.
3. When the agent needs a tool (API, Lambda, MCP server), it goes through Gateway, which acts as a single access-control point.
4. Memory supplies session context and knowledge persisted across sessions.
5. Identity makes sure the agent acts with the user’s permissions, not its own over-broad ones.
6. Observability collects traces and metrics for every step, so you can answer “which agent, did what, at what cost, and why”.

If searching internal documents (RAG) is in play, a vector-search layer sits underneath - and that is where the budget can surprise you. We return to it in the cost section. We laid out the RAG architecture itself in a separate article on RAG architecture on AWS.

How much does Bedrock AgentCore cost - pricing and cost model

AgentCore is billed by consumption: you pay for what you use, per component. There is no license fee for “AgentCore” as such - the cost is the sum of usage across the individual services plus the cost of model inference in Bedrock (billed separately, per token).

Per-component rates

The table below gives the billing unit and rate for each component, per the AWS AgentCore pricing page (as of September 2026, US East region). AWS prices change and depend on region - verify the current rates on the AWS page before you budget.

The line item almost everyone leaves out

If the agent does RAG (searches internal documents), there is usually OpenSearch Serverless underneath as the vector store. And OpenSearch Serverless has a minimum, fixed cost for OCUs (OpenSearch Compute Units) - on the order of a few hundred dollars a month for a minimal configuration, regardless of traffic. Even an agent that has not served a single query still generates that cost as long as the vector collection exists.

It is the most commonly underestimated line item in agent budgets, because everything else is consumption-based (“I pay for what I use”) while this one is a fixed entry threshold. With a single agent it is bearable. With ten separate vector collections it is a real sum that flows every month regardless of usage.

The practical FinOps takeaway: consolidate vector search wherever you can, instead of standing up a separate collection for every agent. It is exactly the same mechanism we described with agent sprawl - the cost comes from fragmentation, not from a single service.

A worked monthly cost example (TCO)

To make the layers concrete, here is one realistic scenario costed out. The figures are illustrative and based on the rates in the table above (US East, September 2026) - they show the shape of the cost, not a quote. Verify current prices before your own calculation.

Scenario: a customer-support agent, 10,000 sessions per month, each ~10 minutes with 90% of the time in I/O wait, 1 vCPU and ~2 GB memory during active processing. Per session: ~10 tool calls (Gateway), ~10 memory events, 1 RAG query, ~15k input and ~2k output tokens to Claude Sonnet 5. RAG on OpenSearch Serverless (2-OCU floor).

The breakdown makes the point: at this profile the biggest item is inference (~$500, per token, grows with traffic), with the fixed OpenSearch Serverless cost (~$350) close behind - which would dominate the bill at low traffic and fade into the background at high traffic. The AgentCore layer itself (Runtime + Gateway + Memory + Observability) is ~$115 here, under a third of the bill. That is why “how much does an agent on AgentCore cost” has no single answer: at 10x the traffic, inference and Runtime scale linearly while the $350 for OpenSearch stays flat - so the cost per session falls.

AgentCore and Loom - how they relate

Briefly, because it is a common question: AgentCore is the managed building blocks (runtime, gateway, memory, identity, observability). Loom is an opinionated governance layer on top of them (UI, lifecycle, tagging, registry, human-in-the-loop).

In other words: you can use AgentCore without Loom - and for many teams that is the most sensible start (managed services plus a thin governance layer of your own). Loom adds a ready-made paved path, but as AWS Labs reference code that you take on to maintain. We laid out the full “adopt Loom, adapt it, or pick an alternative” analysis in the article on AWS Loom.

When AgentCore makes sense, and when it does not

For a comparison of the model layer itself - Bedrock vs SageMaker vs self-hosting on EKS - we have a separate, detailed article on running LLM inference on AWS.

When it is worth bringing in an external partner

• Cost model and TCO. Consumption billing per component plus the fixed vector-search cost is hard to estimate without experience - and it drives the budget.
• Identity and least-privilege design. An agent acting on behalf of a user, with access to production data, needs a properly designed Identity layer.
• The choice: AgentCore, Loom, or your own layer. It is an architectural decision with a long maintenance tail, not a one-off deployment.
• RAG and vector-cost consolidation. Collapsing scattered collections into one shared layer is often the fastest return in an agent budget.

Summary

Bedrock AgentCore is a set of managed, composable services for running AI agents in production: Runtime and Observability as the foundation, with Gateway, Memory, Identity, Browser, and Code Interpreter chosen per use case. Framework- and model-neutral, billed by consumption.

Three things to remember:

1. These are composable services, not a monolith. Use only the components you actually need - a simple agent is often just Runtime + Observability.
2. Cost is the sum of the layers plus per-token inference in Bedrock. At high traffic, inference is usually the biggest item.
3. Watch the fixed vector-search cost (OpenSearch Serverless) with RAG - a few hundred dollars a month regardless of traffic, per collection. Consolidate instead of multiplying.

Frequently asked questions about AgentCore pricing

Designing an agent on AgentCore and sizing the TCO?

Book a free 30-minute call. We help teams design an agent architecture on Bedrock AgentCore, estimate the real cost per component, and avoid underestimated line items like the fixed cost of vector search.

Book a call Send a message