Blog ENG - AWS - Post 4 2026
In Europe, sovereignty is no longer a side conversation for legal, security, or infrastructure teams. It has become a leadership issue. For banks, insurers, and other heavily regulated organizations, sovereignty now sits at the meeting point of growth, resilience, regulatory confidence, and strategic control. That is why the discussion has moved well beyond the location of a data center. Today, it is equally about governance, operational autonomy, dependency risk, and the ability to keep critical services running under stress.
What has changed is not only the volume of regulation, but its tone. The Digital Operational Resilience Act (DORA) applies across the financial sector and places clear expectations on management bodies for ICT risk, resilience, and third-party dependency management. NIS2 reinforces the broader European view that cybersecurity and operational resilience are matters of executive accountability, not just technical implementation. In practical terms, cloud decisions are no longer simply technology decisions. They are decisions about continuity, defensibility, and trust.
From where I sit, that is exactly why sovereignty has become such a central topic for regulated customers in Europe. Most leadership teams do not want less cloud. They want cloud with fewer unanswered questions. They want the agility, scalability, and innovation benefits, but without ending up in an operating model that becomes difficult to justify to regulators, boards, or customers when scrutiny intensifies. That is the real issue: not whether cloud is desirable, but whether its control model is credible.
Sovereignty is not just about where data sits
One of the most important shifts executives can make is to stop treating sovereignty as a location question alone. Data residency matters, but it is only one part of the picture. A workload may run in Europe and still raise legitimate concerns about privileged access, legal exposure, support models, and recovery dependence on systems or processes outside the region. For a regulated firm, the real test is not simply where data is stored, but how control is exercised and how resilience is demonstrated.
This is also where architecture begins to matter in a very practical way. In my experience, sovereignty becomes real not only in compute and storage decisions, but in the paths data takes, the points where traffic is inspected, the way management access is controlled, and the dependencies embedded in connectivity design. Leadership teams do not need to operate at packet level, of course, but they should understand the principle: if critical traffic paths or operational dependencies cross boundaries the firm is trying to contain, the sovereignty narrative weakens quickly.
The European Commission’s adequacy decision for the EU-U.S. Data Privacy Framework improved the legal environment for certain data transfers, and that has practical importance. But many executive concerns go beyond transfer legality. They are about operational autonomy, local governance, resiliency under disruption, and confidence that essential services remain dependable during legal, political, or geopolitical stress. In regulated sectors, legal permissibility is necessary, but it is rarely sufficient.
Why this matters now for banks and insurers
For financial institutions, DORA has shifted the centre of gravity. The conversation is no longer limited to outsourcing approval and contractual safeguards. It is now about whether the institution can identify, oversee, test, recover, and if necessary exit ICT third-party arrangements in a controlled manner. The ECB’s guide on outsourcing cloud services points in the same direction, highlighting governance, concentration risk, substitutability, and the need for a disciplined, risk-based approach.
For insurers, the underlying logic is very similar. EIOPA’s guidance has long stressed governance, risk assessment, auditability, security of data and systems, and exit planning. Even as DORA becomes the stronger cross-sector anchor, the core message remains the same: moving services to cloud does not transfer accountability away from the institution. Boards and executive committees still own the consequences of weak oversight, high concentration, or poor recoverability.
That is why I see sovereignty not as an infrastructure feature, but as part of enterprise risk architecture. It shapes how an organisation structures control, how it satisfies supervisors, how it prepares for disruption, and how confidently it can modernise critical services. Done well, it enables transformation. Done poorly, it produces a fragile operating model hidden behind reassuring language.
Where AWS fits in the European sovereignty discussion
AWS has expanded its sovereignty positioning in Europe by distinguishing between standard AWS Regions, which it presents as sovereign-by-design, and the AWS European Sovereign Cloud, which is intended for more stringent requirements around data residency, operational autonomy, governance, and resilience. AWS also positions Dedicated Local Zones as an option where customers need infrastructure in a customer-selected location with enhanced controls. That distinction is useful because it reflects an important reality: sovereignty is not one-size-fits-all.
From an executive perspective, that is probably the most constructive part of the AWS story. Not every regulated workload needs the same answer. Some workloads can run effectively in AWS EU Regions with strong controls, robust governance, and the right legal and operational guardrails. Others, particularly those with more stringent sovereignty requirements or higher political sensitivity, may justify the AWS European Sovereign Cloud because AWS describes it as a physically and logically separate cloud infrastructure located entirely within the EU and independently operated there, without critical dependencies on non-EU infrastructure for those sovereign operations.
What is often overlooked in executive discussions is that this is also a connectivity question. The most sensitive services are not defined only by the data they hold, but by the dependencies created by the way they communicate. Private connectivity, controlled egress, segmentation, local inspection points, and clear separation of management paths all help turn sovereignty from a policy aspiration into something operationally credible. You do not need that level of detail in the board pack, but you do need confidence that it exists in the design.
What executives should really ask
In leadership discussions, I find the most productive question is not, “ Is this cloud sovereign? ” The better question is, “ What sovereignty outcome do we need for this business service? ” That reframes the conversation immediately. It forces clarity on whether the real concern is legal transfer mechanisms, operational control, support jurisdiction, resilience, recovery, or concentration risk. It also helps avoid a common mistake: applying the most restrictive model to every workload, whether it is necessary or not.
A second question is whether the organisation can evidence its choices. Regulators are increasingly interested not just in policy statements, but in demonstrable governance. That means clear classification of critical services, oversight of third parties, resilience testing, exit planning, and decision-making that can be explained consistently across audit, risk, technology, and executive committees. Sovereignty without evidence is mostly narrative. Regulated institutions need something stronger than that.
A third question is whether sovereignty has been considered together with resilience and connectivity dependency. This is where many discussions remain too narrow. If a firm addresses one legal concern but ignores concentration, portability, or the external paths on which critical services depend, it may simply replace one form of risk with another. For boards, this is the strategic issue that matters most: not whether cloud is acceptable in theory, but whether the operating model remains dependable under pressure.
Final thoughts
My personal view is that sovereignty in Europe is best understood as disciplined freedom. Regulated firms still want the scale, speed, and innovation of cloud. What they do not want is avoidable ambiguity around control, accountability, resilience, and dependency. That is why this conversation matters so much now. It is not about resisting modernisation. It is about modernising in a way that a regulator can understand, a board can defend, and a business can rely on.
AWS has given European customers a broader set of options than before, and that is meaningful. But the most important work still sits with the customer. Executive teams need to decide which services are truly critical, which sovereignty outcomes matter most, and which cloud model best aligns with their regulatory obligations, risk appetite, and strategic intent. In heavily regulated sectors, that judgment is no longer peripheral. It is part of leadership. And increasingly, it is also part of architecture, including the network paths, control boundaries, and operational dependencies that quietly determine whether a sovereignty strategy is convincing in practice.