Le coût cloud reflète l'architecture, non l'usage brut
La première vérité souvent ignorée : votre facture mensuelle n'est pas un accident météorologique. Elle découle de décisions d'architecture prises il y a six mois, douze mois, parfois deux ans. Lorsqu'un service consomme trois instances RDS en permanence alors qu'il traite cinquante requêtes par jour, le problème n'est pas le fournisseur — c'est la conception du système. AWS facture ce que vous provisionnez. GCP facture ce que vous utilisez, mais seulement si vous structurez correctement vos workloads. Azure offre des réductions substantielles si vous acceptez les contraintes de leurs Reserved Instances. Dans tous les cas, l'architecture détermine combien vous payez avant même que le premier utilisateur ne se connecte.
Les ingénieurs platform comprennent cela intuitivement. Pourtant, la pression pour livrer pousse les équipes à suraprovisionner par défaut. Une instance m5.2xlarge « au cas où » devient permanente. Un cluster Kubernetes dimensionné pour un pic hypothétique tourne à 18 % d'utilisation moyenne pendant onze mois. GCP offre des sustained use discounts automatiques après 25 % du mois, mais seulement si vos instances restent actives dans la même région. AWS requiert un engagement Reserved Instance d'un an minimum pour obtenir 40 % de réduction. Azure combine les deux approches avec des Savings Plans flexibles. Le choix du fournisseur cloud importe moins que la discipline architecturale sous-jacente. Sans cette discipline, vous paierez cher sur les trois plateformes.
La granularité de facturation change tout dans le multi-tenant
AWS facture à la seconde près pour EC2 et Lambda (avec un minimum de 60 secondes pour EC2). GCP facture à la seconde également, mais démarre à la première seconde sans minimum artificiel. Azure facture à la minute pour la plupart des services, avec arrondissement supérieur. Ces différences semblent négligeables sur papier. En pratique, elles dictent quelle plateforme convient à quelle charge de travail. Si vous opérez des batch jobs de 90 secondes qui tournent 400 fois par jour, GCP et AWS deviennent équivalents. Si ces jobs durent 40 secondes, GCP vous facture 40 secondes, AWS vous facture 60. Sur un an, à grande échelle, l'écart atteint cinq chiffres.
- Lambda sur AWS facture par tranche de 100 ms après la première seconde, idéal pour micro-services.
- Cloud Functions sur GCP facture par tranche de 100 ms dès la première milliseconde, meilleur pour événements ultra-courts.
- Azure Functions propose un plan Consumption similaire mais avec cold start plus lent, impactant time-to-first-value.
- Les trois offrent des plans dédiés (Provisioned, Always-On) qui éliminent le cold start mais coûtent 10x plus cher.
- Kubernetes sur les trois plateformes facture les nœuds, pas les pods — la granularité descend au niveau VM.
- Serverless containers (Fargate, Cloud Run, Container Instances) facturent par seconde de CPU/RAM allouée, pas utilisée.
Cette granularité influence directement votre modèle économique si vous opérez une plateforme multi-tenant. Un client qui consomme 12 secondes de compute toutes les heures coûte 288 secondes par jour, soit 8 640 secondes par mois — environ 2,4 heures facturables. Sur AWS Lambda au tarif standard ($0,0000166667/GB-seconde avec 1 GB), cela représente $0,24 par mois pour ce client seul. Multipliez par 10 000 clients et vous atteignez $2 400 mensuels juste pour cette micro-charge. GCP Cloud Run, avec une allocation minimale de 128 MB et facturation précise, descendrait ce coût de 40 % grâce à la meilleure granularité mémoire. Le choix de plateforme devient un levier économique direct, pas une préférence technique abstraite.
L'engagement temporel réduit les coûts de 60 %, mais augmente le risque architectural
Reserved Instances sur AWS, Committed Use Discounts sur GCP, Reserved VM Instances sur Azure : tous trois offrent des réductions substantielles en échange d'un engagement de un ou trois ans. AWS propose jusqu'à 72 % de réduction sur certaines instances avec paiement anticipé sur trois ans. GCP atteint 57 % avec des Committed Use Discounts flexibles appliqués automatiquement à vos workloads. Azure se positionne entre les deux avec 62 % sur certaines séries. Ces chiffres transforment un budget infrastructure de $180 000 annuel en $64 800 avec engagement optimal. Pourtant, moins de 40 % des organisations cloud atteignent ce taux de couverture.
L'engagement temporel sur le cloud est un pari sur votre propre discipline architecturale future — la plupart perdent ce pari.
Pourquoi si peu d'adoption malgré l'économie évidente ? Parce que l'engagement suppose une stabilité architecturale qui contredit la réalité des équipes engineering modernes. Vous signez un Reserved Instance de trois ans pour des m5.xlarge en avril 2024. En novembre 2024, votre équipe migre vers une architecture serverless qui n'utilise plus EC2. Vous continuez de payer $4 320 annuels pour des instances fantômes. GCP offre plus de flexibilité — leurs Committed Use Discounts s'appliquent à plusieurs types d'instances dans une famille — mais requièrent quand même une prévision précise de votre utilisation totale de compute. Azure propose des Savings Plans qui couvrent compute across services, incluant VMs, App Service, Functions. C'est l'approche la plus flexible, mais aussi celle avec les réductions les plus modestes (typiquement 47-52 % au lieu de 60-72 %). Le principe fondamental demeure : l'optimisation agressive des coûts via engagement réduit votre agilité architecturale. C'est un trade-off explicite, pas un déjeuner gratuit.
Les architectures event-driven réduisent le coût du data movement
Le transfert de données représente souvent 15-25 % de la facture cloud totale, surtout en architecture distribuée. AWS facture $0,09/GB pour les transferts sortants vers Internet après le premier gigabyte gratuit. GCP commence à $0,085/GB (légèrement moins cher) mais avec une première tranche gratuite plus généreuse (1 TB/mois pour certains services). Azure facture $0,087/GB. Les différences semblent marginales. Mais un système qui transfère 50 TB mensuels paie $4 500/mois sur AWS, $4 250 sur GCP (après la première tranche), $4 350 sur Azure. Sur douze mois, l'écart GCP vs AWS atteint $3 000 — juste pour les sorties réseau.
Pattern saga et réduction des transferts inter-régions
Les architectures synchrones amplifient ces coûts. Un appel API qui traverse trois services, avec chaque service dans une région différente pour « haute disponibilité », génère six transferts réseau (aller-retour sur trois hops). Si chaque requête transporte 50 KB de payload, 10 millions de requêtes mensuelles produisent 3 TB de transfert facturable. Adopter un saga pattern avec event sourcing réduit ce volume de 60-70 %. Au lieu de chaînes synchrones, chaque service publie des événements dans un bus central (EventBridge sur AWS, Pub/Sub sur GCP, Event Grid sur Azure). Les services consommateurs réagissent de manière asynchrone. Les messages d'événements sont plus compacts (souvent 2-5 KB) et ne nécessitent pas de réponse immédiate, éliminant la moitié des transferts.
- Identifiez les chaînes de services synchrones qui traversent plusieurs régions ou availability zones — utilisez Datadog APM pour cartographier les dépendances.
- Remplacez les appels REST synchrones par des événements asynchrones avec idempotency keys pour gérer les doublons inévitables.
- Consolidez les services fortement couplés dans la même availability zone — le trafic intra-AZ est gratuit sur les trois plateformes.
- Implémentez un circuit breaker pour chaque dépendance externe afin d'éviter les cascades de retry coûteuses lors d'incidents.
- Mesurez le GRR (Gross Revenue Retention) par région et concentrez compute et storage dans les régions à plus forte valeur — ne distribuez pas uniformément par défaut.
Le choix de storage tier transforme la courbe de coût à long terme
AWS offre S3 Standard, Intelligent-Tiering, Infrequent Access, Glacier, Glacier Deep Archive. GCP propose Standard, Nearline, Coldline, Archive. Azure a Hot, Cool, Archive. Chaque tier réduit le coût de stockage mais augmente le coût de récupération et la latence. S3 Standard coûte $0,023/GB/mois. Glacier Deep Archive descend à $0,00099/GB/mois — une réduction de 96 %. Mais récupérer 1 TB depuis Deep Archive coûte $25 et prend 12 heures minimum. Pour des données rarement consultées (logs de conformité, backups annuels), l'économie est évidente. Pour des données consultées trimestriellement, Glacier standard ou GCP Nearline offrent un meilleur équilibre. Le piège : les équipes sous-estiment la fréquence d'accès réelle. Un backup « jamais utilisé » est consulté trois fois par an lors d'audits de sécurité. Chaque récupération de 500 GB depuis Deep Archive coûte $12,50. Sur cinq ans, le coût cumulé de récupération peut dépasser ce que vous auriez payé en S3 Infrequent Access.
Les ADR (architecture decision records) doivent documenter explicitement le choix de storage tier pour chaque dataset, avec fréquence d'accès projetée et coût annuel total estimé (stockage + récupération). GCP Cloud Storage offre une fonctionnalité Autoclass qui ajuste automatiquement le tier selon l'usage réel, réduisant les erreurs manuelles. AWS Intelligent-Tiering fait similaire mais facture $0,0025/1000 objets de frais de monitoring — négligeable pour de gros fichiers, prohibitif pour des millions de petits fichiers. Azure Cool storage est souvent le meilleur compromis pour des données consultées mensuellement : $0,0152/GB (34 % moins cher que Hot) avec récupération instantanée et coût de lecture raisonnable. Le principe fondamental : ne stockez jamais au tier le plus cher « par défaut » — chaque dataset mérite une décision consciente basée sur sa lifecycle value.
Lundi matin : audit des coûts cachés et création d'un service catalog
Vous lisez cet article un vendredi. Lundi, démarrez par un audit de 90 minutes de vos coûts réels. AWS Cost Explorer, GCP Cloud Billing Reports, Azure Cost Management offrent tous des breakdowns par service, région, tag. Identifiez vos trois plus grosses lignes de coût. Pour la plupart des organisations, ce sera : compute (EC2/Compute Engine/VMs), data transfer, database (RDS/Cloud SQL/Azure SQL). Exportez les données en CSV. Calculez le coût par utilisateur actif mensuel — si vous ne connaissez pas ce chiffre, vous pilotez à l'aveugle. Un coût cloud de $40 000/mois pour 8 000 utilisateurs actifs donne $5/utilisateur. Si votre ARPU (average revenue per user) est $12, vos marges brutes sont serrées. Si c'est $45, vous avez de la marge pour investir dans la croissance plutôt que dans l'optimisation frénétique.
Ensuite, créez un service catalog entry pour chaque service backend déployé. Documentez : région primaire, tier de storage utilisé, engagement Reserved/Committed actuel, coût mensuel moyen des trois derniers mois, propriétaire technique. Cet exercice révèle immédiatement les secrets scattered across .env files, les ressources orphelines, les environnements de staging surdimensionnés qui tournent 24/7 alors qu'ils ne servent que huit heures par jour. Éteignez automatiquement les environnements non-prod la nuit et le weekend — cela réduit 60 % du coût compute de ces environnements. Implémentez des tags obligatoires (environment, owner, project) sur toutes les ressources et configurez des alertes budgétaires par tag. AWS Budgets, GCP Budget Alerts, Azure Cost Alerts envoient des notifications Slack quand un cluster_435 dépasse son seuil. L'alert fatigue est réelle, mais un budget dépassé de 40 % sans notification est pire. Ajustez les seuils pour équilibrer vigilance et pragmatisme. Ces actions, réalisables en une semaine, réduisent typiquement 15-20 % des coûts sans toucher à l'architecture.
Conclusion : l'optimisation cloud est un choix architectural continu
Les trois hyperscalers offrent des prix compétitifs et des mécanismes d'optimisation sophistiqués. AWS domine en breadth de services et outils d'optimisation (Compute Optimizer, Cost Anomaly Detection). GCP excelle en granularité de facturation et réductions automatiques via sustained use discounts. Azure séduit les organisations Microsoft-centric avec des Savings Plans flexibles et une intégration native avec Active Directory et DevOps Services. Aucun n'est objectivement « moins cher » — le coût final dépend de votre architecture, de votre discipline d'engagement, de votre modèle de traffic. L'optimisation n'est pas un projet trimestriel. C'est une pratique continue, ancrée dans chaque ADR, chaque revue de PR cycle time, chaque discussion sur un nouveau service. Les organisations qui maîtrisent leurs coûts cloud n'ont pas de secrets magiques. Elles ont simplement rendu l'optimisation invisible, intégrée dans leur façon quotidienne de construire. Vous pouvez faire de même dès lundi, en commençant petit : un audit, un service catalog, des tags cohérents. L'argument proper, next : transformez ces principes en pratique systématique.