Architecture cloud AWS : serverless résilient et rentable

[!NOTE] TL;DR - Lambda reste imbattable sous ~10 millions d'invocations mensuelles pour des exécutions courtes ; Fargate gagne de 40 à 70 % au-delà (tarifs publics AWS, relevé nov. 2026). - Step Functions Standard pour les sagas à enjeu financier (exactement-une-fois), workflows Express imbriqués pour le fan-out idempotent (jusqu'à ~100 fois moins cher). - La disponibilité inter-zones est native ; la récupération des pannes, elle, se conçoit : timeouts systématiques, retries avec jitter, files mortes et idempotence des étapes.

Une architecture cloud résiliente ne se gagne pas en ajoutant des serveurs. Sur AWS, elle s'obtient en arbitrant chaque brique sur des chiffres : Lambda sous ~10 millions d'invocations mensuelles, Fargate au-delà et pour tout traitement de plus de 15 minutes, Step Functions pour l'orchestration reprenable, DynamoDB en single-table pour l'état. Appliquée à mes pipelines de production, cette répartition hybride réduit typiquement la dépense compute de 30 à 50 % face au tout-Lambda (estimation LeanOps, mai 2026). Et je le dis d'entrée : le serverless ne rend pas la facture morale, il la rend seulement lisible.

Un pipeline de documents, quatre Lambdas

Retour sur le terrain. Le pipeline que je pilote depuis 2025 chez un client du secteur de l'énergie (région eu-west-3) ingère des rapports PDF de diagnostics, en extrait le texte via Textract, puis l'analyse avec des agents LLM pour produire un JSON structuré. Le socle est volontairement sobre : quatre fonctions Lambda Python 3.12 orchestrées par une Step Functions, du S3 en entrée, EventBridge en routeur avec un input transformer, une file SQS en sortie, Terraform pour l'IaC (module terraform-aws-lambda v11.0.3). Chaque fonction embarque un timeout de 900 secondes, la limite haute de Lambda, et entre 512 Mo et 2048 Mo de mémoire. Un document_id (UUID) généré à l'entrée sert de référence unique du dossier S3 de travail, du pipeline au backoffice.

Trois surprises en production. Les déploiements de fonctions attachées à un VPC (interfaces ENI) prennent 6 à 9 minutes, de quoi relire toute sa PR et douter de son pipeline CI ! Les payloads volumineux ne traversent ni EventBridge ni la Step Function (256 Ko maximum par événement), donc je passe des clés S3, jamais les contenus. Et la mémoire surdimensionnée de page-analysis, montée « par prudence », me facturait du CPU inutilisé : chez Lambda, la mémoire achète le vCPU (1 vCPU pour 1769 Mo, page tarifs AWS Lambda).

J'ai raconté la mécanique événementielle complète dans Serverless MLOps on AWS : an event-driven pipeline. Ici, je m'attaque à l'argent.

La question

Ma question était la suivante : où s'arrête Lambda, où commence Fargate, et comment garantir une disponibilité réelle sans doubler chaque composant. Une seule question, donc, et des réponses chiffrées.

Le piège du tout-Lambda

On croit volontiers que le serverless est une déclaration d'amour à son DAF. Les nombres disent l'inverse passé un certain volume. Lambda facture 0,20 dollar par million de requêtes plus 0,0000167 dollar par GB-seconde ; Fargate facture 0,04048 dollar par vCPU-heure et 0,004445 dollar par Go-heure (page tarifs AWS Fargate, relevé nov. 2026). Ramenées à la même unité, ces deux grilles racontent des histoires opposées. Le GB-seconde Lambda équivaut à 0,06 dollar par Go-heure, environ le double d'une tâche Fargate équivalente. C'est un tarif premium, adossé à une seule condition : le temps mort est gratuit.

