Amazon CLF-C02: Services de calcul essentiels — Guide d'étude

By Laurynas Brazys · 28 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Fait partie du AWS Cloud Practitioner CLF-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.

Concepts fondamentaux d’EC2, modèles d’achat et schémas de disponibilité

Amazon EC2 est l’offre de calcul IaaS fondamentale : vous choisissez des types d’instances pour le CPU, la mémoire, le stockage et le réseau, exécutez des systèmes d’exploitation que vous contrôlez, et attachez éventuellement des volumes Elastic Block Store (EBS) pour un stockage en mode bloc persistant. La conception pour la disponibilité exige de répartir les charges de travail sur plusieurs zones de disponibilité (AZ) et, le cas échéant, sur plusieurs régions. Pour les bases de données relationnelles gérées, utilisez Amazon RDS Multi‑AZ pour une instance de secours synchrone et un basculement automatisé ; pour une mise à l’échelle en lecture extrême ou une reprise après sinistre inter-régions, envisagez Amazon Aurora Global Database. Les choix d’achat d’instances impliquent des compromis entre coût et résilience : les instances à la demande (On-Demand) offrent de la flexibilité sans engagement ; les instances réservées (Reserved Instances) ou les Compute Savings Plans offrent les économies prévisibles les plus importantes pour une utilisation continue et stable ; les instances Spot (Spot Instances) fournissent le prix le plus bas pour les charges de travail tolérantes aux pannes et interruptibles. Les pièges courants incluent le fait de dépendre d’une seule AZ, d’intégrer des informations d’identification à longue durée de vie sur les instances, et de sur-provisionner « au cas où ». Utilisez des groupes Auto Scaling avec des bilans de santé (health checks), des hooks de cycle de vie (lifecycle hooks) et des politiques d’instances mixtes (On-Demand + Spot) pour équilibrer le coût et la disponibilité. Décidez entre les Reserved/Savings Plans et les instances Spot en évaluant le temps de disponibilité requis, la tolérance aux interruptions et la précision des prévisions ; choisissez le Multi-AZ ou le multi-région en fonction des exigences de RTO/RPO et des contraintes de latence inter-régions.

Calcul géré pour les conteneurs, le traitement par lots (batch) et le serverless : critères de décision

AWS propose plusieurs plateformes de calcul gérées pour répondre aux objectifs architecturaux. AWS Lambda permet de créer des fonctions serverless pilotées par les événements, avec une mise à l’échelle automatique et une facturation à la milliseconde, ce qui est idéal pour les tâches sans état (stateless) et de courte durée. Amazon ECS fournit une option d’orchestration de conteneurs gérée qui s’intègre avec Fargate pour une exécution de conteneurs serverless ou avec EC2 pour plus de contrôle. Amazon EKS exécute Kubernetes en tant que plan de contrôle géré pour les équipes qui standardisent sur Kubernetes, avec des nœuds de travail (worker nodes) en tant qu’EC2 ou Fargate. AWS Batch planifie et met à l’échelle des tâches de calcul par lots (batch) sur la capacité EC2 ou Spot, optimisant le débit pour les tâches à haute performance ou à volume élevé. Elastic Beanstalk est une plateforme applicative pour déployer des applications web sans gérer l’infrastructure sous-jacente ; il abstrait la configuration d’EC2, de l’autoscaling, d’ELB et de RDS pour des déploiements lift-and-shift plus rapides. Les critères de décision clés incluent les compétences opérationnelles (l’expertise Kubernetes favorise EKS), la vitesse de déploiement (Beanstalk), la prévisibilité des coûts (Fargate simplifie mais peut coûter plus cher), et les caractéristiques de la charge de travail (Lambda pour les tâches courtes et événementielles ; ECS/EKS pour les services de longue durée). Évitez le piège de sélectionner l’option la plus riche en fonctionnalités alors qu’un service géré plus simple (Lambda ou Fargate) réduirait la charge opérationnelle et augmenterait l’agilité.

Stratégies d’autoscaling, d’élasticité et d’optimisation des coûts

L’élasticité est la capacité de mettre à l’échelle les ressources à la hausse et à la baisse pour correspondre à la demande ; l’autoscaling est le mécanisme pour y parvenir. Utilisez les groupes Auto Scaling (ASG) pour EC2 afin d’ajouter ou de supprimer des instances en fonction de politiques de suivi de cible (target tracking), par paliers (step) ou prédictives. Pour les conteneurs, utilisez l’auto-scaling d’ECS ou d’EKS pour les tâches et les clusters, et utilisez les contrôles de simultanéité intégrés de Lambda pour les fonctions. Concevez des architectures sans état (stateless) et externalisez l’état vers des services gérés tels qu’Amazon RDS, DynamoDB, ElastiCache ou S3 afin que les instances puissent être éphémères. Dimensionnez correctement les instances (right-sizing) avec des examens réguliers, utilisez la surveillance (métriques et alarmes CloudWatch), et envisagez les Savings Plans ou les Reserved Instances pour une utilisation de base stable tout en plaçant les charges de travail variables sur des instances Spot. Modèles de tarification à évaluer :

À la demande (On-Demand) : aucun engagement, paiement à l’heure/seconde.
Instances réservées / Savings Plans : engagement de 1 ou 3 ans pour des réductions substantielles.
Instances Spot : les plus fortes réductions pour les charges de travail interruptibles.
Hôtes/Instances dédiés (Dedicated Hosts/Instances) : isolation physique pour la conformité, coût plus élevé. Les pièges courants incluent la sous-estimation des temps de préchauffage (warm-up) pour l’autoscaling, le fait de ne pas utiliser les hooks de cycle de vie pour un arrêt en douceur (graceful shutdown), et la surutilisation des instances Spot pour des charges de travail critiques avec état (stateful). Utilisez des déploiements blue/green ou canary pour des mises en production sécurisées et des politiques de cycle de vie pour automatiser le contrôle des coûts des ressources non utilisées.

Sécurité, conformité et outils opérationnels pour le calcul

La sécurité et les opérations sont fondamentales pour le calcul dans AWS. Selon le modèle de responsabilité partagée, AWS sécurise l’infrastructure mondiale et les services gérés, tandis que les clients sont responsables du système d’exploitation invité, de la configuration des applications, des données et des autorisations IAM lors de l’utilisation de l’IaaS. Évitez d’intégrer des clés d’accès à longue durée de vie ; attachez plutôt des rôles IAM aux instances EC2 ou utilisez IAM Roles for Service Accounts (IRSA) pour EKS, et utilisez AWS Secrets Manager ou Systems Manager Parameter Store (SecureString) pour effectuer la rotation et gérer les secrets de manière centralisée. Pour l’audit et les investigations, activez AWS CloudTrail pour capturer l’activité des API sur l’ensemble du compte et utilisez AWS Config pour enregistrer les configurations des ressources. Utilisez Amazon Macie pour découvrir et classifier les données sensibles dans S3, et IAM Access Analyzer ou S3 Access Analyzer pour trouver les partages de ressources publics ou entre comptes. Pour les preuves de conformité, utilisez AWS Artifact pour récupérer les rapports d’audit. La visibilité opérationnelle est améliorée avec les VPC Flow Logs pour le trafic réseau, l’AWS Personal Health Dashboard pour les événements spécifiques au compte, et le Service Health Dashboard pour l’état global des services. Les erreurs courantes des praticiens incluent le fait de laisser le compte racine avec des clés actives, de ne pas activer le MFA sur l’utilisateur racine, et de ne pas centraliser l’identité avec IAM Identity Center (anciennement AWS SSO) pour l’authentification unique (SSO) basée sur SAML vers des applications externes.

Problème pratique : Scénario d’utilisation

Scénario : Acme Analytics exécute une application de traitement de données sur EC2 dans une seule AZ au sein d’un compte AWS de production. Ils ont des tâches batch qui traitent de grands volumes chaque nuit et souhaitent réduire les coûts, accélérer la reprise après une défaillance d’AZ et sécuriser la gestion des secrets.

Défi : Réduire les coûts de calcul tout en garantissant le débit des traitements batch nocturnes et en améliorant la disponibilité entre les AZ, sans réarchitecturer immédiatement l’ensemble de l’application.

Approche recommandée :

Migrer les workers batch vers un environnement de calcul AWS Batch en utilisant une politique d’instances mixtes (Spot + On-Demand) pour réduire les coûts tout en maintenant une capacité de base.
Configurer AWS Batch pour utiliser plusieurs AZ et activer Retry/RetryStrategy avec des files d’attente de tâches réparties sur plusieurs AZ pour la résilience.
Remplacer les informations d’identification intégrées par des rôles IAM pour les tâches EC2/Batch et stocker les secrets ayant fait l’objet d’une rotation dans AWS Secrets Manager ; intégrer avec IAM pour une récupération automatique.
Mettre en œuvre des alarmes CloudWatch et des politiques Auto Scaling sur une flotte EC2 minimale pour tous les composants stateful restants et activer le mode Multi-AZ inter-AZ de RDS si une base de données est utilisée.

Justification : L’utilisation de services batch gérés + Spot réduit les coûts et la charge opérationnelle, tandis que la distribution multi-AZ et l’utilisation de IAM/Secrets Manager améliorent la disponibilité et la sécurité, s’alignant sur les meilleures pratiques d’élasticité, de moindre privilège et de rotation automatisée des secrets.

← Infrastructure mondiale AWS · Tous les domaines · Services de stockage essentiels →

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