Chaque discussion « faut-il quitter AWS » à laquelle j'ai assisté commence de la même façon : un tableau comparant le coût du matériel par vCPU au tarif à la demande. Ce tableau a généralement raison, et c'est pourtant la partie la moins importante de la décision. Le vrai coût de gérer sa propre infrastructure n'apparaît pas dans une comparaison de prix au cœur. Il se révèle huit mois plus tard, à 3h du matin, quand un disque tombe en panne d'une façon que votre runbook n'avait pas prévue.
Voici la liste que j'utilise vraiment avec mes clients quand ils hésitent entre un cloud privé, du Kubernetes sur serveurs nus, ou rester chez un hyperscaler. Elle n'est pas exhaustive, et je continuerai à la compléter au fil des nouveaux modes de défaillance qu'on rencontre, parce qu'une liste écrite une fois pour toutes et jamais retouchée cesse d'être utile dès la première fois qu'elle se trompe.
La checklist
| Point à considérer | Ce que ça implique concrètement | Ce que ça vous coûte si vous l'ignorez |
|---|---|---|
| Pannes de stockage | Votre couche de stockage (Ceph, NVMe local, peu importe) a ses propres modes de défaillance, ses temps de reconstruction et ses procédures de récupération, qui n'ont rien à voir avec ceux de votre application | Perdre un nœud pendant une fenêtre de reconstruction et découvrir que vos calculs de redondance supposaient une vitesse de reconstruction que vous n'avez pas réellement |
| Délais de restauration des sauvegardes | Les sauvegardes existent ; les tests de restauration, eux, rarement | Répondre « on a des sauvegardes » pendant un incident, et se retrouver avec une restauration de 11 heures parce que personne ne l'avait jamais chronométrée |
| Chemins de mise à niveau | Kubernetes, votre CNI, votre pilote de stockage et votre OS ont chacun leur propre rythme de sortie et leur propre matrice de compatibilité | Un correctif de sécurité que vous ne pouvez pas appliquer sans mettre à niveau trois autres composants que vous ne comptiez pas toucher ce trimestre |
| Marge de capacité | Vous êtes désormais responsable d'acheter en amont de la demande, plutôt que de scaler automatiquement en fonction d'elle | Un délai d'approvisionnement matériel de six à douze semaines, entre vous et le pic de trafic qui est en train de se produire maintenant |
| Astreinte | Quelqu'un doit désormais assumer le matériel, pas seulement l'application | Un appel à 2h du matin pour une alimentation défaillante, envoyé aux trois mêmes ingénieurs qui géraient déjà l'astreinte applicative |
| Sortie de données (egress) | Sortir ses données de sa propre infrastructure est souvent la chose qui devient vraiment moins chère en quittant AWS, mais seulement si vous avez vraiment repensé votre architecture autour de ça | Construire une architecture hybride qui continue de faire transiter le trafic par le fournisseur cloud que vous essayiez justement de quitter pour faire des économies |
| Latence entre datacenters | Les hypothèses de votre application sur « la base de données est proche » n'étaient peut-être vraies que parce que vous étiez dans une seule région AWS | Une régression de latence en p99 qui apparaît en production et nulle part en staging, parce que le staging n'a jamais traversé un vrai lien WAN |
| Conformité | Votre posture de conformité reposait en partie sur la certification SOC 2 d'AWS, et vous n'en héritez plus du tout en migrant sur vos propres baies | Une remarque d'audit qui suppose l'existence de contrôles qui, avant, vivaient entièrement dans le modèle de responsabilité partagée de quelqu'un d'autre |
Les points qui piègent vraiment les équipes
Le stockage, c'est celui sur lequel je parierais le plus volontiers qu'il est sous-estimé. Les équipes dimensionnent leur cluster de stockage pour la capacité et les IOPS, font tourner les chiffres, et considèrent le sujet clos. Ce qu'elles ne font pas, c'est simuler une reconstruction sous charge de production. Un Ceph qui reconstruit un OSD en panne pendant que votre application continue de taper dessus en lecture ne se comporte absolument pas comme un Ceph au repos, et la première fois que la plupart des équipes l'apprennent, c'est lors d'une vraie panne, pas d'un test.
Les délais de restauration des sauvegardes arrivent juste derrière, pour une raison un peu bête : il est facile de vérifier qu'une sauvegarde existe, beaucoup moins qu'elle fonctionne. Un aws backup ou un pg_dump nocturne qui s'affiche en vert dans votre monitoring vous dit que la sauvegarde a tourné. Il ne vous dit rien sur le temps que prend une restauration, ni sur le fait que la procédure de restauration corresponde encore à votre schéma actuel. Je demande à mes clients à quand remonte leur dernière restauration réelle sur un environnement propre, et dans environ la moitié des cas, la réponse honnête est « jamais ».
La marge de capacité, c'est celle qui prend les gens de court parce que ce n'est pas vraiment un problème technique : c'est un changement de qui porte la responsabilité d'une décision jusque-là invisible. Chez un hyperscaler, la capacité est le problème de quelqu'un d'autre, que vous payez au prix fort pour ne pas avoir à y penser. Sur votre propre matériel, manquer de capacité veut dire un bon de commande, un délai de livraison, et une personne dont le travail consiste désormais à surveiller une courbe et à commander des serveurs avant d'en avoir besoin. J'ai vu des équipes se tromper dans l'autre sens : surprovisionner de 3x par peur, puis, sans le vouloir, justifier tout l'argument du « on aurait aussi bien pu rester chez AWS ».
La sortie de données (l'egress) est le cas bizarre : c'est vraiment le meilleur argument pour quitter AWS, et c'est aussi celui qui se fait défaire en silence le plus facilement. J'ai vu un client construire toute une infrastructure privée spécifiquement pour échapper aux coûts d'egress, puis continuer de faire transiter une partie de son pipeline de données par son ancien compte AWS, parce qu'une intégration tierce ne savait parler qu'à S3. Six mois plus tard, il payait de l'egress sur deux clouds à la fois et ne s'en était même pas rendu compte.
La conformité mérite plus d'attention qu'elle n'en reçoit dans ces discussions, parce que c'est celle où le coût n'est pas opérationnel, il est organisationnel. Chez AWS, une bonne partie de votre discours de conformité tient en une phrase : « AWS est certifié SOC 2 Type II, voici le rapport. » Migrez vers votre propre infrastructure, et cette phrase disparaît de votre réponse d'audit. Contrôles d'accès physique, surveillance environnementale, procédures de mise au rebut du matériel : quelqu'un dans votre équipe doit désormais documenter et prouver tout ça, et cette personne n'est en général identifiée qu'une fois l'audit déjà programmé.
À quoi sert cette liste
Rien de tout cela n'est un argument contre le cloud privé. J'ai mené cette exacte migration pour des clients où c'était clairement la bonne décision, et où la facture AWS qu'ils payaient jusque-là était franchement déraisonnable au vu de leur charge de travail. C'est un argument contre le fait de prendre la décision sur la seule base d'une comparaison de coût matériel, parce que chaque ligne du tableau ci-dessus représente un coût opérationnel bien réel qu'un tableau comparant des euros par cœur ne vous montrera jamais.
Si vous êtes en train de peser cette décision, la démarche honnête consiste à reprendre chaque ligne et à noter, précisément, qui dans votre équipe en est responsable aujourd'hui, et qui en serait responsable après la bascule. Si une ligne n'a personne pour la porter, ce n'est pas une raison de rester chez AWS. C'est simplement le vrai coût de la décision que vous êtes sur le point de prendre, et mieux vaut le connaître avant qu'après.