Amazon SAP-C02: Calcul et Auto Scaling — Guide d'étude

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fait partie du AWS Solutions Architect Professional SAP-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.

Conception, stockage et mise en réseau des instances EC2

La conception des instances EC2 commence par l’adéquation des caractéristiques de la charge de travail avec les familles d’instances, en équilibrant le vCPU, la mémoire, le réseau et le stockage local. Choisissez des types optimisés pour le calcul (C), la mémoire (R/X), le stockage (I/D) ou les GPU (P/G) en vous basant sur le profilage. Tirez parti des instances basées sur Nitro et de l’ENA/SR-IOV pour un débit réseau élevé et une faible latence. Pour les données temporaires sensibles à la latence ou nécessitant un nombre élevé d’IOPS, envisagez le stockage d’instance (éphémère) sur des SSD I3/I4 ou Nitro ; pour le stockage en mode bloc durable, utilisez EBS avec des IOPS provisionnés (io2/io2 Block Express) et activez le chiffrement EBS avec KMS pour la gestion des clés. Lorsque les instances se trouvent dans des VPC derrière des Application Load Balancers, assurez-vous que les ALB accessibles depuis Internet sont placés dans des sous-réseaux publics et que les cibles résident dans des sous-réseaux privés ; un mauvais positionnement des ALB ou une mauvaise configuration des groupes de sécurité est un piège courant. Utilisez les groupes de placement (cluster pour le HPC à faible latence, partition pour les systèmes distribués avec état à grande échelle, spread pour l’isolation des pannes) pour influencer le placement, mais acceptez les compromis : le mode cluster offre les meilleures performances mais réduit la tolérance aux pannes au niveau de la zone de disponibilité (AZ). Pour le chiffrement des données en transit, utilisez la terminaison TLS au niveau de l’ALB ou le TLS de bout en bout avec le mode passthrough du NLB. Les critères de décision pèsent le coût par rapport à la performance : les types d’instances plus denses réduisent les coûts mais peuvent augmenter le rayon d’impact (blast radius) et les coûts de licence ; préférez un dimensionnement juste (right-sizing) guidé par CloudWatch, AWS Compute Optimizer et des tests de charge plutôt que par des règles empiriques.

Groupes Auto Scaling, politiques et gestion du cycle de vie

Les groupes Auto Scaling (ASG) doivent être conçus pour l’élasticité, la résilience et la rentabilité en utilisant une combinaison de modèles de lancement (launch templates), de politiques d’instances mixtes, de hooks de cycle de vie et de politiques de mise à l’échelle. Utilisez les modèles de lancement pour versionner l’AMI, les surcharges de type d’instance, les configurations EBS et les données utilisateur (user-data) ; les instances mixtes avec une allocation Spot optimisée pour la capacité ou une stratégie diversifiée réduisent le risque d’interruption et diminuent les coûts. Pour le comportement de mise à l’échelle, préférez les politiques de suivi de cible (target-tracking) pour les métriques prévisibles (CPU, nombre de requêtes par cible) et la mise à l’échelle par paliers (step-scaling) lorsque des actions multi-étapes basées sur des seuils sont nécessaires ; la mise à l’échelle prédictive peut pré-provisionner la capacité pour des schémas diurnes connus. Implémentez des hooks de cycle de vie pour exécuter des tâches d’initialisation personnalisées ou de drainage (drain) avant la terminaison ; combinez les pools pré-chauffés (warm pools) pour réduire le temps de mise en service et la mise à l’échelle planifiée pour les niveaux de base des heures de bureau. Les vérifications de l’état de santé (health checks) doivent intégrer celles d’ELB et d’EC2 pour éviter un remplacement prématuré. Faites attention aux pièges comme l’agitation lors du scale-in (scale-in churn) causée par des délais de récupération (cooldowns) agressifs, une pondération incorrecte des instances dans les ASG mixtes, et la non-prise en compte du temps de pré-chauffage de l’application. Pour les services avec état (stateful), évitez un scale-in rapide qui entraîne la perte des caches en mémoire ; pour le compromis coût/résilience, la capacité basée sur des instances Spot avec un repli sur des instances à la demande (On-Demand) offre des économies mais nécessite une gestion des interruptions, tandis qu’une capacité 100 % à la demande maximise la prévisibilité à un coût plus élevé.

Conteneurs et orchestration : choix entre ECS, EKS et Fargate

Le choix entre Amazon ECS, EKS et Fargate dépend du modèle opérationnel, des besoins en matière de contrôle et des schémas de charge de travail. Fargate supprime la gestion des nœuds et est idéal pour les équipes qui privilégient la simplicité opérationnelle, mais il présente une tarification par vCPU plus élevée et des limites de stockage éphémère ; il prend en charge Fargate Spot pour réaliser des économies. ECS offre une intégration étroite avec AWS et une simplicité pour les clients qui souhaitent une orchestration de conteneurs sans la complexité de Kubernetes. EKS est approprié lorsque l’écosystème Kubernetes, la portabilité ou une planification avancée sont requis ; envisagez les groupes de nœuds gérés ou les nœuds autogérés (Self-Managed) + Karpenter pour un dimensionnement juste dynamique. Les limites réseau (densité d’ENI/pods) et le comportement du CNI influencent la densité de pods et le dimensionnement des nœuds ; sur EKS, les rôles IAM pour les comptes de service (IAM Roles for Service Accounts) et le CSI EBS pour les volumes persistants réduisent la prolifération des informations d’identification et permettent un stockage par pod. Pour les systèmes de fichiers partagés, utilisez EFS (NFS) ou FSx (Lustre) en fonction des besoins en débit et en latence ; évitez les conteneurs s’appuyant sur NFS pour les opérations à forte charge de métadonnées — préférez EFS avec des modes de débit ajustés à la charge de travail. Implémentez le cluster autoscaler ou Karpenter pour la mise à l’échelle des nœuds et la mise à l’échelle automatique des services avec les métriques de service ALB/ECS. Les pièges courants incluent l’ignorance des budgets d’interruption de pod (pod disruption budgets), la sous-estimation des quotas du plan de contrôle Kubernetes, et le sur-provisionnement des nœuds plutôt que l’utilisation de stratégies de placement optimisé (bin-pack) ; les compromis entre le contrôle, le coût et la charge opérationnelle devraient guider la sélection.

