AWS ou Scaleway pour héberger votre application ?

Quel cloud choisir selon votre application ?

Application web et PostgreSQL

Pour une application Linux et PostgreSQL destinée à des utilisateurs européens, Scaleway fournit les briques principales : machines virtuelles, réseau privé, répartition de trafic et base gérée. Il mérite une évaluation si vous recherchez un fournisseur européen et pouvez adapter votre dispositif de reprise. AWS est un choix cohérent si votre priorité est de combiner un point d’entrée et une base gérée avec une redondance interzone documentée. Les différences de disponibilité comptent davantage qu’une comparaison du prix d’une seule VM.

Kubernetes et services spécialisés

Pour des conteneurs standards, comparez EKS et Kapsule à partir du plan de contrôle, du stockage et des mises à jour. Si votre application dépend déjà de services AWS ou doit écrire dans plusieurs régions sur différents continents, chiffrez d’abord le travail pour remplacer ces fonctions. Scaleway convient à une étude de migration lorsque les services nécessaires existent dans vos régions cibles et que leur comportement répond à vos objectifs.

Les capacités ci-dessous sont celles décrites par les fournisseurs. Les scénarios de recette proposés sont des vérifications à effectuer sur votre propre architecture avant une bascule.

Comparer les briques des deux plateformes

Ces correspondances servent à préparer une architecture, sans présumer une équivalence de disponibilité ou de coût. Les sections suivantes détaillent la reprise, les dépendances et le budget.

Sur petit écran, faites défiler le tableau horizontalement pour lire les deux fournisseurs.

Repères de calcul et de réseau :familles EC2 ·gammes Instances ·Application Load Balancer ·Load Balancer Scaleway.

Une application web avec PostgreSQL

Prenons une application web avec deux serveurs Linux, un point d’entrée HTTPS et une base PostgreSQL gérée. Chez AWS, les briques sont EC2, Application Load Balancer et RDS for PostgreSQL, dans un VPC. Chez Scaleway, ce sont Instances, Load Balancer et Managed Database for PostgreSQL, reliés par un réseau privé. Pour comparer les VM, retenez aussi l’architecture CPU, le partage ou la réservation des vCPU, la mémoire, les performances disque et le débit réseau. Deux VM ayant le même nombre de vCPU ne constituent pas un benchmark. Types EC2 · Choisir une Instance Scaleway

Le point d’entrée doit aussi survivre à une panne

Dans une région AWS, l’Application Load Balancer utilise des sous-réseaux dans au moins deux zones de disponibilité. Répartissez également les serveurs applicatifs entre ces zones et dimensionnez la capacité restante pour absorber une panne. Le Load Balancer Scaleway est déployé dans une zone choisie, même s’il dessert des serveurs situés dans d’autres zones. Cette distribution des serveurs ne rend pas à elle seule le point d’entrée interzone. Si la perte d’une zone doit être couverte, prévoyez plusieurs points d’entrée dans des zones distinctes et un mécanisme de bascule, avec ses délais et son coût. Application Load Balancer AWS · Création du Load Balancer Scaleway · Backends Scaleway

PostgreSQL : secours de nœud et secours de zone

RDS Multi-AZ avec un secours réplique de façon synchrone vers une autre zone et assure le basculement automatique. Ce secours ne sert pas les lectures applicatives. Chez Scaleway, la FAQ décrit la haute disponibilité avec un primaire et un secours synchrone dans le même datacenter, sur deux baies. Ce montage protège contre une panne de nœud ; il ne démontre pas une reprise après perte du datacenter. RDS Multi-AZ · FAQ PostgreSQL Scaleway

Scaleway propose aussi une réplique de lecture dans une autre zone, avec réplication asynchrone et promotion manuelle. Le tarif public réserve son option Multi-AZ aux répliques de lecture. L’API expose séparément un mode de haute disponibilité multiple_zone : avant de retenir une offre sur cette base, faites préciser son activation pour votre type de nœud et votre région, le placement réel des nœuds et les conditions de basculement. Une réplique asynchrone et un secours synchrone automatique ne répondent pas au même objectif de perte de données et de reprise. Répliques Scaleway · Tarif et portée de l’option Multi-AZ · Modes de haute disponibilité de l’API

La sauvegarde couvre un autre risque : une suppression accidentelle peut être répliquée au secours. RDS documente une restauration à un instant choisi dans la période de rétention, vers une nouvelle instance. Scaleway documente la restauration de sauvegardes et des instantanés selon la configuration. Fixez la granularité de reprise, la rétention et le lieu de stockage, puis mesurez le temps nécessaire pour rendre l’application utilisable après restauration. Restauration RDS · Sauvegardes Scaleway

Kubernetes : EKS ou Kapsule

EKS répartit les composants de son plan de contrôle sur trois zones AWS. Kapsule propose un plan mutualisé ou dédié ; son comparatif affiche un SLA de 99,5 % pour les plans dédiés et aucun SLA pour le mutualisé. Ce sont des caractéristiques du service de gestion du cluster, pas une disponibilité garantie de votre application. Les nœuds, l’entrée réseau, les données et les dépendances doivent être conçus séparément. Architecture EKS · Plans de contrôle Kapsule

Un cluster Kapsule peut répartir ses nœuds entre plusieurs zones. Sa documentation précise toutefois que l’accès au plan de contrôle dépend d’un répartiteur dans la zone primaire, y compris en HA Dedicated. La perte de cette zone rend l’API inaccessible. Les volumes persistants décrits dans cette architecture restent liés à leur zone : la continuité des données exige un dispositif de réplication adapté. Le mode d’isolation et l’emplacement de la Public Gateway ajoutent aussi des dépendances à examiner. Limites des clusters Kapsule multizones

Pour une équipe qui livre souvent, le calendrier de maintenance influence aussi le choix. EKS prévoit 14 mois de support standard après la sortie sur EKS, puis 12 mois de support étendu avec un coût supplémentaire. Pour Kapsule, consultez les dates de dépréciation et de fin de support de la version retenue, ainsi que la procédure de mise à jour. Intégrez les essais de vos charges de travail et les montées de version au temps d’exploitation. Cycle des versions EKS · Calendrier et mises à jour Kapsule

Régions, catalogue et dépendances

AWS dispose de régions en Europe et sur d’autres continents. Scaleway répertorie Paris, Amsterdam, Varsovie et Milan pour son cloud public. Chez les deux fournisseurs, la présence d’une région ne signifie pas que chaque produit, famille de machines ou fonction y est disponible. Vérifiez votre liste de services dans chaque région et zone cible, puis les quotas et les capacités nécessaires. Régions AWS · Disponibilité des produits Scaleway

Le catalogue compte surtout à travers les fonctions que vous utilisez réellement. Scaleway répertorie notamment stockage objet, conteneurs, bases gérées et services de données, avec une disponibilité variable. Si votre application utilise déjà DynamoDB global tables, AWS prend en charge la réplication multirégion et les lectures et écritures sur les répliques. Passer chez Scaleway implique de choisir et valider une autre architecture pour ce besoin, plutôt que de remplacer simplement une VM. À l’inverse, une application reposant sur Linux, PostgreSQL et des conteneurs standards réduit le nombre de services propriétaires à remplacer. Catalogue régional Scaleway · DynamoDB global tables

Établir un coût total comparable

Construisez deux devis à partir d’une même charge et des mêmes objectifs de reprise. Comme fiche de départ, vous pouvez retenir 730 heures à Paris, à la demande et hors taxes : deux VM Linux x86 de 2 vCPU et 8 Gio dans deux zones, 50 Gio de disque chacune, une base de capacité cible équivalente avec 100 Gio de stockage et sept jours de sauvegardes. Ajoutez le trafic attendu, par exemple 500 Go vers Internet et 100 Go entre zones, ainsi que les connexions HTTPS et le volume qui traverse les passerelles. Ce sont des hypothèses de dimensionnement à adapter, pas un devis ni une mesure de performance.

Relevez ensuite chaque poste, avec sa région, son unité, sa devise et ses conditions :

• Calcul et données : VM, disques, IOPS ou débit facturés, base primaire, secours, répliques, sauvegardes et restaurations.
• Réseau : répartiteurs, IPv4, passerelles, trafic Internet et interzone. Pour la perte d’une zone, ajoutez le dispositif complet de bascule du point d’entrée et de la base.
• Kubernetes : plan de contrôle, nœuds, volumes, registre d’images et mises à jour ; ne comparez pas le seul prix du plan de contrôle.
• Exploitation : journaux, supervision, support, astreinte et temps de l’équipe.
• Migration : transfert initial, adaptation du code, période d’exploitation en parallèle et retour arrière.

AWS facture notamment le NAT Gateway selon la durée et les données traitées ; l’Application Load Balancer combine durée et activité. Scaleway affiche une sortie incluse pour la Public Gateway, avec un débit propre à chaque offre. Cette ligne incluse ne suffit pas à établir le coût de tous les flux de votre application. Vérifiez également les frais des autres services, les paliers et les engagements avant de convertir les devis dans une même devise. Réseau AWS · Tarification ALB · Réseau Scaleway · Calculateur public AWS

Le support peut modifier le budget dès les petites charges. Comparez la gravité couverte, les horaires, le canal de contact et le délai de première réponse attendu. Les fournisseurs proposent plusieurs plans ; chez Scaleway, les plans payants combinent un minimum mensuel et un pourcentage de consommation, le montant le plus élevé s’appliquant. Une première réponse n’est pas un délai de résolution. Retenez un plan qui correspond à votre organisation d’astreinte et à vos incidents critiques. Plans AWS Support · Plans et facturation du support Scaleway

Préparer une migration et sa recette

Les images de conteneurs et les manifestes Kubernetes standards sont un point de départ. Inventoriez aussi les identités, secrets, annotations de répartiteur, classes de stockage et services externes. EKS Pod Identity associe par exemple un rôle IAM à un compte de service Kubernetes pour accéder à AWS : ces droits ne deviennent pas automatiquement des permissions Scaleway. Les volumes propres au fournisseur doivent être recréés et leurs données transférées ou restaurées. EKS Pod Identity · Stockage Kubernetes Scaleway

Pour PostgreSQL, préparez un export et un import avec pg_dump et pg_restore, en vérifiant les versions, extensions, rôles, volumes et durée de bascule. Pour le stockage objet, comparez les appels S3, droits d’accès et fonctions réellement utilisés à la liste prise en charge. La compatibilité d’une API ne dispense pas d’essayer le parcours de votre application. Import PostgreSQL Scaleway · Opérations Object Storage prises en charge

Avant de basculer, exécutez une recette sur un environnement prévu à cet effet :

1. Déployez depuis le registre, vérifiez HTTPS, les droits et la connexion à la base avec une charge représentative.
2. Évaluez séparément la perte d’un nœud et la perte de sa zone : entrée réseau, accès à l’API Kubernetes, volumes et écritures PostgreSQL.
3. Restaurez un jeu de données après une suppression volontaire dans cet environnement. Mesurez le temps de reprise et les écritures perdues, puis comparez-les à vos objectifs.
4. Répétez la bascule et le retour arrière, en tenant compte des connexions persistantes, du DNS et des écritures effectuées après la bascule.

Ces vérifications servent à décider si l’architecture et l’effort d’exploitation conviennent à votre activité. Leurs résultats doivent venir de votre recette ; les caractéristiques documentaires ne les remplacent pas.

Fournisseur européen et localisation des données

Scaleway SAS a son siège à Paris et se présente comme une filiale du groupe iliad. Le rapport 2025 d’iliad Holding documente son contrôle par le groupe familial Xavier Niel. C’est sur ces éléments de siège et de contrôle que Scaleway figure ici parmi les alternatives européennes. AWS appartient au groupe américain Amazon ; pour une adresse de facturation française, sa documentation désigne Amazon Web Services EMEA SARL, au Luxembourg, comme vendeur. L’entité contractante, le contrôle du groupe et la région d’hébergement sont des informations distinctes. Mentions Scaleway · Groupe Scaleway · Rapport iliad Holding 2025 · Rapport Amazon 2025 · Vendeur AWS

Ce dossier porte sur les régions commerciales AWS et le cloud public Scaleway. AWS European Sovereign Cloud, ouvert dans le Brandebourg, est une infrastructure distincte : ses caractéristiques ne doivent pas être attribuées à la région AWS de Paris. Pour votre offre, examinez séparément les destinations des sauvegardes, journaux et métadonnées, les données de support et les accès d’administration. Un siège européen ou une région en France ne suffit pas à établir que tous ces traitements restent en France, ni à conclure à la conformité de votre projet. Périmètre d’AWS European Sovereign Cloud