devtig.dev

Building Beyond Hyperscalers in European Clouds

Adriaan Wind — Tue, 01 Sep 2026 21:51:00 GMT

EU servers aren’t enough when your provider answers to US law: the legal basis for EU-US data transfers has been struck down twice, and a US decision can take your service offline. So anny built a second region on purely European providers (STACKIT, Scaleway, Lettermint, Bunny, RelAix). That worked because we build on standard tech like Kubernetes, MySQL and object storage. Testing providers took the most time, and some “sovereign” offers still had a US parent or US subprocessors. For us, sovereignty means having a practical way out, and the European region now has more bookings than the first one.

Everybody is nowadays talking about sovereignty in Europe. Mostly, this is linked to topics like “The USA is bad” and “server location must be in EU”. But what does sovereignty really mean, and why is everybody asking for that?

At anny, we dived into this topic quite early in 2022. To understand why, we need to take a look at what anny does: anny is a SaaS booking system for all kinds of resources, desks and meeting rooms in companies, events, sports courses, and equipment, but also seats in libraries of universities for students. So we also work with public institutions and universities, and back in 2022, they already did not like US hyperscalers.
We had then one solution for them: an on-premises installation with Docker Compose. This isn’t really scalable: waiting to get a server and credentials for it, setting it up, dealing with firewall rules, and updating it manually every 3 months. And meanwhile, more and more customers were asking for that.

So we gave ourselves a goal: anny should be available on a purely European infrastructure. And ideally three days ago, because Sales has already told a customer that we can do that. Maybe I still hate sales for that.

But what does purely European infrastructure mean? “Purely European infrastructure” refers to infrastructure owned by companies incorporated in the EU or the European Economic Area (EEA), Iceland, Liechtenstein, and Norway, without a parent company outside of it.

From Safe Harbor to the Data Privacy Framework

Before we dive into how we did it, let’s go into theory. Why do our customers not like the US providers? In 2022, nobody was talking about sovereignty, they were talking about the General Data Protection Regulation, or, in short, GDPR.

TL;DR: Since 2015, the EU’s top court has struck down two agreements on transferring data to the US (Safe Harbor and Privacy Shield) because US authorities can access it. The current one, the Data Privacy Framework, is already being challenged in court, and Trump has weakened one of its key safeguards.

On May 25, 2018, the GDPR became applicable. It had already entered into force two years earlier, but this was the date companies had been preparing for. Many companies feared this day, but the practical consequences became clearer as fines and court rulings followed. GDPR, Article 99.

The question of how European data may end up in the US is older, though. In 2015, the European Court of Justice struck down the old “Safe Harbor” agreement (the first Schrems ruling). Its successor, the EU-US Privacy Shield, followed in 2016: an agreement on how data of Europeans is handled in the US, backed by an adequacy decision of the European Commission. With it, companies had a legal basis for transferring personal data to certified US providers. That covered the transfer, but they still had to follow the rest of the data protection rules.

Then, in 2020, came Schrems II. The European Court of Justice declared the Privacy Shield invalid because personal data in the US was not sufficiently protected against access by US authorities. So did every company have to stop using US services overnight? Not quite. Standard contractual clauses were still an option, but companies had to check whether the data was actually protected and add further safeguards where needed. Signing a contract alone was not enough. In the following years, regulators found that particular uses of services like Google Analytics did not meet the requirements for transfers to the US.

What was the problem? US surveillance rules, including FISA Section 702 and Executive Order 12333, allowed access without the safeguards and effective legal remedies required under EU law. That was a central issue in Schrems II.

Then there is another concern: the CLOUD Act. Passed in March 2018, it clarified that providers under US jurisdiction can be required through valid legal process to hand over data in their possession, custody, or control, even if the servers are abroad. Does that include a European subsidiary? It depends on jurisdiction and who actually controls the data. And a European company can also fall under US jurisdiction. So “the data is stored in Europe” is only part of the answer. The US Department of Justice explains these limits here.

To address the concerns raised in Schrems II, the EU and the US worked on another framework. In July 2023, the EU-US Data Privacy Framework (DPF) was born. It addresses the criticized points with new safeguards: limits on US surveillance, a new Data Protection Review Court for complaints, and independent oversight. US companies can certify themselves, and there is a public list of all companies that do.

Again, this gives companies a basis for the transfer. It does not automatically make everything they do with that service GDPR-compliant.

