Augmenter le Timeout d'une Fonction Lambda AWS : Configuration et Limites

Votre fonction Lambda s'arrête brutalement après 3 secondes alors que votre traitement en nécessite 10 — c'est le comportement par défaut du timeout Lambda qui entre en jeu, et c'est l'une des premières surprises opérationnelles que rencontrent les équipes qui migrent des tâches batch ou des appels API lents vers une architecture serverless.

Résumé (TL;DR) : Augmenter le Timeout Lambda

Point clé Détail
Timeout par défaut 3 secondes
Timeout maximum 900 secondes (15 minutes)
Où le modifier Console AWS, AWS CLI, CloudFormation, SAM, Terraform
Erreur observée Task timed out after X.XX seconds dans CloudWatch Logs
Impact facturation La durée facturée inclut le temps jusqu'au timeout — un timeout mal configuré coûte de l'argent

Comment fonctionne le Timeout Lambda

Lambda exécute votre code dans un environnement d'exécution géré. Dès que l'invocation démarre, un compteur interne se déclenche. Si votre handler n'a pas retourné de réponse avant l'expiration du timeout configuré, Lambda interrompt l'exécution et émet une erreur Task timed out. Ce n'est pas un crash applicatif — c'est une interruption forcée par la plateforme.

Le timeout s'applique à chaque invocation individuelle, pas à la durée de vie totale de l'environnement d'exécution. Une fonction avec un timeout de 10 secondes peut être invoquée des milliers de fois — chaque invocation dispose de ses propres 10 secondes.

