Réduire sa facture AWS sans compromettre la production

Le scénario est fréquent. La facture AWS a augmenté de mois en mois, plus vite que l'activité. La direction financière demande pourquoi, l'équipe technique regarde la console et voit un total, quelques services en tête de liste, mais aucune explication claire : quelle application, quel environnement, quelle décision est à l'origine de la hausse ?

Connaître le montant d'une facture et comprendre ce qui la génère sont deux choses différentes. Pour réduire une facture AWS, il faut d'abord relier chaque dépense à une ressource, une application et un usage réel. Ensuite seulement, on distingue les économies immédiates, celles qui demandent des tests, et les changements d'architecture qui comportent un risque pour la production.

Cet article détaille cette méthode : ce que vous payez réellement, huit leviers d'optimisation avec leurs précautions, un audit en six étapes, la façon de mesurer des économies réelles, et le moment où une migration hors d'AWS mérite d'être étudiée.

Comprendre ce que l'entreprise paie réellement

Une facture AWS se décompose en quelques grandes familles de dépenses. Les identifier est simple ; les attribuer à une application ou à une équipe l'est beaucoup moins sans une organisation préalable des comptes et des tags.

Les outils pour voir la dépense

• AWS Cost Explorer : visualisation des coûts par service, compte, région ou tag, avec des recommandations de redimensionnement et d'engagement.
• AWS Data Exports (CUR 2.0) : l'export le plus détaillé, livré dans un bucket S3, avec une granularité horaire et les identifiants de ressources. C'est la source recommandée par AWS pour une analyse fine.
• Tags de répartition des coûts : ils rattachent une dépense à un projet ou à un environnement, mais doivent être activés dans la console de facturation avant d'apparaître dans Cost Explorer, avec un délai pouvant atteindre 24 heures.
• Budgets et détection d'anomalies : alertes sur seuil et détection automatique des hausses inhabituelles.

Ces tableaux de bord ont une limite : une dépense identifiée ne prouve pas qu'une ressource est inutile. Une base peu sollicitée peut servir de secours, un volume détaché peut contenir la seule copie d'une donnée. La décision exige de connaître l'usage métier, pas seulement la courbe de consommation.

Les 8 leviers d'optimisation AWS

Aucun levier n'est universel. Chacun doit être évalué selon son gain probable, l'effort nécessaire et le risque pour la production. Les deux derniers critères comptent autant que le premier.

1. Les ressources inutilisées ou sous-utilisées

• Problème : instances arrêtées avec des volumes attachés, volumes EBS détachés, adresses IP publiques réservées, équilibreurs de charge sans cible.
• Détection : Cost Explorer, inventaire des ressources, contrôles de coûts de Trusted Advisor. Attention : l'ensemble des contrôles de Trusted Advisor est réservé aux plans de support payants (Business Support+ et supérieurs).
• Action : identifier un propriétaire pour chaque ressource, puis supprimer ce qui n'a ni propriétaire ni usage.
• Précaution : snapshot et validation écrite avant toute suppression.
• Mesure : nombre de ressources sans propriétaire et coût associé, suivis dans le temps.

2. Le dimensionnement des instances

• Problème : des instances choisies pour un pic ponctuel ou « par sécurité ».
• Détection : AWS Compute Optimizer, qui partage son moteur de recommandation avec Cost Explorer. Par défaut, il analyse 14 jours d'historique ; 32 jours sans surcoût, ou 93 jours avec une option payante.
• Action : changer de taille ou de famille d'instance, par étapes.
• Précaution : 14 jours ne couvrent pas une clôture mensuelle ou une saison. Selon la FAQ du service, les métriques analysées par défaut portent sur le processeur, le réseau et le stockage local : vérifiez que la mémoire est bien mesurée avant de réduire une instance.
• Mesure : coût de l'instance et indicateurs de performance (latence, erreurs) avant et après.

3. Les Savings Plans et Reserved Instances

• Problème : une consommation stable payée au tarif à la demande, ou à l'inverse un engagement acheté trop tôt.
• Détection : rapports de couverture et d'utilisation des engagements dans Cost Explorer.
• Action : un Savings Plan est un engagement de dépense horaire sur un ou trois ans, en échange d'un tarif réduit. AWS annonce des remises pouvant aller jusqu'à 66 % (Compute) ou 72 % (EC2 Instance) : ce sont des maximums, pas des moyennes.
• Précaution : un Savings Plan ne peut pas être annulé pendant sa durée. Optimisez d'abord les ressources, engagez-vous ensuite sur la base résiduelle stable.
• Mesure : taux de couverture et taux d'utilisation de l'engagement.