So everything is fine again? Not quite. In January 2025, Trump fired three of the four sitting members of the Privacy and Civil Liberties Oversight Board (PCLOB), leaving it without a quorum. This is exactly the independent oversight body the EU relied on when it declared the DPF adequate. The DPF survived its first lawsuit at the EU General Court in September 2025, but an appeal is pending at the European Court of Justice. Many already call it “Schrems III in waiting”. Third time’s the charm?

From data privacy to the risk of losing access

TL;DR: Since 2025, the question has shifted from “who can access our data who shouldn’t?” to “who can take away our access to our own data?”. The US government has shown it can do exactly that.

In May 2025, AP reported that International Criminal Court (ICC) chief prosecutor Karim Khan had lost access to his Microsoft email account following US sanctions. Microsoft disputed that it had stopped services to the court, and responsibility for the account being cut off remained disputed. For customers watching this, the question was obvious: could we lose access too?

Around the same time, Microsoft France admitted in front of the French Senate that it could not guarantee French data would never be handed over to US authorities.

And it’s not only email. In June 2026, Anthropic released its AI models Claude Mythos 5 and Fable 5, and three days later had to suspend access to comply with new US export controls. Access came back on July 1. Three weeks is not long, but imagine your product depends on it.

Sanction, export control, or executive order: if your provider falls under US law, a decision can take your service offline, so you are not really independent from them.

Our starting point: European servers, US dependencies

Let’s take a look into the main services that we are using to run anny:

Kubernetes and managed databases: Google Cloud, Frankfurt (europe-west3). Contractor: Google Cloud EMEA Limited (Dublin, Ireland), a subsidiary of Google LLC (US) / Alphabet Inc.
Object-Storage: Google Cloud Frankfurt (contractor as above) and AWS Frankfurt (eu-central-1). AWS contractor: Amazon Web Services EMEA SARL (Luxembourg), a subsidiary of Amazon.com, Inc. (US).
Email: Amazon SES (Frankfurt, contracted via AWS EMEA SARL) and Mailgun EU region. Mailgun contractor: Mailgun Technologies, Inc. (US), owned by Sinch AB (Sweden), with infrastructure hosted on Google Cloud in Germany and Belgium.
Backups: Google Cloud (Frankfurt) and Backblaze B2, EU Central region (Amsterdam, Netherlands). Backblaze contractor: Backblaze, Inc. (US).
Firewall and CDN: Cloudflare, with a global edge network. Contractor: Cloudflare, Inc. (US).

We tried for every provider to get Germany or at least Europe as a location. But choosing European data centers did not remove our exposure to US jurisdiction through these providers.

One thing that you may recognize is that we build a lot on standard products with Kubernetes, databases like MySQL and Redis, or object storage and not services like AWS Lambda, Cloud Run, or Supabase. With that, we can find other providers that also support these technologies easily, while provider-specific services make switching hard.

How we chose European providers

Speaking about providers. How do we find these European incorporated providers? We have created here some criteria to select these providers:

Of course the company should be incorporated in the EU without any parent companies outside the EU.
The provider should provide modern technologies and versions. We have seen during our research providers that were providing Kubernetes clusters with outdated versions or do not support the newest database versions.
Fair pricing. We like the flexible pricing that we can get at hyperscalers. We don’t want to pay a high setup fee or prices starting with 1k € per month.
Since most of our customers were located in Germany and Germans love German products, we would prefer Germany as a data region over all regions.
We also had some personal preferences, based on our own experience over the years or recommendations from others.

But how do you find these providers? There are several great websites for that. The current one that I prefer is european-alternatives.eu. You have there a great possibility to find replacements for different services (like Google Maps or Shopify) or filter by technologies like Kubernetes or Object Storage. You directly see information about the provider, like location and pricing.

Is sovereignty pain?

Finding a provider is the easy part. Testing the provider to see if it is suited for the use case is another thing, and this part takes the most time.

For example, some providers have prices that are only available on request. Before you get access to a test account, you have to book a consultation call. After the call, you get a long PDF to fill out and sign before anyone creates an account for you. The price is then based on some magic calculations.
For example, Myra, a firewall and CDN provider from Germany, is excellent at this; at least they now have a pricing calculator. This makes it extremely difficult to compare providers easily, and I know that we all hate these consultation calls.

Another caveat is technical limitations. We already mentioned outdated versions, but this is not all. Some providers do not offer nice monitoring features or Terraform/OpenTofu providers. Or the service is still in beta.
For example, Bunny took quite long to provide their Terraform/OpenTofu provider, and changes made with STACKIT’s Terraform/OpenTofu provider were not visible inside the UI. Also, compliance requirements like ISO 27001 certification were missing, in particular on small providers.

