Amazon SAA-C03: Architectures Serverless et événementielles / Intégration d'API — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

AWS Lambda : Modèle d’exécution, cycle de vie du runtime et démarrages à froid

Lambda exécute le code dans des micro-VM Firecracker isolées qui suivent un cycle de vie en deux phases. La phase INIT provisionne le conteneur, amorce le runtime, télécharge et décompresse le package de déploiement, et exécute toute initialisation au niveau du module — construction du client SDK, chargement des secrets déchiffrés avec KMS, configuration du pool de connexions à la base de données, chargement des classes JVM et préchauffage JIT. La phase INVOKE exécute le gestionnaire (handler). Un démarrage à froid (cold start) entraîne le coût complet de la phase INIT ; une invocation à chaud (warm invocation) réutilise l’environnement, de sorte que tout ce qui est mis en cache en dehors du gestionnaire (pools de connexions HTTP persistantes, secrets déchiffrés, clients de base de données) persiste entre les invocations sur ce conteneur. C’est pourquoi le modèle canonique consiste à construire les objets coûteux au niveau du module et à les réutiliser :

import boto3, os
ddb = boto3.client('dynamodb')          # reused across warm invokes
_secret = None
def _load_secret():
    global _secret
    if _secret is None:
        _secret = kms.decrypt(...)      # KMS call once per container, not per invoke
    return _secret

def handler(event, ctx):
    ...

L’ampleur du démarrage à froid varie selon le runtime. Pour Node.js et Python, il s’agit de dizaines à quelques centaines de millisecondes ; pour la JVM et .NET, cela peut dépasser la seconde. Pour les fonctions attachées à un VPC, les ENI Hyperplane ont largement amorti la pénalité historique liée à l’attachement d’ENI, mais la taille du package et un code d’initialisation lourd restent les facteurs dominants.

Trois outils s’attaquent différemment aux démarrages à froid :

SnapStart est le juste milieu rentable pour les charges de travail Java sans contrats de latence stricts — les démarrages à froid diminuent d’environ un ordre de grandeur sans surcoût par invocation. La simultanéité provisionnée est la bonne solution lorsqu’une API synchrone doit maintenir un p99 inférieur à, disons, 100 ms pendant les pics de trafic ; la dimensionner pour la rafale p95 comble l’écart de latence de queue (tail-latency). Le sous-dimensionner est une erreur classique : le mode à la demande ne démarre de nouveaux conteneurs que lorsqu’une requête arrive, donc un pic de trafic produit des attentes de plusieurs secondes pour les utilisateurs réels.

# SAM: SnapStart on a Java 17 function
MyJavaFn:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: java17
    SnapStart: { ApplyOn: PublishedVersions }
    AutoPublishAlias: live

La simultanéité provisionnée elle-même peut être mise à l’échelle via Application Auto Scaling — une action planifiée augmentant la capacité de 10 à 200 à 07:45 et la ramenant à son niveau initial à 10:00 évite de payer pour une capacité préchauffée pendant la nuit tout en éliminant les démarrages à froid liés au pic du matin.

L’allocation de mémoire est aussi un levier de réglage du CPU : la puissance du vCPU augmente linéairement avec la mémoire jusqu’à environ 1 769 Mo par vCPU. Une fonction configurée avec 128 Mo peut coûter globalement plus cher qu’une fonction à 1 024 Mo, car un temps d’exécution doublé dépasse souvent le doublement du prix par milliseconde. Ne devinez pas — utilisez AWS Lambda Power Tuning pour balayer les configurations avec des charges utiles (payloads) représentatives.

Lambda : Contrôles de la simultanéité et protection des systèmes en aval

Trois leviers de contrôle de la simultanéité sont importants, et chacun a un rôle différent :

• Simultanéité réservée : Plafonne et réserve le nombre d’exécutions simultanées qu’une fonction peut consommer. Elle alloue une partie de la capacité du pool du compte et protège les systèmes en aval (une petite instance RDS, une API partenaire avec des limites de débit) contre la surcharge.
• Simultanéité provisionnée : Pré-initialise les environnements — c’est un levier pour la latence, pas pour la mise à l’échelle.
• Simultanéité de compte non réservée : C’est le pool partagé, par défaut à 1 000 par Région.

