Comment aller chercher des crédits AWS après une panne

Crédits SLA, crédits d’overspend et savoir quand ça ne vaut pas la peine

Lorsqu’une panne AWS survient, il n’y a pas de moment pour réfléchir. Il n’y a pas de discussion sur les crédits. Il y a une seule priorité : remettre les services en ligne.

Les alertes s’enchaînent. Les tableaux de bord virent au rouge. Les messages s’accumulent dans Slack, souvent plus vite qu’on ne peut y répondre. Les équipes avancent rapidement, non pas parce que c’est élégant, mais parce que les clients attendent.

Les crédits viennent beaucoup plus tard. Et c’est exactement comme ça que ça doit se passer.

Ce n’est qu’une fois les systèmes stabilisés que la question finit par émerger. Combien cette panne nous a-t-elle réellement coûté? Et est-ce possible d’en récupérer une partie?

Chez Unicorne, nous avons accompagné nos clients lors de pannes pour savoir que la réponse est rarement évidente. Parfois, les crédits valent l’effort. Parfois, non. Tout dépend de la façon dont AWS mesure l’indisponibilité, de l’impact réel sur les coûts et du temps requis pour monter un dossier solide.

Gérer la panne, puis comprendre ce que AWS mesure réellement

Une fois le service rétabli, les données validées et les systèmes en aval confirmés comme fonctionnant normalement, il est temps de se pencher sur l’accord de niveau de service (SLA) d’AWS.

Les SLA d’AWS sont propres à chaque service et reposent sur des métriques précises. Ils ne mesurent pas la durée pendant laquelle vos clients ont été affectés, mais plutôt le temps pendant lequel AWS considère qu’un service a été indisponible selon ses propres indicateurs internes.

Cette distinction est beaucoup plus importante qu’on ne le croit.

Lors de la panne AWS d’octobre, plusieurs applications clientes ont été impactées pendant plusieurs heures. Pourtant, selon les métriques d’AWS, les services que nous avons observés, soit DynamoDB et Lambda, ont été officiellement considérés comme indisponibles pendant environ deux heures et demie, entre 6 h 50 et 9 h 20 UTC, même si l’incident global a duré près de 14 heures.

Sur le plan contractuel, cela représentait une disponibilité mensuelle d’environ 99,66 %. Ce chiffre était inférieur au seuil SLA, mais il ne reflétait en rien la réalité vécue sur le terrain.

C’est dans cet écart que naissent la plupart des malentendus.

Crédits SLA et crédits d’overspend

Une fois ce cadre compris, il faut distinguer les types de crédits possibles.

Les crédits SLA s’appliquent lorsque AWS ne respecte pas ses engagements contractuels pour un service donné, comme AWS Lambda ou Amazon DynamoDB. Chaque service possède son propre SLA et sa méthode de calcul. Les crédits ne s’appliquent qu’au service officiellement reconnu comme indisponible.

Si le service A est en panne et que le service B cesse de fonctionner par effet domino, seuls les crédits du service A peuvent être demandés.

Les crédits d’overspend fonctionnent autrement. Ils ne sont pas contractuels et ne sont jamais automatiques. Ils servent à compenser des coûts supplémentaires générés par la panne, comme des tentatives répétées, une montée en charge imprévue, une explosion des logs ou une utilisation excessive des outils de monitoring.

Nous avons observé ce phénomène avec des retries Lambda, l’instanciation inutile de ressources et une hausse importante des coûts CloudWatch causée par des boucles d’erreurs.

Dans ce cas, la démonstration repose entièrement sur la capacité du client à prouver le lien entre la panne et les dépenses supplémentaires.

La question clé : est ce que ça en vaut la peine?

C’est souvent la question la plus difficile à poser.

Toutes les pannes ne justifient pas une demande de crédit. Dans certains cas, les économies potentielles sont limitées. Dans d’autres, le travail requis pour collecter les données et préparer la documentation est considérable.

Les crédits ne sont pas gratuits. Ils impliquent un arbitrage clair entre l’effort investi et le gain réel. Savoir reconnaître quand ce n’est pas rentable fait partie d’une approche mature.

Comment nous avons procédé concrètement

Lorsque la décision est prise d’aller de l’avant, le facteur temps devient critique. Même si AWS accorde généralement deux périodes de facturation pour déposer une demande, agir rapidement facilite grandement le processus. Il nous faut des preuves pour justifier la demande et plus on attend, plus il est difficile de fouiller dans les logs pour trouver l’information pertinente. Il est importante de rester organiser pour être efficace dans notre demande de crédits.

Dès la semaine de la panne, nous analysons les exigences AWS et rassemblons les métriques applicatives et d’infrastructure nécessaires. Nous distinguons clairement ce que nous possédons déjà de ce qui doit être extrait directement d’AWS.

Plutôt que de repartir de zéro, nous réutilisons des scripts de monitoring existants pour produire un rapport clair et ciblé. L’objectif est la compréhension, pas la surcharge d’information.

Lors de la soumission, la concision est essentielle. En période de panne majeure, les délais de réponse peuvent être plus longs. De notre expérience, il est plus efficace de regrouper les demandes de support ensemble pour améliorer l’efficacité du procesus et reduire le nombre d’acteurs.

Comment analyser l’overspend efficacement

Pour les crédits d’overspend, AWS Cost Explorer est central. Nous comparons les coûts avant, pendant et après la panne, et lorsque possible, nous utilisons le mois précédent comme référence.

Cette méthode permet d’isoler les dépenses anormales directement liées à l’incident et d’appuyer la demande sur des données solides et des faits concrets, afin de démontrer que l’augmentation des coûts ne provient pas de nos opérations.

En conclusion

Les crédits AWS ne sont ni automatiques ni garantis. L’erreur la plus fréquente consiste à croire qu’une panne applicative entraîne systématiquement une compensation significative.

Une analyse post-incident rigoureuse, une évaluation réaliste du rapport effort-bénéfice et une approche disciplinée des métriques font toute la différence. Parfois, ça en vaut la peine. Parfois, non.

Dans un cas concret, pour un client, nous avons réussi à récupérer seulement 50 $ en crédits d’overspend, alors que la demande liée au SLA a permis d’obtenir entre 500 $ et 1 000 $. À l’inverse, l’analyse nécessaire pour justifier l’overspend a demandé beaucoup plus de temps et d’efforts que le montant récupéré.

Savoir faire cette distinction, c’est ce qui transforme une panne en apprentissage durable plutôt qu’en exercice coûteux et peu rentable.