Cloud infrastructure
Public-cloud regions in Canada
Browse 8 Canadian regions from AWS, Microsoft Azure, Google Cloud and Oracle Cloud. Names, codes and locations come directly from each provider.
A cloud region describes a service area, not a street address. Check the provider's current service list before making residency, latency or resilience decisions.
What a Canadian cloud region tells you
A region name confirms that a provider publishes a service region in Canada. The provider may divide that region into several availability zones, but the public region list does not identify every building, utility service or network route behind those zones. Use the code in this table when checking a product, architecture document, command-line configuration or contract. Similar display names are not interchangeable across providers.
Data residency also needs a service-level check. A workload can run in a Canadian region while logs, support records, identity systems, backups or a managed feature use another location under the selected configuration. Read the provider documentation and agreement for every service in scope. Record the region, backup destination, encryption-key location and administrative access path in the project decision file.
| Provider | Region | Code | Location | Last checked |
|---|---|---|---|---|
| Amazon Web Services | Canada (Central) | ca-central-1 | Montréal, Quebec | 2026-07-14 |
| Amazon Web Services | Canada West (Calgary) | ca-west-1 | Calgary, Alberta | 2026-07-14 |
| Microsoft Azure | Canada Central | canadacentral | Toronto, Ontario | 2026-07-14 |
| Microsoft Azure | Canada East | canadaeast | Québec, Quebec | 2026-07-14 |
| Google Cloud | Montréal | northamerica-northeast1 | Montréal, Quebec | 2026-07-14 |
| Google Cloud | Toronto | northamerica-northeast2 | Toronto, Ontario | 2026-07-14 |
| Oracle Cloud | Canada Southeast (Montreal) | ca-montreal-1 | Montréal, Quebec | 2026-07-14 |
| Oracle Cloud | Canada Southeast (Toronto) | ca-toronto-1 | Toronto, Ontario | 2026-07-14 |
Connect cloud geography to the facility shortlist
A nearby region can reduce part of the network path, but city labels do not prove latency or a direct connection. Measure from the intended office, facility or carrier service. Identify whether traffic uses the public internet, a private cloud on-ramp or a reseller service, and confirm who owns each segment. The internet-exchange directory can identify exchange operators worth researching. It does not prove that a selected cloud service or data-centre suite is connected to that exchange.
For recovery, test the complete application rather than the virtual machine alone. Authentication, domain-name resolution, security controls, storage, keys, licences, monitoring and staff access may need to work before the service is usable. Estimate the time to restore data and validate the application under the available network capacity. A second region is useful only when the team can activate, operate and later return from it under a documented procedure.
Build a cloud review file
Record the provider, region code, required services, current availability by region, quota, expected data movement, network path, support plan and commercial term. Add the date and source for each answer. Then list the conditions that need a live test: user latency, failover, restore duration, throughput, alert delivery and administrator access during a primary-system failure. Recheck the file when the provider adds a region or changes product availability.
Keep public-cloud records beside, but distinct from, the physical facility directory. One describes provider service geography; the other records named Canadian facilities, campuses and projects. Combining the lists without a direct source can create a false claim about where a cloud service is hosted. Preserve that boundary and ask the provider for any relationship that matters to the design.