Amazon SAA-C03: Conteneurs et orchestration — 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.

Choisir entre ECS et EKS, et entre EC2 et Fargate

La première décision d’architecture pour toute charge de travail de conteneurs sur AWS consiste à choisir l’orchestrateur et le mode de calcul. Amazon ECS est un orchestrateur propriétaire d’AWS avec une intégration étroite avec IAM, ALB/NLB, CloudWatch, Service Discovery et le réseau VPC. Il n’a pas de frais pour le plan de contrôle et constitue le chemin le plus rapide vers la production pour les équipes qui n’ont pas besoin d’outillage spécifique à Kubernetes. Les tâches (Tasks) sont des unités d’un ou plusieurs conteneurs partageant un cycle de vie ; les services sont des ensembles de tâches gérés sur le long terme et pilotés par un planificateur (scheduler). Amazon EKS exécute une version de Kubernetes conforme à la version upstream pour un forfait de 0,10 $/heure par cluster, et c’est le bon choix lorsque les charges de travail doivent rester portables, utiliser l’API Kubernetes ou tirer parti de l’écosystème CNCF (Helm, CRD, Operators). Le plan de contrôle — serveur d’API, etcd, gestionnaire de contrôleurs, planificateur (scheduler) — est patché, sauvegardé et rendu hautement disponible sur trois zones de disponibilité (AZ) par AWS.

Les deux orchestrateurs acceptent deux modes de calcul. AWS Fargate exécute chaque tâche ou pod sur des micro-VMs Firecracker isolées ; il n’y a pas d’AMI à patcher, pas de fournisseurs de capacité (capacity providers) d’Auto Scaling Group à régler, pas de décisions de bin-packing, pas d’hôtes accessibles en SSH. Vous payez à la seconde de vCPU et à la seconde de Go de la tâche. Le type de lancement EC2 / les groupes de nœuds gérés (managed node groups) signifient que vous possédez les instances, avec la flexibilité et la charge opérationnelle que cela implique.

Fargate est le bon choix par défaut chaque fois qu’un scénario met l’accent sur « sans serveur » (serverless), « charge opérationnelle minimale » ou « aucune infrastructure à gérer », à condition que la charge de travail respecte ses contraintes : maximum 16 vCPU / 120 Go de mémoire par tâche, pas de GPU, pas de conteneurs privilégiés, pas de DaemonSets, pas de HostPort/HostNetwork, pas de personnalisation au niveau de l’hôte Windows. Choisissez les groupes de nœuds gérés ou le type de lancement EC2 lorsque vous avez besoin de GPU, de DaemonSets qui nécessitent un accès à l’hôte, d’AMI personnalisées, de conteneurs Windows Server avec GMSA, d’une efficacité de bin-packing inférieure à la seconde ou d’une optimisation agressive des coûts basée sur Spot.

Le piège classique est de choisir des nœuds EC2 parce qu’ils « semblent » moins chers. Pour les charges de travail en pic ou à faible utilisation, Fargate est souvent moins cher une fois que l’on prend en compte la capacité inutilisée ainsi que le temps d’ingénierie pour le patching des AMI, le drainage des nœuds et la configuration du cluster autoscaler — tout ce que Fargate élimine.

Définitions de tâches, placement et fournisseurs de capacité

Une définition de tâche (task definition) canonique pour ECS Fargate capture l’essentiel — le dimensionnement CPU/mémoire, un rôle d’exécution pour récupérer les images et écrire les journaux, le mode réseau awsvpc et la connexion à CloudWatch Logs :

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

Sur ECS avec EC2, les stratégies de placement des tâches (task placement strategies) décident comment les tâches sont réparties entre les instances. Elles se composent dans l’ordre :

Les contraintes de placement telles que distinctInstance ou memberOf utilisant le langage de requête du cluster (cluster query language) restreignent davantage les candidats.

