Amazon DOP-C02: Conteneurs et opérations serverless — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-C02 — Guide d’étude. 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.

Aperçu

Les conteneurs et le serverless changent la façon dont vous opérez, mettez à l’échelle et déployez des applications sur AWS. Cette section relie les primitives opérationnelles entre Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda et Amazon API Gateway afin que vous puissiez concevoir des déploiements sécurisés, appliquer la gouvernance des images, ajuster la simultanéité et faire des choix cohérents entre la capacité basée sur EC2 et celle basée sur Fargate. Elle se concentre sur les modèles de planification des tâches et des pods, les bilans de santé et les contrôles de déploiement, le basculement du trafic, la distribution d’images entre comptes et les fonctionnalités de performance telles que la mise en cache d’API et la simultanéité provisionnée de Lambda.

Amazon ECS et AWS Fargate

Les définitions de tâches ECS (task definitions) déclarent un ou plusieurs conteneurs et toute la configuration d’exécution nécessaire au planificateur. Les éléments clés incluent les réservations et limites de CPU/mémoire, les portMappings, les variables d’environnement et les secrets (provenant d’AWS Secrets Manager ou de Systems Manager Parameter Store), les paramètres Linux et les ulimits, la logConfiguration (awslogs, firelens, etc.), la taille de l’ephemeralStorage (pour Fargate, de 20 à 200 Go) et les volumes (y compris EFS). Utilisez le rôle d’exécution de la tâche (task execution role) pour extraire les images et pour les pilotes de logs ; utilisez le rôle de la tâche (task role) pour l’accès de l’application aux API AWS. Le healthCheck du conteneur définit la commande, l’intervalle, le timeout, les tentatives (retries) et la startPeriod. Combinés avec dependsOn (condition=HEALTHY), les bilans de santé imposent un ordre de démarrage pour les sidecars.

Les services ECS maintiennent le nombre de tâches souhaité (desired count) et enregistrent optionnellement les tâches auprès d’un ALB/NLB. La deploymentConfiguration du service contrôle les mises à jour progressives (rolling updates) avec minimumHealthyPercent et maximumPercent. Le disjoncteur de déploiement (deployment circuit breaker) (activé/rollback) peut automatiquement annuler les déploiements échoués lorsque les tâches échouent à leurs bilans de santé. L’autoscaling du service s’intègre avec Application Auto Scaling pour le suivi de cible (target tracking) basé sur le CPU/mémoire ou sur ALB RequestCountPerTarget. La découverte de services (AWS Cloud Map) et ECS Service Connect simplifient le trafic de service à service.

Types de cluster et capacité :

Le type de lancement EC2 exécute les tâches sur des instances EC2 autogérées. Utilisez des groupes Auto Scaling, des contraintes/stratégies de placement et n’importe quel networkMode (bridge/host/awsvpc). Les tâches de type daemon et les AMI spécialisées (par ex., Bottlerocket) sont prises en charge.
Le type de lancement Fargate est une puissance de calcul serverless pour les conteneurs. Il utilise uniquement le mode réseau awsvpc, donnant à chaque tâche sa propre ENI et son propre groupe de sécurité. Pas de tâches daemon ; vous dépendez des sidecars ou des intégrations natives aux services (par ex., FireLens). Les versions de plateforme conditionnent l’accès aux fonctionnalités (vérifiez les notes de version pour le support d’EFS, du stockage éphémère et d’exec). Fargate Spot réduit le coût pour les tâches interruptibles. Choisissez des paires CPU/mémoire prises en charge (par ex., de 0,25 vCPU/0,5–2 Go jusqu’à 16 vCPU/120 Go). Lors de l’exécution dans des subnets privés, ajoutez des points de terminaison d’interface VPC pour ECR (api et dkr), CloudWatch Logs, et un point de terminaison de passerelle S3 pour extraire les images et envoyer les logs sans passer par une NAT.