Also, stability and availability are huge problems. Some providers are completely sold out, for example, GPUs, since everybody needs them for AI.

On the other side, some providers really stand out. Scaleway has a great and really big portfolio with affordable pricing. The same applies to Bunny with great pricing and features that are locked on Cloudflare behind an enterprise plan. UpCloud convinced us with great uptime and pricing. STACKIT has all certifications that enterprise customers need. And Lettermint has an outstanding email service, really great. And the market for European providers is growing rapidly since the demand is increasing.

Looking behind the sovereignty label

The last and most subtle problem: the provider itself was European, but it wasn’t purely European. The company was incorporated in the EU, with no non-EU parent. But when we looked at their infrastructure subprocessors, US companies showed up again. Brevo, for example, is using Google Cloud & Cloudflare.

You can call this also sovereignty washing like greenwashing but with sovereignty. Everybody puts it on their product now, but not everything that says sovereign is sovereign. The most prominent example is the AWS European Sovereign Cloud. It became generally available on January 15, 2026, with its first region in Brandenburg, Germany, physically and logically separate from the other AWS regions. It is operated only by EU residents, and AWS set up a new parent company with three subsidiaries incorporated in Germany. Sounds great, right? But let’s go back to our definition from the beginning: no parent company outside the EU. The company behind it is still a 100% subsidiary of Amazon.com, Inc.

There are other variants too. Some hyperscalers let a European partner run their technology, like T-Systems with Google Cloud or Delos Cloud with Microsoft. That’s better because the operator is European. But the software, the updates, and the licenses still come from the US. And we’ve seen with the ICC and with export controls what can happen when a US company is no longer allowed to deliver.

The stack behind our European region

So at the end, what did we choose as alternatives for our European stack?

Kubernetes and managed databases: STACKIT, Germany.
Object-Storage: STACKIT (same contractor as above).
Email: Scaleway Transactional Email, Paris region. Contractor: Scaleway SAS, subsidiary of the iliad Group (France). Also Lettermint, contractor Lettermint B.V. (Netherlands), with email data hosted on UpCloud (NL) and OVHcloud (FR).
Backups: Scaleway and RelAix Networks GmbH, hex/AC data center, Aachen.
Firewall and CDN: Bunny. Contractor: BunnyWay d.o.o. (Ljubljana, Slovenia).

We did not do a migration from our US-based providers to the European-based providers. We created an entirely new data region, since we did not trust the providers yet. This was a pain (maintaining two data regions) but was a good decision.

Sovereignty means having a practical way out

I want to follow up on the initial question: What does sovereignty really mean? The definition says “freedom from external control”. And that is much more than using European providers, since they could also remove your access to your data for any reason (even if it is legally not okay). This brings us back to our tech stack: using technologies that many providers support gives us a way out.

Does that make switching effortless? Of course not. We still have to move the data, configure the new services, and check that everything works. But we can do that without rebuilding the whole product around another provider. We switched, for example, from AWS S3 to Cloudflare R2 or from EmailLabs to Scaleway Transactional Mails. The move from S3 to R2 was between two US providers, but it shows the same thing: we had a choice, and we could act on it. For us, that freedom is a big part of sovereignty.

What the European region changed for anny

But after the initial difficulties, we are happy to have this sovereign solution. With that, we have won many new customers who had searched for true European solutions, and the European region has even more bookings per month than the first region.
One important learning here is you do not need to be the best solution, you only need to be the best European solution, and that made us at anny from a startup to an industry leader.

I also gave this as a talk, The Sovereign Stack: slides and a recording.

It’s All Just the Cloud: The Appeal and the Limits of the Cloud

Adriaan Wind — Thu, 27 Oct 2022 00:00:00 GMT

This post first appeared in German on the digitalHUB Aachen blog in October 2022. Four years later, the follow-up: Building Beyond Hyperscalers in European Clouds.

The cloud adds flexibility and managed services on top of classic hosting. That pays off at the start, while you stay in the free tiers, and when you really need to scale. Provider-specific services lock you in, and at steady load the bill grows faster than the benefit.

The cloud, the final frontier. At least that’s what the cloud providers promise us these days. The limits depend on how much you are willing to pay. Over the last few years, the cloud has become more and more popular, and many companies have moved into it. But is cloud computing really the solution to every problem, and is it right for everyone?

Not every cloud is the same