Les fournisseurs de capacité (Capacity providers) découplent les services des Auto Scaling Groups bruts. FARGATE et FARGATE_SPOT sont des fournisseurs gérés ; les fournisseurs personnalisés encapsulent un ASG et activent la mise à l’échelle gérée (managed scaling) afin qu’ECS ajuste le nombre désiré (desired count) de l’ASG en fonction du nombre de tâches provisionnées. Une stratégie de fournisseur de capacité répartit les tâches par poids (weight) et base (base) — par exemple, en garantissant deux tâches Fargate à la demande et en répartissant le reste à 1:4 avec Fargate Spot pour les charges de travail tolérantes aux interruptions :

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

Mise à l’échelle automatique (Autoscaling) : Pods, Tâches et Nœuds

Fargate supprime la gestion des nœuds, mais il ne met pas automatiquement à l’échelle le nombre de tâches ou de pods. Cette distinction est l’idée fausse la plus répandue concernant Fargate : le « sans serveur » s’applique à la couche hôte, jamais au nombre désiré (desired count) de votre service. Vous êtes toujours responsable de la mise à l’échelle automatique au niveau du service.

Pour ECS, utilisez Application Auto Scaling. Le suivi de cible (Target tracking) est le choix idiomatique par défaut car il crée automatiquement les alarmes CloudWatch de montée en charge (scale-out) et de réduction (scale-in) et respecte les délais de récupération (cooldowns). Les métriques judicieuses sont ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization et ALBRequestCountPerTarget :

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

La mise à l’échelle par paliers (Step scaling) et la mise à l’échelle planifiée (scheduled scaling) restent disponibles pour les courbes de réponse non linéaires ou les fenêtres de trafic connues.

Pour EKS sur des nœuds EC2, la dimension des pods est gérée par le Horizontal Pod Autoscaler (HPA), qui ajuste le nombre de réplicas en fonction du CPU, de la mémoire ou de métriques personnalisées. Le HPA seul ne peut pas ajouter de nœuds — il augmentera volontiers le nombre de réplicas au-delà de la capacité du cluster, moment auquel les nouveaux pods entreront en état Pending avec des événements FailedScheduling. C’est pourquoi le HPA sur EC2 doit toujours être associé soit au Kubernetes Cluster Autoscaler, soit à Karpenter. Oublier cette association est une erreur de conception fréquente : le HPA signale « mis à l’échelle à 20 réplicas » alors que la moitié d’entre eux sont bloqués en attente (pending). Une configuration minimale du Cluster Autoscaler découvre les groupes de nœuds grâce aux tags des ASG :

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

Sur les profils Fargate, ce problème disparaît — chaque pod devient sa propre micro-VM, éliminant ainsi complètement la dimension de mise à l’échelle des nœuds. C’est précisément pourquoi Fargate est le bon choix pour les charges de travail en rafale (bursty) avec un nombre de pods imprévisible.

Profils Fargate et leurs limitations fonctionnelles

Un profil Fargate dans EKS est un sélecteur — un espace de noms (namespace) plus des étiquettes (labels) de pod facultatives — qui indique à EKS de planifier les pods correspondants sur Fargate plutôt que sur un nœud :

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

La mise en garde essentielle est qu’EKS sur Fargate ne prend pas en charge toute la surface des fonctionnalités de Kubernetes :

• Les DaemonSets ne s’exécutent pas. Sans nœud sur lequel s’exécuter en tant que démon, les expéditeurs de logs comme les DaemonSets fluentd doivent être remplacés par des sidecars ou par le routeur de logs intégré Fluent Bit.
• Les conteneurs privilégiés, HostPort et HostNetwork ne sont pas disponibles.
• Le stockage persistant est limité à EFS via le pilote CSI. EBS n’est pas pris en charge car les volumes EBS nécessitent d’être attachés à une instance EC2 spécifique.
• Les charges de travail GPU ne sont pas prises en charge.
• Les services NodePort et les maillages de services (service meshes) qui dépendent de conteneurs d’initialisation privilégiés ne fonctionnent pas.

