Comparison grid
AWS vs Azure vs GCP vs the EU-sovereign equivalent, side by side
This is the wide view: every hyperscaler keeps its own column, so you can read one capability straight across AWS, Azure, GCP and the European option that actually exists in production today. It is the same conservative data as our service map, laid out for a single glance rather than a deep read. The grades are honest: where Europe is mature we say so, and where there is a genuine gap we grade it a gap.
How to read the verdict column
The verdict grades the European option, never the hyperscaler. Four stops, from a production-proven equivalent to a real gap. A gap means no managed EU-sovereign twin exists today, not that the category is unreachable.
- Mature Production-proven EU equivalent. Low migration risk.
- Viable Solid equivalent with minor feature deltas.
- Partial Usable, but with real gaps in scale or features.
- Gap No true managed EU-sovereign equivalent. Expect to self-host or reduce scope.
| Capability | AWS | Azure | GCP | EU-sovereign equivalent | Verdict |
|---|---|---|---|---|---|
| Object storage | Amazon S3 | Azure Blob Storage | Google Cloud Storage | Scaleway Object StorageOVHcloud Object Storage | Mature |
| Block storage | Amazon EBS | Azure Managed Disks | Persistent Disk / Hyperdisk | Scaleway Block StorageOVHcloud Block Storage | Mature |
| Virtual machines | Amazon EC2 | Azure Virtual Machines | Google Compute Engine | Scaleway InstancesOVHcloud Public CloudHetzner Cloud | Mature |
| Managed Kubernetes | Amazon EKS | Azure AKS | Google Kubernetes Engine (GKE) | Scaleway KapsuleOVHcloud Managed Kubernetes | Mature |
| Container registry | Amazon ECR | Azure Container Registry | Google Artifact Registry | Scaleway Container RegistryOVHcloud Managed Private RegistryHarbor (self-hosted) | Mature |
| Managed PostgreSQL | Amazon RDS / Aurora | Azure Database for PostgreSQL | Cloud SQL / AlloyDB for PostgreSQL | Scaleway Managed DatabaseOVHcloud Managed DatabasesAiven for PostgreSQL | Viable |
| Managed cache (Redis/Valkey) | Amazon ElastiCache | Azure Cache for Redis | Memorystore for Redis | Scaleway Managed Database for RedisAiven for Valkey/Redis | Viable |
| Message queue / pub-sub | Amazon SQS / SNS | Azure Service Bus | Google Cloud Pub/Sub | Scaleway Messaging & QueuingSelf-hosted NATS / RabbitMQ | Viable |
| Event streaming (Kafka) | Amazon MSK / Kinesis | Azure Event Hubs | Managed Service for Apache Kafka | Aiven for Apache KafkaSelf-hosted Kafka / Redpanda | Viable |
| Authoritative DNS | Amazon Route 53 | Azure DNS | Google Cloud DNS | Scaleway Domains & DNSOVHcloud DNSBunny DNS | Viable |
| Transactional email | Amazon SES | Azure Communication Services | No first-party service (SendGrid via Marketplace) | Scaleway Transactional EmailBrevo (FR) | Viable |
| Secrets & key management | AWS Secrets Manager / KMS | Azure Key Vault | Secret Manager / Cloud KMS | Scaleway Secret ManagerHashiCorp Vault (self-hosted) | Viable |
| Application platform (PaaS) | AWS App Runner / Elastic Beanstalk | Azure App Service | Google App Engine | Clever Cloud (FR)Scalingo (FR) | Viable |
| Serverless containers | AWS Fargate | Azure Container Instances | Google Cloud Run | Scaleway Serverless Containers | Viable |
| Customer identity (CIAM) | Amazon Cognito | Azure AD B2C | Google Cloud Identity Platform | Keycloak (self-hosted)ZitadelOry | Viable |
| Serverless functions (FaaS) | AWS Lambda | Azure Functions | Cloud Run functions (Cloud Functions) | Scaleway Serverless FunctionsOVHcloud Functions | Partial |
| Global CDN & edge compute | Amazon CloudFront / Lambda@Edge | Azure Front Door | Cloud CDN / Media CDN | Bunny.netGcoreOVHcloud CDN | Partial |
| Metrics, logs & traces | Amazon CloudWatch / X-Ray | Azure Monitor | Cloud Monitoring / Logging / Trace | Self-hosted Grafana / Prometheus / Loki / Tempo | Partial |
| Managed ML platform | Amazon SageMaker | Azure Machine Learning | Vertex AI | OVHcloud AI Endpoints / AI TrainingScaleway GPU Instances + Managed Inference | Gap |
| Cloud data warehouse | Amazon Redshift | Azure Synapse | Google BigQuery | ClickHouse (self-hosted)Aiven for ClickHouse | Gap |
| Serverless wide-column NoSQL | Amazon DynamoDB | Azure Cosmos DB | Cloud Bigtable / Firestore | ScyllaDB (self-hosted)Self-hosted CassandraFerretDB / MongoDB-compatible | Gap |
What the grid shows at a glance
Scan the verdict column top to bottom and the shape is clear: the commodity layer (object and block storage, virtual machines, managed Kubernetes, container registries, managed PostgreSQL) is settled, with production-proven European equivalents that mostly speak the same APIs.
The three rows graded gap are the ones to plan around: managed ML has no one-platform answer to SageMaker, there is no EU-sovereign serverless data warehouse to match Redshift or BigQuery, and DynamoDB’s pay-per-request model has no managed twin. Global edge compute is the notable partial just above them, thinner than CloudFront and Lambda@Edge, but not absent. Real engineering, named up front rather than discovered mid-migration.
Verdicts are conservative and reflect managed, EU-jurisdiction offerings as of 2026. Provider feature sets move quickly, so we re-check on every engagement.
Reading the grid
- Why keep AWS, Azure and GCP in separate columns?
- Because the choice of hyperscaler changes the migration. The service map collapses the three into one incumbent column when the EU verdict is the same across them; this grid keeps them apart so you can match your exact stack (an Azure Service Bus queue, a BigQuery warehouse, a Lambda function) to its European path without translating twice.
- Does adding the GCP column change any verdict?
- No. The verdict grades the EU-sovereign equivalent, not the hyperscaler. Listing three incumbents where before we listed one never moves a grade. A mature row is mature whether you leave AWS, Azure or GCP.
- How is this different from the service map?
- Same data, different density. The service map is the deep read: search, filter, per-row notes and the full reasoning. This grid is the at-a-glance matrix for comparing all three hyperscalers side by side. Both stay live; start here to scan, go there to dig in.