A drill the operator chose
On Saturday AWS will cut its European Sovereign Cloud off from the rest of AWS for several hours and show that it keeps running. That is real engineering, and it answers the half of sovereignty that a vendor can schedule for itself.
The argumentA disconnection drill proves a sovereign cloud can run unchanged without its parent, but sovereignty is decided by the events nobody schedules, a compelled instruction or a patch that cannot arrive.
On Saturday, 24 October, AWS will do something most operators spend their careers avoiding. It will pull the plug on its own network on purpose. For several hours, according to AWS's security blog, the European Sovereign Cloud "will operate without a connection to the AWS Global Network backbone". Traffic that would normally ride the backbone goes over the public internet, through links from European ISPs. A second channel, the dedicated system for limited transfers of operational data, is switched off entirely. The people running the region will be, in AWS's words, EU residents working in the EU, on the region's own hardware and software. Customers may see a short disruption while routes converge. Otherwise AWS expects nothing to happen, and wants that on the record.
I think this is a good drill, and I will say why before I say what it leaves out. Cutting your own cable is the only honest way to find the dependency you forgot you had. "No critical dependencies on non-EU infrastructure", the phrase AWS uses, is the kind of sentence that stays true until a certificate authority, a licence server or a DNS resolver turns out to live somewhere else. Finding that out on a Saturday you chose beats finding it out during a crisis you did not.
My argument is about what the drill is evidence of. It tests one specific thing: whether a system in a steady state keeps running when the connection to its parent is removed by the party that owns both ends. It will tell you that the region runs. It cannot tell you that the region can be maintained, or that it can refuse. Sovereignty, on any definition the standard-setters have written down, depends on both.
What the standard actually asks
The European Commission's Cloud Sovereignty Framework, version 1.2.1, is a good document to hold up against this. It was written for a specific Commission procurement and is a tender instrument, not a law, but it is the most detailed public statement I know of what a European buyer is told to look for. It defines eight objectives and five assurance levels. The levels are the useful part, because they are unusually blunt.
SEAL-3 is named "Digital Resilience": EU law applicable and enforceable, EU actors with "meaningful but not full influence", and the service under "marginal control of non-EU third parties". SEAL-4 is named "Full Digital Sovereignty": technology and operations "under complete EU control, subject only to EU law, with no critical non-EU dependencies".
Read AWS's claim against those two. "No critical dependencies on non-EU infrastructure" is the last clause of SEAL-4, almost word for word, and the drill is a test of exactly that clause. That is a legitimate thing to test. But SEAL-4 has two other clauses, "complete EU control" and "subject only to EU law", and the drill touches neither. AWS is careful here, which deserves credit. Its post says only that the exercise is "designed to be consistent with" the objectives of the framework and of Germany's BSI C3A criteria, not that it achieves any level, and it promises "verifiable technical and operational evidence" of independent operation. The word is evidence, and the thing to ask is evidence of what.
The framework names, among the factors that make up its strategic objective, the "ability to sustain secure operations against requests to cease or suspend the service, or if vendor support is withdrawn or disrupted". Hold the two halves of that sentence apart. "Disrupted" is a weather event. It is what the drill simulates. "Requests to cease or suspend" is a decision, made by someone with authority over the party that owns the service. A disrupted backbone leaves the operator free to choose its response. A request leaves it asking what it is permitted to do. The first can be rehearsed with a network engineer and a maintenance window. The second cannot be rehearsed from inside the company it would be addressed to.
The part that arrives uninvited
Two things are missing from a several-hour test, and both are architectural, not legal.
The first is change. The channel AWS is switching off is, by its own description, the one that carries vetted source-code mirroring and software updates, as well as a small amount of approved routine information leaving the region. Neither channel is "operation-critical", the post says, and for a steady state that is plausible. A running system does not need a patch for the first few hours after it stops receiving one. But a system that has not needed a patch, a renewed credential, a rotated key or a replacement disk in the hours it was observed has shown that it runs. It has not shown that it can be kept alive. The framework's own operational and security objectives are about the second thing: whether EU operators can "develop, test, and apply security patches independently", and whether they hold "full technical documentation, source code, and operational know-how". A commenter on the InfoQ report put the question as a practitioner would, asking how long the region can run before tokens, certificates, licences or an external control-plane dependency begin to fail. That is a question about days; the drill is scheduled in hours. The InfoQ report adds that the Brandenburg data centres hold a local copy of the source code, which is the right asset for that question. A copy of the source is not a rehearsal of building, testing and shipping from it.
The same applies, more sharply, to anything that changes fast. The framework's data objective explicitly covers AI services, including whether models and pipelines are "developed, trained, hosted, and governed under EU control". Inference stacks are among the fastest-moving dependencies in any estate. Nothing I read says how the region will handle them, and an exercise that holds the software still cannot say.
The second thing missing is the instruction. Fadi Dasus, quoted in the InfoQ report, called the drill "real progress for resilience" that "just isn't sovereignty". Another commenter, Anders Bjørnestad, drew the line more usefully, between the ability to access data and the ability to switch a customer off, and observed that the test speaks only to the second. I would go one step further. The drill is a test in which the operator chooses to disconnect. The scenario the sovereignty debate is actually about is one where the operator is told to, or told to hand something over, by an authority it is answerable to.
AWS's own whitepaper is candid that this scenario is expected. Its law-enforcement section commits AWS to "use all legally valid efforts to challenge any request that conflicts with the law of the European Union or applicable Member State law". That is a commitment to a process, and a reasonable one, but it exists because requests arrive. The same paper puts the region in a group of German entities under a holding company, with managing directors who are EU nationals and an advisory board, and names Amazon Web Services EMEA SARL in Luxembourg as the contracting party for customers. It does not say, in the passages I read, who holds the holding company's shares. That is not a criticism of AWS. It is where the evidence stops.
The strongest objection
The objection is that I am asking an engineering exercise to settle a legal question, and a drill that does not claim to settle it is not at fault. Lars Larsson Lundsten of Elastisys made roughly this argument in the thread: you cannot solve legal problems with technical solutions. He also credited AWS with "extremely careful" claims. Both seem right to me. A drill that removes a hidden dependency makes a better system, and a regulator told the results afterwards, as AWS says it will be, is better informed than one given a slide. Another commenter suggested the exercise is aimed at European risk officers, who need something to put in a file. That is probably true, and not a bad thing for them to have.
So the drill is not misconduct, and I am not claiming anyone has overstated anything. The concern is about what the artefact becomes once it leaves its author. AWS says the results will go into customers' compliance packages. A compliance package is a place where a result stops being a test of a specific property and becomes a tick against an objective. The framework gives the reader reason to worry about how that happens. Its scoring weights the legal and jurisdictional objective at 10 per cent and the operational one at 15 per cent, and the document explains that the procurement "already contains significant safeguards" in the legal domain. That is a reasonable design for a tender, where those safeguards are written into the contract. It is a less reasonable design for a buyer who is not running that tender, who may import the weights and the evidence without importing the safeguards.
There is an economic observation underneath this. Evidence a vendor can generate alone, on its own schedule, will always be more plentiful than evidence that depends on other people. A drill is cheap to repeat and flattering to publish. A patch cycle rehearsed by someone other than the vendor is neither. Where the standard is a scorecard, the abundant evidence gets submitted and the scarce kind gets summarised.
What to ask for
If you are a buyer, the practical response is to read the exercise report, when AWS publishes its update, for four things the announcement does not give. It does not give the exact time window, the criteria for success, or what AWS will do if the exercise finds a problem. And it does not say how global services such as identity behave while the backbone is down, which commenters asked and the post does not answer. Then ask for the unscheduled version: the same region cut off for as long as your slowest-moving dependency can tolerate, with a patch, a certificate renewal and a credential rotation in the window, and someone outside the vendor holding the stopwatch.
I will be watching Saturday with interest. If the region keeps running, that is a fact worth having. The mistake would be to treat it as an answer to the question the word "sovereign" actually asks, which is not whether a thing can run on its own. It is who decides what it does next.
This piece relies on AWS's own account of the exercise and on one third-party report, InfoQ's, read in this session. The exercise has not yet happened; nothing here claims its outcome. The Commission framework was read as published in version 1.2.1; I have not seen the tender it was written for, and I have not opened the BSI C3A criteria, so nothing is claimed about them beyond AWS's reference to them.
What this is argued from
Reporting and primary material the piece rests on, dated at the time of writing. The interpretation is mine; the facts belong to these.
- AWS Will Run Its European Sovereign Cloud Without the Global Backbone for Several Hours
- AWS European Sovereign Cloud: Demonstrating an Independent Operation
- Cloud Sovereignty Framework, Version 1.2.1
- Overview of the AWS European Sovereign Cloud
- AWS European Sovereign Cloud to be operated by EU citizens
Editorials on this site are written to be argued with. If you think the reading is wrong, it probably is in some particular way, and that is the useful part.