Aller au contenu

AWS Mis à jour le 2026-07-04

Comment réduire votre facture AWS : les 12 leviers, classés par effort-rendement

Une liste pratique et classée des 12 leviers qui réduisent réellement une facture AWS — de la suppression des ressources orphelines aux Savings Plans — ordonnée par effort versus économies, avec les commandes pour vérifier chacun.

Pour réduire une facture AWS, travaillez les leviers dans l’ordre effort-rendement, pas dans l’ordre où la console les suggère. Les quatre premiers — supprimer les ressources orphelines, éteindre les environnements hors production en dehors des heures ouvrables, migrer les volumes gp2 vers gp3 et corriger la rétention des journaux — prennent un jour ou deux au total et coupent régulièrement 10 à 25 % sans aucun risque architectural. Les engagements (Savings Plans, instances réservées) viennent après le redimensionnement, jamais avant, parce que s’engager sur une capacité surdimensionnée verrouille le gaspillage pour un à trois ans.

Ce que vous décidez

Chaque levier de coût échange de l’effort et du risque contre des économies. L’erreur de la plupart des équipes : commencer par le levier qui semble le plus sophistiqué — une migration Graviton, une réarchitecture — pendant que des volumes EBS détachés de 2023 facturent tranquillement chaque heure. Le classement honnête ci-dessous place chaque levier là où il appartient. Les pourcentages d’économies dépendent de votre mélange de charges de travail; l’ordre, rarement.

Ce qui fait grimper une facture AWS, mécaniquement : les heures de calcul au tarif à la demande, les Go-mois de stockage, les frais de traitement de données (NAT Gateway, répartiteurs de charge, trafic inter-AZ) et les frais par requête ou par Go (appels d’API S3, ingestion de journaux CloudWatch). Chaque levier attaque l’un de ces quatre postes.

Quoi vérifier en premier

  • Connaissez-vous vos cinq services les plus coûteux? Sinon, rien d’autre sur cette page n’est actionnable — ouvrez Billing and Cost Management > Cost Explorer, groupez par Service, trois derniers mois.
  • Y a-t-il des ressources orphelines? Volumes EBS détachés, Elastic IP non associées, répartiteurs de charge inactifs, instantanés de volumes supprimés. C’est du gaspillage pur.
  • Les environnements hors production tournent-ils la nuit et les fins de semaine? Un environnement de dev qui roule 168 heures par semaine au lieu de 50, c’est 70 % de trop sur ce périmètre.
  • Quelle est votre couverture d’engagements? Un calcul stable entièrement à la demande, c’est payer le plein tarif pour la charge de base.

Comment vérifier

Sortez le classement des services et les orphelins évidents avant de toucher à quoi que ce soit :

# Services les plus coûteux du dernier mois complet
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Volumes EBS détachés — gaspillage pur, facturé chaque heure
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' \
  --output table

# Elastic IP allouées mais non associées
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

Dans la console, Cost Explorer > Group by: Usage Type sur votre premier service révèle le mécanisme — heures d’instance versus traitement de données versus stockage — donc le levier qui s’applique. Répétez par région si vous êtes multi-région; les orphelins se cachent dans les régions que personne ne regarde.

L’approche

