AWS vous aime. Azure vous aime. GCP vous aime. Et une fois que vous êtes dedans, ils augmentent les prix. Le vendor lock-in est le piège le plus coûteux du cloud. Voici comment l'éviter — sans tomber dans le piège inverse du multi-cloud.
Les trois niveaux de lock-in
Niveau 1 : Infrastructure. VMs, stockage, réseau. C'est le lock-in le plus faible. Vous pouvez migrer d'AWS EC2 vers Azure VM en quelques jours. Les outils sont similaires.
Niveau 2 : Services managés. RDS, Lambda, SQS, DynamoDB. C'est le lock-in moyen. DynamoDB n'existe que chez AWS. Si vous voulez migrer, vous devez réécrire votre code. Lambda n'a pas d'équivalent exact chez Azure.
Niveau 3 : Services spécialisés. SageMaker, Rekognition, Textract. C'est le lock-in fort. Ces services sont uniques à un fournisseur. Migrer signifie réécrire toute l'architecture.
Le coût réel du lock-in
Le lock-in ne coûte pas cher au début. Au contraire, les services managés réduisent les coûts de gestion. Mais avec le temps, deux choses se passent :
1. Votre volume augmente, et les prix augmentent avec. AWS ne négocie les réductions que si vous avez une alternative crédible.
2. Le fournisseur augmente ses prix. AWS a augmenté le prix de NAT Gateway en 2024. Azure a augmenté le prix de SQL Database. Vous ne pouvez pas partir, donc vous payez.
Comment éviter le lock-in sans faire du multi-cloud
Le multi-cloud est souvent présenté comme la solution. C'est un piège. Le multi-cloud double la complexité, double les coûts, et réduit la profondeur technique de votre équipe. Vous connaissez mal deux clouds au lieu de bien connaître un.
La vraie solution : l'abstraction au bon niveau.
- Utilisez Kubernetes (EKS/AKS/GKE) au lieu de Lambda. Kubernetes est portable.
- Utilisez PostgreSQL (RDS/Cloud SQL) au lieu de DynamoDB. PostgreSQL est portable.
- Utilisez Kafka (MSK/Event Hubs) au lieu de SQS. Kafka est portable.
- Utilisez Terraform pour votre IaC. Terraform est multi-cloud.
L'idée n'est pas d'être multi-cloud. C'est d'être capable de migrer si nécessaire. La différence est cruciale.
Quand le lock-in est acceptable
Tout lock-in n'est pas mauvais. Si vous utilisez un service spécialisé (SageMaker, Rekognition) qui vous fait gagner 6 mois de développement, le lock-in vaut le coup. La question est : combien de temps pour réécrire si nécessaire ? Si c'est 2 semaines, acceptez le lock-in. Si c'est 6 mois, évitez-le.
Le vendor lock-in est un risque business, pas un péché technique. Gérez-le comme un risque : identifiez-le, évaluez-le, décidez consciemment.
Et vous ?
Vous êtes locked-in sur AWS ou Azure ? Aprilium audite votre dépendance cloud et identifie les abstractions qui vous rendraient portable — sans faire du multi-cloud.
Auditer ma dépendance