Le cloud vous a économisé de l’argent ? Votre facture AWS dit le contraire.

On vous a vendu le cloud comme une économie, mais votre facture AWS prouve que vous payez pour de la complexité invisible. On se fait lobotomiser par les coûts cachés, ces petits frais qui s’accumulent dans l’ombre pendant qu’on admire nos dashboards. Le vrai problème n’est pas le prix à la demande des instances, c’est l’architecture bancale qu’on traîne depuis le début. Et le sale boulot de l’optimisation, personne ne veut le faire.

Pourquoi on se fait avoir ?

Le cloud, c’est une usine à gaz magnifique. On y migre nos applis, on active des services, et on oublie que chaque décision d’architecture a un prix caché. AWS ne vous facture pas seulement pour les ressources que vous utilisez, mais aussi pour celles que vous gaspillez, pour les failles de sécurité que vous n’avez pas colmatées, et pour les pannes que votre mauvaise conception provoque. C’est comme si vous payiez un loyer pour un appartement dont vous n’utilisez que la moitié des pièces, en plus de financer les serrures défaillantes et les fuites d’eau.

Le framework Well-Architected d’AWS existe justement pour ça. Il vous donne une boussole pour naviguer dans ce bazar. Mais attention, ce n’est pas une solution magique. C’est un guide, pas un remède. Il vous force à regarder en face les six piliers de votre architecture : l’excellence opérationnelle, la sécurité, la fiabilité, l’efficacité des performances, l’optimisation des coûts et la durabilité. Ignorer un seul de ces piliers, c’est comme construire une maison sur du sable. Vous le paierez, tôt ou tard.

Les trois gouffres financiers invisibles

Trois domaines vous ruinent discrètement : la sécurité, la disponibilité et l’efficacité des ressources. Prenons la sécurité. Une mauvaise configuration, un accès en trop, et c’est le jackpot pour un hacker. Le coût d’une brèche ne se limite pas à la perte de données. C’est la réputation, les amendes, les clients qui fuient. AWS vous alerte sur les risques critiques (HRI) via son outil Well-Architected. Les ignorer, c’est jouer à la roulette russe avec votre business.

Ensuite, la disponibilité. Une panne, même de quelques minutes, ça coûte une fortune en productivité perdue et en SLA non respectés. Votre équipe ne peut pas bosser, vos clients sont furieux, et vous devez payer des consultants pour réparer la catastrophe. Enfin, l’efficacité des ressources. Combien de serveurs tournent pour rien le week-end ? Combien de bases de données sont surdimensionnées “au cas où” ? On provisionne large par peur, et on paie pour du vide. La facture est salée.

Le Well-Architected Framework : votre boussole

Le framework n’est pas qu’un checklist théorique. C’est un processus concret. Il vous pousse à auditer votre architecture, à identifier les risques, et à corriger le tir. Prenons un exemple : la sécurité. Le framework vous dit de suivre le principe du moindre privilège. En clair, ne donnez à vos utilisateurs et services que les permissions strictement nécessaires. C’est simple à dire, mais en pratique, c’est le bazar. Combien de rôles IAM ont des droits administrateur par flemme ?

AWS vous donne des outils pour ça. L’outil Well-Architected vous pose des questions et vous classe les risques en critiques (HRI), moyens (MRI) ou faibles (LRI). Un HRI en sécurité, c’est une porte ouverte aux attaques. Le framework vous guide aussi sur la protection des données (chiffrement partout), la protection de l’infrastructure (segmentation réseau) et la surveillance. Mais attention, c’est à vous de faire le boulot. AWS ne le fera pas à votre place.

En pratique : chasser les coûts cachés

Passons aux choses sérieuses. Voici un exemple concret pour optimiser les coûts de calcul. Imaginons une application qui n’est utilisée que pendant les heures de bureau. Pourquoi payer une instance EC2 24h/24 ? On peut utiliser des instances Spot ou planifier l’arrêt des instances la nuit.

Voici un snippet de code Terraform pour planifier l’arrêt d’une instance EC2 la nuit et le week-end. C’est un début, mais ça peut économiser jusqu’à 70% des coûts de calcul.

resource "aws_cloudwatch_event_rule" "stop_instances" {
  name                = "stop-instances-nights-weekends"
  description         = "Arrête les instances la nuit et le week-end"
  schedule_expression = "cron(0 19 ? * MON-FRI *)" # 19h du lundi au vendredi
}

resource "aws_cloudwatch_event_target" "stop_instances" {
  rule      = aws_cloudwatch_event_rule.stop_instances.name
  target_id = "StopEC2Instances"
  arn       = "arn:aws:automatisations:${var.region}:${data.aws_caller_identity.current.account_id}:automation-definition/AWS-StopEC2Instances:$DEFAULT"
  role_arn  = aws_iam_role.ec2_automation.arn

  input = jsonencode({
    InstanceIds = aws_instance.app[*].id
  })
}

Autre exemple : les snapshots EBS. On en crée, on les garde, et on oublie. Un script simple pour nettoyer les vieux snapshots peut réduire la facture de stockage.

#!/bin/bash
# Supprime les snapshots EBS de plus de 30 jours
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[?StartTime<`2024-01-01`].SnapshotId' --output text | \
xargs -I {} aws ec2 delete-snapshot --snapshot-id {}

Et si on arrêtait de payer pour la complexité ?

Le vrai enjeu n’est peut-être pas de réduire la facture, mais de décider combien on est prêt à payer pour ne plus gérer l’infrastructure. Le cloud nous a débarrassé des serveurs physiques, mais il nous a donné un nouveau monstre : la complexité opérationnelle. Le framework Well-Architected est un antidote, mais il demande du temps, de la compétence, et une volonté de faire le ménage. La question est : êtes-vous prêt à investir dans cette rigueur, ou préférez-vous continuer à payer pour vos erreurs ? La balle est dans votre camp.