Considérer que Lambda “se met à l’échelle à l’infini” ignore deux plafonds. Premièrement, la limite d’exécutions simultanées au niveau du compte est réelle, et les limites de rafale (initialement 500–3 000 selon la Région, puis +500/min) régissent la vitesse d’augmentation. Une fois cette limite dépassée, les appelants synchrones reçoivent une exception 429 TooManyRequestsException, qu’API Gateway expose comme une erreur 5xx. Deuxièmement, les systèmes en aval ont leurs propres limites : une instance db.t3.micro avec max_connections=85 ne peut pas supporter un millier de Lambdas simultanées ouvrant chacune une connexion. PostgreSQL crée un processus backend pour chaque connexion, consommant environ 10 Mo de RAM ; même avec du CPU disponible, l’établissement et la fermeture des connexions peuvent à eux seuls saturer l’instance.

Les deux stratégies d’atténuation sont (1) RDS Proxy, qui regroupe et multiplexe de nombreuses connexions côté client sur un petit ensemble de connexions persistantes côté backend, et (2) l’insertion d’une file d’attente pour que le taux de traitement soit découplé du taux d’arrivée :

import psycopg2, os
conn = psycopg2.connect(
    host=os.environ['PROXY_ENDPOINT'],   # RDS Proxy, not the DB directly
    dbname='orders', user='app', password=get_secret())

RDS Proxy est une solution à changement minimal — le pilote et la chaîne de connexion changent à peine — ce qui en fait la bonne réponse lorsque l’exigence est “le moins de changements possible à l’application” en plus de l’épuisement des connexions. DynamoDB n’a pas ce problème : son API HTTPS est sans état (stateless), c’est pourquoi DynamoDB s’associe naturellement avec les charges de travail Lambda à haute distribution (high-fanout).

IAM, variables d’environnement et réseau pour Lambda

Chaque fonction assume un rôle d’exécution lors de son invocation. La politique d’approbation du rôle accorde sts:AssumeRole à lambda.amazonaws.com ; sa politique de permissions définit ce que la fonction peut faire. Le runtime injecte automatiquement des identifiants STS à courte durée de vie dans AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_SESSION_TOKEN. N’intégrez jamais de clés d’accès utilisateur IAM dans les variables d’environnement ou le code — elles sont statiques, détectables dans les fuites de code source ou les exports CloudTrail, doivent être renouvelées manuellement et contournent tout le modèle d’identifiants temporaires.

FnRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
      - Effect: Allow
        Principal: { Service: lambda.amazonaws.com }
        Action: sts:AssumeRole
    Policies:
      - PolicyName: ReadOrders
        PolicyDocument:
          Statement:
          - Effect: Allow
            Action: ["dynamodb:GetItem", "dynamodb:Query"]
            Resource: !GetAtt OrdersTable.Arn

Les variables d’environnement contenant une configuration sensible doivent être chiffrées avec une clé KMS gérée par le client, en utilisant les « assistants pour le chiffrement en transit » afin que la console chiffre côté client. Déchiffrez une seule fois à la phase d’INIT et mettez en cache le texte en clair dans une variable au niveau du module — sinon, chaque invocation entraîne un appel à l’API KMS.

Par défaut, une fonction s’exécute dans un VPC géré par AWS avec un accès sortant illimité à Internet. Attachez-la à votre propre VPC uniquement lorsqu’elle doit atteindre des ressources résidant dans le VPC (RDS dans des sous-réseaux privés, ElastiCache, sur site via Direct Connect). Lambda attache alors des ENIs Hyperplane dans les sous-réseaux que vous spécifiez et hérite de leur routage.

Le piège classique consiste à placer une fonction Lambda dans un sous-réseau privé sans autre route pour le trafic des services AWS qu’une passerelle NAT — ou pire, une instance NAT autogérée. Les instances NAT saturent au niveau d’une seule carte réseau (NIC), constituent un point de défaillance unique (SPOF) et facturent au Go. Même les passerelles NAT facturent au Go et sont inutiles pour le trafic des services AWS. Le bon modèle est le suivant :

