Pricing, Regions & the Two CLIs

AWS describes AgentCore as "flexible, consumption-based pricing with no upfront commitments or minimum fees." There is no per-seat license and no reserved capacity — you pay for what your agents actually consume. Across roughly twelve independently billable components (one or more per service), every line item falls into one of five patterns:

If you internalize these five patterns, you can estimate the shape of a bill for any architecture — a chatty Gateway-fronted tool layer is request-dominated; a long-conversation memory app is record-dominated; a code-heavy data agent is compute-dominated — without ever memorizing a rate.

Every rate in the dossier and on the pricing page is tagged [VOLATILE]. As of writing, the illustrative figures look like this — treat them as ballpark only and confirm on the live page:

# Illustrative only — VOLATILE, verify https://aws.amazon.com/bedrock/agentcore/pricing/
Runtime / Browser / Code Interpreter  ~$0.0895 / vCPU-hr   + ~$0.00945 / GB-hr
Gateway                               ~$0.005 / 1k invocations; ~$0.025 / 1k search
Identity                              ~$0.010 / 1k token requests to non-AWS (free via Runtime/Gateway)
Memory                                ~$0.25 / 1k short-term events; ~$0.50 / 1k retrievals
Policy                                ~$0.000025 / authorization request

There are also incidental storage costs that are easy to forget: container images land in ECR storage, direct-code (CodeZip) packages land in S3 Standard, and Browser profiles land in S3 Standard.

The pattern worth understanding in detail is per-session active compute, because it governs the three services where your code (or a managed runtime) executes: Runtime, Browser, and Code Interpreter. These bill on two metered dimensions:

• vCPU-hours — CPU consumed while your session is actively running.
• GB-hours — memory consumed while your session is actively running.

The metering is fine-grained: per-second, with a 1-second minimum and a 128 MB memory minimum. The crucial nuance — and the one that makes AgentCore cheaper than a naively-sized container for agent workloads — is that I/O wait is excluded. When your agent is blocked waiting on a model response, a slow tool, or a downstream HTTP call, you are not billed for active compute during that wait. Agents spend a large fraction of wall-clock time waiting on LLMs and tools, so excluding I/O wait can make the effective cost dramatically lower than the session's elapsed duration would suggest.

A mental sketch of the meter (conceptual, not an SDK call):

session elapsed:  |--run--|----wait on model----|--run--|--wait on tool--|--run--|
billed compute:   |XXXXXXX|                      |XXXXXXX|                |XXXXXXX|
                  ^ vCPU-hrs + GB-hrs accrue ONLY during the run segments (I/O wait excluded)

Two more cost facts that catch people:

• Identity is free when used behind Runtime or Gateway. You only pay Identity's per-request rate (~$0.010/1k as of writing, [VOLATILE]) for token/API-key requests made to non-AWS providers outside that path. Inbound auth and the workload-token flow that Runtime/Gateway drive for you are not a separate Identity charge.
• Pass-through services hide cost elsewhere. Observability is a cheap AgentCore line item because the real spend is in CloudWatch (logs, metrics, traces). Payments adds no AWS charge — you pay the wallet provider. Don't read a tiny AgentCore line and conclude the feature is nearly free.

Region availability and GA dates change as AWS expands the service, so treat both as [VOLATILE] and never hard-code a region list from memory. The durable skill is knowing where to look and which regions are the safe default for examples.