Fargate et EFS : définissez un volume EFS dans la définition de la tâche et montez-le avec TLS ; préférez les points d’accès EFS pour l’application du moindre privilège et de l’identité. Cela répond aux besoins avec état (stateful) comme les configurations partagées, les poids de modèles ou les fichiers intermédiaires, sans avoir à les intégrer dans les images.

Bilans de santé des conteneurs, mises à jour progressives et bleu/vert :

Les bilans de santé s’effectuent à plusieurs niveaux : conteneur (basé sur CMD), tâche ECS (statuts agrégés des conteneurs) et santé de la cible du load balancer (HTTP/TCP). Alignez les intervalles et les seuils pour qu’ECS puisse remplacer en douceur les tâches défaillantes avant que l’ALB ne désenregistre les cibles.
Les mises à jour progressives (rolling updates) sont le comportement par défaut d’ECS. Ajustez minHealthy/maxPercent pour contrôler la montée en charge (surge) et la sécurité de la capacité.
Le déploiement bleu/vert utilise CodeDeploy avec ECS (type de deploymentController :

undefined

). CodeDeploy gère deux groupes cibles derrière l’ALB, bascule le trafic de test vers l’ensemble vert (AfterAllowTestTraffic), exécute des vérifications automatisées (par exemple via Lambda), puis bascule le trafic de production. Associez des alarmes CloudWatch pour déclencher un rollback en cas de pics de 5XX, de latence ou sur des métriques personnalisées. Ce modèle isole les défaillances et permet des retours en arrière rapides avec un temps d’arrêt quasi nul.

Gouvernance des images avec ECR :

Analyse (Scanning) : activez l’analyse lors du push (scan-on-push) et adoptez l’analyse améliorée d’Amazon Inspector pour une couverture continue des CVE et des SBOM. Bloquez les déploiements en fonction de la gravité des vulnérabilités à l’aide de vérifications dans le pipeline.
Les politiques de cycle de vie (lifecycle policies) font expirer les anciens tags d’image par nombre/âge et par préfixe de tag. Combinez avec l’immuabilité des tags (tag immutability) pour bloquer les écrasements accidentels.
Chiffrement : utilisez le chiffrement géré par ECR ou une clé KMS gérée par le client avec une politique de clé appropriée.
Inter-comptes (Cross-account) : attachez des politiques de ressource au référentiel pour accorder les droits de pull/push à d’autres comptes ou rôles de CI. Utilisez les règles de réplication ECR pour copier les images entre régions/comptes pour la localité et la réduction du rayon d’impact (blast radius). PrivateLink (points de terminaison VPC) permet d’extraire des images sans passer par Internet.

Modèles de calcul Amazon EKS

EKS sépare le plan de contrôle (control plane) managé de vos choix pour le plan de données (data plane) :

Les groupes de nœuds managés (MNGs) provisionnent et gèrent le cycle de vie des nœuds de travail (worker nodes) EC2. Ils s’intègrent avec les modèles de lancement (launch templates) pour le choix de l’AMI (Amazon Linux 2, Bottlerocket), les types d’instance et les paramètres de bootstrap. Les MNGs gèrent les mises à jour progressives (rolling updates) avec une capacité de surcroît (surge capacity) et un cordon/drain automatisé pour une interruption minimale. Utilisez les taints/tolerations des nœuds pour diriger des charges de travail spécifiques. Combinez-les avec le Cluster Autoscaler (ou Karpenter) pour ajuster la capacité des nœuds en fonction des pods en attente (pending pods).

Les nœuds autogérés (self-managed) offrent un contrôle total sur le bootstrap et l’OS, mais ajoutent une surcharge opérationnelle ; ils sont généralement réservés pour des noyaux spéciaux ou du matériel de niche.

