Bonnes pratiques AWS Lambda pour des applications serverless à grande échelle

Lambda rend les premiers 80 % faciles. C'est sur les derniers 20 % que la plupart des équipes perdent du temps : les cold starts au p99, des coûts prévisibles à grande échelle, et une sécurité qui résiste à un audit. Voici la méthode que nous appliquons sur chaque mission.

1. Dimensionner la mémoire avant de toucher à quoi que ce soit

Dans Lambda, le CPU est alloué proportionnellement à la mémoire. Doubler la mémoire divise souvent le temps d'exécution par deux et réduit le coût total. Nous profilons chaque fonction de production avec AWS Lambda Power Tuning, une step function qui mesure toute une plage de configurations mémoire et trouve le meilleur compromis entre latence et coût.

Les équipes qui déploient avec les 128 Mo par défaut laissent presque toujours de la performance et de l'argent sur la table. Fixez une base autour de 512 Mo pour la plupart des handlers d'API, puis ajustez à la baisse si la fonction est réellement peu gourmande en CPU.

2. Combattre les cold starts de façon ciblée, pas partout

Les cold starts comptent sur les chemins synchrones exposés aux utilisateurs. Ils comptent rarement pour les workers asynchrones ou les jobs planifiés. Dépensez votre budget là où les utilisateurs le ressentent. Sur l'API d'une marketplace cloud B2B, cette approche ciblée a ramené les cold starts d'environ 8 s à environ 1,5 s.

• Provisioned Concurrency : réserve des instances déjà initialisées. Utilisez-la pour le login, le checkout et tout ce qui est soumis à des SLO p99 sous 1 s.
• SnapStart (Java, Python, .NET) : capture un snapshot d'un runtime initialisé. Des cold starts 10× plus rapides, sans coût récurrent pour Java (Python et .NET facturent le stockage du cache de snapshot et les restaurations).
• Choix du runtime : Node et Go démarrent à froid en ~100 ms. Java et .NET sans SnapStart sont entre 1 et 3 s.
• Taille du bundle : un bundle trop lourd ralentit les cold starts, et l'initialisation des modules domine ce coût. Faites du tree-shaking. Excluez le SDK AWS si le runtime l'embarque déjà.

3. Piloté par les événements, pas par le cron

Les pipelines Lambda les moins chers et les plus fiables sont pilotés par les événements. Plutôt que d'interroger à intervalle régulier, branchez Lambda directement sur l'événement qui doit déclencher le travail : uploads S3, streams DynamoDB, messages SQS, règles EventBridge.

Une Lambda qui ne s'exécute que lorsqu'un événement survient est plus simple à analyser, moins chère à exploiter, et absorbe naturellement les pics de trafic.

4. Logs structurés, tracing et métriques dès le premier jour

On ne rattrape pas l'observabilité après un incident. Trois choses doivent être en place avant qu'une fonction n'atteigne la production :

• Logs JSON structurés avec un correlation ID par invocation. Utilisez Powertools for Lambda ; il le gère par défaut.
• AWS X-Ray ou ADOT pour tracer chaque appel sortant : DynamoDB, APIs externes, SQS.
• Métriques custom via EMF (Embedded Metric Format) pour les KPIs métier, pas seulement techniques.

// Avec AWS Lambda Powertools (TypeScript)
import { Logger } from '@aws-lambda-powertools/logger';
import { Tracer } from '@aws-lambda-powertools/tracer';
import { Metrics, MetricUnit } from '@aws-lambda-powertools/metrics';

const logger = new Logger();
const tracer = new Tracer();
const metrics = new Metrics();

export const handler = async (event) => {
  logger.info('Order received', { orderId: event.orderId });
  metrics.addMetric('OrderProcessed', MetricUnit.Count, 1);
  // ... logique métier ...
};

5. Sécurité : le moindre privilège, vraiment

Le constat de sécurité Lambda le plus fréquent dans les audits que nous menons : un rôle d'exécution avec s3:* sur *. Corrigez cela avec :

• Un rôle IAM par fonction. Ne partagez pas un rôle générique « LambdaFullAccess ».
• Des permissions limitées à la ressource : nommez l'ARN exact de la queue, du bucket ou de la table.
• Les secrets via AWS Secrets Manager ou Parameter Store avec KMS, jamais de credentials dans les variables d'environnement.
• Activez la signature de code AWS Lambda pour les fonctions de production.

6. Maîtriser le coût avant qu'il ne vous maîtrise

La tarification à l'usage de Lambda devient un piège quand les fonctions sont mal architecturées. Les garde-fous budgétaires que nous posons sur chaque projet :

• Reserved concurrency : plafonne les fan-out incontrôlés. Empêche une boucle mal configurée de générer une facture à cinq chiffres.
• Timeouts dimensionnés sur le travail réel, pas sur le maximum de 15 minutes.
• Détection d'anomalies de coût avec alertes sur les dépenses inhabituelles par fonction.
• Compute Savings Plans : couvrent l'usage Lambda stable avec jusqu'à 17 % de réduction.

7. Concevoir pour l'idempotence

Lambda garantit une livraison at-least-once, pas exactly-once. Toute fonction qui écrit de l'état doit être idempotente, sinon les livraisons en double corrompent vos données. Utilisez l'utilitaire d'idempotence de Powertools avec DynamoDB comme lock store, ou un message ID dans votre propre table.

L'essentiel

1. Réglez la mémoire avec Power Tuning, toujours.
2. Utilisez la Provisioned Concurrency ou SnapStart uniquement sur les chemins critiques en latence.
3. Passez à l'événementiel partout où c'est possible.
4. Livrez l'observabilité avec la première fonction, pas la centième.
5. Un rôle par fonction, limité à la ressource.
6. Réservez la concurrence et surveillez les anomalies de coût.
7. Rendez chaque écriture idempotente.