GDPR has been on the books since 2016 and started to be enforced in 2018. Back then, clear guidance for how to technically implement GDPR was missing. Now, an increasing number of GDPR enforcement cases and a myriad of court rulings, opinions, recitals and guidelines later – clarity has emerged. Last week, the Swedish Data Protection Authority (IMY) sent a very strong message during their virtual conference, hosted on a fully Swedish controlled tech stack: data about EU citizens must be processed in EU clouds. Not just EU regions of US-owned clouds. EU clouds.
While this is a ‘need to have’ and not a ‘nice to have’ decision, it can often cause uncertainty for your developers and operators. ”Will we have to manage everything ourselves n<ow? Will our favourite tools be taken away? What about uptime?”. It is true that EU clouds won’t give you the same experience as their US competitors. However, there are good solutions to these questions and the landscape is rapidly evolving.
In this post, we will summarize four actionable advice to reduce the uncertainty your developers and operators may feel and get a good EU cloud migration experience.
Setting Expectations: The EU Cloud Landscape
When moving to EU cloud providers, the first thing one notices is that they are “different”: Instead of a few big providers, the market is filled with many small players. This is both good and bad. Good, because you have more choices when it comes to geography and jurisdiction. If a customer asks you to store data within 100km of Stockholm in a pure-EU cloud provider, there’s a provider for that.
However, having many small providers is also bad. Creating a platform as a service that offers everything from managed databases to click-of-a-button Jupyter Notebooks for GPU-backed machine learning is a huge investment. Since EU cloud providers weren’t as blessed with attention and customers as their US counterparts, migrating to an EU cloud may feel like going back a decade, at least feature-wise.
Each EU cloud is missing “something”, whether it’s encryption-at-rest, load-balancers, IPv6, object storage, Content Delivery Network (CDN), etc. Some of these features may exist, but are not as self-service as they could be. Higher up the tech stack, you will definitely miss fully-integrated solutions like hosted Jupyter Notebooks.
Advice 1: Move Only What You Need to Move
It doesn’t have to be all-or-nothing.
Your first step should really be identifying what class of data needs to be migrated away from US-cloud providers and what components in your tech stack process that data. For example, databases and container compute engines which process EU personal data or patient data should be prioritized. Other components — such as on-call management tools, like OpsGenie or PagerDuty — generally do not process personal data, hence they do not need migration.
Consider using data minimization and anonymisation to reduce the number of components that need migration. For example, you may still use your favorite machine learning tool to understand customer behaviour — such as AWS SageMaker — as long as your ETL (Extract Transform Load) code runs in an EU cloud and strips or anonymizes all personally identifiable information.
Further consider access minimization to ensure you can continue using your favorite DevOps tools. For example, you can most likely continue to use GitHub Actions or Azure DevOps, in particular assuming it has minimal access to your Kubernetes cluster. You can make reasonable enforcement of this via various means, such as role-based access control, image signing, and automatic policy enforcement.
So instead of thinking about it as an “all-or-nothing” migration, do make that extra assessment to pick and choose. This way, your developers can stick to some of the tools and processes your organization has already adopted.
Let’s also briefly talk about the elephant in the room: The sheer number of high-level services – think image and voice recognition – that the major US providers offer, makes it sometimes prohibitively expensive to fully migrate to the EU. Involve your Data Protection Officer (DPO), do a proper risk-cost analysis. The worst thing you can do is ignore the problem and just hope for the best. The best thing, if you anyway decide to make this decision, is to document and communicate – both to your customers and regulators – that you knowingly will process some personal data on US clouds.
Advice 2: Think functionality not software name and version
Success is more likely if the application team is onboard
When shopping for an EU cloud provider, make sure to involve your application team early on.
Why? Most companies make the mistake of specifying requirements of managed services in the form of software name and version, e.g., “PostgreSQL version 14”. While this might make sense if you shop for roughly equivalent US cloud providers, such a mindset needlessly restricts the EU provider you are looking for.
Try to go back one level. Your application needs to run in EU jurisdiction. You have three options:
Demand the exact same software name and version as you used before the migration and look for a managed service provider for exactly that. The benefit is that you need zero application changes, but the downside is that you restrict your options for finding a managed service provider.
Demand the exact same software name and version, but self-host the ones you cannot readily find, managed in the EU. The benefit is that you have more options, but now you burden your application team with having to operate not only their application, but also parts of the platform. Self-hosting things like databases is seldom part of your core business.
Relax your requirements and think in terms of functionality. The benefit is that you keep all EU managed service options on the table. Instead of burdening your application team with platform operations, you simply ask them to make code changes. Your application team is likely to be more successful in changing their own code, rather than learning how to administer a platform component.
In my experience, option 3 is the option preferred by most application teams. While switching from one database to another or one message queue to another is not always automatically easy to do, your application team likely already did an excellent job to contain the needed modifications to a handful of adapter modules. In fact, they likely used a library such as the DotNET Entity Framework, the NodeJS Sequelize or Python Django. If so, swapping the database from one vendor’s to another’s could be a simple configuration change.
Advice 3: Focus on the security goals
You can mitigate some security risks with different means.
Let’s assume that you went shopping for an EU cloud provider. Say that your top selection ticks all boxes except one requirement: perhaps, encryption-at-rest or cross-data-center resilience. There are two directions to address this issue.
First, have an open discussion with the cloud provider. They likely took additional security measures, such as physical security and safe disposal of hard drives, to mitigate the risk of personal data leaking via replacing hard drives. So while they don’t tick exactly the box you have on your list, they might protect EU personal data sufficiently to meet your goals. Verify which information security standards they are certified against to see if those match your requirements.
Second, have an open discussion with your customers. Ask them what are their “must haves” security requirements, and what are their “nice to haves” security requirements. Supposing they decided that processing their data in the EU is a “must have”, they are perhaps willing to trade a few “nice to haves” to get it. For example, if your top selection does not offer cross-data-center resilience, perhaps an off-site backup combined with low disaster recovery time is sufficient to make your customers happy.
Advice 4: Leverage Your Relative Size
EU Cloud providers might not have the feature you need today, but they might implement it for you next quarter.
The relatively small size of most EU cloud providers comes with obvious downsides in the terms we have already mentioned, but it also comes with advantages. Because of their size, some EU clouds would be happy to let you influence their roadmap and even talk to their Product Manager — something you wouldn’t even dare dreaming about with a US cloud provider. Therefore, you can view the size of EU cloud providers as an asset instead of a liability, and work with them to help them help you.
Also, the recent discussions around EU data sovereignty (and initiatives such as GAIA-X) have brought a lot of attention — in the form of revenue and capital — to EU cloud providers. Hence, the landscape is shifting rapidly. Thus, when picking an EU cloud provider, you shouldn’t only evaluate their capabilities today, but also their capabilities tomorrow.
The future belongs to those who respect privacy
Over just the last year, we have seen a tremendous increase of companies seeking advice on how to migrate to an EU cloud. The public sector in many countries and healthcare service providers are among the clearest front-runners for privacy. However, in recent times the debate has spread across an increasing number of industries. Those that already prepare for that future will have a competitive advantage over those that do not, as their sales rep will be able to focus on the products and not the privacy policy.
For those developing the services, the good news is that many have already successfully migrated to the EU. It’s far from impossible. Hands on advice is out there. We have been in this space for years, and we see that both technology and service offerings are rising to meet the demands that a cloud vendor neutral and privacy-first mindset requires.