La bascule ne dépend donc que du taux d'occupation. En dessous de 20 à 30 % de temps d'exécution sur une journée, Lambda gagne ; au-dessus, Fargate s'impose (School of Web, juillet 2026). Pour un job de fond à 1024 Mo durant 2 secondes, mes calculs sur tarifs publics placent le croisement vers 1,1 million d'invocations mensuelles : 33,53 dollars de Lambda contre 36,04 dollars pour une tâche Fargate 1 vCPU / 2 Go. Pour une API à 512 Mo et 200 ms, le croisement tombe vers 9,6 millions d'invocations, et vers 6 à 8 millions si on ajoute API Gateway (3,50 dollars par million de requêtes, souvent plus cher que la fonction qu'elle protège).

S'ajoutent les coûts annexes, ceux que la ligne « compute » masque : l'ingestion CloudWatch Logs (de 50 à 150 dollars par mois au-delà d'un million d'invocations quotidiennes, LeanOps mai 2026), la NAT Gateway pour les fonctions confinées en VPC, la provisioned concurrency qui facture l'attente. Bien que cette liste fasse grimacer, je maintiens le point : sous le seuil, Lambda reste imbattable. Gratuit sous 1 million de requêtes et 400 000 GB-s mensuels (free tier permanent), et parfaitement taillé pour le trafic en dents de scie.

L'architecture cible

Construire sur ces seuils donne une architecture hybride, pas un compromis de salon.

flowchart LR
    U[Upload S3] --> EB[EventBridge + input transformer]
    EB -->|clé S3 seulement| SFN[Step Functions Standard - saga]
    SFN -->|fan-out Map| W[Lambda page-extraction 1024 Mo]
    SFN -->|étapes longues| F[Tâche Fargate 1 vCPU 2 Go]
    SFN --> A[Lambda page-analysis 2048 Mo]
    W --> TX[Textract]
    A --> LLM[Agents LLM]
    SFN --> DB[(DynamoDB single-table)]
    EB --> Q[SQS + DLQ - régulation]
    SFN --> CW[CloudWatch - alarmes]