Modèles de calcul sans serveur, contraintes de Lambda et conception orientée événements

Le sans serveur réduit la charge opérationnelle mais nécessite des modèles d’architecture qui gèrent la simultanéité, l’état et les limites des systèmes en aval. Lambda est excellent pour les tâches de courte durée et orientées événements, les backends d’API via API Gateway ou un ALB, et le traitement asynchrone avec SQS ou SNS. Utilisez Step Functions pour orchestrer les workflows de longue durée et DynamoDB ou RDS Proxy pour l’accès aux bases de données afin d’atténuer les tempêtes de connexions. Soyez conscient de la surcharge de démarrage à froid (cold-start) de Lambda dans un VPC, causée par la création d’ENI ; atténuez-la avec la simultanéité provisionnée pour les points de terminaison sensibles à la latence ou utilisez des points de terminaison de VPC et RDS Proxy pour limiter les connexions. Implémentez le fan-out/fan-in via SNS + SQS, ou Kinesis/MKS pour le traitement ordonné de flux ; utilisez les files d’attente de lettres mortes (dead-letter queues) SQS et des gestionnaires idempotents pour gérer les nouvelles tentatives et les doublons. Les limites de simultanéité, la simultanéité réservée et la limitation (throttling) doivent être planifiées pour éviter les défaillances en cascade ; concevez pour la contre-pression (backpressure) en utilisant des limitations, des nouvelles tentatives avec gigue (jitter) et des disjoncteurs (circuit breakers) (API Gateway ou personnalisés). Les compromis coût-performance sont clairs : Lambda est rentable pour les charges de travail en pic et de courte durée, tandis que Fargate ou EC2 sont préférables pour les tâches soutenues à forte utilisation de CPU ou de longue durée. Les pièges courants incluent le fait de se fier à des nouvelles tentatives synchrones qui surchargent les systèmes en aval, de stocker l’état dans le répertoire local /tmp en s’attendant à sa persistance, et de ne pas provisionner pour les démarrages à froid dans les flux critiques en termes de latence.

Problème pratique : migration du centre de contact de NovaTel Enterprise

Scénario : NovaTel Enterprise exploite un centre de contact hybride avec un routage d’appels sur site (on-premises) et une connexion Direct Connect vers AWS. Ils exécutent des courtiers de session (session brokers) sur EC2 dans deux zones de disponibilité et souhaitent migrer vers un centre de contact géré par AWS offrant une haute disponibilité et une latence prévisible entre le PBX sur site et les services cloud.

Défi : Ils ont besoin d’une connectivité à faible latence pour le trafic SIP, d’une couche de calcul évolutive pour le traitement de la voix qui tolère les interruptions des instances Spot, et d’une stratégie de reprise après sinistre (DR) inter-régionale sans augmenter la complexité opérationnelle.

Approche recommandée :

Provisionner Amazon Connect pour la fonctionnalité de centre de contact et utiliser un VPN Site-to-Site ou Direct Connect avec un AWS Transit Gateway pour le trunking SIP à faible latence, se terminant sur un NLB avec TLS passthrough devant les courtiers de session.
Exécuter les composants de traitement de session en tant qu’Auto Scaling Group mixte avec des modèles de lancement (launch templates) utilisant des instances Spot optimisées pour la capacité (capacity-optimized) plus un repli sur des instances à la demande (On-Demand), et utiliser des groupes de placement (Placement Groups) de type spread pour l’isolation des pannes des courtiers critiques.
Pour les médias d’appel avec état (stateful) qui nécessitent un stockage éphémère à faible latence, utiliser des instances basées sur un stockage d’instance (instance store) (Nitro) pour la mise en mémoire tampon des médias et répliquer les métadonnées de session vers DynamoDB ou ElastiCache avec une réplication multi-AZ ; employer RDS (Multi-AZ) ou Aurora Global DB pour les données persistantes avec des réplicas en lecture (read replicas) inter-régionaux pour la reprise après sinistre (DR).
Implémenter des hooks de cycle de vie (lifecycle hooks) et des pools pré-chauffés (warm pools) pour minimiser le démarrage à froid des courtiers, le basculement pondéré (weighted failover) de Route 53 pour la reprise après sinistre inter-régionale, et CloudWatch + SNS/SQS pour les alertes et les runbooks de basculement automatisés.

Justification : L’utilisation de services de centre de contact gérés réduit la charge opérationnelle tandis que les ASG mixtes avec des instances Spot optimisent les coûts ; l’isolation des médias éphémères sur des stockages d’instance préserve les performances, et la réplication d’état durable vers DynamoDB/ElastiCache ainsi que RDS/Aurora en multi-AZ fournit la résilience et un basculement rapide conformes aux meilleures pratiques d’architecture professionnelle.

← Sécurité · Tous les domaines · Stockage et gestion des données →

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