• Points de terminaison d’un VPC de type passerelle pour S3 et DynamoDB (gratuits)
• Points de terminaison d’interface (PrivateLink) pour KMS, Secrets Manager, SQS, SNS, STS et autres services similaires

Cela maintient le trafic sur le réseau principal (backbone) d’AWS, supprime les plafonds de débit des NAT et évite les factures de sortie de données (egress) surprises. Notez que les ENIs Lambda n’obtiennent jamais d’adresse IP publique ; placer la fonction dans un sous-réseau « public » ne lui donne pas accès à Internet — vous avez toujours besoin d’une passerelle NAT dans un sous-réseau public distinct avec une route appropriée.

Amazon API Gateway : types de points de terminaison, autorisation et livraison

API Gateway propose trois types d’API :

Choisissez l’API REST lorsque vous avez besoin de clés d’API et de plans d’utilisation, de la validation des requêtes par schéma JSON, de modèles de mappage VTL, d’autorisateurs Cognito avec des portées (scopes) par méthode, ou d’un WAF ; choisissez l’API HTTP pour des modèles de proxy légers authentifiés par JWT où le coût et la latence sont plus importants.

Les types de points de terminaison régissent l’emplacement frontal de l’API :

• Optimisé pour la périphérie (Edge) : placé derrière une distribution CloudFront gérée par API Gateway ; le TLS se termine au POP le plus proche. Idéal pour les clients répartis mondialement.
• Régional : exposé depuis une seule région sans CloudFront. Idéal lorsque les clients se trouvent dans la même région, lorsque vous souhaitez utiliser votre propre CloudFront en amont, ou lorsque vous utilisez le routage basé sur la latence de Route 53 sur plusieurs régions.
• Privé : accessible uniquement via un point de terminaison d’un VPC de type interface. Idéal pour les microservices internes qui ne doivent pas transiter par l’Internet public.

Sélectionner le type optimisé pour la périphérie pour une API interne mono-région ajoute un saut CloudFront inutile et une propagation plus lente des déploiements. Sélectionner le type régional pour une API publique consommée mondialement force chaque requête à traverser l’Internet public vers une seule région.

Les domaines personnalisés nécessitent des certificats ACM dont l’emplacement dépend du type de point de terminaison : us-east-1 pour le type optimisé pour la périphérie (CloudFront est mondial et y termine le TLS) ; la propre région de l’API pour les points de terminaison régionaux. Confondre cela est une erreur de configuration courante. Les mappages de chemins de base permettent à un seul domaine de multiplexer plusieurs API (/orders → API des commandes, /users → API des utilisateurs).

L’autorisation comporte quatre modèles, et ignorer les mécanismes intégrés est un anti-modèle classique :

Un autorisateur Lambda personnalisé ajoute une invocation supplémentaire par requête (ou par durée de vie (TTL) du cache), une autre fonction à patcher et à surveiller, et un chemin de code où des bogues de validation de signature peuvent silencieusement autoriser l’accès. Utilisez-le uniquement lorsque les mécanismes intégrés ne peuvent vraiment pas répondre au besoin.

L’intégration proxy Lambda est le modèle par défaut — la requête entière est transmise en tant qu’événement et la fonction doit retourner l’enveloppe de réponse au format attendu :

{
  "statusCode": 200,
  "headers": {"Content-Type": "application/json"},
  "body": "{\"orderId\":\"abc123\"}",
  "isBase64Encoded": false
}

Pour une ingestion de type « fire-and-forget » à un TPS (transactions par seconde) très élevé, utilisez l’intégration directe de service AWS d’API Gateway pour pousser directement dans SQS ou Kinesis, en sautant complètement l’étape Lambda. Cela élimine les démarrages à froid (cold starts) sur le chemin d’écriture et découple le taux d’ingestion de la capacité de traitement.

Pour des déploiements progressifs sécurisés, utilisez les déploiements canary sur un stage : un pourcentage du trafic est dirigé vers le nouveau déploiement tandis que la majorité reste sur la version stable. Les métriques CloudWatch par canary informent la décision de promouvoir ou d’annuler (rollback).

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/canarySettings/percentTraffic,value=10 \
    op=replace,path=/canarySettings/deploymentId,value=xyz789

