AWS Batch et Step Functions ne s'opposent pas sur le même axe : l'un trouve des machines et exécute des traitements, l'autre décide de l'étape suivante et conserve l'état entre les étapes. La règle tient en une phrase : si la difficulté est d'obtenir du CPU, du GPU ou des heures pour un seul traitement, c'est AWS Batch ; si la difficulté est l'enchaînement, les reprises et les branchements autour des traitements, c'est Step Functions. Batch met des jobs conteneurisés en file et dimensionne la flotte EC2 ou Fargate à votre place. Step Functions coordonne, rattrape les échecs et fait circuler les données. La plupart des chaînes réelles utilisent les deux : une machine à états qui soumet un job Batch et attend son verdict.
AWS Batch et Step Functions répondent-ils à la même question ?
Non, et mieux vaut lever l'ambiguïté avant de comparer des fonctionnalités. AWS Batch est un ordonnanceur de traitements conteneurisés : vous soumettez un job, il entre dans une file, et un environnement de calcul provisionne les instances EC2 ou les tâches Fargate nécessaires. Batch ignore totalement ce qui vient après. Step Functions fait l'inverse : il sait ce qui vient après, ce qu'il faut faire quand cette étape échoue et quelles données passent d'un état au suivant, mais il n'exécute aucun calcul métier lui-même.
Une précision de vocabulaire, car les recherches confondent souvent les deux : une machine à états n'est pas une alternative à Step Functions. La machine à états est la ressource que vous décrivez en Amazon States Language ; Step Functions est le service qui la stocke et l'exécute, et une exécution en est un passage. Opposer « machine à états » et « Step Functions », c'est opposer la partition à l'orchestre qui la joue.
Que fait AWS Batch qu'une fonction Lambda ne fera pas ?
Quatre choses, et chacune suffit à faire sortir une charge du calcul serverless.
- La durée. Un job Batch tourne aussi longtemps que le travail l'exige. Lambda s'arrête à 15 minutes, et une agrégation nocturne ou un entraînement de modèle ne négocie pas avec ce plafond.
- La taille. Les environnements de calcul atteignent des familles d'instances sans équivalent chez Lambda : beaucoup de vCPU, des centaines de gigaoctets de mémoire, des GPU pour l'entraînement et l'inférence.
- Votre image. Un job est une image de conteneur que vous construisez : dépendances natives, pilotes CUDA, builds ffmpeg, piles scientifiques Python ou R voyagent avec, au lieu d'être pliées dans un format de packaging.
- Les liens entre traitements. Les array jobs transforment une soumission en milliers d'enfants indexés, et les dépendances entre jobs font attendre l'étape de réduction jusqu'au dernier fragment de l'étape de map, y compris index par index entre deux arrays.
Batch apporte aussi une sémantique de file qu'une architecture événementielle devrait bricoler : plusieurs files de priorités différentes devant une capacité partagée, et des politiques de partage équitable pour qu'un locataire qui déverse dix mille jobs n'affame pas les autres jusqu'au matin.
Quand Step Functions suffit-il tout seul ?
Plus souvent qu'on ne le croit. Ce que l'on appelle « traitement par lots » est souvent une grande quantité de petits éléments indépendants, et c'est précisément la cible de Distributed Map. L'état lit les éléments directement depuis un préfixe S3, un objet JSON ou CSV, ou un inventaire S3, puis lance des exécutions enfants en parallèle, jusqu'à dix mille à la fois. ItemBatcher regroupe les éléments pour que chaque invocation fasse du vrai travail, ToleratedFailurePercentage évite qu'un enregistrement toxique fasse tomber la totalité, et un ResultWriter agrège les résultats vers S3.
Si un élément tient dans une fonction Lambda, sous le plafond des 15 minutes et dans la mémoire allouable, aucun cluster ne se justifie : ni file de jobs, ni environnement de calcul, ni image à reconstruire à chaque montée de dépendance. Nous traitons le volet orchestration de ce schéma dans notre article sur l'orchestration Step Functions, et la question du dimensionnement du calcul dans Fargate ou Lambda.
Cluster nécessaire, ou simplement un meilleur workflow ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →AWS Batch, Step Functions ou Lambda seule : le comparatif
Lisez ce tableau en colonnes plutôt qu'en lignes. Chaque colonne répond à une question différente sur la même chaîne de traitement, d'où des scénarios gagnants qui se recouvrent à peine.
| Critère | AWS Batch | Step Functions | Lambda seule |
|---|---|---|---|
| Unité de travail | Un job conteneurisé soumis à une file | Une exécution composée d'états | Une invocation de fonction |
| Limite de durée | Aucune imposée par le service ; le job va au bout | Jusqu'à un an en Standard, quelques minutes en Express | 15 minutes, sans appel |
| État | Aucun : les données transitent par S3, une base ou les paramètres du job | Porté par l'exécution, dans une limite de taille de payload par état | Ce que l'appelant fournit et ce que le handler retourne |
| Reprises | Nombre de tentatives par job, avec évaluation du code de sortie | Par état, avec backoff, jitter et routes Catch typées | Décidées par la source d'événements ; handler idempotent obligatoire |
| Calcul à gérer | Environnements de calcul : types d'instances, Spot, bornes de scaling | Aucun | Aucun |
| Quand il gagne | Traitements longs, lourds, GPU ou riches en dépendances, avec priorités de file | Enchaînement, branchements, attentes humaines, fan-out sur beaucoup d'éléments | Petits éléments qui tiennent dans le runtime et finissent vite |
Comment soumettre un job Batch depuis une machine à états et l'attendre ?
Avec l'intégration de service synchrone. L'état soumet le job et reste ouvert jusqu'à ce que Batch annonce le succès ou l'échec : le workflow connaît le résultat sans boucle de polling maison. L'intégration Batch remonte le statut du job dans la machine à états, où les politiques de retry et les routes Catch s'appliquent comme partout ailleurs.
{
"Comment": "Soumettre un array job Batch et attendre sa fin",
"StartAt": "RunTransform",
"States": {
"RunTransform": {
"Type": "Task",
"Resource": "arn:aws:states:::batch:submitJob.sync",
"Parameters": {
"JobName": "transformation-quotidienne",
"JobQueue": "arn:aws:batch:eu-west-3:123456789012:job-queue/etl",
"JobDefinition": "arn:aws:batch:eu-west-3:123456789012:job-definition/transform:7",
"ArrayProperties": { "Size": 120 },
"ContainerOverrides": {
"Environment": [
{ "Name": "INPUT_PREFIX", "Value.$": "$.inputPrefix" }
]
}
},
"Retry": [
{
"ErrorEquals": ["Batch.AWSBatchException"],
"IntervalSeconds": 30,
"MaxAttempts": 3,
"BackoffRate": 2
}
],
"Catch": [
{ "ErrorEquals": ["States.ALL"], "Next": "NotifierEchec" }
],
"Next": "PublierResultats"
}
}
}Deux habitudes rendent ce montage tenable en production. Faites circuler des pointeurs, pas des données : une clé S3 plutôt que le contenu, car la taille du payload d'état est plafonnée et un conteneur lit S3 bien plus confortablement qu'un blob JSON. Et rendez le job idempotent sur ses entrées, car une nouvelle tentative relance le conteneur depuis la première ligne, pas depuis le point d'arrêt.
Environnement de calcul Fargate ou EC2, et où placer le Spot ?
Les environnements Fargate ne laissent aucune instance à patcher, aucun groupe de scaling à régler, et isolent chaque job dans sa tâche, au prix d'un tarif par vCPU et par gigaoctet plus élevé que la capacité EC2 équivalente, d'un plafond de vCPU et de mémoire par job, et de l'absence de GPU et de jobs multi-nœuds. Prenez Fargate pour les traitements courts à moyens de taille ordinaire, surtout quand le travail arrive de façon irrégulière et qu'un cluster tournerait à vide entre deux vagues.
Les environnements EC2 couvrent tout le reste : GPU, familles d'instances avec NVMe local, mémoire au-delà de ce que propose Fargate, et jobs parallèles répartis sur plusieurs instances. Ils ouvrent aussi le Spot, et l'ordonnanceur de Batch est construit autour de l'interruption : un traitement qui sait reprendre sur point de contrôle, ou que l'on peut relancer sans dommage, achète le même travail avec une remise importante sur le tarif à la demande. Un montage courant garde une petite file à la demande pour ce qui doit finir cette nuit et envoie le reste sur une file Spot avec davantage de tentatives.
Quelle forme de coût pour Batch et pour Step Functions ?
Des formes, pas des chiffres. AWS Batch n'ajoute aucun tarif de service : vous payez les instances EC2 ou les tâches Fargate qui exécutent les jobs, plus le stockage et le transfert de données. C'est pourquoi la dépense se cache dans la capacité inactive, les instances surdimensionnées et un scale-down paresseux. Les tarifs du moment se lisent sur la page de tarification AWS Batch et sur celle de Fargate.
Step Functions facture sur une autre forme : à la transition d'état pour les workflows Standard, au nombre de requêtes, à la durée et à la mémoire pour les Express, comme détaillé sur la page de tarification Step Functions. Un workflow qui soumet un seul job Batch ne coûte presque rien, car une longue attente synchrone reste une transition unique. Un Distributed Map sur un million d'éléments est une autre affaire : chaque exécution enfant compte, et regrouper les éléments avec ItemBatcher devient autant une décision de coût qu'une décision de débit.
Check-list de décision
- Traitement de plus de 15 minutes, GPU, grosse mémoire, ou image bourrée de dépendances natives : AWS Batch.
- Beaucoup de petits éléments indépendants posés dans S3, chacun sous le plafond Lambda : Distributed Map, sans cluster.
- Plusieurs traitements avec un ordre, des conditions, des validations ou des branches d'échec : Step Functions, quel que soit ce qui exécute les étapes.
- Les deux à la fois, cas le plus fréquent : une machine à états qui appelle l'intégration Batch synchrone.
- Priorités de file ou équité entre locataires sur une capacité partagée : files Batch et politique de partage équitable.
- Arrivées irrégulières et tailles ordinaires : Fargate. Travail lourd, long ou interruptible : EC2 avec Spot et plus de tentatives.
- Dans tous les cas : jobs idempotents, pointeurs S3 plutôt que payloads, et une alarme sur le chemin d'échec. D'autres arbitrages de ce type sont réunis dans nos guides de décision AWS.