Amazon CLF-C02: Concepts du cloud — 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 du cloud et proposition de valeur d’AWS

Le cloud computing transforme les problèmes de planification de capacité et d’investissement en capital en un modèle opérationnel où la puissance de calcul, le stockage et le réseau sont consommés à la demande. AWS offre l’élasticité (mise à l’échelle automatique pour s’adapter à la charge), une portée mondiale (Régions et Zones de disponibilité pour la localité et l’isolation des pannes), et une gamme de services gérés qui éliminent les tâches lourdes et non différenciées. Des concepts architecturaux tels que la conception pour la panne, le couplage lâche et l’infrastructure immuable aident les équipes à exploiter les avantages du cloud : un temps de mise sur le marché plus rapide, un modèle économique de paiement à l’utilisation et une mise à l’échelle mondiale. Les primitives réseau telles que les VPC, les subnets et une Internet Gateway contrôlent le trafic entrant et sortant des charges de travail, tandis que Direct Connect offre une liaison dédiée à haut débit vers les datacenters sur site lorsqu’une bande passante prévisible ou une latence plus faible est requise. Pour les migrations physiques de très grande envergure ou en cas de connectivité intermittente, les appareils Snowball Edge permettent un transfert hors ligne sécurisé et même du calcul en périphérie (edge compute). Les pièges courants pour les praticiens incluent le fait de supposer que le « lift-and-shift » réduira automatiquement les coûts, de sous-estimer les frais de sortie réseau (egress), et de ne pas concevoir pour une résilience multi-AZ. Les critères de décision doivent prendre en compte les exigences de disponibilité métier, la gravité des données (data gravity), les contraintes de latence et les coûts opérationnels à long terme avant de choisir entre les stratégies de réhébergement (rehost), de replatforming ou de refactoring.

Services, modèles de migration et décisions architecturales

Le choix du bon service AWS dépend de si vous avez besoin d’opérations gérées, d’un contrôle sur les responsabilités au niveau du système d’exploitation, ou de capacités en périphérie/hors ligne. Les modèles de migration incluent le réhébergement (rehost ou « lift-and-shift »), le replatforming (apporter de petites optimisations) et le refactoring (ré-architecturer pour le cloud-natif). Les choix de stockage reflètent les modèles d’accès : S3 pour le stockage d’objets et les lacs de données, EBS pour le stockage en mode bloc attaché à EC2, EFS pour les systèmes de fichiers partagés POSIX, et les variantes de FSx pour les besoins de systèmes de fichiers gérés Windows ou haute performance. Les bases de données peuvent être exécutées en tant que services gérés comme Amazon RDS et Amazon DynamoDB, qui déchargent les tâches administratives, ou autogérées sur EC2 où le client conserve la responsabilité du système d’exploitation, des correctifs, des sauvegardes et de la mise à l’échelle. Pour les conteneurs, les options gérées réduisent la charge opérationnelle tout en offrant différents compromis :

Amazon ECS (lancement EC2) : orchestration gérée mais vous gérez les hôtes EC2.
Amazon ECS / Fargate : conteneurs serverless sans gestion d’hôtes.
Amazon EKS : plan de contrôle Kubernetes géré ; vous pouvez gérer les nœuds ou utiliser Fargate. Pour un déploiement rapide d’applications sans avoir à créer manuellement chaque ressource, AWS Elastic Beanstalk ou les modèles CloudFormation accélèrent la livraison tout en appliquant des architectures standard. Les pièges pour les praticiens incluent la sous-estimation de l’effort opérationnel des bases de données ou des hôtes de conteneurs autogérés et l’oubli d’attacher des profils d’instance IAM à EC2 pour un accès sécurisé aux services.

Économie du cloud : modèles de tarification et pratiques d’optimisation des coûts

AWS propose plusieurs modèles de tarification pour correspondre à la prévisibilité de la charge de travail et à la tolérance aux interruptions. Les instances à la demande (On-Demand) sont flexibles et sans engagement, les instances réservées (Reserved Instances) et les Savings Plans offrent des remises importantes pour une utilisation stable, les instances Spot bénéficient de remises très élevées mais peuvent être interrompues, et les hôtes dédiés (Dedicated Hosts) répondent aux besoins réglementaires ou de licence. La visibilité et le contrôle des coûts reposent sur le balisage (tagging), Cost Explorer, AWS Budgets et AWS Cost Anomaly Detection ; des outils de dimensionnement adéquat (rightsizing) comme AWS Compute Optimizer et les recommandations de ressources de Cost Explorer aident à identifier les instances EC2 surprovisionnées. Trusted Advisor expose des optimisations de coût et de performance et met en évidence les ressources orphelines, tandis qu’AWS Budgets peut déclencher des alertes SNS lorsque les dépenses dépassent les seuils définis. Les pièges courants incluent l’achat d’instances réservées ou de Savings Plans sans analyser l’utilisation historique, l’application d’instances Spot à des charges de travail critiques et non interruptibles, et l’échec de la mise en œuvre d’un balisage cohérent, ce qui compromet les efforts de refacturation interne (chargeback) et d’optimisation. Les critères de décision doivent combiner les modèles de charge de travail, la tolérance à l’interruption et les prévisions : utilisez les instances à la demande pour les charges imprévisibles, les Savings Plans ou les RI (instances réservées) pour les charges de base soutenues, et les instances Spot pour le calcul flexible et tolérant aux pannes.

Sécurité, responsabilité partagée et bonnes pratiques opérationnelles

La sécurité sur AWS est un modèle partagé : AWS sécurise l’infrastructure cloud (matériel, réseau, régions, zones de disponibilité et services fondamentaux), tandis que les clients sécurisent dans le cloud — cela inclut les données, le contrôle d’accès, le chiffrement au niveau applicatif, l’application de correctifs pour le système d’exploitation et les logiciels pour l’IaaS, et la fédération d’identités. Utilisez les rôles IAM attachés aux profils d’instance EC2 pour accorder un accès temporaire selon le principe de moindre privilège à des services tels que S3 ; évitez d’intégrer des informations d’identification à longue durée de vie dans les instances. Les fonctionnalités de protection des données incluent le versionnement S3 et S3 Object Lock pour la rétention, le chiffrement côté serveur (SSE) et le chiffrement côté client pour les enregistrements sensibles. La surveillance et l’auditabilité reposent sur CloudTrail pour la journalisation des API, AWS Config pour la conformité de la configuration, Amazon Inspector pour les évaluations de vulnérabilité des charges de travail EC2, GuardDuty pour la détection des menaces, et Amazon Macie pour la découverte de données sensibles dans S3. Le Well-Architected Framework guide les considérations opérationnelles, de sécurité, de fiabilité, de performance et de coût ; les erreurs courantes des praticiens incluent l’utilisation excessive du compte root, la négligence des sauvegardes automatisées, et la non-implémentation d’architectures multi-AZ ou de plans de reprise après sinistre (Disaster Recovery). Les décisions opérationnelles doivent prioriser l’automatisation, le moindre privilège et la journalisation centralisée pour réduire l’erreur humaine et accélérer la réponse aux incidents.

Problème pratique : Scénario d’utilisation

Scénario : Acme Analytics exécute un pipeline de traitement de données saisonnier dans une seule région AWS. Leur environnement comprend des instances EC2 pour le calcul, une archive sur site (on-premises) et un lac de données (data lake) S3. Ils doivent ingérer 50 To depuis leur site chaque saison, garantir une haute disponibilité pendant les exécutions et maîtriser les coûts entre les saisons.

Défi : Transfert de données en masse de 50 To avec une bande passante limitée et un besoin d’ingestion durable et auditable ; la puissance de calcul doit être hautement disponible pendant une fenêtre de traitement de deux mois et rentable lorsqu’elle est inactive.

Approche recommandée :

Commander un Amazon Snowball Edge pour importer de manière sécurisée les 50 To dans Amazon S3, en utilisant la capacité de calcul en périphérie (edge compute) si un prétraitement est nécessaire.
Stocker les données ingérées dans un bucket S3 avec le versionnement activé et appliquer S3 Object Lock pour la rétention des enregistrements source.
Exécuter le traitement sur des groupes Auto Scaling d’instances EC2 répartis sur plusieurs zones de disponibilité (Availability Zones) ou utiliser AWS Batch/ECS Fargate pour une mise à l’échelle gérée pendant la fenêtre de deux mois.
Mettre en œuvre Cost Explorer, AWS Budgets avec des alertes, et appliquer des Savings Plans ou des Reserved Instances uniquement pour les ressources de base persistantes ; résilier ou réduire la puissance de calcul après la saison.

Justification : Snowball Edge minimise le temps de transfert et les coûts réseau pour les importations volumineuses et ponctuelles, tandis que S3 fournit un stockage durable et auditable. L’utilisation d’Auto Scaling ou de calcul géré pendant les mois de pointe assure la disponibilité et n’entraîne des coûts que lors du traitement, tandis que les outils de gestion des coûts préviennent les dépenses imprévues.

Tous les domaines · Infrastructure mondiale AWS →

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