AgentCore course → Reference → Canada & data residency
AgentCore in Canada: availability and data residency
The card to reread before a regulated customer meeting. Built from Lesson 2. Every claim here is from AWS primary documentation, cited inline. Verified 2026-08-05. Re-verify before quoting, because the region matrix changes monthly.
The distinction to hold onto
Availability is whether you can call the API in
ca-central-1. Residency is where the bytes get
processed. AgentCore scores well on the first and unevenly on the second. Customers
ask about the first and mean the second.
Part 1: availability in ca-central-1
Available in Canada (Central)
- Runtime
- harness
- Gateway
- Identity
- Policy (with caveats, see Part 2)
- Browser and Code Interpreter
- Memory
- Observability
- Evaluations
- Optimization Preview
- Runtime session storage Preview
Not available in Canada
- Payments Preview N. Virginia, Oregon, Frankfurt, Sydney
- AWS Agent Registry N. Virginia, Oregon, Ireland, Sydney, Tokyo
- Guardrails within Policy N. Virginia, London, Stockholm, Sydney, Tokyo
Source: Supported AWS Regions, cross-checked against the individual What's New announcements for each narrow-footprint capability. Retrieved 2026-08-05.
The short version for a customer: you can build a complete, production
AgentCore application entirely in ca-central-1. What you cannot
do in-region is agent micropayments, org-wide agent cataloguing, or managed
content screening at the gateway.
Part 2: where prompt data actually travels
Three capabilities perform model inference and therefore use cross-region inference: Memory, Policy, and Evaluations. AWS's wording is precise and worth quoting accurately: data is stored only in the primary region, but input prompts and output results may move outside it, encrypted, across Amazon's network.
| Capability | Inference may run in | Scope | Opt-out |
|---|---|---|---|
| Memory | ca-central-1, us-east-1, us-east-2,
us-west-2 (effective 3/31) |
Canada + US | Yes, via a built-in with overrides strategy |
| Evaluations | ca-central-1, us-east-1, us-east-2,
us-west-2 |
Canada + US | Yes, via custom evaluators without CRIS |
| Policy | Any commercial AWS Region worldwide (effective 4/30) | Global, unbounded | None documented |
Source: Cross-region inference in AgentCore Memory, Policy, and Evaluations. Retrieved 2026-08-05.
Canada is a global-routing source region
AWS documents exactly four source regions that use global cross-region inference for Policy: Asia Pacific (Malaysia), Asia Pacific (Thailand), Canada (Central), and South America (São Paulo). Every other region gets geography-bounded routing. Canada drew the short straw.
AWS's own caution, verbatim in substance: customers with data residency or compliance requirements should assess whether global cross-region inference fits their compliance framework, because requests may be processed in any global commercial AWS Region.
Two aggravating details
- You cannot audit it. AWS states plainly that CloudWatch and CloudTrail logs will not specify the region in which inference occurred. So there is no after-the-fact evidence trail for an auditor.
- Policy has no opt-out. Memory and Evaluations both document a mitigation. Policy documents none.
There is no additional charge for cross-region inference in any case, so cost is not a factor in this decision either way.
Part 3: what to actually recommend
| Customer situation | Recommendation |
|---|---|
| Startup with no specific residency obligation | Build in ca-central-1 and move on. Cross-region inference is
encrypted, adds no cost, and stores nothing outside the region. Do not
manufacture a concern. |
| Data must stay in Canada, or Canada + US | Memory: use built-in with overrides, which pins model selection and is also the cheaper storage tier. Evaluations: custom evaluators without CRIS. Both then stay within the Canada + US geography. |
| Data must stay strictly in Canada, no US processing | Memory and Evaluations still reach US regions even when bounded. Raise this explicitly; it may require an architectural decision or an AWS conversation rather than a configuration change. |
| Regulated and needs deterministic authorization | The hard case. Policy routes globally with no opt-out and no audit trail. If global processing is disqualifying, Policy is currently not usable for them. Say so plainly and design authorization another way. |
| Needs prompt-injection and PII screening at the gateway | Guardrails-in-Policy is not in Canada. Either accept an out-of-region deployment for that layer or screen content in their own application code. |
Say this to a customer"Almost all of AgentCore runs in Canada Central, and nothing is stored outside it. The nuance is inference. Memory and Evaluations can send prompts to US regions, and you can pin both if that matters. Policy is the one to watch. Its authorization prompts route to any region globally, you can't opt out, and CloudTrail won't tell you where. If that's a problem for your compliance framework, let's talk about it now rather than at your security review."
Open question, no AWS statement found
Whether Policy will gain geography-bounded inference for Canada. Nothing in the documentation or the What's New feed addresses it as of 2026-08-05. If a customer is blocked on this, it is a legitimate ask to escalate through your AWS service team rather than something to answer yourself.