graph TD A["Événement déclencheur
(API GW, S3, EventBridge)"] --> B["Lambda démarre l'invocation
Compteur timeout démarré"] B --> C{"Handler terminé
avant timeout ?"} C -- Oui --> D["Réponse retournée
Invocation réussie"] C -- Non --> E["Timeout atteint
Interruption forcée"] E --> F["CloudWatch Logs:
Task timed out after X.XX seconds"]
  1. Invocation reçue : Lambda reçoit l'événement déclencheur (API Gateway, S3, EventBridge, etc.).
  2. Compteur démarré : Le chronomètre interne démarre dès le début de l'exécution du handler.
  3. Exécution normale : Si le handler retourne avant le timeout, l'invocation réussit.
  4. Timeout atteint : Si le compteur expire, Lambda force l'arrêt et écrit l'erreur dans CloudWatch Logs.

Augmenter le Timeout Lambda : Toutes les Méthodes

Il existe plusieurs façons de modifier le timeout selon votre outillage. Choisissez celle qui correspond à votre workflow de déploiement.

Via la Console AWS

C'est la méthode la plus rapide pour un ajustement ponctuel ou un diagnostic en production.

  1. Ouvrez la Console AWS Lambda et sélectionnez votre fonction.
  2. Cliquez sur l'onglet Configuration, puis sur Paramètres généraux.
  3. Cliquez sur Modifier.
  4. Dans le champ Timeout, entrez la valeur souhaitée (minutes et secondes).
  5. Cliquez sur Enregistrer.

Via AWS CLI

La CLI est indispensable pour automatiser la modification ou l'intégrer dans un pipeline CI/CD. La commande update-function-configuration est la bonne action ici — pas update-function-code.

aws lambda update-function-configuration \
  --function-name ma-fonction-lambda \
  --timeout 30 \
  --region us-east-1

La valeur --timeout est exprimée en secondes. Pour 15 minutes (maximum), utilisez --timeout 900.

Pour vérifier la configuration actuelle avant de modifier :

aws lambda get-function-configuration \
  --function-name ma-fonction-lambda \
  --region us-east-1 \
  --query 'Timeout'

Via AWS CloudFormation

🔽 Cliquer pour afficher le template CloudFormation 
Resources:
  MaFonctionLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: ma-fonction-lambda
      Runtime: python3.12
      Handler: index.handler
      Role: arn:aws:iam::123456789012:role/mon-role-lambda
      Timeout: 30
      Code:
        ZipFile: |
          def handler(event, context):
              return {'statusCode': 200}

Via AWS SAM

🔽 Cliquer pour afficher le template SAM 
Resources:
  MaFonctionLambda:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: python3.12
      Timeout: 30
      CodeUri: ./src/

Diagnostiquer une Erreur de Timeout Lambda

Avant d'augmenter aveuglément le timeout, confirmez que c'est bien un timeout et non une autre classe d'erreur. Le message dans CloudWatch Logs est sans ambiguïté :

REPORT RequestId: abc123  Duration: 3000.00 ms  Billed Duration: 3000 ms
Task timed out after 3.00 seconds

Si vous voyez Task timed out, c'est un timeout. Si vous voyez une stack trace Python, Java ou Node.js, c'est une exception applicative — augmenter le timeout ne résoudra rien.

Requête CloudWatch Logs Insights pour isoler les timeouts

Plutôt que de parcourir les logs manuellement, utilisez Logs Insights pour filtrer uniquement les invocations ayant expiré :

fields @timestamp, @message
| filter @message like /Task timed out/
| sort @timestamp desc
| limit 50

Exécutez cette requête via la Console CloudWatch Logs Insights ou via CLI :

aws logs start-query \
  --log-group-name /aws/lambda/ma-fonction-lambda \
  --start-time 1700000000 \
  --end-time 1700086400 \
  --query-string "fields @timestamp, @message | filter @message like /Task timed out/ | sort @timestamp desc | limit 50" \
  --region us-east-1
graph LR A["Erreur observée"] --> B["Vérifier CloudWatch Logs
Chercher 'Task timed out'"] B --> C["Mesurer Duration
dans le rapport REPORT"] C --> D["Augmenter timeout
via CLI ou Console"] D --> E["Surveiller les invocations
suivantes dans CloudWatch"] E --> F{"Timeout résolu ?"} F -- Oui --> G["Terminé"] F -- Non --> H["Vérifier timeout
du service appelant"]
  1. Vérifier les logs : Confirmer la présence du message Task timed out dans CloudWatch Logs.
  2. Mesurer la durée réelle : Regarder le champ Duration dans le rapport REPORT pour estimer le temps nécessaire.
  3. Augmenter le timeout : Configurer une valeur supérieure à la durée observée, avec une marge raisonnable.
  4. Surveiller après modification : Vérifier que les invocations suivantes se terminent sans timeout.

Le Piège Classique : Timeout et Intégrations Synchrones

Voici un scénario que j'ai vu plusieurs fois en production : la fonction Lambda est configurée avec un timeout de 29 secondes, mais les invocations continuent d'échouer à 29 secondes exactement. Le réflexe est d'augmenter encore le timeout Lambda — mais ce n'est pas là que se trouve le vrai problème.

Quand Lambda est invoquée via API Gateway (REST API ou HTTP API), API Gateway impose son propre timeout d'intégration, indépendant du timeout Lambda. Ce timeout d'intégration est de 29 secondes maximum pour API Gateway REST API et HTTP API — et il ne peut pas être augmenté.

Penser que le timeout Lambda est le seul compteur en jeu, c'est comme régler l'alarme de son téléphone sans savoir que quelqu'un d'autre a déjà coupé le courant avant. Deux systèmes, deux compteurs, deux points de défaillance.

Si votre traitement dépasse 29 secondes et passe par API Gateway, augmenter le timeout Lambda au-delà de 29 secondes n'apportera rien. Il faut repenser l'architecture : réponse asynchrone avec un identifiant de job, polling côté client, ou utilisation de WebSockets.

Ce comportement s'applique aussi à d'autres services qui invoquent Lambda de façon synchrone — vérifiez toujours les limites de timeout du service appelant, pas seulement de Lambda.

IAM : Permissions Requises pour Modifier le Timeout

Pour modifier la configuration d'une fonction Lambda (timeout, mémoire, variables d'environnement), le principal IAM doit disposer de l'action lambda:UpdateFunctionConfiguration. Sans cette permission, la commande CLI retournera une erreur AccessDeniedException.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:UpdateFunctionConfiguration",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:ma-fonction-lambda"
    }
  ]
}

L'action lambda:GetFunctionConfiguration permet de lire la configuration actuelle sans la modifier — utile pour les rôles de lecture seule en audit ou en monitoring.

Limites et Considérations Opérationnelles

Le timeout maximum de Lambda est de 900 secondes (15 minutes). C'est une limite de service documentée par AWS — elle ne peut pas être augmentée via une demande de quota.

