EU Digital Sovereignty: A Practical Playbook for Leaving US Cloud Providers

"Digital sovereignty" used to be an EU policy slogan. In 2026 it is a line item on enterprise procurement questionnaires, a topic in most SaaS architecture reviews, and — for a growing number of European companies — a migration in progress. This post is a practical playbook for teams who have decided, or are deciding, to move workloads off US hyperscalers.

The playbook is not ideological. AWS, GCP, and Azure are excellent technical platforms. The case for leaving is a mix of legal exposure, cost, and customer pressure — and the case for staying is equally real. What has changed is that the European alternatives are finally good enough for most workloads. Making the move is an engineering project, not a leap of faith.

What actually drives the move

Every migration I have seen has been some combination of five factors:

• Regulatory pressure. Public-sector procurement in Germany, France, and the Nordics increasingly requires EU-incorporated suppliers. Private-sector enterprise customers are adopting the same posture for their data processors.
• Schrems II fallout. The EU-US Data Privacy Framework is under challenge again. Betting multi-year architecture decisions on the current adequacy mechanism is a legal risk most boards no longer want to carry.
• The CLOUD Act. A US court can compel a US-incorporated company to produce customer data stored anywhere in the world. For EU-regulated data, that is a standing exposure.
• Cost at scale. Hyperscaler bills grow faster than hyperscaler features at most companies' size. European alternatives are frequently 30-60% cheaper for equivalent compute and storage, with flat pricing that makes forecasting possible again.
• Customer reputation. "We host in the EU" is starting to show up in sales decks. For SaaS companies selling to Europe, that is no longer a niche differentiator.

What does "sovereign" really mean?

Digital sovereignty has three nested meanings, and it is worth being precise about which one you are after:

1. Physical residency. Data is stored on hardware in the EU. Every hyperscaler offers this with an EU region.
2. Jurisdictional residency. The provider itself is incorporated in the EU, and no US legal process can compel them to produce your data. Hyperscalers cannot offer this.
3. Operational residency. Not just the provider but every sub-processor on the data path is EU-incorporated. Some providers offer this; most do not.

Most regulatory frameworks ask for (1) and implicitly reward (2). The strictest public-sector procurement asks for (3). Know which level your customers and regulators need before you start picking vendors.

The shape of a typical migration

The good news: a full migration rarely happens in one step. The workable pattern is a staged decomposition:

1. Inventory first. Catalog every AWS/GCP/Azure service you use — compute, storage, databases, queues, DNS, CDN, secrets manager, observability. Rank by criticality and by how hard each is to replace.
2. Start with the stateless layer. Migrate web services, background workers, and cron jobs first. They are the easiest to cut over and have the clearest alternatives.
3. Move managed data next. Postgres, MySQL, Redis, search. The migration is straightforward (dump, restore, cut DNS), but planning around zero-downtime is where the engineering effort goes.
4. Leave object storage for later or keep it. Object storage is the stickiest migration — TBs of data at rest, often with complex access policies. Some teams migrate it; others leave it on AWS S3 with a separate DPA and move everything else.
5. Replace the ancillary services last. Observability, email, DNS, and CI/CD are less sensitive and can be swapped at a more measured pace.

Concrete substitutions, 2026 edition

For the typical SaaS stack, here is what people are replacing US services with:

Compute (ECS, Fargate, Cloud Run, App Service)

The European PaaS market is the most mature it has ever been. HostStack, Scalingo, Clever Cloud, Upsun, and Scaleway Serverless Containers all cover the standard web-service / worker / cron-job shape. For teams that want a Heroku-equivalent, HostStack or Scalingo are the shortest migrations.

Managed databases (RDS, Cloud SQL, Azure Database)

HostStack bundles managed Postgres, MySQL, MariaDB, MongoDB, and Redis with the platform. Aiven (Finland-HQ, multi-cloud) offers deeper per-database features. Scaleway Database is a budget option. See the dedicated buyer's guide for the trade-offs.

Object storage (S3, Cloud Storage, Blob Storage)

Scaleway Object Storage, OVH Object Storage, and Hetzner Object Storage are all S3-compatible and EU-incorporated. For applications that are read-heavy and globally distributed, Cloudflare R2 is an interesting hybrid — US-incorporated parent but zero egress fees and strong EU caching.