4. Les volumes EBS, snapshots et classes de stockage S3

• Problème : anciens volumes gp2, snapshots jamais purgés, données froides stockées en classe standard.
• Détection : Cost Explorer par type d'usage, inventaire des snapshots, analyse des accès aux buckets.
• Action : AWS indique que les volumes gp3 offrent un prix par Go jusqu'à 20 % inférieur à gp2, avec une conversion sans redémarrage. Pour S3, des règles de cycle de vie ou la classe Intelligent-Tiering.
• Précaution : vérifier les performances (IOPS, débit) après conversion. Selon la grille tarifaire S3, certaines classes imposent une durée minimale facturée (30 ou 90 jours) et des frais de récupération ; Intelligent-Tiering facture un suivi par objet.
• Mesure : coût du stockage par Go conservé et nombre de restaurations.

5. Les transferts de données, NAT Gateway et coûts réseau

• Problème : du trafic vers S3 ou DynamoDB qui transite par une NAT Gateway, des échanges entre zones de disponibilité, des sorties vers Internet non anticipées.
• Détection : types d'usage « DataTransfer » et « NatGateway » dans Cost Explorer, journaux de flux VPC.
• Action : une NAT Gateway est facturée à l'heure et à chaque Go traité, quelle que soit la destination. Un point de terminaison VPC de type passerelle permet d'éviter ces frais de traitement pour le trafic vers S3 et DynamoDB.
• Précaution : toute modification de routage se teste hors production et se déploie avec un retour arrière prévu.
• Mesure : volume traité par la NAT Gateway et coût réseau par application.

6. Les bases de données et services gérés