Deux arbitrages structurent l'ensemble. Un : Step Functions Standard (0,025 dollar pour 1000 transitions, 4000 offertes chaque mois) porte la saga mère, exactement-une-fois et auditable jusqu'à un an (documentation AWS). Les étapes courtes et idempotentes partent dans des workflows Express imbriqués (1 dollar par million d'exécutions), jusqu'à ~100 fois moins chers : mille exécutions coûtent environ 0,42 dollar en Standard contre 0,01 dollar en Express (AWS Compute Blog, août 2022). Deux : le claim-check partout. Tu ne balades pas ta valise dans tout le musée ; tu la déposes au vestiaire et tu circules avec des tickets. Chaque état échange des clés S3, jamais des contenus, et la limite de 256 Ko sort de ta vie. L'état applicatif, lui, se concentre dans une seule table DynamoDB : une requête unique sur des items totalisant moins de 4 Ko coûte 0,5 RCU en lecture finalement cohérente, contre 1 RCU pour deux requêtes séparées (documentation DynamoDB). La localité des données, c'est de la résilience et du FinOps dans le même geste.

[!WARNING] Le piège que je baptise « l'exécution orpheline » : sans TimeoutSeconds explicite sur un état Task, une exécution reste suspendue indéfiniment, en attente d'une réponse qui ne viendra jamais. Sur mon pipeline, tout échec part vers un état ProcessingFailed via un Catch States.ALL, sans retry automatique, car retenter une analyse LLM coûte de l'argent pour le même résultat. C'est un choix, il est documenté, et le backoffice peut relancer un traitement document par document.

L'estimateur d'arbitrage en Python

Pour transformer ces seuils en décision quotidienne, j'ai écrit un petit estimateur Pydantic. Il tient dans un atelier d'architecture et se vérifie en direct face à la calculatrice AWS.

from pydantic import BaseModel, Field, model_validator
LAMBDA_GB_S = 0.0000166667  # USD par GB-seconde, x86, releve nov. 2026
LAMBDA_REQ_M = 0.20         # USD par million de requetes
FARGATE_VCPU_H = 0.04048    # USD par vCPU-heure, x86
FARGATE_GB_H = 0.004445     # USD par Go-heure, x86
HOURS_PER_MONTH = 730.0
class WorkloadProfile(BaseModel):
    """Profil de charge pour arbitrer Lambda contre Fargate."""
    model_config = {"strict": True}
    monthly_invocations: int = Field(..., ge=1, description="Invocations attendues par mois.")
    avg_duration_s: float = Field(..., gt=0.0, le=900.0, description="Duree moyenne d'une execution, en secondes.")
    memory_gb: float = Field(..., ge=0.125, le=10.0, description="Memoire allouee a la fonction, en Go.")
    fargate_vcpu: float = Field(default=1.0, gt=0.0, description="vCPU de la tache Fargate equivalente.")
    fargate_gb: float = Field(default=2.0, gt=0.0, description="Memoire de la tache Fargate equivalente, en Go.")
    @model_validator(mode="after")
    def reject_over_lambda_limit(self) -> "WorkloadProfile":
        if self.avg_duration_s > 900.0:
            raise ValueError("Au-dela de 15 minutes, Fargate s'impose : l'arbitrage est deja tranche.")
        return self
    @property
    def lambda_cost_usd(self) -> float:
        gb_seconds = self.memory_gb * self.avg_duration_s * self.monthly_invocations
        return gb_seconds * LAMBDA_GB_S + (self.monthly_invocations / 1_000_000) * LAMBDA_REQ_M
    @property
    def fargate_cost_usd(self) -> float:
        return (self.fargate_vcpu * FARGATE_VCPU_H + self.fargate_gb * FARGATE_GB_H) * HOURS_PER_MONTH
    @property
    def busy_ratio(self) -> float:
        return self.avg_duration_s * self.monthly_invocations / (HOURS_PER_MONTH * 3600.0)
    @property
    def verdict(self) -> str:
        if self.busy_ratio > 0.25 or self.lambda_cost_usd > self.fargate_cost_usd:
            return "Fargate"
        return "Lambda"

Le verdict combine deux conditions observées sur le terrain : un taux d'occupation supérieur à 25 %, ou un coût Lambda qui dépasse la tâche Fargate équivalente. Sur le profil de page-extraction (1 Go, 2 s), l'estimateur bascule à 1,08 million d'invocations mensuelles. Cohérent avec les 33,53 dollars lambda contre 36,04 dollars Fargate du paragraphe précédent. Deux lignes à modifier pour Graviton (0,0000133 dollar par GB-seconde, environ 20 % de remise) ou pour Fargate Spot (1 vCPU / 2 Go à environ 10,70 dollars par mois, remise de 60 à 70 %).

Les chiffres du point de bascule

Le graphique ci-dessous reprend le cas du job de fond (1024 Mo, 2 s), calculé sur les tarifs publics de novembre 2026, hors free tier.

{
  "type": "line",
  "data": {
    "labels": ["100 K", "500 K", "1 M", "2 M", "4 M"],
    "datasets": [
      { "label": "Lambda 1 Go / 2 s (USD/mois)", "data": [3.35, 16.77, 33.53, 67.07, 134.13], "backgroundColor": ["#3b82f6"], "borderColor": "#3b82f6" },
      { "label": "Fargate 1 vCPU / 2 Go en 24/7 (USD/mois)", "data": [36.04, 36.04, 36.04, 36.04, 36.04], "backgroundColor": ["#f59e0b"], "borderColor": "#f59e0b" }
    ]
  },
  "options": {
    "responsive": true,
    "plugins": { "title": { "display": true, "text": "Point de bascule Lambda / Fargate selon le volume mensuel" } },
    "scales": { "y": { "title": { "display": true, "text": "USD par mois" } } }
  }
}

La lecture est sans appel. À 4 millions d'invocations, Lambda coûte près de quatre fois la tâche Fargate équivalente, et l'écart se creuse linéairement : les analyses croisées de 2026 (LeanOps, mai 2026) chiffrent l'avantage Fargate à 40-70 % au-delà du seuil, selon la durée et la mémoire. Chez mon client du secteur énergie, le volume documentaire reste sous le million de traitements mensuels, donc Lambda conserve l'avantage ; l'étude coûts/risques menée en 2025 a malgré tout borné le scénario de croissance, avec une cible à 21 fonctions Lambda qui rendrait la partie déploiement (6 à 9 minutes par fonction VPC) critique en intégration continue.

Limites et pistes ouvertes

Mon estimateur ignore quatre variables réelles : le free tier, Graviton, Fargate Spot et les coûts réseau (NAT, ALB à environ 16 dollars par mois plus 0,008 dollar par LCU-heure). Il suppose aussi une durée d'exécution uniforme, alors que les trafics réels sont bimodaux : une queue de traitements longs suffit à décaler le point de bascule. Sur la disponibilité, je n'ai pas testé le multi-régions : une table DynamoDB mono-région affiche un SLA de 99,99 %, une global table 99,999 %, mais sans endpoint global, le basculement reste à ta charge (Route 53 en tête). Enfin, la file SQS de régulation prévue en amont de mon pipeline, pour respecter les quotas LLM en pic, n'est pas encore en production. Cela pourrait être facilement testé en rejouant un mois de trafic réel sur une tâche Fargate Spot, avec comparaison des latences et de la facture. Reste à savoir si le client acceptera ce test, lui qui n'a pas encore digéré l'arrivée du backoff dans ses réunions.

Le principe qui survit à l'exemple

Plus généralement, la haute disponibilité serverless n'est pas une question de machines mais de récupération. Les services AWS répliquent déjà tes données sur plusieurs zones de disponibilité ; personne, en revanche, ne répliquera pour toi la gestion des pannes. C'est le seul chapitre du runbook que le cloud n'écrira pas à ta place.

Si ce type d'arbitrage t'est utile, je détaille mon accompagnement sur la page architecture serverless AWS, et tu peux m'écrire directement via la page contact. Pour prolonger la lecture : MLOps serverless sur AWS : architecture et facture réelle. Ton DAF te remerciera. Moi aussi, d'avance.

Questions fréquentes

Quand basculer de Lambda vers Fargate ? Pour des exécutions de quelques secondes, la bascule arrive vers 1 million d'invocations mensuelles ; pour une API sub-seconde, vers 9,6 millions (calculs sur tarifs publics, relevé nov. 2026). Pose une alarme CloudWatch sur le coût mensuel de chaque fonction, déclenchée au niveau de la tâche Fargate équivalente.

Step Functions Standard ou Express ? Standard (0,025 dollar pour 1000 transitions) pour tout workflow exactement-une-fois avec enjeu d'argent, auditable jusqu'à un an. Express (1 dollar par million d'exécutions) pour le fan-out idempotent de moins de 5 minutes, environ 100 fois moins cher à volume égal.

Le serverless est-il haute disponibilité par défaut ? Oui entre zones de disponibilité : Lambda, DynamoDB, SQS et Step Functions répliquent nativement, et une table DynamoDB mono-région garantit 99,99 %. Non entre régions : il te faut des global tables (99,999 %) et un routage inter-régions pour survivre à une panne régionale.

Comment réduire la facture sans toucher au code ? Right-sizer la mémoire Lambda (la mémoire achète le CPU), activer Graviton (environ 20 % de remise), basculer les charges soutenues sur Fargate Spot (60 à 70 % de remise), filtrer les logs CloudWatch et auditer la NAT Gateway, souvent plus coûteuse que le compute qu'elle protège.