We all know the line “the cloud is just someone else’s computer”. But if all we get in the cloud is servers, how is it different from the classic hosting offers that have been around for decades? Simple: the cloud offers a lot more. Not just servers, but services, and one more important thing: flexibility.

To understand what the cloud adds, we need to take a few steps back. Companies have always needed servers, and more than one of them has a server room in the basement. That’s on-premises: everything runs on your own premises. You take care of power, cooling and security, and you buy the hardware yourself.

What the cloud has to do with pizza

To make this easier to follow, people like to reach for a pizza analogy. An on-premises setup is baking pizza at home: we use our own kitchen, provide the energy and the oven, make our own dough, take care of the toppings, put it all together and eat it at home. The upside: we decide exactly which ingredients go into the dough and which toppings go on the pizza.

Hosting

With hosting, it gets simpler. You don’t take care of the infrastructure, and you don’t buy or maintain the server hardware: the provider does that. You rent the server for a fixed period.

Back to the pizza: this is a frozen pizza. It’s almost done, we only put it in the oven, finish baking it and eat. But we can only choose from a few predefined varieties.

Infrastructure as a Service (IaaS)

The cloud has the same principle. It’s called Infrastructure as a Service (IaaS), and what sets it apart from classic hosting is mostly flexibility.

At a classic hoster, we choose between fixed combinations of CPU and memory. In the cloud, we set both in fine steps, exactly as we need them. The same goes for terms: a classic hoster usually rents for fixed terms, from one month to several years. In the cloud, you can cancel at any time, and you pay by the minute.

Platform as a Service (PaaS)

Now to where the cloud really shines: Platform as a Service (PaaS). Here we take care of even less. Roughly speaking: we hand over the application, exactly the thing that should run in the cloud, and the provider makes sure it runs. We don’t manage databases either, we book them as managed services. That saves us a lot of admin work, and of course we pay for it.

In pizza terms: we order a pizza, it gets delivered, and all that’s left is eating it at home.

To finish the analogy, the last step is eating the pizza in a restaurant instead of at home. There you don’t take care of anything at all. That’s Software as a Service (SaaS): a finished product you simply buy.

Pizza as a service: the more you hand over, the less you do yourself, and the more you pay for it.

The power of PaaS

PaaS is the big advantage of the cloud, because the provider takes over a lot of the management. But there is more behind it. In software development, it has become normal to pack an application into containers. Each container is self-contained and brings every dependency it needs, and a container runtime runs them.

Who would have guessed: cloud providers offer this runtime as a service too, for example as Kubernetes. All you need are your containers and the manifests that configure Kubernetes. Need a database as well? No problem: a few clicks and a few minutes later, it runs on hardware built for exactly that, without a database administrator.

One step further: maybe we don’t want to deal with building containers at all. We have a finished application, and it should run in the cloud. The providers have a ready-made answer for that too, for example App Engine on Google Cloud.

We quickly notice that the cloud can take more and more work off our hands, especially for management, flexibility and scaling. But we haven’t reached the top level yet: services that only exist at one provider. With AWS Cognito, you hand off the whole authentication, including sign-up and user management. With Google Firebase, the whole backend of an application. That’s already deep in “serverless” territory. Many providers also offer big data and machine learning, so you can plug those into your application through their APIs with very little know-how of your own.

So the cloud isn’t just “someone else’s computer” after all. It’s also a service provider with a broad offering.

Stuck in the cloud

Building on existing services looks very practical at first. But there is a catch: once you depend on these products or this provider, switching gets hard.

So always ask yourself: do you invest a bit more time at the start and build some features yourself, to stay independent of the cloud providers? Or do you go all in and accept being tied to one provider?

At anny, we deliberately went with the universal container route on Kubernetes, so we can run on different cloud providers. That’s also how we built an on-premises version within a few days, which runs on our customers’ own infrastructure. That would not have been possible if we depended on cloud services.

Back down to earth

When the cloud got really big, you saw lots of companies move into it. Now, a few years later, you also see a growing trend the other way: out of the cloud and back to the classic hosters.

Why? All the flexibility and management the cloud brings has a price. Cloud is expensive!

The principle is simple: if you start small in the cloud, it’s very cheap. You don’t produce many costs yet and usually stay within the providers’ free tiers. As your usage grows, so does the bill, and that can go through the roof. A real hefty bill.

So the cloud pays off mainly in two cases: early on, while you stay within the free tiers, or when you need exactly that scalability and flexibility, for example to absorb load peaks. If your load is moderate and you don’t need that scalability, you can take the path others have already taken: out of the cloud and back to classic servers.