D'AWS ECS à Kubernetes sur OVH :
l'histoire d'une migration de startup
Quand votre facture AWS se met à rivaliser avec vos salaires d'ingénieurs, il est temps de remettre les choses à plat. Cet article retrace notre migration d'une architecture AWS ECS multi-tenant vers un cluster Kubernetes auto-géré sur des nœuds bare-metal OVH.
Nous détaillons les postes de coût qui nous ont forcé la main, le processus technique de migration et les compromis que toute équipe d'ingénierie devrait peser avant de franchir le pas.
À qui s'adresse ce guide
Ce guide s'adresse aux startups early-stage et aux petites équipes techniques qui doivent faire tourner des outils open source (automatisation de workflows, outils de documentation, tableaux de bord analytiques) pour leurs opérations internes ou pour des déploiements multi-tenant chez leurs clients. Si vous êtes une entreprise entre le seed et la Série A et que votre facture AWS grimpe vers les cinq chiffres par mois pour moins de cinquante clients, la situation vous est sans doute familière, et les détails ci-dessous peuvent vous aider à décider de la suite.
Le piège des coûts de la tarification par service dans le cloud
Les startups qui construisent des outils internes ou des plateformes destinées aux clients se retrouvent à un carrefour classique : payer des abonnements SaaS qui croissent linéairement avec le nombre d'utilisateurs, ou auto-héberger des alternatives open source et gérer soi-même l'infrastructure. Le pilier Optimisation des coûts de l'AWS Well-Architected Framework recommande d'adopter un modèle de consommation où vous « ne payez que les ressources de calcul que vous consommez ». En théorie, cela correspond parfaitement à l'économie d'une startup. En pratique, la tarification par service d'AWS crée des coûts fixes qui ne baissent pas quand l'utilisation est faible.
Pourquoi ne pas simplement prendre des abonnements SaaS ?
La question évidente : pourquoi ne pas éviter toute la complexité d'infrastructure et payer les versions hébergées de ces outils ? Pour des déploiements multi-tenant, le calcul plaide souvent contre.
n8n Cloud
Démarre à 20 €/mois, mais n'inclut que 2 500 exécutions de workflow. Un seul workflow de cinq étapes exécuté une fois compte pour cinq exécutions. Dès que les besoins d'automatisation sont ne serait-ce que modérés, les coûts grimpent vite, et l'offre Pro à 50 €/mois pour 10 000 exécutions impose toujours une facturation à l'exécution, imprévisible lors des pics de trafic.
Metabase Cloud
L'offre Starter coûte 85 $/mois pour cinq utilisateurs, plus 5 $/mois par utilisateur supplémentaire. Montez à vingt utilisateurs répartis sur plusieurs clients, et vous voilà à 160 $/mois pour un seul outil de BI. L'offre Enterprise, avec un vrai support multi-tenant et le marquage blanc, démarre à 15 000 $/an.
Quand on multiplie ces coûts par plusieurs outils et plusieurs tenants, les abonnements SaaS peuvent dépasser le coût d'infrastructure de l'auto-hébergement, tout en offrant moins de maîtrise sur la résidence des données, la personnalisation et l'intégration. Pour les startups qui servent des clients soumis à des exigences de souveraineté des données, ou qui ont besoin d'une personnalisation poussée, l'auto-hébergement devient la seule option viable.
L'écart de remises entre startups et grandes entreprises
Les grandes entreprises jouent avec d'autres règles économiques. Elles négocient des Enterprise Discount Programs avec AWS, s'engagent sur des Savings Plans pluriannuels qui réduisent le coût par service jusqu'à 72 %, et traitent l'infrastructure comme une erreur d'arrondi face au chiffre d'affaires. Leurs équipes financières disposent de praticiens FinOps dédiés qui épluchent les tableaux de bord Cost Explorer. Pour elles, les conseils de l'AWS Well-Architected Framework sur le dimensionnement des instances et la mise en place de l'auto-scaling produisent des économies significatives.
Les startups n'ont pas ce luxe. Nous optimisons le burn rate, pas la marge. Chaque dollar économisé sur l'infrastructure est un dollar qui allonge la runway ou finance un recrutement d'ingénieur de plus. Quand votre facture AWS mensuelle approche ce que vous paieriez un développeur junior, le calcul change du tout au tout.
Comprendre l'architecture historique
Notre architecture d'origine suivait les bonnes pratiques AWS à la lettre. Chaque charge de travail de tenant tournait sur sa propre pile isolée : n8n pour l'orchestration des workflows, Docmost pour la documentation et Metabase pour l'analytique. Chaque pile comprenait :
Pile AWS par tenant
ECS Fargate
Orchestration de conteneurs
ALB + ACM
Routage du trafic et SSL
RDS PostgreSQL
Données persistantes
EFS
Stockage de fichiers partagé
Secrets Manager
Identifiants
CloudWatch
Journalisation et supervision
+ un VPC avec sous-réseaux privés, nécessitant des NAT gateways pour le trafic sortant
Sur le papier, cette architecture était à toute épreuve. En pratique, elle était financièrement intenable pour une startup.
La ventilation réelle des coûts
Les coûts de l'architecture ne dépendaient pas de l'usage réel. Ils dépendaient du modèle de tarification d'AWS, qui facture chaque service indépendamment, quel que soit son taux d'utilisation. Voici ce que coûtait réellement un seul environnement au repos :
Calcul (ECS Fargate)
100 $+/moisChaque tâche était dimensionnée pour le pire scénario, à 1 vCPU et 2 à 4 Go de mémoire. Même en heures creuses, sans aucun trafic, chaque petite charge de travail consommait 35 à 50 $ par mois en calcul pur. Avec trois applications principales par tenant, cela fait plus de 100 $ par mois avant même qu'une seule requête n'atteigne le système.
Base de données (RDS PostgreSQL)
25 à 30 $+/moisNous faisions tourner plusieurs instances RDS toujours actives, avec du stockage gp2 et des IOPS provisionnés. L'instance minimale prête pour la production démarre autour de 25 à 30 $ par mois, mais les besoins réels nous poussaient vers des instances plus grosses. Les snapshots de base de données alourdissaient la facture, et nous ne pouvions pas partager les instances entre tenants sans compromettre l'isolation.
Répartition de charge (ALB + ACM)
16 à 22 $+/moisC'est ici que les coûts sont devenus absurdes. Chaque service avait besoin de son propre ALB pour le routage et la terminaison SSL. Un ALB coûte environ 16 à 22 $ par mois rien que pour exister, auxquels s'ajoutent des frais de connexion et d'octets traités. Sur l'ensemble des services et des tenants, notre ligne répartiteurs de charge rivalisait avec notre calcul.
Stockage (EFS)
Nous avions dimensionné les volumes EFS pour les pics de capacité, mais la plupart des données restaient froides. Le tiering d'AWS aurait dû aider, mais les opérations sur les métadonnées et le verrouillage de fichiers ramenaient sans cesse les données vers la classe standard, annulant toute économie liée à la tarification Infrequent Access.
Réseau
LE TUEUR CACHÉLes frais des NAT gateways (0,045 $ par Go traité, plus des frais horaires) s'accumulaient en silence à mesure que les conteneurs des sous-réseaux privés émettaient des requêtes sortantes. Les transferts de données entre zones de disponibilité ajoutaient une couche de mauvaises surprises lors de la revue mensuelle de facture.
Un seul environnement brûlait des centaines de dollars par mois avant même l'arrivée du vrai trafic. Passer à l'échelle horizontalement en ajoutant des tenants ne faisait que multiplier ces coûts fixes de façon linéaire.
Quand l'architecture devient un handicap
L'architecture n'était pas mauvaise au sens classique. Elle était fiable, sécurisée et conforme aux principes de l'AWS Well-Architected Framework. Mais ces principes ont été conçus pour des entreprises où le coût de l'infrastructure est une erreur d'arrondi. Pour des startups qui optimisent leur burn rate, l'approche était économiquement irrationnelle.
À chaque nouveau tenant, nous dupliquions les mêmes primitives AWS : une autre instance RDS, un autre ensemble de services ECS, un autre ALB, un autre groupe de logs CloudWatch avec ses politiques de rétention. Le coût marginal de chaque nouveau client tendait vers le coût de base par service au lieu de tendre vers zéro.
La décision : pourquoi Kubernetes sur OVH
Évaluer les alternatives
Avant de nous engager dans la migration, nous avons évalué plusieurs alternatives :
Optimisation des coûts AWS
Nous avons essayé le right-sizing des instances, l'auto-scaling et l'achat de capacité réservée. Les résultats ont été marginaux. Le problème de fond n'était pas l'inefficacité ; c'était le modèle de tarification d'AWS pour des services facturés quelle que soit leur utilisation.
Passer à EKS
Le Kubernetes managé d'Amazon aurait consolidé certains coûts, mais EKS facture 0,10 $ par heure pour le control plane (73 $/mois), et nous aurions toujours subi les mêmes coûts d'ALB, de NAT gateway et de transfert de données. L'équation économique ne s'améliorait pas assez pour justifier l'effort de migration.
Approches serverless
Lambda et API Gateway proposaient une tarification à l'usage, mais nos charges de travail ne se prêtaient pas au serverless. n8n, Docmost et Metabase exigent tous des connexions persistantes et des processus de longue durée que les architectures serverless pénalisent.
Autres fournisseurs cloud
Nous avons évalué GCP, Azure et des fournisseurs plus petits. GCP proposait de meilleurs tarifs de conteneurs avec Cloud Run, mais les coûts réseau restaient problématiques. Azure avait des structures tarifaires proches de celles d'AWS.
Bare-metal + K8s auto-géré : OVHcloud
OVH proposait des serveurs dédiés à des tarifs mensuels prévisibles, avec une bande passante généreuse. Un seul serveur capable de faire tourner toute notre charge coûtait moins cher que notre ancienne facture AWS par tenant.
Qu'est-ce qu'OVHcloud ?
OVHcloud est un fournisseur cloud européen surtout connu pour ses serveurs dédiés bare-metal et son infrastructure à prix fixe et sans détour. Contrairement aux hyperscalers comme AWS, OVH mise sur une tarification mensuelle prévisible, une bande passante incluse et un accès direct au matériel physique. L'entreprise exploite ses propres datacenters, principalement en Europe, ce qui en fait un choix courant pour les équipes attentives aux coûts, soumises à des exigences de souveraineté des données, ou qui préfèrent une infrastructure auto-gérée.
Pourquoi OVH en particulier
OVH l'a emporté pour plusieurs raisons :
Tarification prévisible
Des tarifs mensuels fixes pour les serveurs dédiés ont éliminé les surprises liées à la facturation à l'usage. Nous pouvions modéliser les coûts avec précision, sans les acrobaties du simulateur de prix AWS.
Bande passante incluse
OVH inclut une bande passante substantielle avec ses serveurs. Nos inquiétudes sur les transferts de données se sont évaporées.
Datacenters européens
Pour certains de nos clients, la conformité au RGPD et la souveraineté des données comptaient. La présence européenne d'OVH a simplifié ces conversations.
Pas de verrouillage fournisseur
Faire tourner un Kubernetes auto-géré signifiait que nous pouvions migrer à nouveau si nécessaire. Nos charges de travail seraient portables vers n'importe quelle plateforme compatible Kubernetes.
Assumer les compromis
Nous n'étions pas naïfs sur les inconvénients. Un Kubernetes auto-géré, c'est :
- Pas de SLA AWS en cas de défaillance des nœuds
- La responsabilité de la maintenance, des correctifs et de la sécurité du control plane
- Un besoin d'expertise interne sur les sauvegardes CNPG, les ingress controllers et MetalLB
- Un effort de migration initial plus important que de rester en place
Nous avons jugé que les économies mensuelles justifiaient l'investissement opérationnel. L'idée clé : nous aurions besoin d'une expertise Kubernetes de toute façon, puisque les abstractions d'AWS fuyaient déjà dans notre quotidien opérationnel. Autant maîtriser toute la pile.
Architecture technique : l'état cible
Principes de conception du cluster
Notre architecture cible reposait sur la consolidation des ressources. Au lieu de dupliquer l'infrastructure par tenant, nous partagerions un seul cluster Kubernetes avec une isolation forte par namespace :
Comparaison des architectures
AWS ECS (avant)
K8s sur OVH (après)
Un seul cluster, plusieurs namespaces
Chaque application (n8n, Docmost, Metabase) dispose de son propre namespace avec des politiques RBAC adaptées. Les tenants sont isolés au niveau applicatif plutôt qu'au niveau de l'infrastructure.
CloudNativePG pour les bases de données
CNPG remplace RDS par des clusters PostgreSQL exécutés dans Kubernetes. Nous obtenons la même haute disponibilité grâce à la réplication native par streaming de Postgres, sans frais AWS par instance.
Couche d'ingress partagée
Un seul contrôleur ingress-nginx avec MetalLB remplace plusieurs ALB. cert-manager gère l'émission des certificats via Let's Encrypt, ce qui supprime la dépendance à ACM.
Stratégie de stockage hybride
Rook/Ceph fournit les volumes persistants au sein du cluster, tandis qu'AWS S3 reste notre destination de sauvegarde. Nous profitons de la durabilité d'AWS sans y faire tourner de charges de travail.
Choix des composants
Runtime de conteneurs
containerd standard sur Ubuntu 24.04 LTS. Nous avons évité les runtimes exotiques pour maximiser la compatibilité et simplifier le débogage.
Réseau
Calico pour le réseau des pods, avec les network policies Kubernetes standard. MetalLB fournit les types de service LoadBalancer sur du bare-metal, en attribuant des IP externes depuis un pool configuré.
Ingress
ingress-nginx avec cert-manager pour l'émission automatique des certificats TLS. Toutes les applications partagent le même ingress controller, avec un routage basé sur le nom d'hôte et des règles de chemin.
Stockage
- Rook/Ceph pour les volumes persistants nécessitant une haute disponibilité
- Stockage bloc OVH pour les cas d'usage plus simples
- AWS S3 pour les sauvegardes (conservé de l'architecture historique)
Base de données
CloudNativePG gère les instances PostgreSQL comme des ressources Kubernetes natives. CNPG prend en charge :
Gestion des secrets
Nous avons conservé AWS Secrets Manager pour le stockage des identifiants. Le chemin des données reste hors d'AWS, mais les secrets sont récupérés au déploiement via External Secrets Operator.
Enseignements d'architecture
La tarification par service est dangereuse à grande échelle
Le modèle d'AWS fonctionne bien quand on a quelques services à forte valeur. Il s'effondre quand on a besoin de nombreux petits services. Kubernetes permet d'amortir l'infrastructure sur un nombre illimité de charges de travail.
Les services managés ont des coûts cachés
RDS, ce n'est pas seulement le prix de l'instance. Ce sont les snapshots, les PIOPS, le stockage et les réplicas multi-AZ. EFS, ce n'est pas seulement du stockage. Ce sont le provisionnement du débit et les acrobaties de classes d'accès. Ces coûts cachés ne deviennent visibles qu'à l'arrivée de la facture.
La complexité opérationnelle est transférable
Nous avons échangé la complexité opérationnelle d'AWS contre celle de Kubernetes. La complexité totale n'a pas diminué ; elle s'est déplacée vers des compétences plus portables et plus recherchées.
Les approches hybrides fonctionnent
Garder S3 pour les sauvegardes tout en faisant tourner les charges de travail ailleurs nous donne le meilleur des deux mondes : la durabilité d'AWS pour les données critiques, les tarifs d'OVH pour le calcul.
Quand cette migration n'a pas de sens
Nous ne recommanderions pas cette approche à toutes les équipes :
- Si vous manquez d'expertise Kubernetes :La courbe d'apprentissage est réelle. Prévoyez 3 à 6 mois d'investissement avant d'espérer une maturité opérationnelle.
- Si la conformité est non négociable :Certains secteurs réglementés exigent des certifications cloud précises. OVH en détient beaucoup, mais pas toutes celles qu'offre AWS.
- Si vous êtes déjà à l'échelle :Les grandes organisations obtiennent souvent des remises AWS qui changent le calcul. Les accords entreprise peuvent réduire les surcoûts par service qui nous ont pénalisés.
- Si le time-to-market est critique :Notre migration a demandé des semaines d'effort d'ingénierie. Si vous courez pour livrer des fonctionnalités, l'optimisation de l'infrastructure peut attendre.
Conclusion
Passer d'AWS ECS à un Kubernetes auto-géré sur OVH a été l'une des décisions d'infrastructure les plus déterminantes que nous ayons prises. La réduction de 70 % des coûts finance des recrutements d'ingénieurs supplémentaires. Le savoir-faire opérationnel que nous avons acquis rend notre équipe plus précieuse et notre architecture plus portable.
La migration n'a pas été simple, et elle ne convient pas à tout le monde. Mais pour les startups dont le modèle de tarification par service d'AWS entre en conflit avec la réalité économique, cette voie offre une alternative viable.
Vos coûts cloud vous pèsent ? Nos ingénieurs infrastructure peuvent vous aider à évaluer vos options et à exécuter des migrations qui ont un sens financier.