Notes de terrain / Dernières nouvelles
Des notes d’ingénierie issues de l’exploitation d’infrastructures ouvertes : pannes, décisions de conception et travail upstream qui améliorent l’infrastructure ouverte.
Parcourir toutes les notes
Learn the difference between Canadian sovereign cloud and data residency, including jurisdiction, infrastructure control, provider ownership, private cloud, and OpenStack.
Lire la note
Evaluate OpenStack as a VMware alternative, including networking, storage, hardware reuse, migration methods, downtime, workload waves, and Day 2 operations.
Lire la note
Infrastructure exceptions add hidden complexity to automation, upgrades, troubleshooting, and operations. Learn when standardization matters.
Lire la note
Learn the difference between Canadian sovereign cloud and data residency, including jurisdiction, infrastructure control, provider ownership, private cloud, and OpenStack.
For Canadian organizations evaluating cloud infrastructure, “our data stays in Canada” can sound like a complete answer to questions about sovereignty.
It is not.
Data residency tells you where data is stored. Sovereignty asks who ultimately controls the data and the infrastructure around it, under which jurisdiction, and with what level of operational and technical independence.
That distinction matters for organizations handling regulated information, sensitive intellectual property, critical applications, AI datasets, or infrastructure where provider dependency itself has become a business risk.
A Canadian data centre can satisfy an important residency requirement. But organizations with broader sovereignty requirements may also need to understand who operates the infrastructure, who can administer it, where backups and replicas exist, who controls encryption keys, which legal jurisdictions apply, and whether workloads can realistically move to another environment.
Sovereignty is therefore better treated as an infrastructure control model than as a location label.
There is no single architecture that automatically makes a cloud sovereign.
Instead, a sovereign cloud architecture is one in which an organization deliberately defines the jurisdictional, operational, technical, and data-control boundaries appropriate to its workloads.
For Canadian organizations, that may include requirements around:
Not every workload requires the same level of control.
A public website may need little more than reliable Canadian hosting. Government workloads, financial information, healthcare data, critical infrastructure, sensitive AI models, or proprietary datasets may justify much stricter boundaries.
The objective is therefore not to label an entire environment “sovereign.” It is to determine which controls each workload actually requires.
These concepts overlap, but they answer different questions.
Data residency describes where data is physically stored.
If an organization requires information to remain inside Canada, its infrastructure needs to keep the relevant data in Canadian facilities.
But “data” rarely means only the primary database.
Backups, snapshots, object copies, replicated storage, monitoring data, logs, disaster-recovery systems, and support tooling can all create additional locations where information exists.
A residency architecture therefore needs to account for the entire data lifecycle, not simply the location of the main workload.
Data sovereignty concerns the legal and operational authority surrounding data and the infrastructure processing it.
The Government of Canada's digital guidance similarly distinguishes geographic data residency from broader questions of sovereignty and control.
For infrastructure teams, the practical question is: Who has authority over the data and the systems running it?
That includes infrastructure operators, administrators, identity systems, encryption keys, support processes, and the technologies on which the environment depends.
Infrastructure location and provider jurisdiction also need to be evaluated separately.
A server can physically operate in Canada while the provider, parent company, support organization, contracts, or operational systems involved in delivering the service have connections to additional jurisdictions.
That does not automatically make the environment unsuitable.
Likewise, data leaving Canada does not automatically mean an organization cannot satisfy every Canadian privacy requirement.
The appropriate model depends on sector, workload classification, contractual obligations, applicable regulation, and the organization's own risk assessment.
But physical location alone does not answer the jurisdiction question.
It can be enough for a data-residency requirement. It is not, by itself, evidence of infrastructure sovereignty.
Consider two environments whose application data both resides in Montreal.
In the first, an organization runs dedicated infrastructure with clearly defined control over identity, networking, encryption keys, backups, administrative access, and the underlying cloud platform.
In the second, Canadian storage is one component of a globally operated proprietary cloud service in which parts of the control plane, operational access, management tooling, and service delivery depend on systems outside the organization's direct control.
Both environments may satisfy a narrowly defined Canadian residency requirement.
They provide very different sovereignty and infrastructure-control models.
That is why organizations evaluating stronger sovereignty requirements also need to ask:
Canada's current infrastructure direction reinforces this distinction.
Shared Services Canada's 2026–27 Departmental Plan discusses data residency alongside sovereign cloud hosting, increased use of Canadian cloud services, sovereign AI infrastructure, and a dedicated sovereign private cloud environment within Canadian jurisdiction.
Organizations outside government do not need to reproduce that architecture.
The broader lesson is that residency and sovereignty solve different problems.
Cloud services consist of several layers.
There is the physical facility, followed by servers, storage, networking, the cloud platform, identity systems, APIs, monitoring tools, support processes, and operational teams.
Different providers control different parts of that stack.
As sovereignty requirements become stronger, those control boundaries matter more.
Organizations may need to establish:
Who owns the physical infrastructure?
Is it dedicated to the organization, shared with other customers, or supplied through another infrastructure provider?
Who operates the cloud control plane?
Which organization can create, modify, access, or remove cloud resources?
Who has privileged access?
Where can administrators connect from, and what authentication, approval, and auditing controls govern that access?
Who controls the infrastructure lifecycle?
Who determines hardware replacement, firmware, networking architecture, storage design, upgrades, and platform changes?
Which dependencies are unavoidable?
Could the environment continue operating without a particular proprietary control plane, licensing service, API, or management platform?
Provider ownership is therefore not automatically good or bad.
The issue is whether its relationship to the infrastructure matches the organization's required control model.
Sovereignty becomes easier to evaluate when infrastructure control is broken into technical layers.
Compute control includes where workloads run, which physical hardware they use, whether resources are shared or dedicated, and how capacity is allocated.
Dedicated infrastructure can create clearer hardware and operational boundaries for workloads requiring stronger isolation.
Storage architecture determines where virtual machine volumes, databases, object storage, backups, snapshots, and replicated datasets exist.
Primary storage is only part of the residency picture. Every persistent copy can create another control and jurisdiction consideration.
Network sovereignty includes routing, segmentation, ingress and egress, firewalls, public addressing, private connectivity, and links between cloud infrastructure and organizational networks.
Teams may also need to understand who operates the physical and virtual networking layers beneath their workloads.
Infrastructure cannot be considered strongly controlled if privileged access is poorly understood.
Identity architecture should account for authentication, role-based access control, provider access procedures, audit trails, privileged identities, and separation of responsibilities.
Encryption can reduce exposure, but key ownership matters as well.
Teams evaluating sovereignty should know which organization manages the keys, where the key-management system runs, and which administrators can access or rotate them.
Operational independence also matters over time.
Can the organization decide when upgrades occur? Can an upgrade be delayed when an application is not ready? Can workloads move elsewhere? Does the architecture use portable interfaces, or has it become inseparable from one provider's proprietary services?
These Day 2 questions often reveal more about practical sovereignty than the address of the data centre.
Neither public nor private cloud is inherently sovereign or non-sovereign.
The right model depends on the required control boundary.
A Canadian public cloud can be entirely appropriate when the primary requirements are Canadian infrastructure, cloud elasticity, standard workload isolation, and a provider-operated platform.
For example, VEXXHOST Public Cloud operates Canadian infrastructure in Montreal using OpenStack, providing a cloud option for workloads that need to operate on Canadian infrastructure without requiring a dedicated private environment.
Other workloads require stronger boundaries.
A private cloud can provide dedicated infrastructure and give an organization greater control over hardware, networking, storage, security, identity, capacity planning, and platform operations.
Private cloud can also be deployed in different operational models.
An organization may operate the environment itself, deploy it in its own data centre, use dedicated hosted infrastructure, or have a specialist provider manage the cloud while retaining a clearly defined infrastructure boundary.
VEXXHOST Private Cloud is one example of this model, using dedicated OpenStack infrastructure that can support hosted or customer-controlled deployment requirements.
The distinction matters because stronger sovereignty requirements usually require stronger and more explicit control boundaries.
Sovereignty requirements do not necessarily apply uniformly across an organization's entire infrastructure estate.
In many environments, a hybrid approach is more practical.
General-purpose applications may remain in public cloud while regulated services, sensitive datasets, proprietary AI models, or critical workloads run on dedicated Canadian infrastructure.
Private connectivity can then link those environments while keeping stronger controls around specific applications or data.
This approach allows teams to apply sovereignty requirements according to workload risk rather than forcing every system into the most restrictive architecture.
For organizations operating at scale, that can provide a better balance between infrastructure control, cost, operational complexity, and flexibility.
No.
Using open-source infrastructure does not automatically make an environment sovereign.
A poorly designed open-source cloud can still have weak access controls, unclear operational responsibilities, external dependencies, or unsuitable data-handling practices.
But open infrastructure can reduce another sovereignty risk: technological dependence on a single proprietary platform.
Open-source cloud technologies allow organizations to inspect architectures, operate infrastructure themselves, choose between service providers, and use APIs and components that are not available from only one vendor.
That can improve portability and technical autonomy.
The goal is not necessarily to remove vendors from the architecture.
It is to avoid building infrastructure that can realistically be operated by only one vendor.
OpenStack is relevant to sovereign infrastructure because it provides open-source components for compute, networking, storage integration, identity, APIs, and cloud management without tying the cloud operating model to a single proprietary hyperscale platform.
It can run:
That flexibility allows organizations to determine where the operational boundary should sit.
One organization may operate OpenStack directly on infrastructure it owns. Another may use dedicated infrastructure while having an experienced provider operate the cloud. Others may use an OpenStack public cloud when Canadian location and infrastructure portability are the primary requirements.
In each case, the broader architectural model can remain based on the same open cloud ecosystem.
That is useful when sovereignty includes not just data location, but also the ability to retain greater control over the technology underneath the workload.
Before describing an environment as sovereign, infrastructure, security, and procurement teams should be able to answer questions such as:
Those answers provide a much clearer picture of sovereignty than the location of a cloud region alone.
Dedicated Canadian infrastructure is not necessary for every workload.
It becomes more compelling when multiple requirements converge, including:
In these environments, the question is not simply public cloud versus private cloud.
The better question is:
How much control does this workload require, and at which layers of the infrastructure stack?
For some applications, Canadian public cloud will provide the right balance.
Others may justify dedicated private infrastructure.
And many organizations will use both.
The architecture should follow the control requirement.
Data residency answers a relatively straightforward question:
Where is the data?
Sovereignty requires several more:
Who controls it? Who controls the infrastructure around it? Which jurisdictions apply? And how independently can the organization operate, change, or move that environment?
A Canadian data centre may satisfy residency.
A sovereign infrastructure strategy goes further by defining the jurisdictional, operational, technical, and data-control boundaries required by each workload.
For organizations that need stronger boundaries, Canadian private cloud infrastructure built on open technologies such as OpenStack can provide greater control over compute, storage, networking, identity, and platform operations without giving up cloud automation, APIs, scalability, or modern infrastructure management. In search for your best solution for a sovereign cloud? Contact us!
Choose from Atmosphere Cloud, Hosted, or On-Premise.
Simplify your cloud operations with our intuitive dashboard.
Run it yourself, tap our expert support, or opt for full remote operations.
Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes
