Une application existante a été migrée vers une fonction Lambda qui effectue de nombreux appels d'API tiers pour extraire des données en fin de mois, puis les traite pour produire des rapports mensuels. Le fournisseur tiers a introduit des limites : un nombre fixe d'appels d'API par minute et par jour (fourni dans les en-têtes de réponse), renvoyant des erreurs lorsque les limites sont dépassées. L'exécution complète du traitement des données peut désormais prendre des jours si l'application doit ralentir pour éviter de dépasser les limites. Quelle est la manière la plus efficace sur le plan opérationnel de refactoriser ce workflow serverless pour respecter ces limites ?

AWS Step Functions est la solution la plus efficace car elle permet d'orchestrer des workflows complexes et de gérer les échecs de manière robuste. L'utilisation d'un état Wait (attente) permet de mettre en pause l'exécution du workflow pendant une durée spécifiée après avoir détecté un dépassement de limite de débit (via les échecs d'API), puis de réessayer l'appel. Cela garantit que les limites du fournisseur tiers sont respectées sans intervention manuelle et que le traitement se poursuit automatiquement. Envoyer les tâches à une file d'attente SQS et interroger avec Lambda est une solution viable mais plus complexe à gérer pour le contrôle précis du débit et la logique de réessai conditionnel. Créer une métrique CloudWatch pour arrêter la fonction Lambda est trop drastique et ne permet pas de reprendre le traitement de manière fluide. Utiliser Kinesis Data Firehose pour regrouper les requêtes n'est pas adapté ici, car il s'agit de gérer des appels sortants avec des limites de débit, non d'ingérer des données en continu.