Encaisser dix fois plus de trafic n'oblige pas à payer dix fois plus, ni tout le temps. La suite de mon archi e-commerce : comment je dimensionne pour tenir un pic, puis redescendre — sans laisser la facture en haut.
On part de l'archi e-commerce : EC2 pour le site, RDS pour la base, S3 + CloudFront pour les images. Pour scaler, on ne grossit pas une seule machine à l'infini — on en met plusieurs derrière un load balancer, et on décharge la base.
Si tu n'as pas lu la base, commence par pourquoi AWS pour un e-commerce — cet article en est la suite directe.
La clé du coût maîtrisé, c'est l'élasticité : ajouter des instances quand le trafic monte, les retirer quand il redescend. On ne paie la capacité de pointe que pendant la pointe.
Un ALB répartit le trafic sur N instances et retire automatiquement celles qui échouent au health check.
Des règles sur le CPU (ou la file de requêtes) ajoutent/retirent des instances. Min 2 pour la résilience, max borné pour le budget.
Les lectures (catalogue, fiches produit) partent sur des répliques RDS ; la base primaire garde les écritures (commandes).
ElastiCache/Redis absorbe ce qui est lu en boucle. La requête la moins chère est celle qu'on ne fait pas.
La base est presque toujours le premier goulot. Avant d'ajouter des serveurs web, on met en cache ce qui est lu en boucle — souvent 80% des requêtes portent sur 20% des données.
Le piège : sur-provisionner « au cas où » et laisser tourner. Fixe un max d'auto-scaling raisonnable et surveille — sinon un bug qui boucle peut faire exploser la facture en une nuit.
Le scaling et le coût sont les deux faces d'une même pièce. Le playbook pour dégonfler ce qui a dérivé : diviser une facture AWS par deux.
« Auto-scaling » n'est pas un seul bouton. Il y a plusieurs manières de déclencher l'ajout d'instances, et le choix change le comportement pendant un pic. Sur mon archi e-commerce, je pars presque toujours du target tracking : je fixe une cible — par exemple 50 % de CPU moyen, ou un nombre de requêtes par instance — et EC2 Auto Scaling crée et gère lui-même les alarmes CloudWatch pour tenir cette cible. AWS le recommande explicitement pour scaler sur le CPU moyen ou le nombre de requêtes par cible.
Détail qui piège beaucoup de monde : le cooldown ne s'applique qu'aux simple scaling policies. Le target tracking et le step scaling peuvent relancer un scale-out immédiatement — c'est le warmup d'instance (le temps qu'une nouvelle machine devienne saine) qui régule le rythme, pas un cooldown fixe. AWS déconseille désormais les simple scaling policies au profit du target tracking.
Le target tracking est réactif : il attend que le CPU monte pour agir, et une nouvelle instance met une ou deux minutes à démarrer. Pour un pic que je vois venir — soldes du lundi matin, campagne à 18 h — j'ajoute du predictive scaling. Il analyse jusqu'à 14 jours d'historique, en déduit une prévision horaire sur 48 h, et provisionne avant que la charge n'arrive. Deux choses à retenir : il démarre en mode « forecast only » (il prévoit sans scaler, le temps que tu valides), et il ne fait que scaler out — pour redescendre, tu gardes tes politiques dynamiques. Predictive gère le prévisible, target tracking encaisse l'imprévu par-dessus.
Pour les read replicas, pas de magie équivalente : RDS ne gère pas l'auto-scaling des répliques. On les ajoute et on les retire à la main, et chaque réplique est facturée comme une instance de sa classe. C'est justement pour ça que le cache passe avant : ajouter une réplique, c'est un coût fixe qui ne redescend pas tout seul la nuit.
Un cache n'a de valeur que par son taux de hit : la part des requêtes servies depuis le cache plutôt que depuis l'origine. Ce chiffre n'est pas cosmétique, il pilote directement la facture. À 80 % de hit, seule une requête sur cinq atteint la base ou l'EC2 ; à 95 %, c'est une sur vingt. Passer de 80 à 95 %, ce n'est pas « 15 % de mieux » : c'est diviser par quatre la charge qui arrive derrière — donc potentiellement une read replica en moins ou deux instances EC2 en moins pendant le pic.
Concrètement il y a deux caches à surveiller. Sur ElastiCache/Redis, la documentation AWS sur les métriques à suivre recommande d'alarmer sur les evictions et la mémoire : quand Redis évince des clés faute de place, ton taux de hit chute et la base réencaisse tout. Devant le statique, CloudFront a son propre levier : augmenter le cache hit ratio en allongeant le max-age, en limitant les query strings et cookies pris dans la clé de cache, et en activant Origin Shield comme couche supplémentaire devant l'origine.
La bonne boucle : mesure d'abord le taux de hit, puis décide. Souvent, gagner 10 points de hit coûte zéro (juste de la config) et t'évite d'ajouter du matériel qui, lui, se facture 24/7.
Scaler proprement, c'est rendre le coût proportionnel au trafic : plusieurs instances derrière un load balancer, une base déchargée par le cache et les répliques, et de l'auto-scaling qui redescend vraiment. On tient le pic, et la facture retombe avec lui.
AWS — Auto Scaling ↗