Le coût caché du « cloud is cheaper »

« Le cloud est moins cher. » C'est la phrase qu'on entend dans every pitch, every keynote, every deck de vente. Pas de CapEx, seulement de l'OpEx. Pas de serveurs à acheter, pas de climatisation à maintenir, pas de salle blanche à construire. Vous payez ce que vous consommez. C'est magnifique. Sauf que ce n'est pas vrai. Ou plutôt, c'est vrai au début — quand vous avez trois instances et une base de données de test. Mais au moment où votre application grandit, où vous ajoutez des environnements, où vous activez des services que vous pensiez gratuits, la facture fait ce que toute facture cloud fait : elle augmente. Silencieusement. Continuellement. Et sans aucune action de votre part.

Après avoir audité des dizaines d'infrastructures cloud — AWS, Azure, GCP — je peux vous dire une chose : presque personne ne connaît le coût réel de son infrastructure. Pas par incompétence. Parce que les fournisseurs cloud ont conçu un système de tarification d'une complexité que personne ne peut maîtriser intégralement. Plus de 300 services sur AWS, chacun avec sa propre grille, ses propres options, ses propres régions avec des prix différents. C'est intentionnel. L'opacité paie.

L'egress : le coût que personne ne voit venir

Le egress — le transfert de données sortant du cloud — est le coût le plus insidieux du cloud. Entrer des données est gratuit. Les stocker est bon marché. Mais les faire sortir ? Ça, ça coûte. Sur AWS, c'est $0.09 par Go pour un transfert vers internet. Sur Azure, $0.087. Sur GCP, $0.08. Ça semble négligeable. Ça ne l'est pas.

Imaginez une application qui sert 500 Go de données par mois à ses utilisateurs — images, API responses, fichiers téléchargeables. C'est 500 × $0.09 = $45/mois. Raisonnable. Maintenant, imaginez que cette application grandit et sert 5 To par mois. 5000 × $0.09 = $450/mois. Toujours gérable. Mais ajoutez un service qui réplique des données vers une autre région pour la disaster recovery : 2 To de réplication inter-région à $0.02/Go = $40/mois. Ajoutez un data warehouse qui exporte ses résultats vers un bucket S3 dans une autre région pour être consommé par une BI : 1 To à $0.02/Go = $20/mois. Ajoutez un service de monitoring externe qui scrape vos métriques : 200 Go/mois à $0.09/Go = $18/mois.

Et voilà comment on passe de $45 à plus de $500/mois, juste en egress. Sans que personne n'ait délibérément décidé de dépenser cet argent. Chaque service ajoute son flux de données, chaque flux ajoute son coût, et personne ne regarde la facture de près parce que « c'est juste du transfert ».

Le pire ? L'egress est structurellement difficile à réduire. Vos utilisateurs veulent leurs données. Vous ne pouvez pas arrêter de les servir. La seule façon de réduire l'egress est de rapprocher les données de l'utilisateur — CDN, edge computing — ce qui ajoute... un autre coût. Le cloud est un système où chaque optimisation crée une nouvelle dépense.

Les snapshots : la croissance silencieuse

Vous avez une base de données RDS. Vous activez les snapshots automatiques. Bonne pratique. 7 jours de rétention. Ça coûte $0.095/Go/mois sur AWS. Pour une base de 100 Go, c'est $9.50/mois. Rien.

Sauf que. Votre base grandit. 200 Go. 500 Go. 1 To. Et vos snapshots aussi. Mais les snapshots sont incrémentaux — chaque snapshot ne stocke que les blocs modifiés depuis le précédent. Donc le coût ne grandit pas linéairement, il grandit en fonction du churn de votre base. Une base avec beaucoup d'écritures aléatoires — typiquement une base OLTP avec des mises à jour partout — génère des snapshots qui grossissent vite.

Et puis il y a les snapshots manuels. Ceux que quelqu'un a créés « juste avant la migration » et qui ne sont jamais supprimés. Trois mois plus tard, ils sont toujours là, accumulant du coût. Six mois plus tard, toujours là. Personne ne sait qui les a créés. Personne n'ose les supprimer — « et si on en a besoin ? ». J'ai vu des comptes AWS avec des snapshots qui coûtaient plus de $2000/mois, dont 80% étaient des snapshots orphelins que personne n'utilisait.

La règle : les snapshots doivent avoir une politique de lifecycle. Création, rétention, suppression — tout automatisé. Si un snapshot n'a pas de tag « propriétaire » et « date de suppression », il ne devrait pas exister. Mais combien d'équipes appliquent cette règle ? Trop peu.

CloudWatch et les logs : l'incendie lent

