Optimisation des coûts AWS : ce qui change la facture (et ce qu'on laisse de côté)

Les factures AWS gonflent plus vite que prévu. Les expériences deviennent permanentes, des environnements de dev survivent au roulement de personnel, et le total mensuel grimpe pendant que tout le monde reste concentré sur la livraison. La plupart des guides « d’optimisation des coûts AWS » traitent chaque poste comme s’il méritait la même attention. Ce n’est pas le cas. Voici les trois optimisations qu’on applique en premier sur chaque mandat, et deux qu’on laisse de côté.

#1. Dimensionner avant tout — le reste est secondaire

Le plus gros écart sur la facture, c’est presque toujours des instances trop grosses pour leur charge. AWS offre des dizaines de types et de tailles; la friction de choisir le bon pousse les équipes à surdimensionner et à ne jamais y revenir.

Sortez 30 jours d’utilisation CPU, mémoire et réseau dans CloudWatch. Tout ce qui tourne sous 40 % en continu est candidat à passer une taille plus bas. AWS Compute Optimizer remonte les mêmes recommandations et a généralement raison quand il suggère « réduire » — un peu moins quand il suggère « burstable », qu’on remet en question pour la production.

Le dimensionnement n’est pas un projet ponctuel. Les charges évoluent; la bonne taille aujourd’hui est la mauvaise dans six mois. On le met au calendrier trimestriellement.

#2. Savings Plans, plafonnés à la base

Si vous avez une charge stable — et c’est presque toujours le cas — les Savings Plans et Reserved Instances vous donnent jusqu’à 72 % de rabais sur le prix de liste sur un engagement d’un ou trois ans. Ce sont de vraies économies.

Le piège, c’est d’acheter de la couverture au-dessus de la base. On plafonne la couverture engagée à environ 80 % du steady-state réel, en laissant 20 % de marge pour l’on-demand et le Spot. Le calcul est asymétrique : un Savings Plan inutilisé pendant la moitié de son terme efface les économies qu’il aurait produites, alors qu’une heure d’on-demand non couverte coûte environ 20 % de plus qu’une heure couverte. Optimisez la protection contre les pertes, pas le maximum théorique.

On commence prudemment — Compute Savings Plans, terme d’un an, couverture autour de 60 % de la base évidente — et on élargit seulement après quelques mois d’utilisation stable. Les termes de trois ans et les EC2 Instance Savings Plans (qui vous enferment dans une famille d’instances) viennent plus tard, si jamais.

#3. Niveaux de stockage — commencez par gp2 vers gp3

La migration gp2 vers gp3 sur EBS est le gain le plus facile à empocher. Les volumes gp3 sont plus rapides que les gp2 à taille égale, ont des paramètres IOPS et débit indépendants (vous arrêtez de surpayer la capacité juste pour avoir du IOPS), et la conversion est en direct — pas de détachement, pas d’interruption, pas de snapshot. aws ec2 modify-volume --volume-id <id> --volume-type gp3 et le volume change de type en place pendant qu’il est toujours monté.

On n’a pas encore trouvé une charge qui n’en bénéficie pas. Faites la migration un vendredi après-midi si vous êtes nerveux; les économies apparaissent sur la facture suivante.

Les politiques de cycle de vie S3 forment la couche suivante. Les défauts conviennent à la plupart des comptes :

• S3 Standard pour le niveau actif.
• S3 Standard-IA pour ce qui n’a pas été touché depuis 30 jours.
• S3 Glacier Instant Retrieval pour ce qui n’a pas été touché depuis 90 jours, quand il faut encore un accès en millisecondes.
• S3 Glacier Deep Archive pour la rétention de conformité.

On ne recourt pas à Intelligent-Tiering sauf sur les buckets aux schémas d’accès vraiment imprévisibles. Les frais de monitoring s’additionnent vite sur les charges de petits objets.

#Ce qu’on ne fait pas

• Spot Instances pour quoi que ce soit de stateful. Les économies sont réelles, le casse-tête opérationnel aussi. On utilise le Spot pour le traitement par lots, les fermes de build, et les workers web sans état qu’on peut vider. On ne l’utilise pas pour les bases de données, les workers de queue à sémantique « au plus une fois », ou tout ce dont l’interruption bloque le reste de la plateforme.
• Couverture Savings Plan agressive au-delà de ~80 % de la base. Voir plus haut. Le gain marginal entre 80 % et 100 % de couverture est plus petit que la perte attendue si une seule charge est mise hors service pendant le terme.
• L’auto-scaling comme stratégie principale de coûts. L’auto-scaling est un outil de fiabilité qui économise de l’argent à la marge. Dimensionner le plancher et plafonner le plafond fait la majorité du travail. On l’active par défaut et on arrête d’en parler.
• Le nettoyage de ressources comme transformation. Les volumes EBS sans tag et les snapshots orphelins représentent au mieux quelques pourcents de la facture. L’hygiène compte — on fait du ménage hebdomadaire — mais personne n’a jamais coupé 20 % de la facture en supprimant des volumes non attachés.

#Ce qui reste, c’est la cadence

Configurez des tableaux de bord Cost Explorer, mettez une alerte de facturation à 110 % de la dépense prévue, et placez les revues de dimensionnement et de couverture Savings Plan au calendrier trimestriellement. Les gains qui s’accumulent viennent de ne jamais perdre la facture de vue, pas d’un grand projet d’optimisation.