• Problème : instances de base surdimensionnées, réplicas inutiles, capacité provisionnée figée.
• Détection : Compute Optimizer couvre aussi RDS et Aurora ; métriques de connexions, de processeur et d'entrées-sorties.
• Action : redimensionner, revoir le stockage, étudier les Database Savings Plans (engagement d'un an) pour une charge stable.
• Précaution : une base est rarement isolée. Tester les requêtes lourdes et le basculement avant toute réduction.
• Mesure : coût par base et temps de réponse des requêtes critiques.

7. Les environnements de développement et de test

• Problème : des environnements identiques à la production, allumés en permanence.
• Détection : ventilation des coûts par compte ou par tag d'environnement.
• Action : arrêts programmés hors heures de travail, tailles réduites, environnements éphémères créés à la demande.
• Précaution : préserver la représentativité des tests de performance.
• Mesure : part du coût hors production dans la facture totale.

8. La visibilité financière et les responsabilités

• Problème : personne n'est responsable d'une ligne de coût.
• Détection : proportion des dépenses non taguées.
• Action : règles de tags, budgets par équipe, et détection d'anomalies, qui analyse les coûts environ trois fois par jour à partir de données pouvant avoir jusqu'à 24 heures de décalage. Côté journaux, CloudWatch conserve les journaux indéfiniment par défaut : fixer une durée de rétention par groupe.
• Précaution : les tags ne s'appliquent pas rétroactivement par défaut ; les obligations légales de conservation des journaux priment sur l'économie.
• Mesure : part des coûts attribués à un responsable.

Comment réaliser un audit AWS des coûts

Un audit sérieux suit six étapes, de la collecte des données au suivi récurrent. Il produit une liste d'actions classées par impact, effort et risque, et non une liste de suppressions.

Ce tableau décrit une pratique recommandée. Côté CERVOX Services, deux missions correspondent à ce besoin. L'analyse de facture AWS porte sur les 90 derniers jours : principaux postes de coût et leur origine, corrections possibles avec leurs contreparties, application des seules corrections que vous validez, alertes et budget configurés selon le périmètre convenu, documentation et transmission. L'audit de compte AWS, réalisé en lecture seule, livre un inventaire des ressources analysées, les principaux points d'attention et des recommandations.

Comment mesurer les économies réelles

Comparer deux factures mensuelles est trompeur : la charge, la saisonnalité, les engagements tarifaires et les coûts ponctuels faussent la comparaison. La mesure fiable est un coût unitaire, rapporté à une unité d'activité pertinente.

Plusieurs effets brouillent la lecture d'une facture : la hausse ou la baisse du trafic, les pics saisonniers, les paiements initiaux d'engagements, les coûts ponctuels de migration ou de double fonctionnement, et le temps d'exploitation ajouté ou retiré à l'équipe. Le coût unitaire divise la dépense cloud par une mesure d'activité : utilisateur actif, commande, document traité, heure de calcul utile.

Exemple entièrement hypothétique. Avant optimisation : 12 000 € par mois pour 400 000 commandes, soit 0,030 € par commande. Trois mois plus tard : 12 600 € pour 520 000 commandes, soit environ 0,024 €. La facture a augmenté de 5 %, mais le coût par commande a baissé d'environ 19 %. Le cas inverse existe : une facture en baisse de 15 % (10 200 €) avec seulement 300 000 commandes donne 0,034 € par commande, soit une dégradation d'environ 13 %. Limites : l'exemple suppose une unité représentative de la consommation et ne tient pas compte des coûts humains.

Quand faut-il envisager une migration hors d'AWS ?

Une optimisation d'AWS suffit souvent quand la hausse vient de ressources mal dimensionnées, oubliées ou mal réparties. Une architecture hybride ou une migration partielle mérite une étude quand le problème est structurel : exigences de gouvernance, dépendance à éviter, ou écart de coût qui persiste après optimisation.

Le prix d'une instance ne représente pas le coût total d'une infrastructure. Une comparaison sérieuse intègre les dépendances techniques, le réseau, la sécurité, les exigences de gouvernance et le coût d'exploitation. Notre article sur la migration d'AWS vers un cloud européen détaille cette méthode, avec un calcul de coût total sur 36 mois. Pour trancher, CERVOX Services propose aussi un diagnostic « Aller sur AWS, en rester, ou en sortir », qui compare trois options chiffrées sur 12 mois.

Les erreurs à éviter

Checklist : première analyse de votre facture AWS

• Les douze derniers mois de coûts sont visibles par service dans Cost Explorer.
• Un export détaillé (Data Exports, CUR 2.0) est activé vers un bucket S3.
• Les cinq services les plus coûteux et leur évolution sont identifiés.
• Chaque compte AWS a un responsable nommé.
• Les tags de projet et d'environnement sont définis et activés pour la facturation.
• La part des coûts non taguée est connue.
• Les volumes détachés, IP inutilisées et snapshots anciens sont listés, avec un propriétaire.
• Les environnements hors production ont des horaires d'arrêt.
• Les coûts de NAT Gateway et de transfert de données sont isolés.
• Chaque groupe de journaux a une durée de rétention définie.
• Un budget et une détection d'anomalies envoient des alertes à une personne qui agit.
• Le taux de couverture et d'utilisation des engagements est suivi.

Questions fréquentes

Pourquoi ma facture AWS augmente-t-elle ?

Les causes les plus courantes sont une hausse d'activité, des ressources créées puis oubliées, un dimensionnement choisi pour un pic, des transferts de données non anticipés et des journaux conservés sans limite. Seule une ventilation par service, type d'usage et application permet de distinguer une hausse normale d'une dérive.

AWS Cost Explorer est-il suffisant pour auditer une facture ?

Il suffit pour une première lecture par service et par tag. Pour relier une dépense à une ressource précise sur une base horaire, l'export détaillé (Data Exports, CUR 2.0) est plus adapté. Aucun des deux ne dit si une ressource est encore utile : il faut aussi interroger les équipes.

Les Savings Plans sont-ils toujours intéressants ?

Non. Ils sont pertinents pour une consommation stable et prévisible. Acheté avant d'avoir optimisé, ou sur une charge qui va baisser, un engagement non annulable peut coûter plus qu'il ne rapporte.

Comment réduire les coûts AWS sans interrompre la production ?

En classant chaque action selon son risque, en commençant par les actions sans impact (tags, rétention, ressources orphelines validées), en testant les autres hors production, et en prévoyant un retour arrière pour chaque modification.

Faut-il quitter AWS pour réduire sa facture ?

Pas nécessairement. Une optimisation peut suffire. Une migration se justifie après comparaison du coût total, dépendances, réseau et exploitation compris, et parfois pour des raisons qui ne sont pas financières.

Quand faire réaliser un audit AWS ?

Quand la facture progresse plus vite que l'activité, quand personne ne peut expliquer ses principaux postes, avant un achat d'engagement pluriannuel, ou avant une décision de migration.

Conclusion : comprendre avant de modifier

Avant de modifier son infrastructure ou de changer de fournisseur, une entreprise doit savoir précisément ce qu'elle paie, pourquoi elle le paie et quel risque accompagne chaque optimisation. Les économies durables viennent de cette compréhension, pas d'une réduction générale des ressources.

CERVOX Services intervient sur ce sujet par missions cadrées, sur votre propre compte AWS et sans abonnement : seules les corrections que vous validez sont appliquées, et une estimation écrite vous est remise sous 24 h ouvrées après un premier échange de 20 minutes. Si votre facture AWS progresse sans explication, décrivez votre situation en quelques lignes : nous vous disons si nous pouvons intervenir, et comment.