Pour un webhook simple où le formalisme d’API Gateway est excessif (callback Slack mono-locataire, gestionnaire de push GitHub), les URL de fonction Lambda fournissent un point de terminaison HTTPS dédié directement sur la fonction. Sécurisez-les avec AuthType: AWS_IAM lorsque les appelants sont des principaux AWS ; si NONE, vous devez valider la signature de la requête dans la fonction. Une URL de fonction avec AuthType: NONE et sans vérification dans la fonction est un point de terminaison de calcul anonyme sur l’Internet public.

Types d’invocation, tentatives et idempotence

Les sources d’événements se divisent en deux catégories aux comportements très différents. Les sources en mode push (API Gateway, ALB, S3, SNS, EventBridge, Cognito) invoquent Lambda directement et nécessitent une politique basée sur les ressources AWS::Lambda::Permission accordant lambda:InvokeFunction avec le Principal correct (par ex., events.amazonaws.com) et le SourceArn. Sans cela, la règle correspond aux événements mais chaque invocation est silencieusement refusée — la fonction ne s’exécute jamais et les échecs n’apparaissent que dans CloudTrail. Ceci est distinct du rôle d’exécution, qui régit ce que la fonction peut faire, et non qui peut l’appeler.

Les sources en mode polling (SQS, Kinesis, DynamoDB Streams, MSK) sont lues par le service Lambda via un mappage de source d’événement — aucune politique basée sur les ressources n’est nécessaire, mais le rôle d’exécution doit accorder des autorisations de lecture.

Les types d’invocation déterminent également le comportement des tentatives :

• Synchrone (API Gateway, ALB, SDK RequestResponse) : les erreurs sont retournées immédiatement ; l’appelant est responsable des tentatives.
• Asynchrone (S3, SNS, EventBridge) : Lambda met en mémoire tampon dans une file d’attente interne et réessaie deux fois avec des délais en cas d’échec, puis envoie à une DLQ ou à une destination en cas d’échec.
• Mappage de source d’événement SQS : SQS continue de re-livrer jusqu’à ce que maxReceiveCount déclenche un déplacement vers la DLQ de la file d’attente source.
• Kinesis / DynamoDB Streams : réessaie un seul lot de partition (shard) jusqu’au succès ou à l’expiration, bloquant la partition pendant ce temps — un lot bloqué paralyse tout le traitement en aval pour cette partition.

Parce que les tentatives sont intégrées à chaque couche, l’idempotence est obligatoire, et non optionnelle. L’expiration d’un délai de visibilité SQS lors d’une écriture lente ou une nouvelle tentative asynchrone après une erreur 5xx en aval produira des doublons. Le pattern canonique utilise une clé déterministe et une écriture conditionnelle DynamoDB :

def handler(event, context):
    msg_id = event['Records'][0]['messageId']
    try:
        ddb.put_item(
            TableName='processed',
            Item={'id': {'S': msg_id}, 'ttl': {'N': str(ttl)}},
            ConditionExpression='attribute_not_exists(id)')
    except ddb.exceptions.ConditionalCheckFailedException:
        return  # already processed
    process(event)

Le décorateur @idempotent des AWS Lambda Powertools implémente exactement ce pattern en s’appuyant sur DynamoDB.

Découplage avec SQS et SNS

Connecter directement des sources push à haute distribution (fan-out) à Lambda est fragile. Les notifications d’événements S3, par exemple, sont synchrones pour chaque événement et soumises au plafond de simultanéité de Lambda ; si les invocations dépassent la simultanéité disponible lors d’un pic de téléversements (une campagne marketing déposant des milliers de documents en quelques secondes), la fenêtre de tentative de S3 est courte et les événements peuvent effectivement être perdus (dropped). Le remède est une mémoire tampon (buffer) :

SNS est un service pub/sub : une publication, de nombreux abonnés (SQS, Lambda, HTTPS, e-mail). Le filtrage des messages est basé sur les attributs. SQS est une file d’attente point à point durable qui conserve les messages jusqu’à 14 jours. La combinaison la plus robuste est le fan-out SNS → SQS, donnant à chaque consommateur sa propre file d’attente tamponnée pour une mise à l’échelle et une relecture indépendantes.

Pour un ordre strict (par ex., les commandes par client traitées séquentiellement), utilisez une file d’attente SQS FIFO avec le MessageGroupId défini sur la clé d’ordonnancement. Les messages au sein d’un groupe sont livrés dans l’ordre ; différents groupes sont traités en parallèle. Les files d’attente SQS standard n’offrent qu’un ordre au mieux (best-effort).

Le pattern canonique d’ingestion découplée utilise l’intégration directe SQS de API Gateway pour absorber les pics de charge et un processeur à débit limité :

Resources:
  OrdersQueue:
    Type: AWS::SQS::Queue
    Properties:
      FifoQueue: true
      ContentBasedDeduplication: true
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt OrdersDLQ.Arn
        maxReceiveCount: 5

  ProcessorFunction:
    Type: AWS::Lambda::Function
    Properties:
      ReservedConcurrentExecutions: 20   # cap the DB write rate

  Mapping:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      EventSourceArn: !GetAtt OrdersQueue.Arn
      FunctionName: !Ref ProcessorFunction
      BatchSize: 10

La simultanéité réservée est délibérée — elle plafonne la vitesse à laquelle la base de données voit les écritures, de sorte que la file d’attente (et non RDS) absorbe le pic de charge. Les messages en échec sont routés vers une DLQ après maxReceiveCount pour une inspection hors ligne.

EventBridge : Règles, transformation d’entrée et destinations d’API

EventBridge est un bus d’événements conscient des schémas, avec une correspondance de patterns JSON riche, des sources de partenaires SaaS, un registre de schémas, et l’archivage/relecture. Les règles correspondent à des patterns d’événements et distribuent (fan out) vers plus de 30 types de cibles (Lambda, Step Functions, SQS, Kinesis, ECS, Firehose), avec un filtrage basé sur le contenu du corps du message — pas seulement sur les attributs comme avec SNS :

{
  "source": ["tenant.energy"],
  "detail-type": ["UsageReported"],
  "detail": { "kWh": [{ "numeric": [">", 100] }] }
}

Une règle peut avoir jusqu’à cinq cibles, chacune recevant soit l’événement brut, soit un sous-ensemble transformé. Les transformateurs d’entrée (Input transformers) imposent un couplage lâche : un InputPathsMap extrait des chemins JSON de l’événement, et un InputTemplate les reformate exactement comme la cible s’y attend :

EventPattern:
  source: ["com.acme.orders"]
  detail-type: ["OrderPlaced"]
Targets:
  - Arn: !GetAtt PaymentValidator.Arn
    InputTransformer:
      InputPathsMap:
        orderId: "$.detail.orderId"
        amount: "$.detail.total"
        card: "$.detail.payment.cardToken"
      InputTemplate: |
        {"orderId": <orderId>, "amount": <amount>, "cardToken": <card>}

Chaque Lambda de validation ne reçoit que ce dont elle a besoin ; le validateur d’adresse ne voit jamais le jeton de la carte. C’est nettement supérieur à une Lambda monolithique qui reçoit l’événement complet et se ramifie en interne — un monolithe concentre les permissions IAM (un seul rôle doit détenir toutes les permissions en aval), augmente le rayon d’impact (blast radius) d’un bug, couple la cadence de déploiement, empêche l’ajustement de la mémoire/timeout par responsabilité, et force la fonction entière à s’adapter au débit de la branche la plus sollicitée.

Les destinations d’API (API destinations) inversent la direction : EventBridge appelle un point de terminaison (endpoint) HTTPS externe. Associé à une connexion qui stocke des informations d’identification Basic, clé d’API ou OAuth dans Secrets Manager, c’est la manière serverless de notifier un SaaS tiers lorsque, par exemple, une tâche AWS Batch réussit — aucune Lambda n’est requise. EventBridge capture l’événement de changement d’état, une règle correspond à JobSucceeded, et la cible de destination d’API envoie une requête POST au fournisseur avec les informations d’identification injectées depuis la connexion.

Les règles planifiées (expressions cron/rate) ou le plus récent EventBridge Scheduler remplacent les instances EC2 de type “heartbeat” pour les tâches périodiques — rapports nocturnes, rafraîchissement horaire du cache.

Choisissez EventBridge plutôt que SNS lorsque le filtrage porte sur le contenu du corps du message (pas seulement les attributs), lorsque de nouveaux consommateurs doivent pouvoir s’attacher ultérieurement sans modification du producteur, ou lorsque le routage s’étend sur plusieurs comptes ou sources SaaS. Choisissez SNS lorsque la distribution (fan-out) est une simple notification filtrée par attributs à un ensemble stable d’abonnés.

Step Functions : Orchestration et Distributed Map

Lorsqu’un workflow comporte plus de quelques étapes, des branchements, des tentatives, une approbation humaine ou de longues attentes, intégrer cette logique dans des Lambdas enchaînées devient ingérable. Step Functions externalise la machine à états dans l’Amazon States Language.

• Workflows Standard : jusqu’à un an, sémantique de type exactly-once (traitement unique), historique complet des exécutions, .waitForTaskToken pour les validations humaines/externes. Idéal pour le traitement des commandes, les ETL, les flux d’approbation.
• Workflows Express : jusqu’à cinq minutes, sémantique de type at-least-once (au moins un traitement), volume élevé, coût par exécution faible. Pour les orchestrations synchrones courtes derrière API Gateway ; transformations pour l’IoT et le streaming.

Chaque tâche doit déclarer explicitement des Retry et des Catch :

"ValidatePayment": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "PaymentValidator", "Payload.$": "$"},
  "Retry": [{
    "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"],
    "IntervalSeconds": 2, "MaxAttempts": 4, "BackoffRate": 2.0
  }],
  "Catch": [{"ErrorEquals": ["PaymentDeclined"], "Next": "RefundStep"}],
  "Next": "ShipOrder"
}

Les états Parallel et Map exécutent des branches simultanément et agrègent les résultats — une solution idéale pour les systèmes de commande avec des validateurs indépendants (adresse, inventaire, paiement). L’état entre les étapes transite via le document JSON de l’exécution, éliminant le besoin d’une base de données partagée utilisée uniquement pour la coordination du workflow.

Le pattern .waitForTaskToken met l’exécution en pause jusqu’à ce qu’un acteur externe appelle SendTaskSuccess avec le jeton (token) — la réponse canonique lorsqu’un workflow s’étend sur des Lambdas, des instances EC2, des conteneurs, des systèmes sur site (on-prem) et nécessite une approbation manuelle avec une surcharge opérationnelle minimale :

"ManagerApproval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {
    "TopicArn": "arn:aws:sns:us-east-1:111:approvals",
    "Message": { "TaskToken.$": "$$.Task.Token", "OrderId.$": "$.orderId" }
  },
  "Next": "Fulfill"
}

Distributed Map étend l’état Map standard pour traiter jusqu’à 10 000 exécutions enfants parallèles et peut itérer directement sur des objets dans un bucket S3 ou des lignes dans un fichier CSV/JSONL, avec traitement par lots (batching), points de contrôle (checkpointing) et tolérance aux pannes automatiques. Pour des milliers d’objets S3 semi-structurés, c’est l’option la plus efficace sur le plan opérationnel — il suffit de le pointer vers un préfixe, de définir la tâche par élément, et Step Functions gère la distribution (fan-out), MaxConcurrency, les tentatives (retries) et l’agrégation des résultats :

{
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:listObjectsV2",
    "Parameters": { "Bucket": "raw-events", "Prefix": "2024/" }
  },
  "MaxConcurrency": 1000,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" },
    "StartAt": "ProcessObject",
    "States": { "ProcessObject": { "Type": "Task", "Resource": "arn:aws:lambda:...:function:ProcessOne", "End": true } }
  }
}

Recréer la même logique sur SQS ou EventBridge nécessite une gestion personnalisée pour le suivi de l’achèvement, les tentatives et l’assemblage des résultats.

Step Functions vs. EventBridge : Step Functions est la bonne solution lorsque vous maîtrisez la séquence et le résultat — état, branchements, tentatives, approbations. EventBridge est la bonne solution lorsque les producteurs ne savent pas ou ne se soucient pas de qui sont les consommateurs, et que les consommateurs se connectent indépendamment.

Notifications d’événements S3

Pour le traitement quasi temps réel des téléversements (uploads), configurez les notifications d’événements S3 sur s3:ObjectCreated:* (ou une variante spécifique comme Put, Post, CompleteMultipartUpload) avec une cible Lambda — en tenant compte des mises en garde sur les pics de charge (bursts) mentionnées précédemment. Garde-fous :

• Définissez une concurrence réservée (reserved concurrency) pour protéger une base de données en aval.
• Activez une DLQ ou une destination en cas d’échec (on-failure destination) pour les messages empoisonnés (poison messages).
• Acheminez les événements S3 via EventBridge lorsque plusieurs consommateurs ont besoin des mêmes événements. Les configurations de notification S3 directes sont limitées en nombre et en expressivité ; la distribution (fan-out) via EventBridge avec des transformateurs d’entrée (input transformers) par cible est bien plus évolutive.

Streaming : Kinesis Data Streams vs. Firehose

Kinesis Data Streams (KDS) est un journal (log) partitionné (sharded), ordonné et rejouable avec une rétention de 24 heures à 365 jours. L’ordre est préservé par partition (shard), basé sur la clé de partition — ce qui est essentiel pour l’agrégation par appareil ou par locataire (tenant). Plusieurs consommateurs lisent indépendamment (enhanced fan-out pour un débit isolé par consommateur). Choisissez KDS lorsque vous avez besoin de rejouer les données dans l’ordre, de plusieurs consommateurs indépendants ou d’un débit élevé par partition.

Kinesis Data Firehose est un flux de livraison entièrement géré vers S3, Redshift, OpenSearch ou Splunk avec une mise en mémoire tampon (buffering) intégrée (60 s ou 1–128 Mo), une transformation Lambda optionnelle, la compression (GZIP, Snappy) et la conversion en Parquet/ORC. Aucune partition (shard) à gérer. Firehose est le choix à faible charge opérationnelle (low-ops) lorsque des consommateurs personnalisés et la relecture ne sont pas nécessaires — juste pour déposer des données en quasi temps réel.

Le pipeline d’analytique quasi temps réel canonique est producteurs → KDS → Firehose → S3 (Parquet) → Athena/QuickSight, avec un enrichissement Lambda optionnel dans Firehose.

AWS Transfer Family pour le SFTP géré

Lorsque des partenaires exigent d’utiliser SFTP, FTPS ou FTP pour transférer des fichiers vers ou depuis S3 ou EFS, AWS Transfer Family fournit un point de terminaison (endpoint) géré et multi-AZ qui parle le protocole que les clients utilisent déjà. L’authentification prend en charge les utilisateurs gérés par le service, les clés SSH ou des IdP personnalisés via API Gateway/Lambda. Les fichiers arrivent directement dans S3 avec le chiffrement SSE et les politiques de cycle de vie appliquées ; les politiques IAM de restriction de périmètre (scope-down) limitent chaque utilisateur à un préfixe spécifique.

Construire cela soi-même sur EC2 nécessite le durcissement d’OpenSSH, l’application de correctifs, la haute disponibilité (HA) multi-AZ, la rotation des clés et l’expédition des journaux (logs) — tout ce que Transfer Family prend en charge. Choisissez-le chaque fois que l’exigence est « les partenaires nous envoient des fichiers via SFTP » et que vous voulez que les fichiers soient dans S3 avec une surcharge opérationnelle minimale.

Composer un pattern Serverless canonique

Un design d’ingestion à faible surcharge pour des métriques horaires par locataire (per-tenant) : des capteurs envoient des requêtes POST à API Gateway (HTTP API, régional) → une Lambda valide et publie sur EventBridge → des règles acheminent vers une Lambda d’écriture pour DynamoDB (ID du locataire comme clé de partition, compartiment horaire comme clé de tri) et, en parallèle, vers Firehose → S3 (Parquet) pour l’analytique. De nouveaux consommateurs se connectent en tant que règles EventBridge supplémentaires sans toucher aux producteurs — une exigence d’extensibilité que SNS seul ne satisferait pas aussi proprement. Lorsque le débit soutenu et l’ordre sont importants (rapprochement de facturation, flux d’événements financiers), remplacez EventBridge par Kinesis Data Streams et utilisez l’enhanced fan-out pour les consommateurs indépendants.

Catalogue des pièges : Pourquoi les anti-patterns courants échouent

Instance/passerelle NAT pour le trafic vers les services AWS depuis des Lambdas dans un sous-réseau privé. Les instances NAT lient le débit à une seule carte réseau EC2 et sont un SPOF (Single Point of Failure) ; les passerelles NAT facturent au Go. Les deux sont inutiles pour les destinations de services AWS. Utilisez des points de terminaison de passerelle (gateway endpoints) pour S3/DynamoDB, et des points de terminaison d’interface (interface endpoints) pour tout le reste.

Ignorer les démarrages à froid (cold starts) sur les API sensibles à la latence. Le mode à la demande ne provisionne les conteneurs que lorsqu’une requête arrive, donc les pics de trafic ne respectent pas les SLA. Dimensionnez la simultanéité provisionnée pour le p95 des pics de trafic ; utilisez SnapStart pour les charges de travail Java sans SLA stricts.

Lambda monolithique recevant un événement complet et effectuant un branchement interne. Viole le principe de moindre privilège (un seul rôle détient toutes les permissions en aval), couple la cadence de déploiement, empêche l’ajustement par responsabilité, et met à l’échelle toute la fonction au rythme de la branche la plus sollicitée. Séparez par responsabilité ; utilisez EventBridge ou Step Functions pour les relier.

Connexions directes à la base de données depuis de nombreuses Lambdas. Le nombre total de connexions est égal aux invocations simultanées car les conteneurs ne partagent pas les pools. Corrigez avec RDS Proxy (mutualisation des connexions), la simultanéité réservée (plafonnement du débit), ou SQS (mise en mémoire tampon).

Lambda synchrone pour une ingestion en rafale. Le dépassement de la simultanéité renvoie des erreurs 429 à API Gateway et 5xx aux clients ; les notifications directes de S3 pendant les pics de trafic perdent silencieusement des événements. Insérez SQS, ou utilisez l’intégration directe API Gateway → SQS.

URL de fonction Lambda publiques avec AuthType: NONE et sans validation de signature dans la fonction. Calcul anonyme sur l’internet public. Utilisez AWS_IAM pour les appelants AWS ou validez les signatures pour les webhooks tiers.

Autorisateur Lambda personnalisé là où un autorisateur intégré fonctionnerait. Ajoute de la latence, une autre fonction à maintenir, et un chemin de code où des bugs de vérification de signature autorisent silencieusement l’accès. Préférez l’autorisation IAM pour les principaux AWS ; l’autorisateur Cognito pour les groupes d’utilisateurs (user pools).

Mauvaise Région de certificat ACM pour les domaines personnalisés. Les points de terminaison optimisés pour la périphérie (edge-optimized) nécessitent le certificat dans us-east-1 ; les points de terminaison régionaux dans la Région de l’API elle-même.

Absence de AWS::Lambda::Permission pour les sources en mode push (EventBridge, S3, SNS). Les événements correspondent aux règles mais les invocations sont refusées silencieusement. Distinct du rôle d’exécution — ceci régit qui peut appeler la fonction, et non ce que la fonction peut faire.

Absence d’idempotence. Chaque couche effectue des nouvelles tentatives — invocations asynchrones, re-livraison SQS à l’expiration du délai de visibilité, nouvelles tentatives de lot Kinesis. Sans une clé de déduplication déterministe et une écriture conditionnelle, les doublons sont inévitables.

← Conteneurs et orchestration · Tous les domaines · Stockage et cycle de vie des données →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →