Amazon CLF-C02: Architecture cloud et Framework Well-Architected — 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.

Principes de conception et décisions d’achat de puissance de calcul

Une bonne architecture cloud commence par de petits changements itératifs, l’automatisation et un couplage lâche afin que vous puissiez faire évoluer les parties d’une application indépendamment. Concevez pour l’élasticité en créant des services sans état (stateless) lorsque c’est possible, favorisez l’immuabilité et le calcul éphémère, et appliquez le principe du moindre privilège pour les accès. Lors du choix des modèles de tarification de la puissance de calcul, évaluez l’horizon temporel, la prévisibilité de l’utilisation et la tolérance à l’interruption : les charges de travail de longue durée et à état stable favorisent une tarification engagée ; les charges de travail en rafale ou imprévisibles favorisent les modèles On-Demand ou Spot, le cas échéant. Un piège courant est de s’engager sur des Reserved Instances ou des Savings Plans à long terme sans comprendre la croissance variable, ce qui peut entraîner des dépenses inutiles ou vous enfermer dans la mauvaise famille d’instances. Une autre erreur est d’utiliser des instances Spot pour des charges de travail critiques avec état (stateful) sans concevoir pour l’interruption. Tenez compte des besoins en matière de licences et de placement : les Dedicated Hosts prennent en charge les licences logicielles liées et l’isolement physique, tandis que les Savings Plans offrent une flexibilité sur les familles d’instances et les régions pour les dépenses de calcul. Le balisage (tagging) et l’allocation automatisée des coûts sont essentiels — sans balises cohérentes, il est difficile d’appliquer les Savings Plans ou d’effectuer des analyses de dimensionnement correct (rightsizing). Utilisez la surveillance et les alertes pour détecter rapidement l’inefficacité et réexaminez les décisions d’achat trimestriellement à mesure que l’utilisation change.

On-Demand : paiement à l’heure/seconde, flexibilité maximale, sans engagement
Reserved Instances / Standard RIs : réduction à long terme pour des attributs d’instance spécifiques, rentable pour un état stable
Savings Plans : réductions flexibles sur les familles d’instances en échange d’un engagement de dépense
Spot Instances : réductions importantes pour les charges de travail interruptibles
Dedicated Hosts : allocation d’hôte physique pour des contraintes de licence ou de conformité

Infrastructure as Code, provisionnement et isolement