Queues and streaming (SQS, Kinesis, Event Hubs)

NATS JetStream covers most SQS/Kinesis use cases, with mTLS and durable streams. HostStack ships it as a managed primitive; it can also be self-hosted trivially. For heavier streaming (log pipelines, event buses), Aiven Kafka is the mature option.

Email (SES, SendGrid, Mailgun)

PostStack is the European transactional email option we happen to know well; it runs in Germany and Finland and powers HostStack's own email. Mailjet (French, Mailgun's European cousin) is the other serious choice.

Observability (CloudWatch, Stackdriver, Datadog)

Self-hosted Loki + Prometheus + Grafana on a European PaaS is usually the cheapest answer. Grafana Cloud has an EU instance; Datadog does not meaningfully change its legal posture whichever region you pick.

CDN and DNS (CloudFront, Route 53)

Cloudflare remains the dominant CDN choice even for EU-first teams; DNS and CDN are usually deemed low-risk transfers because they only see traffic metadata. For the strictest sovereignty requirements, Bunny.net (Slovenian) and Fastly (US, but with specific EU-only configurations) are alternatives.

Identity and secrets (IAM, Secrets Manager, Key Vault)

This is the layer hyperscalers genuinely lead on. Most teams keep an IAM boundary with their hyperscaler for historical reasons, or adopt a cross-cloud tool (HashiCorp Vault, 1Password secrets) as part of the migration.

The cost conversation

A rough rule of thumb, based on the migrations I have seen: equivalent compute and storage on an EU PaaS or EU cloud is 30-60% cheaper than AWS/GCP list price, before discounts and reserved instances. The gap narrows but rarely closes entirely even with hyperscaler committed-spend discounts.

The more interesting number is predictability. Hyperscaler bills swing with traffic, S3 request rates, NAT gateway egress, and a dozen other metered surfaces. EU PaaS bills tend to be flat. For finance teams that want to forecast runway without surprises, that change alone is often worth the migration.

Where hyperscalers remain cheaper is in bursty workloads with very uneven traffic — auction platforms, batch ML training, media rendering pipelines. If that is your shape, you probably keep some hyperscaler spend even post-migration.

Risks, and how to manage them

Three risks are worth naming honestly:

• Vendor maturity. Smaller European providers do not have the scale or the runbook depth of AWS. The good ones are explicit about this and compensate with responsive support; the mediocre ones are not. Reference-check your shortlist.
• Feature gaps. Niche hyperscaler services (AWS Step Functions, SageMaker, Redshift) have thinner European equivalents. If your architecture depends on them, budget for a rewrite.
• Migration effort. A team-weeks estimate is fair for a straightforward SaaS; multi-month projects are realistic for anything with complex data pipelines or serverless glue. Budget accordingly, and stage it.

A six-month migration plan

A concrete template we have seen work for mid-stage SaaS teams (~20 services, couple of TB of Postgres, moderate object storage):

1. Month 1: Inventory + vendor selection. Audit every AWS service. Pick EU replacements. Sign DPAs.
2. Month 2: Dark launch. Stand up the new platform in parallel. Wire CI to deploy to both. Mirror production traffic with a shadow deployment for a week to sanity-check.
3. Month 3: Stateless cutover. Move web services, workers, and cron jobs. DNS-level traffic shift, rollback plan in place. No data migration yet.
4. Month 4: Database migration. Replicate Postgres to the new managed instance (logical replication or AWS DMS). Freeze writes, final sync, cut over.
5. Month 5: Storage and ancillaries. Migrate object storage with a rclone-style replication job. Move email and observability.
6. Month 6: Decommission. Spin down AWS resources, rotate credentials, close the account or downgrade to the minimum tier. Update the DPA with the new sub-processor list.

Bottom line

EU digital sovereignty is not a slogan in 2026. It is an achievable engineering outcome with real vendors and real migration runbooks. For teams whose customers, regulators, or finance departments are asking, the window for "we'll get around to it" is closing.

If you want the shortest version of the playbook: pick one workload, try one European PaaS for a month, see whether the trade-offs match the hype. The worst outcome is that you learn which parts of your stack actually depend on hyperscaler lock-in. The best outcome is a cheaper, simpler, jurisdictionally clean platform that your sales team starts bragging about.