Is AWS ca-central-1 actually Canadian data residency?

Deploy to ca-central-1 and your data sits in Montreal. That part is real, contractual, and auditable. Whether it satisfies your data residency requirement depends on what that requirement actually says.

A region is a geography setting. Jurisdiction is a corporate fact. Most data residency checklists treat them as the same thing, and they are not.

This post is about that gap. It is not legal advice, and it is not an argument that hyperscaler Canadian regions are a bad choice. For plenty of workloads they are the right call.

What follows describes public commitments and public testimony, with sources, so you can check them yourself. If a contract, a regulator, or a client questionnaire is driving your residency requirement, have qualified counsel read the actual wording before you act on it.

What the hyperscalers actually offer in Canada

All three major providers have Canadian infrastructure, and there is more of it than people assume.

AWS runs two Canadian regions. Canada (Central), ca-central-1, opened near Montreal in December 2016. Canada West, ca-west-1, opened near Calgary in December 2023, making AWS the first major provider with a region in Western Canada.

Azure runs Canada Central in Toronto and Canada East in Quebec City, both online since 2016. They are a paired region set, so you can replicate across them without leaving the country.

Google Cloud runs northamerica-northeast1 in Montreal, launched in 2018, and northamerica-northeast2 in Toronto.

These are real facilities with real Canadian addresses. Nobody is faking the geography.

What a region guarantees

AWS states the residency commitment plainly on its Canada data privacy page: AWS will not move your content outside your chosen region without your agreement, "except in each case as necessary to comply with the law or a binding order of a governmental body."

That sentence is worth reading twice. The commitment is genuine. The exception at the end is the entire subject of this post.

Storage location is a technical control. Whose law can compel disclosure is a different control, and the region dropdown does not touch it.

Where the region setting stops

The CLOUD Act, passed in the United States in 2018, gives US law enforcement a mechanism to compel American companies to produce data in their possession, custody, or control, regardless of where that data is stored. Amazon, Microsoft, and Google are US companies. Storing in Montreal does not remove them from US jurisdiction.

We already wrote the detailed version of this, including what the law does and does not cover and why PIPEDA is not a defence against it. Read the US CLOUD Act explainer rather than taking our word for it here.

A recent illustration came from Europe. On June 10, 2025, testifying under oath before a French Senate committee, Microsoft France's director of public and legal affairs, Anton Carniaux, was asked whether he could guarantee that French citizens' data would never be handed to US authorities without French approval. His answer was no, he could not guarantee it. He added that, to his knowledge, no such request had ever been made.

Both halves of that answer matter. The exposure is structural, not hypothetical. On the evidence he gave, it has also not been exercised. Reasonable people weigh those two facts differently depending on what they are running.

Sovereignty-branded offerings, and where they exist

The hyperscalers know this is a live objection and have built products in response. Be precise about what each one changes.

AWS European Sovereign Cloud changes the corporate structure, not just the controls. It became generally available in January 2026 and is operated by German-incorporated entities under a separate governance model, with a first region in Brandenburg. It is a European offering. There is no Canadian equivalent.

Microsoft's sovereign solutions, announced in June 2025, span a sovereign public cloud, a sovereign private cloud, and national partner clouds. Again, aimed at European organizations.

Google Cloud does have a Canada-specific product. Assured Workloads includes a Canada Data Boundary control package that restricts data location to Canadian regions, with a Protected B variant that adds support from screened Canadian personnel. That is meaningful. It is a controls package layered on Google Cloud, not a change to which company is contracting with you.

Personnel controls, customer-managed keys, and access justifications all narrow the risk surface. None of them change the incorporation of the entity that receives a subpoena.

When a Canadian hyperscaler region is the right answer

Plenty of the time.

If your requirement is written as "data at rest must remain in Canada," a hyperscaler Canadian region satisfies it directly and gives you documentation to prove it. If you need multi-region failover inside Canada, all three providers let you do that today. If you need a specific managed service that only a hyperscaler operates, that is a real constraint and geography is what you get.

Physical residency is a genuine requirement in many contracts, and it is genuinely met here. Do not let anyone tell you a Montreal region is meaningless. It is not.

When jurisdiction is the actual requirement

The distinction bites when the requirement is about legal control rather than physical location.

• A client contract that asks which country's law governs access to their data, not just where it is stored.
• A procurement questionnaire asking where your provider's parent company is incorporated.
• An RFP that distinguishes "hosted in Canada" from "Canadian-controlled."
• Your own preference, if you would rather your infrastructure answer to Canadian courts.

That last one is not a compliance argument and does not need to be. Preferring Canadian jurisdiction is a legitimate reason on its own.

The useful test is simple. Ask whether your obligation is satisfied by a map or by a corporate registry. If a map is enough, pick the region and move on. If someone is going to ask who can be compelled, the region setting will not answer them.

What a Canadian-jurisdiction option looks like

It looks like a Canadian-owned company running on Canadian-owned infrastructure, with no US provider in the path of your application data.

MapleDeploy is Canadian-owned and operated. Customer VMs run on LunaNode, a privately held Canadian company incorporated in British Columbia (Corporate Registry #BC0997033) that operates its own infrastructure in a Toronto data center. Each customer gets a dedicated VM running managed Coolify, with git push deploys, automatic SSL, and one-click databases. Your application data, databases, and Coolify instance stay under Canadian jurisdiction.

We are also honest about the boundaries. Payment processing runs through Stripe, a US company, for PCI reasons, and we offer Interac e-Transfer as a Canadian alternative. Uptime monitoring uses a US provider that sees server health status and no application data. Both tradeoffs are documented on our sub-processors page rather than hidden.

Canadian jurisdiction is also not the same thing as a regulated-workload platform. Our terms rule out several data categories entirely, including health and medical information, payment card data, and government-issued or financial account identifiers. If that is what you need to host, you need a provider that has signed up for those obligations.

For a broader checklist on evaluating providers, including the questions worth asking before you sign, see what actually matters in Canadian hosting.

The short version: ca-central-1 is Canadian geography. Whether you also need Canadian jurisdiction is a question only your contracts, your clients, and your own judgement can answer.