EKS sur Fargate exécute des pods sans avoir à gérer de nœuds. Les profils Fargate (Fargate profiles) mappent les namespaces/labels à Fargate. Chaque pod obtient sa propre ENI (awsvpc), ce qui simplifie l’isolation réseau. Les limitations incluent l’absence de DaemonSets, de réseau/volumes de l’hôte (host networking/volumes) et des contraintes sur les charges de travail privilégiées. Les agents d’observabilité (par ex., Fluent Bit) doivent s’exécuter en tant que sidecars ou utiliser la collecte de logs managée. Ce modèle est idéal pour les charges de travail avec des pics de trafic (spiky), à faible empreinte (small-footprint) ou multi-locataires (multi-tenant) qui bénéficient de l’isolation par pod et d’une facturation par pod.

Add-ons opérationnels :

VPC CNI, CoreDNS et kube-proxy sont des add-ons managés ; épinglez des versions compatibles avec la version du cluster et mettez-les à niveau de manière délibérée.
IAM Roles for Service Accounts (IRSA) applique le principe de moindre privilège pour l’accès AWS par pod et remplace le partage d’identifiants via le rôle du nœud.
L’équilibrage de charge via l’AWS Load Balancer Controller prend en charge les ALB/NLB pour les Services et les Ingress ; assurez-vous que les règles IAM et de groupe de sécurité sont correctes, en particulier lorsque vous mélangez MNG et Fargate.
Le stockage persistant via les drivers CSI (EBS pour le stockage en mode bloc par pod, EFS pour le stockage partagé POSIX). Pour Fargate, EFS est l’option typique pour l’état partagé.

Opérations et simultanéité (concurrency) AWS Lambda

Empaquetage et configuration :

Les paquets de déploiement (deployment packages) peuvent être des archives ZIP (avec un runtime de langage) ou des images de conteneur jusqu’à 10 Go. Le format ZIP est plus léger pour du code de petite taille ; les images unifient l’outillage avec les builds basés sur des conteneurs.
Les couches (Layers) encapsulent les bibliothèques partagées entre les fonctions ; gardez-les minimales et versionnées. Une fonction peut inclure jusqu’à cinq couches.
Les versions sont des instantanés (snapshots) immuables ; les alias sont des pointeurs stables vers des versions et peuvent porter des poids pour la répartition du trafic (traffic shifting).
Le stockage éphémère est de 512 Mo par défaut et peut être augmenté jusqu’à 10 240 Mo pour les builds, les fichiers temporaires ou les caches d’inférence ML. Choisissez x86_64 ou arm64 pour des compromis coût/performance. Utilisez des variables d’environnement pour la configuration et intégrez avec Secrets Manager ou Parameter Store.

Répartition du trafic et sécurité :

Utilisez CodeDeploy pour des déploiements progressifs de type canary/linear avec restauration automatique (rollback) sur des alarmes CloudWatch (par ex., erreurs 5XX, latence ou métriques applicatives personnalisées). Alternativement, définissez directement les poids des alias pour un routage A/B simple.
Utilisez la journalisation structurée vers CloudWatch Logs et créez des filtres de métriques (metric filters) pour dériver des métriques dimensionnées par opération/version/code sans modifier l’instrumentation des métriques. Activez X-Ray pour le traçage de latence de bout en bout.

Contrôles de la simultanéité :

La simultanéité non réservée (unreserved concurrency) puise dans le pool régional du compte. Des pics de trafic peuvent priver d’autres fonctions de ressources (starve).
La simultanéité réservée (reserved concurrency) plafonne la simultanéité maximale d’une fonction et lui garantit cette capacité en la prélevant du pool régional ; cela fournit une isolation contre les voisins bruyants (noisy neighbors).
La simultanéité provisionnée (provisioned concurrency) maintient des environnements d’exécution initialisés pour une version/un alias, éliminant quasiment les démarrages à froid (cold starts) et stabilisant la latence. Mettez à l’échelle la simultanéité provisionnée avec Application Auto Scaling en fonction de l’heure de la journée ou de métriques.
Le throttling (limitation) se produit lorsqu’une fonction atteint sa limite de simultanéité ; les appelants synchrones reçoivent des erreurs 429, tandis que les invocations asynchrones sont réessayées avec un backoff exponentiel et peuvent être envoyées à une file de lettres mortes (dead-letter queue) après les tentatives configurées. Pour les sources basées sur l’interrogation (poll-based) comme SQS, Lambda augmente la simultanéité avec la profondeur de la file d’attente ; assurez-vous que la simultanéité réservée/provisionnée et la capacité en aval correspondent au nombre maximum de messages en cours (inflight) pour éviter l’accumulation de backlog.

