European alternatives to AWS.

AWS is the dominant cloud-hosting platform globally and the default choice for a generation of SaaS companies — and it is also a US-incorporated product under CLOUD Act jurisdiction, which is what drives European procurement teams to evaluate alternatives. It is also a US-incorporated product (Amazon Web Services, Inc., a subsidiary of Amazon.com, Inc., NASDAQ: AMZN), and despite multiple EU-region data centres and the announced European Sovereign Cloud, the corporate ownership structure means CLOUD Act jurisdiction applies. For a German procurement team writing a Schrems II transfer impact assessment, a French public-sector buyer requiring SecNumCloud, or any European SaaS planning for the May 2026 Tech Sovereignty Package implications, the ownership profile is what prompts buyers to evaluate alternatives. The April 2026 EU sovereign cloud tender (€180M awarded to Scaleway, Clever Cloud, OVH, and STACKIT, with AWS deliberately excluded) is the institutional signal that European procurement teams are responding to.

This page maps the twelve European cloud-hosting alternatives we have verified against AWS on the criteria a buyer actually cares about: who legally owns the company, where the data physically sits, which sub-processors handle the operational layer, and whether the platform holds a recognised European compliance framework (ISO 27001, BSI C5, EUCS, SecNumCloud). The compliance score is editorial, never paid, and every row is sourced to the vendor's public DPA. We re-verify quarterly.

If you only have ten minutes: Scaleway is the best fit for modern SaaS workloads with the broadest managed-services catalog (France, Paris, 5/5, EU sovereign cloud tender winner), Hetzner is the strongest price-per-performance choice for compute-heavy workloads (Germany, Gunzenhausen, 5/5), and OVHcloud is the largest-scale European cloud with SecNumCloud-qualified tiers for French public-sector buyers (France, Roubaix, 5/5).

What you keep when you switch from AWS to a European cloud:

• 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.

What you give up:

• 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.

A practical seven-step migration plan most European clouds will accept.

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.