CloudWatch Logs est probablement le service le plus sournois d'AWS. Vous activez les logs parce que c'est une bonne pratique. Vous configurez vos applications pour logger vers CloudWatch. Ça marche. Vous regardez la facture : $0.50 par Go d'ingestion. Raisonnable.

Sauf que vos applications loguent beaucoup. Chaque requête HTTP génère 5 lignes de log. Chaque erreur en génère 20. Chaque transaction de base de données en génère 3. Votre application traite 1000 requêtes/seconde. C'est 5000 lignes/seconde. À 200 octets par ligne en moyenne, c'est 1 Mo/seconde. 86 Go/jour. 2.6 To/mois. 2.6 × 1024 × $0.50 = $1331/mois. Juste pour ingérer des logs.

Et ce n'est pas fini. CloudWatch Logs facture aussi le stockage : $0.03/Go/mois. 2.6 To × $0.03 = $78/mois. Et les Insights queries : $0.005 par Go scanné. Si vous queryez vos logs régulièrement — et vous le faites, parce que c'est le but — c'est facilement $200/mois supplémentaires. Total : plus de $1600/mois. Pour des logs. Que la plupart des équipes ne regardent jamais sauf quand il y a un incident.

La solution n'est pas d'arrêter de logger. C'est de logger intelligemment. Niveaux de log dynamiques — INFO en normal, DEBUG uniquement quand on debug. Sampling — logger 10% des requêtes en succès, 100% des erreurs. Rétention courte — 7 jours pour les logs détaillés, 30 jours pour les logs agrégés. Et envisager des alternatives : ELK self-hosted, Loki, ou même un simple fichier sur disque pour les logs de debug. CloudWatch est pratique mais c'est un luxe qui se paie.

Les NAT gateways : le péage invisible

Si vous avez une architecture VPC correcte — et vous devriez — vos ressources privées n'ont pas d'IP publique. Pour accéder à internet (mises à jour, API externes, téléchargements), elles passent par une NAT gateway. Et la NAT gateway facture : $0.045/Go de données traitées, plus $0.045/heure d'existence.

Une NAT gateway qui tourne 24/7, c'est $0.045 × 730 = $32.85/mois. C'est le coût de base. Mais le vrai coût, c'est le trafic. Si vos instances privées téléchargent 1 To/mois — mises à jour de packages, images Docker, API externes — c'est 1000 × $0.045 = $45/mois. Total : ~$78/mois. Pour une seule NAT gateway.

Maintenant, multipliez. Vous avez trois environnements (dev, staging, prod), chacun avec sa NAT gateway. Trois × $78 = $234/mois. Et si vous avez du multi-AZ — et vous devriez, pour la haute disponibilité — c'est trois NAT gateways par environnement. Neuf NAT gateways. $700/mois. Juste pour permettre à vos instances d'accéder à internet.

Le pire, c'est que la plupart du trafic qui passe par la NAT gateway n'a pas besoin d'aller sur internet. Vos instances qui téléchargent des images Docker depuis Docker Hub ? Utilisez un VPC endpoint pour ECR. Vos instances qui accèdent à S3 ? Utilisez un VPC endpoint gateway — c'est gratuit. Vos instances qui accèdent à DynamoDB ? VPC endpoint. Chaque VPC endpoint élimine du trafic NAT, et chaque Go économisé est $0.05 dans votre poche.

Le piège du free tier

« 12 mois de free tier ! » C'est le crochet de AWS. Et c'est réel — pendant 12 mois, vous avez 750 heures/mois de t2.micro, 5 Go de S3 standard, 750 heures de RDS micro. C'est suffisant pour un prototype. C'est suffisant pour apprendre. Ce n'est pas suffisant pour une application réelle.

Le piège est subtil. Pendant le free tier, vous construisez votre architecture. Vous choisissez vos services. Vous vous habituez à CloudWatch, à Lambda, à API Gateway. Et quand le free tier expire — bam. La facture arrive. Et elle n'est pas petite, parce que vous avez construit une architecture qui suppose que tout est gratuit.

Le free tier n'est pas un cadeau. C'est un investissement marketing. AWS dépense des millions pour vous donner des ressources gratuites pendant 12 mois, parce qu'ils savent que le coût de migration après 12 mois est supérieur à la facture qu'ils vont vous envoyer. Vous êtes lock-in avant même de payer. C'est brillant. Et c'est exactement ce que vous devez anticiper.

Reserved instances vs on-demand : le faux débat

Tout le monde vous dit d'acheter des Reserved Instances. « Vous économisez jusqu'à 72% ! ». C'est vrai. Mathématiquement. Mais c'est une promesse sur 1 ou 3 ans, et le cloud est un monde où vos besoins changent en 3 mois.