The GA timeline (as of writing — confirm on AWS What's New):

• July 16 2025 — Preview announced at AWS Summit NY (the original 7 services).
• Sept 16 2025 — end of the preview free window.
• Sept 17 2025 — standard pricing begins.
• October 13 2025 — GA: Runtime, Memory, Gateway, Identity, and Observability reached general availability (Browser and Code Interpreter are part of the platform too). Newer modules followed: Evaluations went GA in early 2026; Registry, Payments, and Optimization remained in preview. (A reported Policy GA around March 2026 is unverified in first-party sources — don't state it as fact.)

Regions (as of writing — verify the live regions page): at GA, AgentCore was available in 9 regions:

# VOLATILE — verify https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-regions.html
us-east-1   us-east-2   us-west-2
ap-south-1  ap-southeast-1  ap-southeast-2  ap-northeast-1
eu-central-1  eu-west-1

Throughout this course, examples default to us-east-1 or us-west-2 — they were available at GA, host the broadest Bedrock model selection, and keep snippets copy-pasteable. When you deploy for real, pick the region closest to your users and confirm it is on the live regions list and that the Bedrock models you need are enabled there.

In the CLIs, region is explicit. With the starter toolkit you pass -r/--region; with either CLI your ambient AWS config (AWS_REGION / ~/.aws/config) and credentials apply:

# Starter toolkit: pin the region explicitly
agentcore configure -e my_agent.py -r us-west-2

# Or rely on ambient AWS config (applies to both CLIs)
export AWS_REGION=us-east-1

This is the single most common setup trip-up in AgentCore. There are two different command-line tools, both of which install a binary called agentcore, and they expose different verbs. Copy-pasting commands across tutorials that assume different CLIs is the number-one reason a "get started" walkthrough fails.

The toolkit's README now marks itself (legacy) and points users to the new AgentCore CLI.

Legacy starter toolkit — the configure → launch → invoke flow:

pip install bedrock-agentcore-starter-toolkit
agentcore configure -e my_agent.py            # writes .bedrock_agentcore.yaml + Dockerfile
agentcore launch                              # default: AWS CodeBuild, no local Docker
agentcore invoke '{"prompt":"Hello"}'
agentcore status                              # agent ARN, endpoint, log group
agentcore destroy --force                     # teardown

New AgentCore CLI — the create → dev → deploy → invoke flow:

npm install -g @aws/agentcore
agentcore create --name MyAgent --framework Strands --protocol HTTP --model-provider Bedrock --memory none
cd MyAgent
agentcore dev                                 # hot-reload server + inspector on :8080
agentcore deploy                              # package + CDK synth + CloudFormation deploy
agentcore invoke "Tell me a joke"             # --stream, --session-id, --runtime
agentcore status; agentcore logs; agentcore traces list
agentcore remove all && agentcore deploy      # teardown

Note the launch vs deploy wrinkle even within the legacy tool: the devguide and the Python Runtime API use launch / .launch(), while the current starter-toolkit CLI (v0.3.x) renamed the verb to deploy (with destroy for teardown) — same operation, different word. The Python method always stays .launch().

Despite the different verbs, both CLIs are thin orchestration over the same two things: the bedrock-agentcore Python SDK that wraps your agent, and the same serverless AgentCore Runtime they deploy it to. The CLI you pick changes the developer experience and the build/deploy plumbing (CodeBuild vs CDK/CloudFormation), not the artifact or where it runs.

The invariant in every case is the SDK wrapper. You turn a plain function into the Runtime's HTTP service contract with BedrockAgentCoreApp, @app.entrypoint, and app.run():

from bedrock_agentcore import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload):
    user_message = payload.get("prompt", "")
    # ... call your framework / model here ...
    return {"result": f"You said: {user_message}"}

if __name__ == "__main__":
    app.run()   # binds 0.0.0.0:8080; serves /invocations + /ping

This exact my_agent.py is what the legacy toolkit points agentcore configure -e my_agent.py at, and it is the same SDK the new CLI scaffolds for you with agentcore create. Both then deploy to the identical serverless Runtime, which gives you per-session isolation, autoscaling, and CloudWatch logging regardless of which CLI pushed the build.

The build paths differ but converge:

              ┌─ legacy toolkit ─ configure/launch ─→ CodeBuild → ARM64 image / CodeZip ─┐
your agent ──▶│  (bedrock-agentcore SDK wrapper)                                          ├─▶ same AgentCore Runtime
              └─ new CLI ──────── create/dev/deploy ─→ CDK → CloudFormation ─────────────┘

Practical consequence: your agent code is portable across the two CLIs. If you start on the legacy toolkit and later move to the new CLI (or vice-versa), the BedrockAgentCoreApp entrypoint doesn't change — only the surrounding config files and the deploy command do. That portability is exactly why understanding the SDK matters more than memorizing either CLI's flags.

Half of "setup" knowledge in a fast-moving service is facts that expire: pricing, region lists, GA dates, preview-vs-GA status, SDK/CLI versions, and model IDs. The dossier tags every one of these [VOLATILE]. The professional discipline is a three-step rule:

1. Learn the concept, not the number. Know that Runtime bills on active vCPU-hours + GB-hours excluding I/O wait — not the exact dollar figure. Know that there's a regions page — not the exact count today.

2. Cite the official live source. Every volatile claim should travel with the canonical AWS URL so anyone (including future-you) can re-check it. Bookmark the four that matter most:

   text Copy

   Pricing   https://aws.amazon.com/bedrock/agentcore/pricing/
   Regions   https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-regions.html
   Quotas    https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html
   GA / What's New  https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available/

3. Re-verify before you rely on it. Before a cost estimate, a region decision, a customer commitment, or pinning a package version, open the live page and confirm. Package versions are a classic example — as of writing the SDK reported bedrock-agentcore 1.13.0 and the starter toolkit 0.3.9, but those move; check PyPI before pinning.

There's also a stricter tier: facts marked UNVERIFIED in the dossier (e.g. the exact Policy GA date, which exists only in third-party reporting). For those, either omit them or hedge explicitly ("reportedly… — not confirmed in first-party docs"). Never launder an unverified rumor into an asserted fact.

A quick way to caption a volatile figure in your own notes or docs:

Runtime active compute ≈ $0.0895/vCPU-hr  [as of <today's date>; VOLATILE — verify pricing page]

That one-line habit — value, date, source, VOLATILE tag — is what separates an estimate a stakeholder can trust from a number that quietly goes stale.