Présumer une parité des fonctionnalités conduit à des échecs de migration pour les StatefulSets qui nécessitent EBS, les contrôleurs d’ingress qui utilisent hostPort, ou les charges de travail d’inférence GPU.

Ingress : ALB vs NLB via l’AWS Load Balancer Controller

L’AWS Load Balancer Controller est un contrôleur Kubernetes qui traduit les objets Ingress et Service en véritables ALB et NLB. Pour les microservices HTTP/HTTPS avec un routage basé sur le chemin (path) ou l’hôte (host), créez un unique objet Ingress de classe alb. Un seul ALB en frontal de plusieurs services (via alb.ingress.kubernetes.io/group.name) est considérablement moins cher qu’un ALB par service et constitue le modèle canonique le plus rentable :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

Utilisez un NLB (Service de type LoadBalancer avec service.beta.kubernetes.io/aws-load-balancer-type: external et un type de cible nlb-ip) pour le TCP, l’UDP, le pass-through TLS, les exigences d’IP statique ou un débit extrême en Couche 4. Placer un proxy de base de données gRPC-sur-HTTP/2 ou TCP simple derrière un ALB n’est acceptable que pour gRPC (l’ALB prend en charge HTTP/2 et gRPC) ; l’ALB ne peut pas terminer du TCP arbitraire ni aucun trafic UDP. Tenter de servir du trafic de jeu UDP via un ALB est une inadéquation de protocole qui doit être détectée lors de la phase de conception.

IAM au niveau du pod avec IRSA

IAM Roles for Service Accounts (IRSA) est le mécanisme correct pour accorder des permissions d’API AWS à des pods individuels. Attacher le profil d’instance du nœud pour donner aux pods un accès à S3 est une erreur, car chaque pod sur le nœud hérite de ces permissions, violant ainsi le principe du moindre privilège. IRSA fonctionne en fédérant le fournisseur OIDC du cluster avec IAM : créez le fournisseur OIDC une seule fois, puis créez un rôle IAM dont la politique de confiance (trust policy) fait confiance à ce fournisseur pour un sujet namespace:serviceaccount spécifique.

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

Le compte de service (service account) est annoté avec eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role, et les pods qui le montent reçoivent des informations d’identification STS à courte durée de vie via un jeton projeté. Omettre l’association du fournisseur OIDC ou l’annotation entraîne un repli silencieux sur le rôle du nœud — une régression de sécurité subtile et facile à manquer lors d’une revue.

Le plugin VPC CNI complète cela en attribuant à chaque pod une adresse ENI/IP routable dans le sous-réseau du VPC. Les pods peuvent alors communiquer directement avec RDS, ElastiCache ou les points de terminaison VPC en utilisant des groupes de sécurité, et CloudTrail voit l’adresse IP réelle du pod pour l’audit.

Stockage persistant et éphémère

Le choix du stockage dépend du mode d’accès, de la durabilité et du type de lancement.

EBS (via le pilote EBS CSI sur EKS, ou EBS attaché à la tâche sur ECS) fournit des volumes de blocs ReadWriteOnce pour les charges de travail stateful à pod unique, comme une base de données primaire Postgres. EFS fournit un stockage NFS ReadWriteMany qui est régional, multi-AZ et montable par de nombreux pods simultanément — le choix correct chaque fois que l’exigence mentionne “haute disponibilité, tolérance aux pannes, partagé entre plusieurs conteneurs” ou des artefacts de ML partagés. FSx for Lustre gère le HPC à haut débit ; FSx for NetApp ONTAP et FSx for Windows File Server gèrent le NFS/SMB d’entreprise.

Les tâches Fargate reçoivent 20 Go de stockage éphémère par défaut, configurable jusqu’à 200 Go via ephemeralStorage.sizeInGiB sur la plateforme 1.4.0+. Supposer que Fargate dispose toujours de “beaucoup d’espace de travail” est un piège : un conteneur tiers qui écrit 50 Go de fichiers intermédiaires peut tenir dans le stockage éphémère étendu, mais si l’exigence est de 50 Go de stockage partagé ou durable entre les redémarrages de tâches ou entre les tâches, le stockage éphémère est le mauvais choix car il est détruit à l’arrêt de la tâche et n’est jamais partagé. Fargate ne prend pas en charge EBS. Si une charge de travail Fargate a besoin d’un stockage persistant ou partagé, EFS est essentiellement la seule option prise en charge.

Pour ECS, montez EFS directement dans la définition de la tâche ; les points d’accès appliquent un UID/GID POSIX et un répertoire racine par tâche, offrant une multi-location (multi-tenancy) sécurisée sur un seul système de fichiers, et l’autorisation IAM limite la portée à elasticfilesystem:ClientMount :

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

Pour EKS, connectez EFS via une StorageClass :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

Un piège récurrent : sélectionner Fargate pour une charge de travail stateful en oubliant d’installer le pilote EFS CSI et la StorageClass — les pods démarrent mais les PersistentVolumeClaims restent à l’état Pending indéfiniment. Inversement, choisir des nœuds EC2 uniquement pour attacher EBS lorsque l’exigence est un stockage partagé multi-écrivain est également une erreur ; un volume EBS io2 attaché à un seul nœud ne peut pas être partagé entre plusieurs zones de disponibilité (AZ).

Analyse d’images et cycle de vie ECR

Amazon ECR propose deux modes d’analyse. L’analyse de base utilise la base de données open-source Clair et s’exécute lors d’un push (ou à la demande) sans frais. L’analyse améliorée intègre Amazon Inspector, surveille en continu les CVEs du système d’exploitation et des paquets de langage, et rapporte les résultats dans Security Hub. Pour “analyser les CVEs, analyser les nouvelles images à leur création, avec le moins de changements possible aux charges de travail”, l’action correcte est d’activer l’analyse au push (scan on push) au niveau du dépôt — aucun changement de pipeline n’est requis car l’événement de push déclenche l’analyse :

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

Le CI/CD appelle ensuite describe-image-scan-findings et fait échouer les builds en cas de détection de vulnérabilités CRITICAL ou HIGH. Ignorer l’analyse signifie que des CVEs non corrigées pour Log4j, OpenSSL ou glibc s’exécutent en production ; le coût de mitigation lié à la non-analyse éclipse le coût quasi nul de son activation.

Les politiques de cycle de vie plafonnent les coûts de stockage et imposent une hygiène des tags :

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Migration des charges de travail Kubernetes + MongoDB

Lors d’un lift-and-shift d’une pile Kubernetes + MongoDB auto-hébergée vers AWS avec les contraintes « ne pas modifier le code de l’application » et « surcharge opérationnelle minimale », deux décisions s’imposent. Premièrement, la couche de calcul est déplacée vers EKS car la compatibilité de l’API Kubernetes signifie que les manifestes et les chartes Helm sont portés sans modification ; utilisez les profils Fargate pour les services sans état (stateless) afin d’éliminer la gestion des nœuds.

Deuxièmement, MongoDB lui-même ne doit pas être ré-hébergé sur des instances EC2 autogérées ou des StatefulSets — cela réintroduirait les sauvegardes, le sharding, le basculement (failover) et l’application de correctifs comme des fardeaux opérationnels. Utilisez Amazon DocumentDB (avec compatibilité MongoDB), qui parle le protocole filaire (wire protocol) de MongoDB 3.6/4.0/5.0, de sorte que les pilotes et les chaînes de connexion existants fonctionnent avec des changements minimes.

