Sur la plupart des scale-ups que j'accompagne chez Stralya, la moitié de la facture AWS est du gaspillage pur. Voici le playbook que j'applique — dans l'ordre, du plus rentable au plus fin — sans jamais toucher à la prod.
On ne coupe pas ce qu'on ne voit pas. Avant toute optimisation, il faut attribuer chaque dollar à un projet, un environnement, une équipe. Sans tags, Cost Explorer te montre un gros bloc opaque « EC2 : 12 000 $ » et tu es aveugle.
Active les Cost Allocation Tags dans la console de facturation, sinon tes tags n'apparaissent pas dans les rapports. C'est l'étape que tout le monde oublie.
Toujours dans cet ordre : on nettoie le gaspillage évident d'abord (gratuit, sans risque), on engage ensuite sur ce qui reste.
Environnements de staging qui tournent la nuit et le week-end, volumes EBS détachés, IP élastiques non utilisées. Gain immédiat, zéro risque.
Des instances surdimensionnées tournant à 5-10% de CPU. Descendre d'une taille divise la ligne par deux, sans impact perçu.
Sur la charge stable et prévisible (le socle qui tourne 24/7), un engagement 1 an paie -40% à -50% vs le on-demand.
Pour les tâches tolérantes à l'interruption (batch, workers, CI) : jusqu'à -90%. Jamais pour la base ni le checkout.
Le rightsizing se fait sur des métriques, pas au feeling. On regarde le CPU et la mémoire moyens sur 30 jours : une instance à 6% de CPU depuis un mois est un candidat évident.
Descends d'une taille à la fois et observe 48h. Compute Optimizer d'AWS te propose des recommandations toutes prêtes — utilise-les comme point de départ, pas comme vérité absolue.
Une boutique cliente, facture mensuelle avant/après le playbook. Aucune fonctionnalité retirée, aucune dégradation de perf — juste du gaspillage supprimé et des engagements bien placés.
De 11 800 $ à 5 900 $ par mois — exactement la moitié. Les deux premiers leviers (gratuits) ont fait le plus gros du chemin.
Le vrai piège n'est pas la première optimisation, c'est la dérive. Les coûts cachés reviennent en silence — j'en ai fait un article à part : les 5 lignes qui plombent ta facture.
Une fois le gaspillage nettoyé, la question devient : sur quoi s'engager, et comment ? Trois modèles coexistent et je les combine presque toujours. La règle que je répète aux équipes : engage sur ce qui est prévisible, garde le on-demand pour la respiration, et pousse le jetable sur Spot.
Le tableau de comparaison officiel d'AWS est net sur les pourcentages et la flexibilité : Compute Savings Plans and Reserved Instances. À retenir : un Savings Plan ne s'applique jamais à l'usage Spot ni à ce qui est déjà couvert par un RI.
Spot donne accès à la capacité inutilisée d'AWS avec jusqu'à -90% vs on-demand, en échange d'une seule contrainte : l'instance peut être reprise avec deux minutes de préavis. Donc jamais la base de données ni le checkout — mais parfait pour le batch, les workers, la CI, le rendering. La clé pour survivre aux interruptions, c'est la diversité : AWS recommande d'être flexible sur au moins 10 types d'instances par workload et d'utiliser la stratégie d'allocation `price-capacity-optimized` dans un Auto Scaling group.
Ne fais jamais de failover Spot vers on-demand « pour compenser » : AWS le déconseille explicitement, ça peut au contraire déclencher plus d'interruptions sur tes autres instances Spot. Architecture tolérante à la panne d'abord, économies ensuite. Détails : Best practices for Amazon EC2 Spot.
Après le compute, deux leviers passent presque toujours sous le radar alors qu'ils sont quasi gratuits à activer : le bon storage class S3 et la migration vers Graviton.
Sur la plupart des buckets, une grosse part des objets n'est jamais relue après quelques semaines : logs, exports, uploads clients, backups. Les laisser en S3 Standard, c'est payer le tarif le plus cher pour de la donnée dormante. S3 Intelligent-Tiering règle ça sans intervention : il déplace automatiquement un objet vers un tier moins cher après 30 jours sans accès, puis vers Archive Instant Access après 90 jours — et le remonte instantanément si on le relit.
Intelligent-Tiering est idéal quand les patterns d'accès sont inconnus ou changeants — c'est le cas par défaut sur une scale-up. Le mécanisme et les seuils exacts sont documentés ici : How S3 Intelligent-Tiering works. Pour des durées de vie connues (logs à supprimer à 90 jours), une lifecycle policy classique reste plus simple et plus économique.
Les instances Graviton (le processeur ARM maison d'AWS) coûtent jusqu'à 20% de moins que leurs équivalents x86, pour la même performance et jusqu'à 60% d'énergie en moins. Sur un socle qui tourne 24/7, c'est une réduction qui se cumule avec le Savings Plan par-dessus. Le coût de migration ? Souvent nul pour du code managé (RDS, ElastiCache) ou des workloads containerisées multi-arch ; parfois un rebuild pour du natif compilé.
Je commence toujours par les services managés et les workers stateless : le risque est faible et le gain immédiat. Les chiffres officiels et l'outil d'estimation sont ici : AWS Graviton.
Un budget avec alerte à 80% attrape le dépassement — mais trop tard, et seulement si tu as bien fixé le seuil. AWS Cost Anomaly Detection va plus loin : un modèle de machine learning apprend ton pattern de dépense normal (par service, compte, tag) et t'alerte quand une ligne dévie, avec l'analyse de cause racine par service, compte, région ou usage type. C'est ce qui repère une instance oubliée en test ou un bucket qui explose avant que ça ne coûte un mois entier.
Le service est gratuit et se configure en quelques minutes avec des monitors gérés par AWS qui suivent automatiquement les nouveaux comptes et tags. Mise en route : Getting started with AWS Cost Anomaly Detection.
Réduire une facture AWS n'est pas un coup de génie technique, c'est de la discipline : voir, couper le gaspillage évident, engager sur le stable, et surveiller. La moitié se récupère souvent sans écrire une ligne de code.
AWS — Cost Optimization ↗