Neuf paires de services AWS qu'on confond — et la question qui tranche

La confusion autour des services AWS n’est pas un problème de mémoire. Elle vient de ce que les noms décrivent une technologie, jamais une décision. « Elastic Container Service » et « Elastic Kubernetes Service » se ressemblent parce qu’ils font effectivement la même chose : faire tourner des conteneurs. Ce qui les sépare n’est pas dans le nom.

L’outil utile n’est donc pas un tableau comparatif de plus — il en existe des centaines, et personne ne les retient. C’est une question par paire, dont la réponse tranche. Voici les neuf que j’utilise, et surtout ce que le mauvais choix coûte une fois en production, parce que c’est là que la différence cesse d’être théorique.

Ce n’est pas un relevé de terrain : c’est une grille de décision, sans dépôt associé.

01 — EC2 / Lambda : qui exploite le serveur ?

Avec EC2, la machine est à vous : le système, les correctifs, le dimensionnement, la surveillance. Avec Lambda, AWS exploite l’exécution ; vous ne fournissez qu’une fonction et vous payez à l’invocation.

Ce que ça change en exploitation. Une instance EC2 facture quand elle ne fait rien. Une fonction Lambda ne facture rien au repos, mais elle plafonne à quinze minutes d’exécution, démarre à froid, et déplace votre charge d’exploitation ailleurs : limites de concurrence, traçage distribué, gestion des relances.

Le vrai discriminant n’est ni la mode ni le prix affiché, c’est le cycle d’utilisation.

• EC2 — une instance qui tourne en permanence
• Lambda — facturé à l'invocation

C’est exactement la même courbe qui décide, plus bas, entre SageMaker et Bedrock. Deux paires sur neuf se réduisent à cette seule question.

02 — ECS / EKS : avez-vous besoin de Kubernetes ?

Les deux orchestrent des conteneurs. ECS est l’ordonnanceur d’AWS : peu de concepts, intégration native avec IAM, les répartiteurs de charge et CloudWatch. EKS est un Kubernetes géré : portable, immense écosystème, et toutes les notions qui vont avec.

Ce que ça change en exploitation. EKS ajoute une surface d’astreinte entière — montées de version du cluster, greffons, définitions de ressources personnalisées — et son plan de contrôle est facturé à l’heure, qu’il travaille ou non. ECS supprime cette couche.

La question n’est donc pas « lequel est le meilleur » mais avez-vous déjà les compétences Kubernetes, ou un besoin réel de portabilité ? Si la réponse est non deux fois, EKS vous fait payer un écosystème que vous n’utiliserez pas.

Au passage, une confusion fréquente : Fargate n’est pas un concurrent des deux. C’est un mode d’exécution disponible pour ECS comme pour EKS, dans lequel vous ne gérez plus les instances sous-jacentes. La question « ECS ou EKS » et la question « Fargate ou pas » sont indépendantes.

03 — S3 / EBS : des objets, ou un disque ?

S3 est un stockage d’objets : on y accède par une API HTTP, il n’y a pas de système de fichiers, la capacité est pratiquement illimitée et la durabilité annoncée est de onze neuf. EBS est un volume bloc attaché à une instance : il se comporte comme un disque, il a des caractéristiques d’IOPS, et on le formate.

Ce que ça change en exploitation. Le piège n’est pas l’API, c’est la portée. Un volume EBS vit dans une seule zone de disponibilité. Il disparaît avec elle. S3 est régional. C’est la différence qu’on découvre le jour d’une panne de zone, pas le jour du choix.

Et non, on ne monte pas S3 comme un système de fichiers POSIX pour s’épargner la question : c’est le rôle d’EFS, qui est un troisième service, avec un troisième modèle de coût.

04 — RDS / DynamoDB : comment allez-vous l’interroger ?

RDS gère des moteurs relationnels — PostgreSQL, MySQL et les autres. SQL, jointures, requêtes que vous n’aviez pas prévues. DynamoDB est un magasin clé-valeur géré, à la latence de quelques millisecondes annoncée, qui monte en charge horizontalement.

Ce que ça change en exploitation. Avec DynamoDB, les schémas d’accès se conçoivent avant d’écrire la première ligne. Une question métier imprévue six mois plus tard se paie en index secondaire, voire en refonte de table. Avec RDS, la même question se paie en une requête un peu lente.

Formulé autrement : DynamoDB échange la souplesse d’interrogation contre une montée en charge que RDS ne sait pas faire aussi bien. Si vous ne savez pas encore quelles questions vous poserez à vos données, vous n’êtes pas prêt pour DynamoDB.

05 — CloudFormation / Terraform : un seul fournisseur, ou plusieurs ?

