Lesson 2· ~12 min· Reading + retrieval practice· Meeting-ready checkpoint

Runtime, isolation, and the compute decision

"Where should this agent run?" is the question you will field most often. It has four credible answers, and the tiebreakers are session isolation and how long a turn takes. This lesson also covers what actually runs in ca-central-1, including one finding that will matter to your regulated customers.

Start from what you have

You've already made this call for non-agent workloads many times: Lambda for short and stateless, containers for anything with awkward dependencies. Agents break that heuristic in one specific way. A single agent turn can run for a very long time and must not leak state into the next user's turn. That's the whole reason a purpose-built runtime exists.

The decision, as a tree

Draw this on a whiteboard and let the customer answer the questions. It moves the conversation from "which AWS product" to "what is true about your workload," which is a much better conversation to be having.

Gate 1

Is there working agent code already?

No harness Declare the agent — model, tools, skills, instructions — as configuration and skip the orchestration code entirely. No charge for the harness itself.

Yes Go to gate 2 Keep the code. Nothing below asks them to rewrite it — that is the point.

Gate 2

Does one turn finish inside fifteen minutes, with no session state to carry?

Yes Lambda Cheapest, and every team already knows it. Do not talk them out of it — recommending AgentCore here costs you credibility.

No Go to gate 3 Long turns or session state are what make the agent-specific primitives worth paying for.

Gate 3

Do they need a custom sidecar, a GPU, or an existing service mesh?

Yes ECS or EKS Total control, and they build session isolation, autoscaling, and identity integration themselves. Say that part out loud.

No AgentCore Runtime Serverless hosting for the loop they already wrote, with the session isolation they would otherwise have to build. This is the common answer, and gates 1 to 3 are why it is defensible rather than assumed.

A decision tree with three questions. First: is there working agent code
already? If no, use harness and declare the agent in configuration. If
yes, second question: does one turn finish in under fifteen minutes with
no session state? If yes, Lambda is cheapest. If no, third question: do
you need a custom sidecar, GPU, or service mesh? If yes, use ECS or EKS
and build session isolation yourself. If no, use AgentCore Runtime. — **Figure 1.** The same three gates, as you would draw them. Redraw this from memory rather than reading it. Three questions, four destinations, and the shape is the argument: each gate rules out a cheaper or simpler option before Runtime is reached.

What each destination actually buys

Compute options compared
Option	Buys you	Costs you
harness GA	No orchestration code at all. Model, tools, skills, and instructions in configuration. Isolated environment per session with filesystem and shell. No charge for the harness itself.	Less control over the loop, though it exports to Strands code when you outgrow that, on the same primitives.
Runtime GA	Serverless hosting for a loop you wrote. True session isolation, fast cold starts, long-running async agents, multi-modal and multi-agent workloads, MCP and A2A.	Consumption pricing on vCPU and memory. You still own the agent code.
Lambda	Cheapest option for short, stateless turns. Familiar to every team.	Hard timeout, no session model, and no agent-specific primitives. You bolt on state and isolation yourself.
ECS / EKS	Total control. Custom sidecars, GPUs, existing service mesh and deployment pipeline.	You build and operate session isolation, autoscaling, and identity integration, the exact work AgentCore exists to remove.

Why session isolation is the real argument

This is the part worth being precise about, because it is the one genuinely hard thing to retrofit. AWS describes Runtime as providing "true session isolation."Runtime capability description in the AgentCore Developer Guide overview. Retrieved 2026-08-05. For harness, each session gets its own isolated environment with a filesystem and shell.AgentCore harness is now generally available, 17 June 2026. Retrieved 2026-08-05.

Why a founder should care: an agent writes files, holds credentials, and executes code it generated itself. If two users' turns share a process, a filesystem, or a credential cache, you have built a data-leakage path that no amount of prompt engineering closes. On ECS or EKS you can achieve isolation, but you are now operating it, testing it, and defending it in a security review.

The one idea

Session isolation bounds blast radius. That is a security property, not a performance one, and it is the hardest thing on this list to add later, which is why it rather than cost is usually the honest reason to pick Runtime over containers.

A related preview worth knowing

Runtime also offers managed session storage Preview, which externalises the local session filesystem so an agent can suspend mid-task and resume exactly where it left off.Runtime managed session storage (preview), March 2026. Available in fourteen regions including Canada (Central). Retrieved 2026-08-05. For long-running research or migration agents this is the difference between a crash costing an hour and costing nothing. Flag it as preview.

What runs in Canada, and where the data goes

This section is the one your team most needs and is least likely to find on its own. There are two separate questions, and customers conflate them.

Question one: is the capability available in `ca-central-1`?

Mostly yes. Runtime, Gateway, Identity, Built-in Tools, and Observability are the broadest, available in all nineteen commercial regions plus GovCloud (US-West). harness, Memory, Policy, Evaluations, and Optimization all include Canada (Central) too.Read from the feature-by-region matrix, Supported AWS Regions. Retrieved 2026-08-05. This table changes monthly, so re-check before promising availability.

Three things are not in Canada today:

Not in `ca-central-1`	Where it is	Consequence for a Canadian customer
Payments Preview	N. Virginia, Oregon, Frankfurt, Sydney	Agent micropayments need an out-of-region deployment. Preview anyway, so rarely a blocker yet.
AWS Agent Registry	N. Virginia, Oregon, Ireland, Sydney, Tokyo	Org-wide agent cataloguing has to live elsewhere for now.
*Guardrails within* Policy**	N. Virginia, London, Stockholm, Sydney, Tokyo	The sharp one. Policy runs in Canada, but its Guardrails integration does not, so no in-region prompt-injection or PII screening at the gateway perimeter.

That last row deserves care. Policy, the authorization capability, is available in ca-central-1. What is not available is the Guardrails integration inside Policy, which is what evaluates content for prompt injection, harmful output, and sensitive data exposure at the gateway perimeter.Guardrails-in-Policy region list from AgentCore now supports Bedrock Guardrails in Policy, 17 June 2026. Retrieved 2026-08-05. A customer can author Cedar rules locally; they cannot yet get managed content screening in-region.

Question two: where does the data actually go?

Availability is not residency. Three capabilities perform model inference (Memory, Policy, and Evaluations) and therefore use cross-region inference. AWS is explicit: data is stored only in the primary region, but input prompts and output results may move outside it, encrypted, across Amazon's network.All residency detail in this section from Cross-region inference in AgentCore Memory, Policy, and Evaluations. Retrieved 2026-08-05.

Inference routing from `ca-central-1`
Capability	Prompts may be processed in	Bounded?
Memory	`ca-central-1`, `us-east-1`, `us-east-2`, `us-west-2`	Canada + US
Evaluations	`ca-central-1`, `us-east-1`, `us-east-2`, `us-west-2`	Canada + US
Policy	Any commercial AWS Region worldwide	Unbounded

The finding that matters for Canada

Policy is one of only four source regions AWS routes globally, alongside Malaysia, Thailand, and São Paulo. An authorization decision originating in ca-central-1 may be processed in any commercial region on earth. AWS's own guidance is that customers with data residency or compliance requirements "should assess whether global cross-region inference fits their compliance framework."

Two aggravating details: CloudWatch and CloudTrail do not record which region inference occurred in, so you cannot audit it after the fact. And unlike Memory and Evaluations, Policy has no documented opt-out.

Memory and Evaluations both have escape hatches. For Memory, a built-in with overrides strategy lets you manage model selection and avoid cross-region inference, and it happens to be the cheaper long-term storage tier as well. For Evaluations, you can author custom evaluators that operate without it. There is no additional charge for cross-region inference either way.

Say this to a customer
"Almost all of AgentCore runs in Canada Central. Two things to check before you commit: Policy sends authorization prompts to any global region and you can't opt out or audit which one, and the Guardrails content screening inside Policy isn't in Canada yet. If you're in a regulated vertical, let's design around both. Memory and Evaluations you can pin, Policy you currently can't."

Don't overclaim

Two numbers a founder will ask for that AWS does not publish: Runtime cold-start latency (documented only as "fast") and the maximum duration of an asynchronous agent (documented only as "extended"). Say they aren't published and offer to find out. Also: no credible independent cost benchmark exists comparing Runtime against self-managed ECS or EKS for the same agent, so treat any cost claim in either direction, including your own, as unproven.

Read this next: 5 minutes, highest value for your region

Cross-region inference in AgentCore Memory, Policy, and Evaluations

The least-read consequential page in the AgentCore docs, and the one that will make you the most credible person in a Canadian compliance conversation. Short. Read the tables, not the prose. Retrieved 2026-08-05.

Retrieval practice

Three workload profiles and a pricing question. Answer from memory. This is the set most like a real customer meeting.

A startup's agent researches for up to two hours per task, holds per-user credentials, and runs code it wrote. Where should it run?
- Lambda, since each research task is one request
- ECS, since long tasks need container control
- Runtime, since isolation and duration both matter
Answer: C (Runtime).
A two-person team has no agent code yet and wants a working prototype this week. What do you point them at?
- harness, declaring the agent in configuration
- Runtime, deploying whatever they build first
- EKS, so they keep options open later
Answer: A (harness).
For a long-running agent on Runtime, which dimension dominates the AgentCore bill?
- The number of separate requests it serves
- The wall-clock time it holds vCPU and memory
- The count of model tokens it reads and writes
Answer: B. vCPU-hours and GB-hours over wall-clock time.
A Toronto fintech asks where their prompt data is processed. Which capability gives you the hardest answer?
- Memory, which sends prompts to other regions
- Evaluations, which scores traces off-region
- Policy, which routes globally with no opt-out
Answer: C. Policy, global with no opt-out.

You're meeting-credible from here

With Lesson 1 and this one, you can place AgentCore correctly, choose a compute target and defend it, rough out the cost driver, and give a Canadian customer a straight answer on availability and residency. That is the bar for an advisory conversation.

Three reference cards come out of this lesson: the service map for maturity and regions at a glance, the Canada card for the residency detail above, and the pricing cheat sheet with worked cost sketches. Print the Canada one.

Lesson 3 goes down a layer into the part customers actually get stuck on: connecting an agent to systems that already exist, safely.

Questions to take forward

Here is a real customer workload in one sentence: walk the decision tree with me.
Argue the opposite case. Which workloads is ECS genuinely right for? Knowing those makes the Runtime recommendation more convincing.
What breaks first if we pick wrong?