Si votre traitement dépasse 15 minutes, Lambda n'est pas le bon outil. Les alternatives natives AWS pour les traitements longs incluent AWS Fargate, AWS Batch, ou AWS Step Functions avec des activités de longue durée.

Un timeout à 900 secondes sur une fonction invoquée fréquemment peut générer des coûts significatifs si le code attend passivement (connexion base de données suspendue, appel HTTP bloquant). La durée facturée correspond au temps réel d'exécution jusqu'au timeout — pas au temps utile.

Quelques points à vérifier avant de simplement augmenter le timeout :

  • Le code est-il bloquant ? Un appel HTTP sans timeout côté client peut bloquer indéfiniment jusqu'au timeout Lambda. Configurez des timeouts explicites dans votre code.
  • La connexion base de données est-elle correctement fermée ? Les connexions non libérées peuvent épuiser le pool de connexions même si la fonction finit par se terminer.
  • La mémoire est-elle suffisante ? Lambda alloue du CPU proportionnellement à la mémoire configurée. Une fonction sous-dimensionnée en mémoire peut être lente non pas à cause du timeout, mais à cause du manque de CPU.

Conclusion et Prochaines Étapes pour Optimiser le Timeout Lambda

Modifier le timeout Lambda est une opération de deux minutes — mais comprendre pourquoi votre fonction dépasse son timeout est ce qui évite de revenir sur le même problème trois semaines plus tard. Confirmez l'erreur dans CloudWatch Logs, mesurez la durée réelle, ajustez le timeout avec une marge raisonnable, et vérifiez que le service appelant n'impose pas sa propre limite.

Pour aller plus loin :

Glossaire

Terme Définition
Timeout Lambda Durée maximale allouée à une invocation Lambda avant interruption forcée. Configurable de 1 à 900 secondes.
Task timed out Message d'erreur émis par Lambda dans CloudWatch Logs quand une invocation dépasse le timeout configuré.
Invocation synchrone Mode d'invocation où l'appelant attend la réponse de Lambda. API Gateway utilise ce mode.
Timeout d'intégration API Gateway Limite de 29 secondes imposée par API Gateway sur les intégrations synchrones, indépendante du timeout Lambda.
UpdateFunctionConfiguration Action IAM Lambda permettant de modifier les paramètres de configuration d'une fonction (timeout, mémoire, etc.).

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Structure de base d'une politique IAM : Effect, Action, Resource et Condition expliqués

La première fois qu'on ouvre une politique IAM JSON en production pour diagnostiquer un accès refusé, les quatre éléments Effect , Action , Resource et Condition semblent évidents — jusqu'au moment où une permission ne se comporte pas comme prévu et qu'on réalise qu'on avait mal compris la portée d'un seul de ces champs. Comprendre la structure d'une politique IAM, c'est comprendre comment AWS évalue chaque requête API avant de l'autoriser ou de la rejeter. TL;DR — Structure d'une politique IAM Élément Rôle Obligatoire Effect Autorise ( Allow ) ou refuse ( Deny ) explicitement Oui Action Quelle(s) opération(s) API sont ciblées Oui Resource Sur quel(s) objet(s) AWS s'applique la règle Oui Condition Contraintes contextuelles supplémentaires (IP, MFA,...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

EBS vs EFS pour plusieurs instances EC2 : partager un dossier entre 5 serveurs

Vous venez de concevoir une architecture multi-instances et vous réalisez que cinq EC2 doivent lire et écrire dans le même répertoire — uploads utilisateurs, fichiers de configuration partagés, assets statiques. La première question qui vient : est-ce que EBS peut faire ça, ou faut-il absolument passer par EFS ? La réponse change radicalement selon le type de volume EBS et le mode d'accès souhaité. TL;DR — EBS vs EFS pour le partage entre instances EC2 Critère EBS (volume standard) EBS Multi-Attach (io1/io2) EFS Instances simultanées 1 seule Jusqu'à 16 (même AZ) Illimité, multi-AZ Portée géographique 1 AZ 1 AZ uniquement Toute la région Système de fichiers ext4, xfs, ntfs… Cluster-aware requis (GFS2, OCFS2) NFS v4.1 natif Compatibilité OS Linux, Windows ...
Lire la suite