La mise en garde sur la compatibilité est importante. DocumentDB émule la surface de l’API MongoDB mais n’est pas MongoDB. Certains opérateurs d’agrégation, types d’index spécifiques, sémantiques de flux de changements (change stream) et fonctionnalités introduites dans les versions plus récentes de MongoDB peuvent échouer. L’étape de pré-migration correcte consiste à exécuter l’outil de compatibilité DocumentDB (compat.py) sur l’application pour confirmer que chaque opération est prise en charge. Choisir DynamoDB à la place forcerait une réécriture du modèle de données ; choisir RDS briserait entièrement le modèle de document. Les deux violent la contrainte « pas de changement de code ».

Options Hybrides : ECS Anywhere et EKS Anywhere

ECS Anywhere enregistre des serveurs sur site (ou des VM d’autres clouds) en tant qu’instances externes dans un cluster ECS. Le plan de contrôle (control plane) reste dans AWS ; l’agent SSM et l’agent ECS sur l’instance externe se connectent en sortie. Un seul pipeline de déploiement, une seule définition de tâche et un seul ensemble de rôles IAM couvrent à la fois les charges de travail cloud et sur site (on-prem).

EKS Anywhere installe une distribution Kubernetes conforme sur votre matériel (généralement vSphere ou bare metal), avec en option une visibilité via EKS Connector dans la console AWS. Choisissez ECS Anywhere pour un mode hybride léger basé sur des définitions de tâches ; choisissez EKS Anywhere lorsque des contraintes réglementaires ou de latence exigent Kubernetes localement avec le même outillage qu’EKS dans le cloud. Les deux maintiennent la cohérence de l’orchestration — la valeur fondamentale est que les équipes évitent de maintenir deux systèmes CI/CD ou deux modèles mentaux.

Visibilité Multi-Cluster avec EKS Connector

Les organisations exploitent fréquemment un mélange de clusters EKS, de clusters Kubernetes autogérés sur EC2 et de clusters sur site. L’Amazon EKS Connector enregistre n’importe quel cluster Kubernetes conforme dans la console EKS, offrant une vue centralisée (single pane of glass) pour les nœuds, les charges de travail et les métadonnées du cluster. Il s’agit essentiellement d’un agent léger plus un canal SSM — la réponse à faible surcharge pour une « vue centrale de tous les clusters ». Construire une visibilité équivalente avec Rancher, Anthos auto-hébergés, ou une fédération Prometheus/Grafana personnalisée est faisable mais beaucoup plus coûteux sur le plan opérationnel et ne s’intègre pas avec IAM ou l’accès basé sur la console.

EKS Connector est strictement une couche de visibilité ; il ne gère ni ne met à niveau le cluster distant, ce qui est exactement ce que « vue centrale avec le moins de surcharge » implique.

Synthèse des modèles

Pour une charge de travail e-commerce avec un frontal à répartition de charge (load-balanced), un niveau intermédiaire conteneurisé et une base de données relationnelle où le critère est « le moins d’intervention manuelle possible », la pile canonique est ALB → ECS sur Fargate → Aurora Serverless v2. Chaque niveau élimine la gestion au niveau de l’instance : l’ALB est entièrement géré, Fargate supprime les hôtes, et Aurora Serverless v2 s’adapte en ACU sans dimensionnement d’instance.

Pour une plateforme de microservices où l’équipe « ne peut pas gérer d’infrastructure supplémentaire », la combinaison correcte est ECS ou EKS avec Fargate, plus un service de données entièrement géré. Sélectionner le type de lancement EC2 ou des groupes de nœuds autogérés contredit la contrainte, même si la charge de travail fonctionnerait techniquement.

Pour un lift-and-shift de Kubernetes + MongoDB, la réponse converge vers EKS + DocumentDB : l’API Kubernetes préserve les méthodes de déploiement, DocumentDB préserve la compatibilité des pilotes, et les profils Fargate préservent une surcharge opérationnelle minimale — à condition que l’utilisation des fonctionnalités Kubernetes et la surface des commandes MongoDB de la charge de travail se situent dans les enveloppes prises en charge décrites ci-dessus.

← Calcul · Tous les domaines · Architectures Serverless et événementielles →

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

Parcourir Amazon →