C’est la paire où l’argument affiché est presque toujours le mauvais.

Ce que ça change en exploitation. La différence structurante n’est pas le multi-cloud, c’est le fichier d’état. CloudFormation n’en a pas : AWS conserve l’état des piles, il n’y a rien à sauvegarder, rien à verrouiller, rien à perdre. Terraform maintient un état que vous devez stocker, verrouiller et protéger — historiquement un compartiment S3 plus un verrou. Cet état devient un actif critique, avec ses sauvegardes et ses droits d’accès.

Et la vraie raison de choisir Terraform est rarement « nous sommes multi-cloud » — très peu d’organisations le sont réellement. C’est l’écosystème de fournisseurs : GitHub, Datadog, Cloudflare, votre fournisseur d’identité. Vous décrivez tout votre système, pas seulement la partie AWS. C’est un argument bien plus solide que celui du second cloud.

06 — SageMaker / Bedrock : entraîner un modèle, ou en appeler un ?

SageMaker est une plateforme pour construire, entraîner, ajuster et déployer vos modèles. Bedrock donne accès par API à des modèles de fondation déjà entraînés.

Ce que ça change en exploitation. Un point de terminaison SageMaker, c’est une instance : elle facture tant qu’elle est provisionnée, y compris la nuit et le week-end. Bedrock facture à l’appel.

Vous reconnaissez la courbe de la première figure. C’est la même décision, déplacée d’un étage : est-ce que la charge justifie une capacité permanente ?

07 — CloudWatch / CloudTrail : comment ça se comporte, ou qui a fait quoi ?

CloudWatch collecte des métriques, des journaux et déclenche des alarmes : le comportement de vos systèmes. CloudTrail enregistre les appels d’API adressés à AWS : qui a fait quoi, quand, depuis quelle identité.

Ce que ça change en exploitation. Pendant un incident, vous avez besoin des deux, pour deux questions différentes :

• « Pourquoi la latence a doublé à 3 h ? » → CloudWatch.
• « Qui a supprimé ce groupe de sécurité à 3 h ? » → CloudTrail.

Deux pièges classiques. CloudTrail n’est pas le journal de votre application : il ne voit que le plan de contrôle AWS. Et comme CloudTrail peut être livré dans CloudWatch Logs, on finit par croire qu’il s’agit du même produit — ce sont deux sources distinctes qui se croisent dans le même endroit de stockage.

08 — SNS / SQS : diffuser à plusieurs, ou mettre en file ?

SNS est un mécanisme de publication-abonnement : un message part vers tous les abonnés, en mode poussé. SQS est une file : les messages attendent qu’un consommateur vienne les chercher, et survivent en attendant.

Ce que ça change en exploitation. SQS vous donne un tampon : absorption des pointes, relances, file de rebut pour ce qui échoue. SNS n’en a pas — si un abonné est indisponible, le message est perdu au terme des tentatives.

Et surtout, la question est mal posée, parce que ces deux services ne s’opposent pas. Le motif standard les combine :

09 — Security Group / NACL : à état, ou sans état ?

Un groupe de sécurité s’attache à une ressource et tient l’état des connexions : si vous autorisez une requête entrante, la réponse repart automatiquement. Il n’accepte que des règles d’autorisation. Une liste de contrôle d’accès réseau s’attache à un sous-réseau, elle est sans état, elle est évaluée dans l’ordre des numéros de règle, et elle sait refuser explicitement.

Ce que ça change en exploitation. C’est le bug de 3 h du matin le plus classique d’AWS :

En pratique : gérez vos autorisations avec les groupes de sécurité, et ne descendez aux listes de contrôle réseau que lorsque vous avez besoin d’un refus explicite — bloquer une plage d’adresses, par exemple. C’est la seule chose qu’un groupe de sécurité ne sait pas exprimer.

Ce que je retiens

Le nom du service ne contient jamais la décision. « Elastic », « Simple », « Managed » décrivent une technologie. La question qui tranche porte toujours sur autre chose : qui exploite, quelle portée, quel cycle d’utilisation, quel modèle d’interrogation.

Deux des neuf paires se réduisent à la même courbe. EC2/Lambda et SageMaker/Bedrock posent la question du taux d’occupation. Une fois qu’on a vu ça, on n’a plus deux décisions à prendre mais une, appliquée deux fois.

Les pires surprises sont des questions de portée, pas de fonctionnalité. Un volume EBS enfermé dans une zone, une NACL qui ne laisse pas repartir la réponse, un état Terraform qu’on n’avait pas sauvegardé : aucune ne se voit sur une fiche produit.

Trois autres paires mériteraient le même traitement, et feront sans doute une suite : Secrets Manager et Parameter Store, ALB et NLB, EFS et FSx.