Classés par effort-rendement, les meilleurs d’abord :

  1. Supprimez les ressources orphelines. Volumes détachés, vieux instantanés, Elastic IP non associées, répartiteurs sans cible saine, instances arrêtées qui gardent des EBS coûteux. Quelques heures de travail, économies immédiates, aucun risque au-delà de confirmer que personne n’a besoin des données (instantané avant suppression).
  2. Planifiez l’arrêt hors production. Une règle EventBridge Scheduler ou Instance Scheduler qui arrête dev et pré-production les nuits et fins de semaine coupe ces heures d’instance d’environ deux tiers. Les instances RDS s’arrêtent aussi (elles redémarrent après sept jours — planifiez le ré-arrêt).
  3. Migrez gp2 vers gp3. gp3 a un tarif au Go plus bas et découple les IOPS de la taille. C’est une modification en ligne par volume, sans arrêt pour la plupart des charges. Vérifiez les volumes de plus de 1 To — les besoins en débit provisionné peuvent changer légèrement le calcul.
  4. Corrigez la rétention et l’ingestion CloudWatch Logs. Les groupes de journaux n’expirent jamais par défaut. Fixez une rétention (30 à 90 jours pour la plupart des journaux applicatifs) et traquez le niveau debug qui expédie des gigaoctets par jour.
  5. Redimensionnez le calcul. Utilisez les constats de Compute Optimizer et les données CloudWatch, pas l’intuition — les règles de validation sont dans le redimensionnement Compute Optimizer. Descendre d’une taille d’instance, c’est environ 50 % de moins sur cette instance.
  6. Achetez des engagements pour le plancher stable. Après le redimensionnement, couvrez la base avec des Savings Plans ou des RI. La matrice de décision par forme de charge est dans RI, Savings Plans, Spot et à la demande.
  7. Ajoutez des politiques de cycle de vie S3. Transition vers Infrequent Access ou Glacier, expiration des téléversements multipart incomplets, expiration des vieilles versions sur les compartiments versionnés. Intelligent-Tiering est le défaut à faible effort pour les accès imprévisibles.
  8. Coupez le traitement de données NAT Gateway. Les points de terminaison de passerelle S3 et DynamoDB sont gratuits et éliminent le traitement NAT pour ce trafic. Un gros volume vers d’autres services AWS peut justifier des points de terminaison d’interface — faites le calcul par service.
  9. Passez à Graviton. Même niveau de performance à tarif plus bas pour les charges compatibles. Services gérés d’abord (RDS, ElastiCache, OpenSearch — un indicateur de moteur, pas un changement de code), puis les applications conteneurisées.
  10. Utilisez Spot pour le travail tolérant aux interruptions. Exécuteurs CI, traitements par lots, travailleurs sans état dans des ASG mixtes. Gros rabais, risque d’interruption réel — un effort d’ingénierie est requis pour le gérer.
  11. Réduisez le bavardage inter-AZ et inter-région. Le transfert de données inter-AZ est facturé dans les deux sens. Gardez les niveaux bavards dans la même AZ quand la conception de disponibilité le permet; c’est de la vraie réarchitecture.
  12. Re-plateformez le niveau coûteux. Aurora I/O-Optimized pour les grappes intensives en E/S, redimensionnement des nœuds ElastiCache, sortir les grosses files du mode sondage. Effort maximal, gain spécifique à la charge.

Quand c’est la mauvaise approche

Si la facture bondit soudainement au lieu de dériver, arrêtez — vous avez un incident, pas un problème d’optimisation, et un triage de 60 minutes passe en premier. Si vous êtes avant l’adéquation produit-marché et que la facture est petite, le temps d’ingénierie vaut plus que les économies; faites les leviers 1 à 4 et passez à autre chose. Et n’achetez pas d’engagements pendant une migration ou une réarchitecture majeure — vous vous engageriez sur la forme que vous quittez.

Erreurs courantes

  • Acheter des Savings Plans avant de redimensionner. L’engagement verrouille la base surdimensionnée pour toute sa durée.
  • Optimiser le service intéressant au lieu du service coûteux. Régler Lambda pendant qu’EC2 représente 60 % de la facture.
  • Un nettoyage unique sans suivi. Les orphelins repoussent. Sans revue mensuelle, la facture revient à sa tendance en deux trimestres.
  • Supprimer sans instantané. Détaché ne veut pas toujours dire inutile; instantané d’abord, suppression après un délai d’attente.

Garder le contrôle

  • Tenez une revue de coûts mensuelle d’une heure : plus gros mouvements, nouveaux orphelins, pourcentage de couverture.
  • Activez Cost Anomaly Detection pour que les pointes avertissent quelqu’un au lieu d’apparaître sur la facture.
  • Imposez une norme d’étiquetage pour que la dépense se rattache aux équipes — une dépense sans étiquette est une dépense sans propriétaire.
  • Configurez des alertes AWS Budgets à 80 % du réel et 100 % de la prévision mensuelle.
  • Revérifiez la couverture d’engagements chaque trimestre; les charges dérivent et la couverture doit suivre. Les mécaniques de tarification sont dans la documentation AWS Cost Management et calculator.aws sert à modéliser les changements.

Les leviers ne sont pas des secrets; c’est la discipline de les travailler dans l’ordre, de mesurer le résultat et de recommencer chaque trimestre qui plie vraiment la courbe. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.