Vous achetez une Reserved Instance m5.xlarge pour 3 ans. Six mois plus tard, votre workload a changé — vous avez besoin de m5.2xlarge, ou vous avez migré vers Graviton (c6g.xlarge), ou vous avez optimisé votre code et n'avez plus besoin de cette instance. La RI est là. Vous la payez. Que vous l'utilisiez ou non.

Les Savings Plans — la nouvelle génération de RI — sont plus flexibles : ils s'appliquent à n'importe quelle instance d'une famille donnée. Mais ils restent un engagement. Et dans un monde où les prix des instances baissent régulièrement (les Graviton sont 20% moins chers que les équivalents x86), s'engager sur 3 ans peut signifier payer plus cher que le marché.

Ma recommandation : 30% de votre capacité en on-demand (pour la flexibilité), 50% en Savings Plans 1 an (le meilleur ratio risque/bénéfice), 20% en Spot (pour les workloads tolérants aux interruptions). Mais cette répartition dépend de votre contexte. Il n'y a pas de réponse universelle, et quiconque vous en donne une sans connaître votre workload vous ment.

Le support : l'assurance que vous n'utilisez jamais

AWS Support a quatre niveaux : Basic (gratuit), Developer ($29/mois), Business ($100/mois ou 3% de votre facture), Enterprise ($15 000/mois ou 3% de votre facture). La plupart des entreprises prennent Business, parce que « il faut bien avoir du support ».

Combien de tickets de support ouvrez-vous par an ? Pour la plupart des équipes : moins de 5. Et la plupart de ces tickets sont des questions de configuration, pas des incidents critiques. Vous payez 3% de votre facture — potentiellement des milliers de dollars par mois — pour un service que vous utilisez cinq fois par an.

Le support Business a du sens si vous avez des workloads critiques en production avec des SLA stricts. Pour le reste — dev, staging, applications non critiques — Basic suffit. Et si vous avez vraiment besoin d'aide, payez un consultant à l'heure. C'est presque toujours moins cher.

La réalité FinOps : ce que personne ne veut entendre

FinOps — la discipline d'optimisation des coûts cloud — est à la mode. Des outils comme CloudHealth, Cloudability, AWS Cost Explorer promettent de « visualiser et optimiser » vos coûts. C'est nécessaire. Mais c'est insuffisant.

Le vrai problème du coût cloud n'est pas technique. Il est organisationnel. Chaque développeeur peut créer des ressources. Chaque équipe peut lancer des services. Et personne n'est responsable de la facture. La facture arrive au DSI, qui la regarde, qui grimace, qui demande « pourquoi ça augmente ? », et qui ne reçoit pas de réponse parce que personne ne sait exactement qui a créé quoi.

La solution est de trois ordres :

• Tagging obligatoire — chaque ressource doit avoir un tag « équipe », « projet », « environnement ». Sans tag, la ressource est supprimée. Automatiquement. Pas de négociation.
• Budgets par équipe — chaque équipe a un budget cloud. Quand le budget est dépassé, l'équipe est alertée. Quand il est dépassé de 20%, les ressources non critiques sont automatiquement arrêtées.
• Revue mensuelle — une fois par mois, chaque équipe présente sa facture cloud et justifie chaque ligne. C'est fastidieux. C'est nécessaire. C'est la seule façon de maintenir la discipline.

Sans ces trois piliers, les outils FinOps ne servent à rien. Ils vous montrent que vous dépensez trop. Ils ne vous empêchent pas de dépenser trop. La différence est cruciale.

Le coût du « on a toujours fait comme ça »

Le coût le plus invisible du cloud, c'est le coût de l'inertie. Des ressources qui tournent parce qu'elles ont toujours tourné. Des environnements de test qui ne sont jamais éteints. Des instances surdimensionnées « au cas où ». Des services managés que personne n'utilise mais que personne n'a supprimés.

Sur chaque audit cloud que je fais, je trouve entre 20% et 40% de gaspillage. Pas des optimisations fines. Du gaspillage pur. Des ressources qui ne servent à rien et qui coûtent de l'argent. Et ce n'est pas parce que les équipes sont incompétentes. C'est parce que le cloud est conçu pour être facile à démarrer et difficile à arrêter. Créer une instance prend 30 secondes. Supprimer une instance demande de vérifier que personne ne l'utilise, que personne n'y stocke de données critiques, que personne n'a de dépendance dessus. C'est plus facile de la laisser tourner.

Sauf que chaque instance qui tourne sans raison est de l'argent qui sort de votre entreprise chaque mois. Et cet argent s'accumule. $50/mois ici, $200/mois là, $800/mois ailleurs. À la fin de l'année, c'est des dizaines de milliers de dollars. Pour rien.