Conception d’API Gateway et accès inter-comptes à ECR

API REST d’API Gateway versus API HTTP :

Les API REST offrent l’ensemble de fonctionnalités le plus riche : mappage des requêtes/réponses (VTL), plans d’utilisation et clés d’API, autorisateurs, WAF et mise en cache au niveau de l’étape. Choisissez les API REST lorsque vous avez besoin de transformations avancées, de clés d’API avec des quotas ou d’intégrations d’écosystèmes matures.
Les API HTTP ont une latence et un coût inférieurs avec un routage plus simple vers les backends Lambda et HTTP (y compris les intégrations ALB/NLB/privées). Elles prennent en charge les autorisateurs JWT et IAM mais ne disposent pas de nombreuses fonctionnalités des API REST, notamment la mise en cache au niveau de l’étape et les transformations VTL. Choisissez les API HTTP pour une simple proxyfication avec une surcharge minimale.

Étapes et limitation (throttling) :

Les étapes lient un déploiement spécifique à un chemin d’URL. Configurez les variables d’étape, la journalisation et la limitation au niveau de l’étape. Appliquez des plans d’utilisation (REST) pour imposer des limitations et des quotas par clé d’API. Les paramètres de limitation incluent le débit (rate) et la rafale (burst) ; ils se combinent avec les limites au niveau du compte, alors assurez-vous que le trafic agrégé ne dépasse pas les quotas régionaux. Activez la journalisation des accès avec du JSON structuré et intégrez WAF pour inspecter et bloquer les requêtes malveillantes.

Mise en cache (API REST uniquement) :

La mise en cache au niveau de l’étape réduit la charge du backend et la latence ; définissez des TTL par méthode, activez le chiffrement et tenez compte des paramètres/en-têtes de la clé de cache pour garantir l’exactitude. Invalidez les caches après les déploiements qui modifient la forme ou le comportement des réponses.

Connectivité privée :

Choisissez le type de point de terminaison : optimisé pour les points de présence (edge) (REST, global via CloudFront), régional ou privé (points de terminaison de VPC). Les intégrations privées avec VPC Link se connectent aux backends NLB/ALB dans les VPC sans exposition publique.

Accès inter-comptes à ECR :

Utilisez les politiques de ressources de dépôt pour accorder les autorisations pull/push aux principaux (principals) dans d’autres comptes (rôles de CI/CD ou d’exécution). Si vous utilisez une clé KMS gérée par le client, étendez la politique de clé en conséquence. Pour la distribution multi-comptes, définissez des règles de réplication ECR pour cibler les comptes/régions de destination et validez l’intégrité de l’image avec l’immuabilité des balises (tags) et l’épinglage des digests dans les déploiements.

Scénario de problème pratique

Spotify modernise une pile de microservices de playlists pour réduire la variation de latence lors des pics de lancements et pour renforcer sa chaîne d’approvisionnement d’images à travers plusieurs comptes AWS.

Standardiser la construction et la gouvernance des images

Mettre en œuvre des dépôts ECR avec l’analyse lors du push (scan-on-push) et l’analyse améliorée d’Amazon Inspector. Ajouter l’immuabilité des balises (tags) et des politiques de cycle de vie pour conserver les N dernières versions par branche et élaguer les dérives. Configurer la réplication inter-régions/comptes depuis le compte de construction vers les comptes de production et de pré-production. Pourquoi : Inspector assure une couverture continue des CVE, l’immuabilité empêche le détournement de balise (tag hijacking), et la réplication localise les pulls pour réduire la latence de déploiement et le rayon d’impact (blast radius).

Servir des API sans état (stateless) sur ECS avec Fargate

Définir des définitions de tâches ECS avec awslogs et FireLens pour des journaux et des métriques structurés. Activer le healthCheck du conteneur et l’aligner avec les vérifications de santé du groupe cible de l’ALB. Monter un volume EFS pour une configuration partagée en lecture seule via un point d’accès. Exécuter les services sur Fargate avec une stratégie de fournisseur de capacité mélangeant Fargate et Fargate Spot pour l’efficacité des coûts. Pourquoi : Fargate supprime la gestion des nœuds et isole les tâches par ENI ; EFS évite d’intégrer les configurations dans les images et prend en charge les restaurations (rollbacks) atomiques de la configuration.

Déploiements sécurisés avec blue/green et tests automatisés

Basculer les services ECS vers un contrôleur de déploiement CodeDeploy. Configurer deux groupes cibles sur l’ALB. Utiliser un déploiement canary avec AfterAllowTestTraffic pour invoquer un exécuteur de tests Lambda qui sollicite les points de terminaison critiques en 5 minutes. Attacher des alarmes CloudWatch sur les erreurs 5XX et la latence p90 pour déclencher une restauration (rollback). Pourquoi : Le déploiement blue/green de CodeDeploy isole le risque, le hook de test valide l’environnement ‘green’ avant le basculement complet, et les alarmes permettent une restauration automatisée et objective.

Opérations sensibles à la latence sur Lambda avec des démarrages à froid (cold starts) stabilisés

Pour une API d’aide à la tokenisation, empaquetez la fonction en tant que ZIP avec des dépendances minimales. Créez une version/un alias et activez la concurrence provisionnée dimensionnée pour les pics. Pilotez la concurrence provisionnée via Application Auto Scaling avec une planification quotidienne qui suit les fenêtres de lancement. Utilisez un déploiement canary CodeDeploy (10 %/15 minutes) pour une répartition du trafic basée sur les alias, liée aux alarmes CloudWatch. Pourquoi : La concurrence provisionnée élimine les démarrages à froid lors des pics de charge ; les déploiements canary sur alias permettent une exposition progressive avec une restauration rapide.

Exposer les API externes via API Gateway et sécuriser les backends privés

Placer API Gateway en frontal du Lambda et de l’ALB d’ECS. Utiliser des API HTTP pour le proxy Lambda afin de minimiser le coût/la latence. Utiliser une API REST pour le chemin de l’ALB d’ECS qui nécessite un mappage requête/réponse et une mise en cache au niveau de l’étape pour les points de terminaison à forte lecture. Appliquer des ACL web WAF et une limitation au niveau de l’étape ; activer les journaux d’accès structurés. Pourquoi : Adapter les types d’API aux besoins optimise les coûts et les capacités ; la mise en cache réduit la charge ; WAF et la limitation ajoutent une protection lors des pics d’événements.

Pulls d’exécution inter-comptes sans Internet

Dans les VPC d’exécution, ajoutez des points de terminaison d’interface pour ECR (api, dkr) et CloudWatch Logs, ainsi qu’un point de terminaison de passerelle S3. Attachez des politiques de ressources de dépôt ECR pour permettre aux rôles d’exécution de tâches du compte de production d’effectuer des pulls. Utilisez une clé KMS gérée par le client avec une politique de clé inter-comptes pour le chiffrement des images au repos. Pourquoi : Les pulls d’images privés évitent les coûts de NAT et les risques de sortie (egress) ; des politiques de ressources/clés explicites appliquent un accès inter-comptes selon le principe du moindre privilège.

Cette conception réduit la charge opérationnelle (pas de nœuds à gérer), fournit une latence déterministe via la concurrence provisionnée et des déploiements alignés sur la santé de l’ALB, et garantit la provenance des images de bout en bout avec l’analyse, la réplication et l’immuabilité d’ECR.

← Sécurité · Tous les domaines · Haute disponibilité →

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