European alternatives to AWS.

A German procurement team writing a Schrems II transfer impact assessment, a French public-sector buyer requiring SecNumCloud, or a SaaS company mapping its dependencies ahead of the EU Tech Sovereignty Package all end up asking the same question about AWS: who actually controls this infrastructure? Amazon Web Services, Inc. is a subsidiary of the US-incorporated Amazon.com, Inc. (NASDAQ: AMZN), and despite multiple EU-region data centres and the announced European Sovereign Cloud, that ownership structure means CLOUD Act jurisdiction still applies. The April 2026 EU sovereign cloud tender (€180M, awarded to Scaleway, Clever Cloud, OVH, and STACKIT, with AWS excluded) is the clearest institutional signal that European buyers are already answering the question with alternatives.

This page checks twelve European cloud-hosting alternatives against AWS on four concrete questions: who legally owns the company, where the data physically sits, which sub-processors touch the operational layer, and whether the platform holds a recognised European compliance framework such as ISO 27001, BSI C5, EUCS, or SecNumCloud. The source for each answer is the vendor's published DPA.

The three names worth knowing up front are Scaleway (France, Paris; broadest managed-services catalogue, winner of part of the EU sovereign cloud tender), Hetzner (Germany, Gunzenhausen; strongest price-per-performance for compute-heavy workloads), and OVHcloud (France, Roubaix; the largest-scale European cloud, with SecNumCloud-qualified tiers for French public-sector buyers). All three are EU-owned and EU-hosted.

Your compute, storage, and networking primitives survive the move largely untouched:

• IaaS primitives (VMs, block storage, object storage, VPC networking, load balancers, managed databases). Every alternative has direct equivalents.
• Kubernetes (Scaleway, OVH, IONOS, STACKIT, Exoscale, UpCloud all ship managed K8s).
• S3-compatible object storage with standard SDK compatibility.
• Standard Linux and Windows VM images, with cloud-init support.
• Terraform / OpenTofu and Pulumi support across all major European clouds.
• IPv6, DDoS protection on most tiers, basic CDN options.

Where parity breaks down is breadth, not the core building blocks:

• AWS's managed-services breadth at the AWS scale: ~250 AWS services, ~50–80 services on the larger European clouds. The breadth narrows on the lower-cost European clouds (Hetzner is famously minimal on managed services: compute, storage, network, and that's intentional).
• AWS-specific products: DynamoDB (use a managed Postgres or Scaleway Document Database), Lambda's full runtime catalog (use Scaleway Functions, OVH Functions, or self-hosted OpenFaaS), SageMaker (Scaleway and OVH have ML-platform equivalents but smaller).
• Some integrations with US-flavoured DevTools (AWS-specific CodePipeline, CloudFormation StackSets at extreme scale). Most teams use Terraform / OpenTofu instead, which works identically across all European clouds.
• The AWS Marketplace's third-party software catalog. European clouds have smaller marketplaces; for niche enterprise software you may need direct vendor relationships rather than marketplace pull-in.

AWS-to-EU moves tend to follow the same seven stages regardless of which European cloud you pick.

1. Inventory your AWS service usage. Use AWS Cost Explorer to identify which services actually consume budget. Most SaaS workloads use 5–10 services for 90% of cost (EC2, S3, RDS, ELB, CloudFront, Route 53). The long tail is usually CloudWatch logs and forgotten test resources. Migrate the high-cost set; archive or terminate the long tail before moving.
2. Map AWS services to European equivalents. Build the mapping table explicitly: EC2 → Scaleway Instances / Hetzner Cloud / IONOS Compute, S3 → Scaleway Object Storage / OVH Object Storage, RDS → Scaleway Managed PostgreSQL / OVH Managed Databases, CloudFront → Scaleway Edge or BunnyCDN. For each AWS service in your inventory, pick the European target.
3. Re-create your VPC topology on the new cloud. Scaleway, OVH, Hetzner Cloud, IONOS, and STACKIT all support private networks with subnet routing equivalent to AWS VPCs. Replicate your subnet layout, security groups, and routing rules in code (Terraform/OpenTofu) before moving any data.
4. Set up data replication in both directions during the cutover. For databases, use logical replication (Postgres logical decoding, MySQL GTID-based replication) to stream data from AWS RDS to the new European managed database. For object storage, use rclone with s3-to-s3 mode to sync S3 buckets to the European S3-compatible service. Run both in parallel for 2–4 weeks to verify consistency before cutting over the application layer.
5. Cut over application traffic with DNS, not by changing application config. Use weighted DNS records (Route 53 or your DNS provider's equivalent) to shift traffic from the AWS endpoint to the European endpoint over a 7–14 day window. This lets you roll back quickly if something breaks. Most teams find one or two CloudFront-cached responses or Route 53 health checks that need adjustment during this window.
6. Migrate Lambda functions as containerised services. Lambda functions cannot be lifted into Scaleway Functions or OVH Functions without rework: different cold-start models, different event-source bindings. The pragmatic path is to containerise each Lambda as a small Docker image, deploy to your new Kubernetes cluster or to Scaleway Serverless Containers, and route via API gateway. Most Lambda code transfers with minor wrapper changes.
7. Keep AWS active for 90 days after the last service moves over. AWS migrations have a long tail of forgotten resources: an unused CloudWatch log group still being written to, a Lambda triggered by an SNS topic you forgot exists, an S3 bucket with an old data export. Pause the AWS account at zero spend, run AWS Cost Anomaly Detection on the residual, and only close the account after 90 days of clean reports.