Ever since announcing the European Sovereign Cloud (ESC), AWS has gone to great lengths to convince people that the ESC is sovereign in more than just name. One of its promises was that the ESC would remain operational even without a connection to the global AWS network. The company recently put this to the test. We spoke with Mustafa Isik, Chief Technologist for Sovereignty at AWS, about this test and what the results mean for the sovereignty debate.
The desire to set up a sovereign IT infrastructure is quite strong in our region these days. The debate surrounding this topic is also quite polarizing. Some parties view sovereignty as a black-and-white issue. By definition, any provider not based in the region cannot be sovereign. So if organizations want to operate with 100 percent sovereignty, they must avoid all such providers.
Others take a stance that allows for more room for shades of gray. In this approach to sovereignty, a risk analysis is conducted, resulting in varying degrees of sovereignty. The European Commission appears to be following this path, particularly for cloud infrastructure. To that end, it has established five different Security Effective Assurance Levels (SEAL) as part of the Cloud Sovereignty Framework.
AWS European Sovereign Cloud
In the midst of this discussion, AWS made the European Sovereign Cloud (ESC) generally available earlier this year in Potsdam. AWS developed and built the ESC entirely on its own. It is not the result of a partnership with a local or regional sovereign entity, like we see from other hyperscalers.
After an investment totaling approximately $8 billion, AWS claims to have created a truly sovereign cloud region for customers in our region. Every detail was carefully considered. For example, the ESC is technically, physically, and logically separated from the global AWS infrastructure, including its own DNS and IAM, to name just a few aspects. The ambition was, and remains, to ensure that only EU citizens have access to it. Furthermore, the AWS source code has been made available to people within the EU.
It should be clear that AWS was, and remains, committed to ensuring the ESC is viewed as truly sovereign. For the hardliners in the debate, however, this is still not enough. They see the AWS logo and conclude that it can never be 100 percent sovereign. Since, for such parties, sovereignty is either 0 percent or 100 percent (“you can’t be just a little bit sovereign”), AWS is therefore not sovereign, no matter how hard it tries. The fact that the German federal government explicitly stated during the ESC’s launch that it is sufficiently sovereign for this typically critical EU member state does not change that.
AWS ESC does not need broader AWS infrastructure
In addition to the ESC’s completely separate design, in which not only the employees but also the suppliers (including connectivity providers) are based in the region, AWS made another promise. The ESC would be able to operate completely independently of the broader AWS infrastructure. Furthermore, there is a guarantee that all AWS services and features will remain available. So, should there ever be a situation, for whatever reason, where there absolutely must be no connection between the ESC and the rest of the infrastructure, AWS can disconnect the ESC.
AWS did just that on Saturday, October 24, after announcing in advance that it would happen. Ultimately, this mainly involves changing the BGP (Border Gateway Protocol) route from the AWS Global Network’s Autonomous System (AS) number to an AS number belonging to a provider for the ESC. Isik explains this.
What was the impact of the disconnection on customers?
When we ask Isik if anything went wrong, he says that was not the case. Everything went exactly as they had planned. Of course, there is always a very brief moment when the connection is unavailable. That’s simply because the route has to be switched over. As a result, there was some disruption for a few customers. Overall, though, it went very smoothly, Isik reiterates.
As mentioned, the disconnection on October 24 was announced in advance. Additionally, AWS conducted the test on a Saturday. These are two factors that work in AWS’s favor. After all, customers can plan accordingly. Furthermore, the weekend is generally quieter for many organizations than a weekday.
In and of itself, the timing of the shutdown and switchover doesn’t matter that much, Isik notes. “We can do this at any time of the week,” he says. Switching a BGP route on a Saturday isn’t much different than on any other day of the week. However, we can imagine that the number of workloads is lower on a Saturday. As a result, fewer organizations are affected if it happens on a Saturday.
How does the ESC perform without the AWS Global Network?
What about the performance of the disconnected ESC? After all, the AWS Global Network is a private backbone, while the disconnected ESC connects via the public internet. According to Isik, there was no negative impact. He notes that sufficient redundancy is built into the connections. AWS sets specific requirements for the redundancy of providers’ connections. Additionally, there is also redundancy between providers.
Finally, there’s also the expansion of the ESC, which was announced last January. Local Zones are coming to the Netherlands, Belgium, and Portugal. This makes the ESC as a whole a lot more complex. We can imagine that this will also have an impact on the performance of a disconnected ESC. This ESC would then operate without access to the AWS Global Network, which consists of about 9 million kilometers of fiber-optic cable.
When we ask Isik whether this decoupling can also scale to a larger, and thus more complex, ESC, he indicates that he is fully confident this will be the case. Based on this answer, it appears that the future expansion has not yet been fully factored into the current design principles. However, AWS now knows that the current design works, so it’s reasonable to assume that it can also be scaled up to incorporate the Local Zones.
Why doesn’t the AWS European Sovereign Cloud always run independently?
If we listen to Isik, one might almost think that switching to the public internet has absolutely no effect on the performance of the AWS cloud, in this case, the ESC. In the context of sovereignty, wouldn’t it be better to always have the ESC run separately from the AWS Global Network?
The blog post in which AWS announced the test on October 24 includes the following passage:
The AWS European Sovereign Cloud runs connected to the AWS Global Network backbone because it delivers superior performance, capacity, reliability, security, and cost savings to customers. That includes always-on encryption and distributed denial-of-service (DDoS) defenses, and the backbone cannot decrypt or view the encrypted data that AWS European Sovereign Cloud customers send and receive. While the backbone delivers these benefits on a day-to-day basis, the AWS European Sovereign Cloud can continue to operate independently, with the appropriate security controls in place.
According to AWS, the ECS delivers the best performance, reliability, capacity, and security via the AWS Global Network (i.e., the private backbone). All of this at the best price. This implies that these qualities are reduced when the ECS operates independently. It is not clear to us by how much. In itself, that is not surprising, of course, given the enormous infrastructure that AWS has built worldwide.
It’s important to note here that AWS makes it clear that the European Sovereign Cloud is fully functional and well-secured even when disconnected from the AWS Global Network. That will be necessary, because, as Isik rightly pointed out in our conversation, one of the reasons for choosing AWS is the combination of extensive functionality and strong performance. Both must remain at a high level.
Is it truly sovereign?
AWS is keen to position the European Sovereign Cloud as a truly sovereign cloud. It is the only one of the major hyperscalers to take such a thorough approach. In doing so, it adheres to the frameworks of the European Commission (CSF) and the German government (BSI) as guidelines.
Whether the ESC, in autonomous mode, will achieve the highest SEAL level (SEAL-4) of the Cloud Sovereignty Framework is something we cannot fully assess. Legal experts will undoubtedly have strong opinions on this matter, whether or not based on previous court cases.
Formally, the following must be true for SEAL-4: “Technology and operations under complete EU control, subject only to EU law, with no critical non-EU dependencies.” As far as we can tell, this appears to be the case for a disconnected ESC.
Of course, we are assuming here that everything functions as intended. The German GmbH (and the board that oversees it), which formally manages the operations, has ESC’s interests as its top priority. This GmbH is subject to German (and European) law. And because the ESC is completely decoupled, no interference from outside the EU is possible.
The only remaining options for outside influence are heavy pressure from the parent company and/or backdoors in the infrastructure. Such reasoning does not seem very meaningful to us. After all, we could still come up with a whole host of arguments as to why technology and infrastructure originating in the EU are not entirely sovereign either. They, too, can be relatively easily sabotaged and shut down by actions originating outside the EU.
Not for everyone, but for many
For organizations that simply do not want to see logos from non-European suppliers, the evidence provided by AWS will still not be sufficient, since the technology is and remains American in origin. If you really do not want that, then the AWS European Sovereign Cloud is still not an option. Fortunately, organizations are free to decide this entirely for themselves. For (regulated) organizations that view sovereignty as a spectrum, the AWS European Sovereign Cloud seems like an excellent option to us.