AWS Certified Developer Associate
Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen DVA-C02. Lisez de haut en bas ou sautez à une section.
Cible d'invocation stable pendant que vous poussez du nouveau code Lambda.
Publier des versions numérotées et immuables ; exposer un alias qui pointe vers une version. Les appelants invoquent l'ARN de l'alias.
Pourquoi: Les versions sont des instantanés figés de code + configuration ; les alias fournissent une indirection pour que les appelants n'invoquent jamais directement `$LATEST`.
Déploiement progressif d'une nouvelle version de Lambda avec retour arrière automatique en cas d'erreurs.
Alias avec routage de version pondéré (par exemple 90/10). CodeDeploy `LambdaCanary10Percent5Minutes` ou `LambdaLinear*` déplace le trafic et surveille les alarmes CloudWatch.
Pourquoi: Le décalage de trafic intégré + le retour arrière basé sur les alarmes éliminent la logique canary codée manuellement.
Injecter la configuration (URL de base de données, indicateurs de fonctionnalités) sans redéploiement.
Variables d'environnement Lambda. Chiffrées par KMS au repos ; référencez une CMK personnalisée pour un chiffrement supplémentaire en transit lors de la récupération.
Partager NumPy / pandas / environnement d'exécution commun entre plusieurs Lambdas.
Empaqueter en tant que couche Lambda ; jusqu'à 5 couches par fonction, total 250 Mo décompressés. ARN versionné par couche.
Lambda synchrone sensible à la latence — pas de démarrage à froid autorisé.
Concurrence provisionnée sur l'alias. Pré-initialise N environnements d'exécution ; facturé par seconde-gigaoctet.
Pourquoi: Élimine le démarrage à froid à un coût prévisible. Configurez l'auto-scaling d'application sur l'alias pour s'adapter à la charge.
Lambda Java ou Python avec un code d'initialisation lourd ; besoin d'un démarrage à froid rapide sans payer pour la concurrence provisionnée.
Activer SnapStart sur une version publiée. AWS prend un instantané de l'environnement d'exécution initialisé et reprend à partir de celui-ci.
Pourquoi: Gratuit pour Java ; facturé par restauration pour Python/.NET. Réduit les démarrages à froid de plusieurs secondes à <1s sans coût d'inactivité.
Lambda doit consommer un flux Kinesis / un flux DynamoDB / une file d'attente SQS / un sujet MSK.
Mappage de source d'événement (basé sur le pull). Lambda interroge ; taille du lot + fenêtre de regroupement maximale ajustent le débit vs la latence. Échec → DLQ via destination On-Failure.
Pourquoi: Pour les sources basées sur le pull, le service ne peut pas invoquer directement Lambda ; le mappage est l'adaptateur d'interrogation de Lambda.
Routage succès/échec de Lambda asynchrone sans DLQ Lambda.
Destinations OnSuccess / OnFailure sur la fonction. Cibles : SNS, SQS, EventBridge, une autre fonction Lambda. Inclut le contexte d'invocation.
Pourquoi: Les destinations capturent l'événement complet + la réponse ; la DLQ héritée ne capture que la charge utile de l'événement.
Choisir le type d'API Gateway pour une nouvelle API REST.
API HTTP : moins chère, plus rapide, authentification JWT intégrée, plus simple. API REST : fonctionnalités complètes (modèles de mappage, validateurs de requêtes, WAF, points de terminaison privés, X-Ray, mise en cache d'API).
Pourquoi: Utilisez l'API HTTP par défaut, sauf si vous avez besoin d'une fonctionnalité spécifique aux API REST. Les API WebSocket sont un produit distinct pour le temps réel avec état.
Promouvoir les modifications d'API de dev → test → prod sans redéployer des API distinctes.
Étapes sur une seule API. Déployez une étape pour publier ; les variables d'étape contiennent des valeurs spécifiques à l'environnement comme les noms d'alias Lambda.
Le backend Lambda s'attend à une forme différente de celle envoyée par le client.
Modèle de mappage requête/réponse (API REST uniquement). VTL avec `$input`, `$context`, `$util` pour transformer le JSON.
Pourquoi: Les modèles de mappage s'exécutent dans API Gateway — pas de saut Lambda supplémentaire, pas de latence ou de coût supplémentaire.
Valider un jeton personnalisé (pas Cognito, pas IAM) avant de router la requête.
Authorizer Lambda. Le type TOKEN lit un en-tête ; le type REQUEST lit le contexte de requête complet. Renvoie la politique IAM + principalId. Mis en cache par identité pour la durée de vie (TTL).
Valider un JWT de Cognito User Pool à chaque requête.
Authorizer Cognito User Pool (REST) ou authorizer JWT (HTTP). API Gateway valide le jeton ; aucune Lambda n'est nécessaire.
Pourquoi: La validation native est moins chère et plus rapide qu'un authorizer Lambda pour le cas courant du JWT.
Limiter/allouer le quota d'un consommateur d'API partenaire.
Plan d'utilisation + Clé API. Le plan associe les clés à une étape avec une limite de débit (req/sec) + rafale + quota (req/jour ou mois).
Réduire la charge du backend pour les requêtes GET répétées.
Cache au niveau de l'étape (API REST). TTL configurable ; clé de cache dérivée de la méthode + chemin + paramètres de requête/en-tête sélectionnés.
Mettre à jour un élément uniquement si une précondition est remplie (par exemple, statut == "PENDING").
PutItem/UpdateItem avec `ConditionExpression`. L'échec lève une `ConditionalCheckFailedException`.
Pourquoi: La vérification côté serveur évite les conflits de lecture-modification-écriture sans verrouillage.
Tout ou rien sur plusieurs éléments DynamoDB.
`TransactWriteItems` / `TransactGetItems`. Jusqu'à 100 éléments / 4 Mo ; 2 fois le coût WCU/RCU des écritures/lectures normales.
Incrémenter un compteur sans lecture-modification-écriture.
UpdateExpression `ADD count :inc`. Le serveur applique le delta de manière atomique.
Itérer un grand ensemble de résultats de requête/scan.
`LastEvaluatedKey` de la réponse → `ExclusiveStartKey` lors de l'appel suivant jusqu'à son absence. Limiter via le paramètre `Limit`.
Besoin d'un modèle d'accès supplémentaire au-delà de la clé primaire.
GSI : clé de partition + de tri alternative, cohérence éventuelle, capacité séparée, peut être ajoutée à tout moment. LSI : même clé de partition, clé de tri alternative, option de forte cohérence, doit être créée lors de la création de la table.
Indexer uniquement les éléments qui ont un attribut particulier (par exemple, seules les commandes ACTIVES).
Index sparse : omettez l'attribut sur les éléments que vous souhaitez exclure. Les éléments sans l'attribut indexé n'apparaissent pas dans le GSI/LSI.
Lecture/écriture en masse de plusieurs éléments.
`BatchGetItem` (jusqu'à 100 éléments / 16 Mo) et `BatchWriteItem` (jusqu'à 25 éléments / 16 Mo). Non atomique ; les échecs partiels sont retournés dans `UnprocessedItems`.
Empêcher les mises à jour perdues dues aux écrivains concurrents.
Attribut de version + `ConditionExpression: version = :v`. Les écritures échouées sont retentées par relecture.
Déclencher des actions en aval à chaque modification de DynamoDB.
DynamoDB Streams + mappage de source d'événement Lambda. Vue du flux : NEW_IMAGE / OLD_IMAGE / NEW_AND_OLD_IMAGES / KEYS_ONLY.
Le navigateur télécharge/téléverse directement vers S3 sans que votre serveur ne proxifie les octets.
SDK `getSignedUrl` pour GET ou PUT. Expiration jusqu'à 7 jours lorsqu'il est signé par un utilisateur IAM (sigv4) ; plus court pour les sessions dérivées de rôles.
Pourquoi: Décharge la bande passante de votre backend ; l'URL est une capacité temporaire limitée à un objet + méthode.
Téléverser un fichier volumineux (≫100 Mo) de manière fiable depuis le SDK.
`CreateMultipartUpload` → `UploadPart` parallèle → `CompleteMultipartUpload`. Le gestionnaire de transfert de haut niveau du SDK gère automatiquement le dimensionnement des parties.
Pourquoi: Obligatoire >5 Go ; recommandé ≥100 Mo. Les parties échouées sont re-téléversées indépendamment. Définissez le cycle de vie pour annuler les multiparts incomplets afin de récupérer de l'espace de stockage.
Exécuter du code lorsqu'un objet est créé/supprimé dans S3.
Notifications d'événements S3 → Lambda / SNS / SQS / EventBridge. Filtrer par préfixe et suffixe.
L'application navigateur récupère des données de S3 via des origines différentes (`fetch('https://bucket.s3...')`) ; la pré-vérification CORS échoue.
Configurer les règles CORS du bucket : origines autorisées, méthodes (GET/PUT), en-têtes et en-têtes exposés.
Filtrer les lignes d'un objet CSV/JSON/Parquet de 50 Go sans le télécharger.
S3 Select avec SQL. Ne renvoie que les lignes correspondantes ; payez pour le scan + les octets retournés.
Connecter un utilisateur depuis un client mobile/web public sans envoyer le mot de passe.
Cognito User Pool avec le flux `USER_SRP_AUTH`. Le client calcule la preuve SRP ; le backend ne voit jamais le mot de passe. Renvoie les jetons ID + accès + rafraîchissement.
Un utilisateur fédéré (Google/Apple/Cognito UP) a besoin de justificatifs AWS temporaires pour appeler les API AWS directement depuis une application mobile.
Cognito Identity Pool. Échange le jeton du fournisseur d'identité → rôle IAM → justificatifs AWS temporaires via STS.
Pourquoi: Les User Pools authentifient les utilisateurs ; les Identity Pools les autorisent à accéder aux ressources AWS.
Choisir un type de flux de travail Step Functions.
Standard : longue durée (≤1 an), exécution unique et exacte, 0,025 $/1k transitions, historique complet. Express : ≤5 min, au moins une fois ou au plus une fois, facturé par requête + durée ; pour l'ETL/streaming à haut volume.
Une étape du flux de travail échoue ; souhaiter une nouvelle tentative avec backoff et un routage vers un état de récupération.
Tableau `Retry` (par état, avec `BackoffRate` + `MaxAttempts`) et `Catch` pour le routage des échecs terminaux. Correspondance par `ErrorEquals` (par exemple `States.TaskFailed`, noms d'erreurs personnalisés).
Appliquer le même flux de travail à chaque élément d'un tableau, avec une limite de concurrence.
État Map avec `ItemsPath` et `MaxConcurrency`. La carte distribuée gère plus de 10 000 éléments avec une entrée sauvegardée par S3.
Déclencher Lambda soit selon une planification cron, soit en fonction d'événements entrants correspondants.
Règle EventBridge. Planification : `rate(...)` ou `cron(...)`. Modèle : filtre d'événements JSON ; correspondance sur la source, le type de détail, les champs de détail.
Router des événements de SQS / Kinesis / DynamoDB Streams / MSK vers une cible avec filtre + transformation optionnels.
EventBridge Pipes. Source → Filtre → Enrichissement (Lambda/Step Functions) → Cible. Aucune Lambda n'est nécessaire pour les cas simples.
Traiter les messages strictement dans l'ordre par client, avec déduplication.
File d'attente SQS FIFO. `MessageGroupId` partitionne l'ordonnancement (parallélisme par groupe) ; `MessageDeduplicationId` (ou déduplication basée sur le contenu) supprime les doublons dans les 5 minutes.
Un consommateur extrait un message mais plante avant de le supprimer.
Message masqué pendant VisibilityTimeout secondes, puis réapparaît pour une nouvelle livraison. Ajuster au temps de traitement attendu le plus long + tampon.
Pourquoi: Trop court → traitement en double. Trop long → récupération lente en cas de plantage. ChangeMessageVisibility prolonge la durée de visibilité si nécessaire.
Un événement doit atteindre plusieurs consommateurs (Lambdas / files d'attente SQS / points de terminaison HTTP).
Rubrique SNS avec plusieurs abonnés. Les politiques de filtrage d'abonnement acheminent uniquement les messages correspondants par abonné.
Ajuster la capacité de Kinesis Data Streams pour le débit d'écriture.
Chaque shard = 1 Mo/s ou 1000 enregistrements/s en entrée, 2 Mo/s en sortie. Ajouter des shards (split) ou utiliser le mode On-Demand pour l'auto-scaling.
Le code sur EC2 / tâche ECS / Lambda a besoin d'un accès AWS — pas de clés intégrées.
Attacher un rôle IAM via un profil d'instance (EC2) ou un rôle de tâche/exécution (ECS/Lambda). Le SDK extrait les informations d'identification temporaires du service de métadonnées ; rotation automatique.
Accès inter-comptes depuis le code de l'application ou la CLI.
`sts:AssumeRole` depuis le principal appelant. La politique de confiance du rôle cible liste l'appelant comme `Principal`. Renvoie des informations d'identification temporaires (max 12 heures).
AssumeRole inter-comptes échoue — la permission semble correcte.
Les deux doivent être configurés : la politique de confiance sur le rôle cible liste l'appelant comme Principal ; la politique d'identité de l'appelant autorise `sts:AssumeRole` sur l'ARN du rôle cible.
Pourquoi: Confiance = qui peut assumer. Permission = ce qu'ils peuvent faire une fois assumé. L'un ou l'autre manquant → Accès Refusé.
Politique qui accorde aux utilisateurs un accès uniquement à leur propre dossier dans S3.
Utiliser `${aws:username}` ou `${aws:PrincipalTag/X}` dans les ARN de ressource : `arn:aws:s3:::bucket/${aws:username}/*`.
Permettre à une équipe de gérer elle-même les rôles IAM, mais limiter les permissions qu'elle peut accorder.
Politique de limite de permissions sur le rôle créateur de l'équipe. Tout rôle qu'ils créent avec la limite a l'intersection de la politique d'identité + la limite comme permissions effectives.
Restreindre une action par IP source / VPC / région / MFA.
`Condition` de politique : `aws:SourceIp`, `aws:SourceVpc`, `aws:SourceVpce`, `aws:RequestedRegion`, `aws:MultiFactorAuthPresent`.
Client SPA / mobile vs service côté serveur appelant Cognito.
Clients publics (SPA, mobile) → client d'application sans secret. Clients confidentiels (serveur) → client d'application avec secret ; le client doit inclure `SECRET_HASH` (HMAC de nom d'utilisateur + clientId).
Distinguer le jeton ID Cognito vs le jeton d'accès vs le jeton de rafraîchissement.
ID = revendications d'identité utilisateur (à consommer côté client). Accès = autorisation limitée pour les API. Rafraîchissement = obtenir de nouveaux jetons ID/accès. Tous les JWTs sauf le Refresh.
Interface utilisateur de connexion/inscription prête à l'emploi sans construire de formulaires.
Interface utilisateur hébergée Cognito. Flux de code d'autorisation OAuth2 : redirection vers `/oauth2/authorize` → URL de rappel avec `code` → échange à `/oauth2/token`.
Chiffrer un petit secret (≤4 Ko) directement avec KMS.
`kms:Encrypt` renvoie un blob de texte chiffré contenant l'ARN de la clé. `kms:Decrypt` récupère le texte clair si l'appelant a la permission et (si spécifié) si le `EncryptionContext` correspond.
Chiffrer de grandes quantités de données avec KMS sans atteindre la limite de 4 Ko de chiffrement direct.
Chiffrement d'enveloppe. `GenerateDataKey` renvoie un DEK en texte clair + chiffré ; chiffrez les données localement avec le DEK, stockez le DEK chiffré à côté, jetez le DEK en texte clair.
Pourquoi: KMS applique le contrôle d'accès sur le petit DEK ; le chiffrement en masse se fait localement à la vitesse de la ligne.
Donner à un autre principal un accès limité dans le temps à une CMK sans modifier la politique de clé.
Créer une subvention `kms:CreateGrant` délimitant les opérations + le bénéficiaire. Révoquer avec `RetireGrant`.
Référencer une clé KMS indirectement afin que la CMK sous-jacente puisse être renouvelée sans modification de code.
Utiliser `alias/my-key` (ou `arn:aws:kms:region:acct:alias/my-key`). Mettre à jour l'alias pour pointer vers une nouvelle CMK ; les consommateurs continuent de fonctionner.
Choisir un magasin de justificatifs.
Secrets Manager : rotation intégrée, intégration native RDS/Redshift/DocumentDB, 0,40 $/secret/mois. Parameter Store SecureString : niveau gratuit (Standard), pas de rotation intégrée, chemins stratifiés `/app/env/key`.
Rotation automatique des justificatifs RDS.
Rotation native de Secrets Manager (Lambda gérée) pour Aurora/RDS/DocumentDB/Redshift. Le modèle maître/utilisateur utilise un secret maître séparé pour faire pivoter le secret utilisateur.
Stocker une valeur de configuration avec chiffrement KMS au repos dans Parameter Store.
Type de paramètre SecureString. Spécifier `--key-id` pour une CMK personnalisée ; sinon, utilise `aws/ssm`. Le déchiffrement nécessite `kms:Decrypt` sur la CMK.
Restreindre l'accès CloudFront aux utilisateurs authentifiés.
URL signées (ressource unique) ou cookies signés (ressources multiples, SPA/streaming). Signer avec une paire de clés CloudFront stockée comme clé publique dans un groupe de clés CloudFront.
Choisir le chiffrement côté serveur S3.
SSE-S3 (AES-256 géré, par défaut), SSE-KMS (CMK, audit via CloudTrail, politique de clé), SSE-C (clés fournies par le client, vous gérez), DSSE-KMS (double couche pour haute conformité).
Trouver les rôles/politiques qui accordent un accès en dehors du compte ou sont trop permissifs.
IAM Access Analyzer. Découvertes sur l'accès externe ; génération de politiques à partir de l'historique CloudTrail pour un dimensionnement optimal du moindre privilège.
La variable d'environnement Lambda contient une valeur sensible.
Lambda chiffre les variables d'environnement au repos avec KMS par défaut. Pour le contrôle en transit/au déchiffrement, configurez une CMK personnalisée et utilisez les assistants de chiffrement de la console pour expédier le texte chiffré pré-chiffré.
Navigateur → API Gateway avec en-tête `Authorization` est bloqué par la pré-vérification.
Ajouter la méthode OPTIONS (intégration fictive). Autoriser `Authorization` dans `Access-Control-Allow-Headers` ; autoriser les appelants dans `Access-Control-Allow-Origin`.
Signer une requête HTTP personnalisée vers un service AWS à partir de code non-SDK.
Sigv4 : dériver la clé de signature à partir du secret + date + région + service ; canoniser la requête ; signer ; ajouter les en-têtes `Authorization`, `X-Amz-Date`, `X-Amz-Security-Token`.
Assumer un rôle large mais le limiter pour une session spécifique.
`AssumeRole` avec `Policy` (politique de session en ligne) restreint davantage les permissions effectives : intersection du rôle + de la politique de session.
Accès S3 refusé même si la politique IAM l'autorise.
La politique de bucket et la politique d'identité sont toutes deux évaluées. Un refus explicite l'emporte partout. Les paramètres de blocage de l'accès public peuvent également annuler une autorisation.
Construire un pipeline CI/CD : source → build → test → déploiement avec approbation manuelle en production.
Étapes CodePipeline, chacune avec une ou plusieurs actions. Action d'approbation manuelle entre Test et Déploiement. Source = CodeCommit / GitHub / S3 / ECR.
Définir les étapes de build pour CodeBuild.
`buildspec.yml` à la racine du dépôt. Phases : `install`, `pre_build`, `build`, `post_build`. Sorties : `artifacts.files`, `cache.paths`. Variables d'environnement via `env.variables` ou références Parameter Store/Secrets Manager.
Déplacer le trafic Lambda à 10% puis 100% avec retour arrière automatique en cas d'alarmes.
CodeDeploy avec `LambdaCanary10Percent5Minutes` / `10Percent10Minutes` / `10Percent15Minutes` / `10Percent30Minutes`. Configurer les alarmes CloudWatch dans le DeploymentGroup.
Déploiement progressif de Lambda par incréments égaux.
`LambdaLinear10PercentEvery1Minute` / `2Minutes` / `3Minutes` / `10Minutes`. Chaque incrément déplace +10% jusqu'à 100%.
Déploiement bleu/vert pour un service ECS derrière un ALB.
Plateforme de calcul CodeDeploy = ECS. Crée un ensemble de tâches vertes ; l'ALB déplace l'écouteur vers le groupe cible vert ; approbation manuelle optionnelle avant le basculement du trafic et avant de terminer le bleu.
Mettre à jour un parc EC2 sans temps d'arrêt total du parc.
Déploiement sur place avec les configurations `OneAtATime` / `HalfAtATime` / `AllAtOnce`. Les hooks du groupe d'Auto Scaling suspendent le lancement de nouvelles instances pendant le déploiement.
Héberger des dépôts Git dans AWS avec un accès contrôlé par IAM.
CodeCommit. Authentification : clés SSH par utilisateur IAM, justificatifs Git HTTPS par utilisateur IAM, ou assistant de justificatifs AWS CLI. Déclenchements via SNS / Lambda sur push.
Choisir un outil IaC pour une application serverless.
CDK : langages de programmation (TS/Python/Java/Go/.NET), constructions d'application complètes, modèles multi-ressources. SAM : extension YAML de CFN, axé sur le serverless, plus simple. Les deux compilent en CloudFormation.
Définir une pile Lambda + API Gateway + DynamoDB avec un minimum de YAML.
`Transform: AWS::Serverless-2016-10-31`. Ressources : `AWS::Serverless::Function`, `Api`, `SimpleTable`. `sam build` → `sam deploy --guided`.
Structurer le code CDK.
`App` contient une ou plusieurs `Stack`s. Chaque Stack contient des constructs (L1/L2/L3). `cdk synth` → modèle CFN. `cdk deploy` déploie via CFN.
Choisir le niveau de construct CDK.
L1 = CFN brut (`CfnXxx`). L2 = wrappers organisés avec des valeurs par défaut sûres (les plus courants). L3 = modèles combinant plusieurs ressources pour des architectures complètes (par exemple `LambdaRestApi`).
Prévisualiser les changements avant de les appliquer à une pile CloudFormation.
`create-change-set` → examiner le JSON des ajouts/modifications/remplacements → `execute-change-set`. Les actions de remplacement entraînent la recréation des ressources.
La mise à jour de la pile échoue à mi-parcours.
CloudFormation annule automatiquement, sauf si `DisableRollback` est vrai. Bloqué en `UPDATE_ROLLBACK_FAILED` ? Utiliser `ContinueUpdateRollback` avec `ResourcesToSkip`.
Empêcher la mise à jour accidentelle d'une ressource critique (par exemple, une base de données RDS) lors des mises à jour de la pile.
Politique de pile : JSON refusant `Update:Replace` et `Update:Delete` sur l'ID logique de la ressource. Contournement avec une annulation explicite lors d'une mise à jour spécifique.
Réutiliser l'infrastructure entre les piles.
Piles imbriquées (`AWS::CloudFormation::Stack` avec `TemplateURL`) pour la réutilisation possédée par un seul parent. Inter-piles via Outputs + `Fn::ImportValue` pour un couplage plus étroit entre des piles séparées.
Injecter une valeur de Parameter Store ou un secret Secrets Manager dans un modèle CFN.
`{{resolve:ssm:/path/to/param}}`, `{{resolve:ssm-secure:/path}}`, `{{resolve:secretsmanager:secret-id:SecretString:json-key}}`. Résolu au moment du déploiement.
Choisir la politique de déploiement Elastic Beanstalk.
Tout-en-une fois (le plus rapide, temps d'arrêt), Glissant (pas d'instances supplémentaires, capacité partielle), Glissant avec lot additionnel (pas de perte de capacité, coût supplémentaire), Immutable (nouveau ASG, le plus sûr), Bleu/Vert (environnement séparé, échange de CNAMEs).
Personnaliser l'environnement Elastic Beanstalk (packages, fichiers, commandes de conteneur).
YAML `.ebextensions/*.config` dans le bundle source. Plateformes plus récentes : scripts shell `.platform/hooks/...` pour le cycle de vie prebuild/predeploy/postdeploy.
Besoin d'un artefact Lambda stable, qui ne mute jamais.
Publier une version numérotée. Code + la plupart de la configuration (mémoire, timeout, variables d'environnement, couches) sont figés. `$LATEST` est mutable ; les versions numérotées ne le sont pas.
Pousser une image Docker vers ECR pour ECS / EKS / Lambda.
`aws ecr get-login-password | docker login` → `docker tag` → `docker push`. Images de conteneur Lambda : image tirée une fois au déploiement ; l'image taguée doit être dans la même région.
Exécuter un traitement par lots ponctuel vs un service web à longue durée de vie sur ECS.
RunTask = tâche unique, se termine et s'arrête. Service = maintient N tâches souhaitées, redémarre les échecs, s'intègre avec ALB/NLB.
Réduire les coûts de calcul pour les charges de travail ECS tolérantes aux pannes.
Fournisseur de capacité Fargate Spot. Mélanger avec Fargate régulier via des poids et une base. Les tâches peuvent être interrompues avec un préavis de 2 minutes.
Tracer une requête qui se ramifie à travers Lambda → DynamoDB → HTTP externe.
Segments X-Ray par saut de service, sous-segments pour les appels en aval. La carte de service visualise la topologie + la latence. Les règles d'échantillonnage plafonnent le volume.
Attacher des données recherchables vs de référence à une trace X-Ray.
Annotations : indexées, filtrables dans la console (par exemple `customerId`, `tier`). Métadonnées : non indexées, forme libre (corps de requête, corps de réponse pour le débogage).
Le coût de X-Ray est élevé en production.
Règle d'échantillonnage personnalisée. Par défaut : les 1ère req/s + 5% supplémentaires. Les règles correspondent par service / chemin URL / méthode.
Interroger les logs Lambda pour les erreurs de la dernière heure, regroupées par tranche de 5 minutes.
CloudWatch Logs Insights : `fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(5m)`.
Générer une métrique personnalisée à partir d'un modèle de log (par exemple, nombre de `OutOfMemoryError`).
Filtre de métrique sur le groupe de logs. Le modèle correspond aux événements de log ; le filtre crée une métrique CloudWatch personnalisée sur laquelle vous pouvez déclencher une alarme.
Émettre des métriques personnalisées depuis Lambda sans appel API `PutMetricData` séparé.
Format de métrique intégré : écrire du JSON structuré vers stdout ; CloudWatch analyse les logs et crée des métriques. Moins cher et asynchrone.
Pourquoi: Découple le chemin de la métrique du chemin de la requête ; pas de latence API ni de permission IAM supplémentaire.
L'application émet des métriques personnalisées haute résolution chaque seconde.
`PutMetricData` avec `StorageResolution=1` pour une granularité de 1 seconde. La résolution standard est de 60 secondes ; la haute résolution coûte plus cher.
Les démarrages à froid de Lambda atteignent les cibles de latence p99.
Concurrence provisionnée pour une charge prévisible. SnapStart pour le code Java/Python à initialisation lourde. Dépendances légères, utiliser ARM/Graviton, déplacer l'initialisation lourde en dehors du gestionnaire.
Choisir la mémoire Lambda pour le meilleur coût/latence.
La mémoire met également à l'échelle le CPU + le réseau. Utiliser la machine à états AWS Lambda Power Tuning pour balayer la mémoire et trouver le point idéal pour votre charge de travail.
Une longue invocation Lambda atteint la limite stricte de 15 minutes.
Décomposer en Step Functions ; décharger vers Fargate (longue durée) ou Batch (HPC). Le maximum de Lambda est de 900 secondes ; non négociable.
`TooManyRequestsException` de Lambda ; limite de concurrence atteinte.
Concurrence réservée par fonction (plafonne + réserve) ou demande d'augmentation de la limite au niveau du compte. Les invocations asynchrones sont mises en file d'attente et retentées ; les invocations synchrones échouent.
DynamoDB renvoie `ProvisionedThroughputExceededException`.
CloudWatch `WriteThrottleEvents` / `ReadThrottleEvents`. Passer en mode On-Demand, augmenter la capacité provisionnée ou corriger une partition chaude avec une meilleure conception de clé.
Une clé de partition reçoit un trafic disproportionné ; limitation sous faible charge globale.
Repenser la clé de partition avec une cardinalité élevée. Pour les écritures : préfixer avec un shard aléatoire (par exemple `shard#user`) ; pour les lectures : dispersion-collecte (scatter-gather) à travers les shards.
Besoin d'une latence de lecture DynamoDB de l'ordre de la microseconde sans modifier la logique de l'application.
Cluster DAX + SDK DAX en remplacement direct du SDK DynamoDB. Les lectures sont servies depuis le cache en mémoire ; les écritures sont écrites en mode write-through vers la table.
Choisir une stratégie de mise en cache pour ElastiCache / DAX.
Chargement paresseux (cache miss → DB → remplir le cache) : ne met en cache que les données demandées, mais sujettes à l'obsolescence. Écriture immédiate (write-through) (écrire dans le cache + la DB à chaque écriture) : toujours frais, mais les écritures ont un coût supplémentaire. Le TTL limite l'obsolescence dans les deux cas.
API Gateway renvoie 429 Too Many Requests.
Niveau de compte par défaut : 10 000 req/sec + 5 000 en rafale. Surcharges par étape et par méthode ; limitation par clé via les plans d'utilisation pour le contrôle par niveau de partenaire.
Erreurs transitoires du service AWS lors d'un trafic intense.
Le SDK AWS réessaye automatiquement avec backoff exponentiel + jitter. Configurer `RetryMode = adaptive` ou `standard` ; ajuster `maxAttempts`.
CloudFront sert du contenu obsolète après un déploiement.
Invalider les chemins (`/index.html`, `/*`) — facturé par chemin au-delà de 1000/mois gratuits. Mieux : noms de fichiers versionnés (`app.abc123.js`) pour que le cache soit naturellement contourné.
