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 GPU or other specialised hardware, or sessions running longer than eight hours?

Yes Runtime Instances New as of 6 August 2026. Agents run on AWS-managed EC2 in the customer's account, so they get GPU-accelerated, memory-optimised or compute-optimised families and sessions up to 14 days, while AgentCore still handles provisioning, patching, scaling and lifecycle. Not in ca-central-1 yet, which for your customers is usually the deciding detail.AgentCore runtime instances are now generally available, 6 August 2026. Retrieved 2026-08-10.

No Go to gate 4 Ordinary compute needs, so the question becomes what else has to sit alongside the agent.

Gate 4

Do they need a custom sidecar 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 Runtime microVMs Serverless hosting for the loop they already wrote, with the session isolation they would otherwise have to build, and I/O wait billed at nothing. This is the common answer, and gates 1 to 4 are why it is defensible rather than assumed.

Gate 3 is new. Until 6 August 2026 a GPU requirement meant leaving AgentCore for ECS or EKS, and that is still what most write-ups say. It is now the wrong answer outside Canada, and still the right answer inside it.

A decision tree with four questions. First: is there working agent code
already? If no, use the 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: does it
need a GPU or other special hardware, or sessions over eight hours? If yes,
Runtime Instances run it on managed EC2, though not in ca-central-1 yet. If
no, fourth question: does it need a custom sidecar or an existing service
mesh? If yes, use ECS or EKS and build session isolation yourself. If no,
Runtime microVMs are the fit. — **Figure 1.** The same four gates, as you would draw them. Redraw this from memory rather than reading it. Four questions, five destinations, and the shape is the argument: each gate rules out a cheaper or simpler option before Runtime microVMs are 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 microVMs 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. Billing follows active CPU and peak memory per second, so I/O wait costs nothing.	Sessions cap at 8 hours. No choice of hardware. You still own the agent code.
Runtime Instances GA 6 Aug 2026	The same deployment and invocation path, on AWS-managed EC2 in the customer's account. Any EC2 family including GPU-accelerated, sessions up to 14 days, and several agents can share one instance. AgentCore still provisions, patches, scales and manages lifecycle.	EC2 On-Demand cost plus an AgentCore management fee, charged per instance-hour from boot, so idle time is billed. Not in `ca-central-1`.
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 microVMs, Gateway, Identity, Built-in Tools, Observability and Policy are the broadest, available in all nineteen commercial regions plus GovCloud (US-West). harness, Memory, Evaluations, and Optimization all include Canada (Central) too.Read from the feature-by-region matrix, Supported AWS Regions. Retrieved 2026-08-24. This table changes monthly, so re-check before promising availability.

If a customer asks about GovCloud (US-West), harness, Memory, Policy and Evaluations are all there as of 24 August 2026. Runtime Instances, Payments, Registry, Web Search and Optimization are not. Worth knowing that this answer was contradictory two weeks earlier, when an announcement and the region matrix disagreed for a fortnight — the matrix is the one to trust when they diverge.

Five things are not in Canada today:

Not in `ca-central-1`	Where it is	Consequence for a Canadian customer
Web Search	us-east-1, eu-west-1, ap-northeast-1	The one most likely to catch you out, because it is often a research agent's largest cost meter and it has never been in Canada.
Runtime Instances	Nine regions, US, Europe and Asia Pacific	GPU and 14-day-session agents still mean ECS or EKS for a Canadian customer. See the compute decision above.
Payments GA	Twelve regions, US and Europe plus Singapore and Sydney	GA since 18 Aug 2026, so no longer excusable as preview. Agent micropayments need an out-of-region deployment.
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-10.

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

Canada is one of only two source regions AWS routes globally for Policy, the other being 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.

This list moves. On 5 August AWS documented four such source regions, including Malaysia and Thailand; by 10 August only Canada and São Paulo remained. That is a reason to re-check the page before a meeting rather than a reason to expect Canada to come off it.Both readings from Cross-region inference. Retrieved 2026-08-10 and again 2026-08-10.

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-10.

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?