L’Infrastructure as Code (IaC) apporte la répétabilité, la révisabilité et le versionnement à l’infrastructure. AWS CloudFormation est le service IaC déclaratif natif utilisé pour décrire et provisionner des piles (stacks) ; les modèles (templates) codifient les ressources, les dépendances et le paramétrage. L’AWS Cloud Development Kit (CDK) fournit des constructions de plus haut niveau et prend en charge plusieurs langages (dont TypeScript, Python, Java, C# et Go), permettant aux développeurs de synthétiser du CloudFormation à partir de langages familiers. Le provisionnement programmatique peut également être effectué via l’AWS CLI, les SDK, l’AWS CDK et des outils tiers comme Terraform ; choisissez les outils natifs lorsque vous souhaitez une parité de fonctionnalités étroite avec AWS et la détection de dérive (drift) de CloudFormation. L’isolement logique est fourni par Amazon Virtual Private Cloud (VPC), qui, combiné avec des sous-réseaux, des tables de routage, des groupes de sécurité et des ACL réseau, établit des limites réseau. IAM contrôle les identités et les permissions — utilisateurs, rôles, groupes et politiques — et est utilisé pour gérer les identifiants programmatiques et l’accès aux ressources. Les pièges courants pour les praticiens incluent le stockage des clés d’accès du compte racine, le fait de ne pas établir de rôles inter-comptes pour l’automatisation et de ne pas appliquer les politiques de balisage (tagging) dans les modèles. Les modèles CloudFormation doivent être traités comme du code : revus, analysés (linted) et stockés dans un système de contrôle de version pour éviter la dérive de configuration et permettre des déploiements prévisibles.

Piliers du Well-Architected Framework — focus pratique

Le Well-Architected Framework s’articule autour de cinq piliers qui guident les décisions de conception et les compromis. Comprendre et associer les services à chaque pilier aide à prioriser le travail et à comparer les alternatives.

Excellence Opérationnelle : concevoir pour des opérations observables, utiliser les métriques CloudWatch, les journaux et l’automatisation de Systems Manager ; piloter les guides d’exécution (runbooks) et l’amélioration continue.
Sécurité : appliquer le moindre privilège avec IAM, chiffrer les données au repos avec KMS, activer CloudTrail et GuardDuty pour l’audit et la détection, et protéger les points d’entrée (edges) avec WAF et Shield.
Fiabilité : concevoir pour la panne en utilisant le Multi-AZ, la restauration automatisée, les vérifications de santé (health checks) de Route 53 et les sauvegardes (snapshots EBS, sauvegardes automatisées RDS, AWS Backup) pour atteindre les objectifs de restauration.
Efficacité des Performances : dimensionner correctement (right-size) avec Compute Optimizer, tirer parti de la mise en cache (caching) (CloudFront, ElastiCache), choisir des services gérés (Aurora, DynamoDB) et les niveaux de stockage appropriés pour optimiser les E/S et la latence.
Optimisation des Coûts : mettre en œuvre une architecture soucieuse des coûts avec des politiques de cycle de vie (S3 Intelligent-Tiering ou Standard-IA pour les objets rarement consultés nécessitant une récupération immédiate), utiliser les Savings Plans et planifier les arrêts des environnements hors production.

Un critère de décision fréquent est de savoir s’il faut utiliser des services gérés pour échanger la charge opérationnelle contre un coût. Un piège courant est le surprovisionnement pour le pic du pire des cas, plutôt que de tirer parti de l’autoscaling et de la mise en cache pour maintenir les performances à moindre coût.

Outils opérationnels, services de données, sécurité et choix en périphérie

La visibilité opérationnelle et les outils de sécurité sont l’épine dorsale d’un environnement bien architecturé. AWS CloudTrail enregistre l’activité des API à des fins d’audit, tandis qu’Amazon GuardDuty assure une détection continue des menaces contre les comportements anormaux au niveau du compte. CloudWatch collecte les métriques et les journaux et prend en charge les alarmes pour des événements tels que les pics d’écriture sur les volumes EBS ; utilisez l’agent CloudWatch pour les métriques au niveau du système d’exploitation si les métriques natives sont insuffisantes. Pour les services de données gérés, RDS fournit des correctifs et des sauvegardes automatisés pour les bases de données relationnelles, DynamoDB est la base de données NoSQL de type clé-valeur et de documents entièrement gérée, et Amazon Neptune est une base de données de graphes gérée, optimisée pour les ensembles de données hautement connectés. Pour la diffusion de contenu mondiale et la distribution à faible latence, CloudFront en périphérie, combiné à Shield et WAF, fournit un CDN ainsi qu’une protection DDoS et un filtrage au niveau de la couche applicative. Pour les besoins de faible latence en périphérie ou sur site (on-prem), évaluez AWS Outposts ou les Local Zones ; Outposts place du matériel AWS sur site pour obtenir la latence la plus faible possible et des API cohérentes. La fédération d’identité et l’accès des utilisateurs aux comptes sont gérés via AWS IAM Identity Center (anciennement AWS SSO). Lors de la conception de la surveillance, combinez les alarmes avec une remédiation automatisée (Lambda ou Systems Manager) et évitez les erreurs courantes comme dépendre d’une seule zone de disponibilité, utiliser les informations d’identification racine ou sélectionner un stockage d’archivage profond (Glacier) pour des objets qui doivent être récupérés instantanément.

Choix de services clés par cas d’utilisation : RDS pour les bases de données relationnelles gérées ; DynamoDB pour le NoSQL ; Neptune pour les graphes ; Lex pour les chatbots ; CloudFront + WAF + Shield pour la diffusion web mondiale et la protection DDoS

Problème pratique : Scénario de cas d’utilisation

Scénario : Acme Manufacturing exécute une charge de travail mixte sur AWS avec des instances EC2 de production dans un VPC, une instance RDS pour le traitement des commandes, et un site web d’actifs statiques déployé via S3 et CloudFront. L’équipe utilise l’AWS CLI et CloudFormation, et les développeurs ont besoin d’un accès sécurisé entre comptes (cross-account) pour le CI/CD.

Défi : Ils doivent réduire les coûts de calcul pour les serveurs d’application fonctionnant en continu, sécuriser l’automatisation sans utiliser les informations d’identification racine, et assurer une récupération rapide d’une instance basée sur EBS avec un temps d’arrêt minimal.

Approche recommandée :

S’engager dans un Savings Plan qui correspond à la dépense horaire de calcul soutenue, et convertir les instances éligibles pour utiliser les Savings Plans afin de réaliser des économies immédiates.
Migrer les besoins d’instances spécifiques de longue durée vers des Reserved Instances uniquement après avoir analysé l’utilisation et appliquer la flexibilité de la taille d’instance le cas échéant.
Remplacer tout accès via le compte racine par des utilisateurs et des rôles IAM : créer un rôle IAM pour le CI/CD avec des politiques de moindre privilège et utiliser des informations d’identification à durée de vie limitée via STS AssumeRole pour l’automatisation entre comptes.
Mettre en œuvre des snapshots EBS automatisés à l’aide d’AWS Backup ou de politiques planifiées de Data Lifecycle Manager, et utiliser des AMI ainsi que des user-data pour un remplacement rapide des instances et un groupe Auto Scaling avec restauration de snapshot EBS attachée pour un temps d’arrêt minimal.

Justification : Faire correspondre la tarification engagée aux dépenses prévisibles réduit les coûts sans sacrifier la disponibilité ; remplacer l’utilisation du compte racine par des rôles IAM et des informations d’identification à durée de vie limitée suit les meilleures pratiques du moindre privilège ; les snapshots automatisés et les AMI permettent une récupération rapide, conformément aux piliers de la Fiabilité et de l’Excellence Opérationnelle.

← Facturation · Tous les domaines · Gestion →

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