Tu as une application web qui tourne sur un VPS — React en frontend, Node.js en backend, PostgreSQL en base de données et Redis pour le cache. Tout fonctionne bien sur un serveur à 15–30 €/mois chez Hetzner ou DigitalOcean. Mais arrive le moment où le trafic augmente, les clients exigent des SLA et tu as besoin d’une vraie scalabilité. Il est temps de regarder AWS sérieusement.
Dans cet article, nous passons en revue l’architecture AWS adaptée à ce type d’application, nous comparons les coûts de façon concrète et nous expliquons comment fonctionne l’autoscaling sur EC2 — avec des chiffres réels.
Le point de départ : le VPS classique
Le scénario typique ressemble à ceci : un seul serveur (Hetzner CPX31 — 4 vCPU, 8 Go RAM, 160 Go SSD) à environ 15 €/mois qui fait tourner tout — Node.js, PostgreSQL, Redis, éventuellement Nginx en reverse proxy. Tu ajoutes peut-être un second serveur pour la redondance, tu arrives à 30–40 €/mois au total.
Ça marche. Mais tu as plusieurs problèmes fondamentaux : pas d’autoscaling (le trafic du Black Friday peut faire tomber le serveur), pas de bascule automatique (si le serveur tombe, tout tombe), les sauvegardes sont manuelles ou semi-automatisées, et scaler signifie « j’achète un serveur plus gros et je migre à la main ».
L’architecture AWS proposée
Sur AWS, la même application se décompose en services spécialisés :
Frontend (React) — S3 + CloudFront. Les fichiers statiques (HTML, CSS, JS) sont servis depuis S3 via le CDN CloudFront. Zéro serveur à administrer, faible latence à l’échelle mondiale, coût négligeable pour un trafic modéré.
Load Balancer — Application Load Balancer (ALB). Il répartit le trafic HTTP/HTTPS vers les instances backend. Coûte environ 0,0252 $/heure fixe plus un coût variable basé sur les LCU (Load Balancer Capacity Units) selon le trafic.
Backend (Node.js) — EC2 Auto Scaling Group. Minimum 2 instances t3.medium (2 vCPU, 4 Go RAM) dans des zones de disponibilité différentes. Le groupe ajoute ou retire des instances automatiquement selon le trafic.
Base de données (PostgreSQL) — RDS PostgreSQL. Instance db.t3.medium avec Multi-AZ pour la bascule automatique. Sauvegardes automatiques, correctifs gérés par AWS, restauration point-in-time.
Cache (Redis) — ElastiCache. Nœud cache.t3.medium entièrement géré. Tu n’as plus à gérer le processus Redis, les mises à jour ou la surveillance.
Comparaison des coûts : VPS vs. AWS
Mettons les chiffres côte à côte. Les prix sont pour la région eu-central-1 (Francfort), On-Demand, sans remises.
Scénario VPS (Hetzner)
Une configuration de production typique avec deux serveurs pour la redondance coûte à peu près : deux serveurs CPX31 à 15 €/mois chacun, plus sauvegarde managée à ~3 €/mois, soit environ 33 €/mois au total.
Scénario AWS (On-Demand)
Sur AWS, les coûts se répartissent par service. Deux instances EC2 t3.medium (backend) représentent environ 67 $/mois (0,046 $/h × 730 h × 2). L’ALB coûte environ 25 $/mois (frais fixes plus LCU pour un trafic modéré). RDS PostgreSQL db.t3.medium Single-AZ atteint ~53 $/mois (0,072 $/h × 730 h), et en Multi-AZ ça double à environ 106 $/mois. ElastiCache Redis cache.t3.medium environ 50 $/mois. S3 et CloudFront pour le frontend statique coûtent moins de 5 $/mois pour un trafic modéré. Au total, AWS On-Demand se situe autour de 200–306 $/mois, selon l’option Single-AZ ou Multi-AZ pour la base de données.
Scénario AWS optimisé
Avec des Reserved Instances (1 an, sans paiement initial), tu économises environ 30–40 %. Le total descend à environ 130–200 $/mois. Avec des Savings Plans sur 1 an, tu peux descendre encore. Et si tu utilises des instances Graviton (t4g au lieu de t3), tu gagnes encore 10–20 % sur le prix avec des perfs similaires ou meilleures.
Verdict sur les coûts
Le VPS est 5 à 8 fois moins cher en prix brut. Mais on ne compare pas des choses comparables. AWS t’offre : bascule automatique, sauvegardes gérées, scalabilité élastique, surveillance intégrée (CloudWatch), certifications et conformité (SOC 2, ISO 27001, GDPR), et un SLA de 99,99 % sur l’ALB. Quand tu calcules le coût réel — y compris ton temps d’administration, le risque de downtime et les pertes potentielles — l’écart se réduit nettement.
L’autoscaling sur EC2 : comment ça marche
L’autoscaling est la raison principale de migrer vers AWS. Au lieu de payer une capacité maximale 24/7, tu paies seulement ce que tu utilises.
L’Auto Scaling Group (ASG) définit : combien d’instances EC2 au minimum (ex. 2), au maximum (ex. 8) et souhaité (desired capacity). L’ASG maintient automatiquement le nombre souhaité et remplace les instances qui échouent aux health checks.
Les Scaling Policies définissent quand et comment scaler. Il y a deux approches principales.
Target Tracking Scaling — la plus simple et recommandée. Tu fixes une cible (ex. « je veux une CPU moyenne à 60 % ») et AWS ajuste automatiquement le nombre d’instances pour maintenir cette valeur. Ça fonctionne comme un thermostat : si le trafic monte et la CPU dépasse 60 %, des instances sont ajoutées ; si ça baisse, elles sont retirées.
Step Scaling — pour un contrôle plus fin. Tu définis des paliers : si la CPU dépasse 70 %, ajoute 1 instance ; si elle dépasse 90 %, ajoute 3. Utile quand tu as des patterns de trafic prévisibles et que tu veux des réactions différenciées.
Métriques sur lesquelles scaler. La CPU est la plus courante mais pas toujours la meilleure. Pour une app Node.js, tu peux scaler sur : ALB Request Count per Target (combien de requêtes reçoit chaque instance — idéal pour les web apps), CPU Utilization (bien pour les charges compute-intensive), ou des métriques custom via CloudWatch (ex. longueur de la file de jobs, latence des réponses).
Période de cooldown — après qu’un ASG a ajouté une instance, il attend un intervalle (par défaut 300 secondes) avant de prendre une autre décision de scaling. Ça évite les oscillations : tu ne veux pas ajouter 10 instances en 10 secondes pour un pic momentané.
Exemple concret : ton application sert en moyenne 500 req/s le jour et 50 req/s la nuit, avec des pics à 2000 req/s lors de lancements de campagnes. Tu configures l’ASG avec min 2, max 8 instances, et Target Tracking sur ALBRequestCountPerTarget à 1000 requêtes/instance. La nuit tu tournes sur 2 instances (~2 $/jour). Le jour, le système maintient 2–3 instances. En pic, il scale à 4–5 puis redescend. Tu paies seulement pour les heures réellement utilisées.
Ce qu’on ne scale pas : la base de données et Redis
Un détail important — RDS PostgreSQL et ElastiCache ne scalent pas horizontalement aussi facilement qu’EC2. La base peut utiliser des Read Replicas pour répartir les lectures, mais les écritures restent sur l’instance primaire. Redis sur ElastiCache supporte le mode cluster avec sharding, mais ça ajoute de la complexité.
Recommandation pratique : dimensionne la base et Redis pour le pic dès le départ (ou un peu au-dessus), et scale uniquement la couche backend (EC2). C’est plus simple, plus prévisible et ça couvre 90 % des cas.
Étapes concrètes pour la migration
Le processus de migration comporte plusieurs étapes. D’abord le déploiement du frontend React sur S3 avec CloudFront. Ensuite la configuration de RDS PostgreSQL et la migration des données avec pg_dump et pg_restore. Puis la mise en place d’ElastiCache Redis. Ensuite la création de l’AMI (Amazon Machine Image) avec l’app Node.js et la configuration du Launch Template et de l’Auto Scaling Group. On place l’ALB devant l’ASG. Et last but not least, la configuration de Route 53 pour le DNS, avec un cutover planifié du VPS vers AWS.
Délai réaliste pour une migration complète : 2–4 semaines, incluant les tests et une période de run en parallèle.
Quand ça vaut le coup et quand non
Migre vers AWS quand : tu as besoin de scalabilité élastique, les clients exigent des SLA et de la conformité, tu veux de la haute disponibilité sans effort manuel, ou l’application dépasse les capacités d’un VPS.
Reste sur un VPS quand : le trafic est prévisible et modeste, le budget est la priorité n° 1, l’équipe est petite et n’a pas d’expérience AWS, ou l’application est un MVP en phase de validation.
Il n’y a pas de réponse universelle. Mais si ton application génère du chiffre d’affaires et qu’une heure de downtime, c’est de l’argent perdu, AWS n’est pas un coût — c’est un investissement dans la stabilité.
Publié sur teninvent.ro — TEN INVENT S.R.L. propose du conseil et de l’implémentation d’infrastructure AWS. Contacte-nous pour une évaluation gratuite de ton architecture cloud.