Concepts du cloud et responsabilité partagée

Le cloud computing est un mode d'utilisation dans lequel on ne possède pas les ressources informatiques, mais on les emprunte seulement quand on en a besoin, dans la quantité nécessaire, en payant uniquement ce qui est utilisé. Le délai entre la demande et la mise à disposition est court, et la facturation s'arrête dès la restitution des ressources. Fixer la quantité nécessaire avant le déploiement et acheter du matériel, tout comme gérer soi-même l'alimentation et la climatisation, relèvent de l'approche sur site ; comme la quantité doit être décidée à l'avance, cela entraîne un surprovisionnement ou un manque de capacité. L'affirmation selon laquelle la quantité ne peut pas être modifiée pendant la durée du contrat est l'inverse du principe du cloud, qui permet d'augmenter ou de réduire les ressources par la suite.

Le paiement à l'usage (Pay-as-you-go) est le principe selon lequel, sans paiement initial ni engagement à long terme, on ne paie que ce qui est réellement utilisé. Comme la mise à l'échelle suit la demande réelle plutôt qu'une prévision, cela réduit le risque de surprovisionnement. Faire baisser le tarif unitaire en échange d'un engagement sur une période donnée correspond à « économiser en s'engageant » (Save when you commit) ; faire baisser le tarif unitaire à mesure que la consommation augmente correspond à « payer moins en consommant plus » (Pay less by using more) ; regrouper des services en un forfait mensuel fixe sans dépassement correspond au tarif forfaitaire (Flat rate). Ce sont là d'autres principes.

« Payer moins en consommant plus » (Pay less by using more) est le principe selon lequel une tarification par paliers s'applique, par exemple pour S3 ou le transfert de données, et le tarif par Go baisse à mesure que la consommation augmente. Faire baisser le tarif unitaire en échange d'un engagement sur une consommation fixe pendant une période donnée correspond à « économiser en s'engageant » (Save when you commit), dont les Savings Plans sont un exemple. Payer à chaque fois seulement ce qui est utilisé correspond au paiement à l'usage (Pay-as-you-go), et regrouper des services en un forfait mensuel fixe sans dépassement correspond au tarif forfaitaire (Flat rate). Ces quatre principes répondent à des objectifs différents et se combinent plutôt qu'ils ne s'opposent.

« Économiser en s'engageant » (Save when you commit) est le principe selon lequel, comme avec les Savings Plans, en échange d'un engagement sur un niveau de consommation donné pendant une durée de 1 ou 3 ans, le tarif des services de calcul ou d'apprentissage automatique est réduit. Fixer un montant mensuel sans dépassement correspond au tarif forfaitaire (Flat rate), et ce n'est pas un mécanisme de report. La tarification par paliers où le tarif baisse à mesure que la consommation augmente correspond à « payer moins en consommant plus » (Pay less by using more). Pouvoir arrêter à tout moment sans engagement est une caractéristique du paiement à l'usage (Pay-as-you-go), ce qui est l'inverse de ce principe fondé sur l'engagement.

Selon la liste officielle des guides d'examen à la date d'août 2026, seules deux certifications sont classées Foundational : AWS Certified Cloud Practitioner (CLF-C02) et AWS Certified AI Practitioner (AIF-C01). Developer - Associate (DVA-C02) et Data Engineer - Associate (DEA-C01) sont toutes deux de niveau Associate, et Advanced Networking - Specialty (ANS-C01) est de niveau Specialty. Pour les certifications dont le nom se termine par le niveau, cela sert d'indice, mais Cloud Practitioner et AI Practitioner n'ont pas de mention de niveau dans leur nom ; il faut retenir que ce sont ces deux-là qui sont Foundational.

CLF-C02 est le code d'examen de AWS Certified Cloud Practitioner. CLF représente Cloud Practitioner, et le suffixe C02 indique la génération de révision. Le code de AWS Certified AI Practitioner est AIF-C01, celui de AWS Certified Developer - Associate est DVA-C02, et celui de AWS Certified Data Engineer - Associate est DEA-C01. Le nom d'une certification peut être renommé, mais le code d'examen ne change pas tant qu'il n'y a pas de révision ; c'est donc un moyen fiable de vérifier si un support pédagogique correspond à la version actuelle.

Le code d'examen de AWS Certified Solutions Architect - Professional est SAP-C02. SAA-C03 est le code du même domaine Solutions Architect mais de niveau Associate, SOA-C03 est celui de CloudOps Engineer - Associate, et SCS-C03 est celui de Security - Specialty. Les trois premières lettres se ressemblent et prêtent à confusion, mais il faut retenir que SAA correspond à Associate et SAP à Professional.

L'Exam Guide du CLF-C02 fixe les proportions suivantes : Cloud Concepts 24 %, Security and Compliance 30 %, Cloud Technology and Services 34 %, Billing, Pricing, and Support 12 %. Le domaine le plus important est donc Cloud Technology and Services, et le plus faible Billing, Pricing, and Support. Comme il s'agit d'une certification d'introduction, on pourrait croire que les concepts occupent la plus grande part, mais en réalité le domaine portant sur la connaissance des services est le plus important, suivi de la sécurité. Il convient de répartir son temps d'étude en fonction de ces proportions.

L'Exam Guide du SAA-C03 fixe les proportions suivantes : Design Secure Architectures 30 %, Design Resilient Architectures 26 %, Design High-Performing Architectures 24 %, Design Cost-Optimized Architectures 20 %. Le domaine le plus important est donc la conception d'architectures sécurisées. Il est utile de retenir les quatre domaines en les associant aux piliers du Well-Architected Framework : ils suivent l'ordre sécurité, fiabilité, efficacité des performances, optimisation des coûts.

La certification Associate liée à l'exploitation a changé de nom, passant de SysOps Administrator à CloudOps Engineer, et son code d'examen est passé de SOA-C02 à SOA-C03. La dernière date d'examen pour l'ancien code était le 29 septembre 2025, et le nouveau code a débuté le 30 septembre 2025. Data Engineer - Associate et Machine Learning Engineer - Associate ne sont pas des successeures dans le domaine de l'exploitation, mais des certifications nouvellement créées respectivement dans les domaines des données et du ML. DevOps Engineer - Professional est une certification de niveau Professional qui existait déjà auparavant, et son niveau est également différent.

AWS désigne officiellement sa propre responsabilité par « Security of the Cloud », définie comme la protection de l'infrastructure qui exécute tous les services fournis dans le cloud AWS, c'est-à-dire la protection du matériel, des logiciels, du réseau et des installations. La correction des vulnérabilités d'une application installée sur une instance relève de la responsabilité du client lorsqu'il choisit EC2. Le choix des options de chiffrement des données et l'attribution des autorisations via IAM restent des tâches du côté client quel que soit le service choisi, et relèvent toutes deux de « Security in the Cloud ».

AWS précise officiellement que « la responsabilité du client est déterminée par le service cloud AWS que le client choisit ». Cela signifie que le volume de tâches de configuration à effectuer par le client, dans le cadre de sa part de responsabilité en matière de sécurité, varie selon le service choisi. Le plan de support détermine la façon de recevoir une assistance technique, et ne modifie pas la frontière des responsabilités. La région et la zone de disponibilité concernent le placement des ressources, et la durée ou le montant d'utilisation concernent la facturation ; aucun de ces éléments ne détermine l'étendue de la responsabilité.

AWS précise que, pour les services nécessitant une configuration comme EC2, le client assure « la gestion du système d'exploitation invité (y compris les mises à jour et les correctifs de sécurité), les logiciels applicatifs ou utilitaires installés sur l'instance, et la configuration du groupe de sécurité ». L'application des correctifs au système d'exploitation relève donc de la responsabilité du client. Pour EC2, AWS exploite l'infrastructure physique et la couche de virtualisation, mais pas le système d'exploitation à l'intérieur de l'instance. Un plan de support est un contrat d'assistance technique et ne transfère pas la responsabilité.

Pour les services abstraits ou managés, AWS indique que « AWS exploite la couche d'infrastructure, le système d'exploitation et la plateforme, et le client accède au point de terminaison pour stocker et récupérer ses données ». Ce qui reste au client, c'est la gestion de ses propres données (y compris les options de chiffrement), la classification des actifs, et l'application d'autorisations appropriées via les outils IAM. Le client ne s'occupe ni de la mise à jour du système d'exploitation ni de l'exploitation de la plateforme, mais la classification des données et la configuration des autorisations restent toujours du côté du client, quel que soit le service.

La frontière du modèle de responsabilité partagée n'est pas fixe : elle dépend du service choisi. Pour des services comme EC2, où le client gère le système d'exploitation invité, l'application des correctifs relève de la responsabilité du client, tandis que pour des services comme S3 ou DynamoDB, où AWS exploite jusqu'au système d'exploitation et à la plateforme, cela relève d'AWS. Il est donc erroné de dire que c'est « toujours AWS » ou « toujours le client ». La région concerne le choix de l'emplacement et ne modifie pas la répartition des responsabilités. En retenant ce seul point, il suffit de se demander si un service inconnu ressemble plutôt à EC2 ou plutôt à S3 pour estimer où se situe la frontière.

Les installations font explicitement partie de la « Security of the Cloud » en tant qu'infrastructure exécutant les services cloud AWS, et cela relève toujours d'AWS, quel que soit le service utilisé. Le client ne peut ni auditer lui-même ce périmètre ni s'y rendre pour l'inspecter ; il le vérifie via les certifications tierces et les rapports d'audit publiés par AWS. Cela correspond, parmi les trois catégories de contrôles, aux contrôles hérités (Inherited Controls), c'est-à-dire la part que le client hérite intégralement d'AWS. Ce qui varie selon le service choisi, c'est la couche du système d'exploitation ou des middlewares, et non la couche physique.

AWS précise que la gestion de ses propres données (y compris les options de chiffrement), la classification des actifs et l'application d'autorisations appropriées via les outils IAM restent du côté du client, même en utilisant des services abstraits. Comme cela ne change pas quel que soit le service choisi, c'est un point fixe à garder en tête pour raisonner sur la frontière. Le remplacement des serveurs physiques et la protection du réseau de dorsale concernent les installations et le matériel, et relèvent toujours d'AWS. Le système d'exploitation qui sert de base à un service managé étant exploité par AWS, l'application de correctifs ne relève pas du client.

Les contrôles hérités sont définis officiellement comme ce que le client hérite intégralement d'AWS, correspondant aux contrôles physiques et environnementaux. Les contrôles appliqués séparément à la fois à la couche d'infrastructure et à la couche client sont les contrôles partagés (Shared Controls), et ce qui relève entièrement de la responsabilité du client, correspondant à la sécurité des services et des zones, sont les contrôles spécifiques au client (Customer Specific Controls). L'héritage va dans un seul sens, d'AWS vers le client, et il ne s'agit pas d'AWS reprenant la configuration du client.

Les trois exemples officiellement cités pour les contrôles partagés sont la gestion des correctifs, la gestion de la configuration, et la sensibilisation et la formation. Leur caractéristique commune est qu'une même activité est menée en parallèle à la fois à la couche d'infrastructure et à la couche client : par exemple, pour la gestion des correctifs, AWS l'applique à sa propre infrastructure tandis que le client l'applique au système d'exploitation invité et aux applications, chacun de son côté. Le contrôle d'accès, la redondance de l'alimentation, l'approvisionnement et la mise au rebut du matériel sont des contrôles physiques et environnementaux, hérités par le client depuis AWS. La sécurité des services et des zones est un exemple de contrôle spécifique au client.

DynamoDB étant un service abstrait, AWS exploite jusqu'à la couche d'infrastructure, le système d'exploitation et la plateforme. L'application des correctifs au système d'exploitation invité, qui incombait au client avec EC2, devient une tâche du côté d'AWS après la migration. En revanche, la classification des données et le choix des options de chiffrement, ainsi que l'attribution des autorisations via IAM, restent du côté du client quel que soit le service choisi. La protection des installations physiques relève depuis toujours d'AWS et ne passe pas au client lors de la migration. On peut retenir que « ce qui bouge, c'est la couche du système d'exploitation et de la plateforme ; ce qui ne bouge pas, ce sont les données et les autorisations ».

Les piliers actuels sont au nombre de six : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts, et durabilité. La durabilité a été ajoutée en 2021 comme sixième pilier ; une liste de cinq piliers sans celui-ci correspond donc à une information ancienne, antérieure à cet ajout. L'interopérabilité et la portabilité ne figurent pas parmi les piliers de ce framework et n'apparaissent dans aucune liste officielle. Un article présentant un nombre de piliers erroné a de fortes chances de contenir aussi des noms de services ou des codes d'examen obsolètes ; c'est donc un bon indicateur pour juger de la fraîcheur d'un support pédagogique.

L'excellence opérationnelle est le pilier qui porte sur l'exécution et la surveillance des systèmes, ainsi que sur l'amélioration continue des processus et procédures. Cela comprend l'automatisation des déploiements, la mise à jour des procédures après une analyse des incidents, et la réalisation de changements petits et fréquents. La protection des informations et des systèmes relève de la sécurité, l'optimisation de l'allocation des ressources et le choix du type de ressource relèvent de l'efficacité des performances, et l'élimination des dépenses inutiles et l'ajustement des ressources relèvent de l'optimisation des coûts ; ce sont là d'autres piliers.

Le pilier Sécurité porte sur la protection des informations et des systèmes, avec au centre l'intégrité des données et le contrôle d'accès. Le chiffrement et le contrôle d'accès fondé sur le moindre privilège correspondent directement à cela. Arrêter les ressources inutilisées et ajuster leur taille relève de l'optimisation des coûts, automatiser le déploiement et mettre à jour les procédures après une analyse des incidents relève de l'excellence opérationnelle, et mesurer et réduire l'impact environnemental relève de la durabilité. La plus grande partie de ce qui reste du côté du client dans le modèle de responsabilité partagée relève de ce pilier Sécurité.

La fiabilité est le pilier qui porte sur le fait que la charge de travail remplisse sa fonction prévue, et sur la rapidité de reprise après une défaillance. Cela comprend la répartition sur plusieurs zones de disponibilité, la reprise automatique, ainsi que la vérification des procédures de sauvegarde et de restauration. Sa particularité est de ne pas se limiter à éviter les pannes, mais d'inclure aussi la capacité à s'en remettre rapidement en cas de panne. L'optimisation de l'allocation des ressources relève de l'efficacité des performances, l'exécution, la surveillance et l'amélioration des procédures relèvent de l'excellence opérationnelle, et la minimisation de l'impact environnemental relève de la durabilité.

L'efficacité des performances est le pilier qui porte sur l'optimisation de l'allocation des ressources IT et sur le choix du type de ressource adapté aux besoins de la charge de travail. Le fait de choisir à nouveau un type de ressource pour répondre à une exigence correspond directement à cela. L'optimisation des coûts peut sembler être une activité similaire, mais son objectif est d'éliminer les dépenses inutiles, alors qu'ici c'est le respect de l'exigence de latence qui motive la démarche : l'accent est donc différent. La fiabilité porte sur la résistance aux défaillances et l'excellence opérationnelle sur l'amélioration des procédures ; aucun des deux n'est ici la préoccupation principale.

L'optimisation des coûts est le pilier qui porte sur l'élimination des dépenses inutiles et sur l'ajustement des ressources aux besoins de l'entreprise. Cela comprend l'arrêt de ressources inutilisées, la correction de la taille d'instances surdimensionnées, et l'utilisation combinée de différents modèles tarifaires. L'objectif n'est pas simplement de réduire les coûts, mais de vérifier que la valeur obtenue est à la hauteur de la dépense engagée. La protection des informations et des systèmes relève de la sécurité, l'exécution de la fonction prévue et la reprise relèvent de la fiabilité, et la minimisation de l'impact environnemental relève de la durabilité.

La durabilité est le pilier qui porte sur la minimisation de l'impact environnemental de l'exécution des charges de travail cloud. C'est le pilier le plus récent, ajouté en 2021 comme sixième pilier, et sa présence ou son absence permet de distinguer un support à jour d'un support obsolète. L'optimisation de l'allocation des ressources et le choix du type de ressource relèvent de l'efficacité des performances, l'exécution, la surveillance et l'amélioration continue des procédures relèvent de l'excellence opérationnelle, et l'exécution de la fonction prévue et la reprise après une défaillance relèvent de la fiabilité ; ce sont là d'autres piliers.

Le pilier manquant est la durabilité (Sustainability), qui traite de la minimisation de l'impact environnemental de l'exécution des charges de travail cloud. Ayant été ajoutée en 2021 comme sixième pilier, les articles rédigés avant cette date en sont restés à cinq piliers. L'excellence opérationnelle, l'efficacité des performances et la fiabilité existaient déjà avant cet ajout, et figurent donc aussi dans les articles n'en comptant que cinq. Un article dont un élément aussi fondamental que le nombre de piliers est erroné a de fortes chances de contenir également d'autres informations obsolètes.

Les piliers actuels sont au nombre de six : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts, et durabilité ; l'interopérabilité ne figure pas dans cette liste. La connexion entre différents systèmes est une préoccupation de conception importante, mais le Well-Architected Framework n'en fait pas un pilier à part entière. L'optimisation des coûts, l'excellence opérationnelle et l'efficacité des performances sont bien chacune l'un des six piliers officiels. Retenir un terme absent du framework comme s'il en était un pilier peut semer la confusion lors de l'élimination des réponses.

L'élimination des dépenses inutiles et l'ajustement des ressources aux besoins de l'entreprise relèvent de l'optimisation des coûts, et non de la fiabilité. La fiabilité est le pilier qui porte sur le fait que la charge de travail remplisse sa fonction prévue et sur la rapidité de reprise après une défaillance. Les trois autres associations correspondent bien à la description officielle. Les noms des piliers étant proches du langage courant, on peut facilement se tromper en se fiant à leur simple apparence. Retenir chaque pilier avec la phrase décrivant son objet évite de trébucher sur ce type de question.

Une région est un lieu physique dans le monde où AWS dispose de plusieurs zones de disponibilité. Elle porte un nom comme us-east-1 ou ap-northeast-1, et on la choisit en fonction de l'emplacement des données et de la réglementation, de la distance par rapport aux utilisateurs, et du tarif. Une unité d'isolation des défaillances composée d'un ou plusieurs centres de données indépendants correspond à la description d'une zone de disponibilité. Le point d'accès où CloudFront met en cache et diffuse du contenu est une edge location (point de présence), et ce qui est placé dans le réseau d'un opérateur de télécommunications correspond aux Wavelength Zones.

Une zone de disponibilité est définie comme étant composée d'un ou plusieurs centres de données indépendants, chacun équipé d'une alimentation, d'un réseau et d'une connectivité redondants, et hébergés dans des installations distinctes les unes des autres. Ce n'est pas l'équivalent d'un seul bâtiment de centre de données : ce qui compte, c'est qu'il s'agit d'un ensemble, et que chaque zone se trouve dans un bâtiment différent des autres. La couche située entre une edge location et l'origine est le cache régional de périphérie (Regional Edge Cache), et l'endroit proche des utilisateurs permettant d'exécuter des applications correspond à la description des Local Zones ; ce sont là d'autres mécanismes.

AWS indique officiellement que chaque région est composée d'« au moins trois zones de disponibilité, physiquement séparées et indépendantes ». Le nombre total de régions et de zones continue d'augmenter, ce qui rend peu utile de le mémoriser, mais la règle fixant le nombre minimal de zones par région est stable et peut directement servir de base à la conception. L'affirmation selon laquelle les zones seraient situées dans une même installation contredit la définition selon laquelle elles sont hébergées dans des installations distinctes. Les zones ne sont pas quelque chose que le client demande à faire augmenter, ni limitées à une seule par région.

Une edge location fait partie du réseau mondial de centres de données à travers lequel CloudFront diffuse du contenu. Les requêtes sont routées vers l'edge location offrant la latence la plus faible, depuis laquelle le contenu est diffusé. L'essentiel est qu'il ne s'agit pas d'une unité de redondance destinée à augmenter la disponibilité, mais d'un point de cache permettant de redistribuer le contenu depuis un endroit proche des utilisateurs. L'isolation des défaillances relève des zones de disponibilité, la délimitation des plages d'adresses IP relève des sous-réseaux, et l'exécution au sein des installations d'un opérateur de télécommunications relève des Wavelength Zones.

Une requête est routée vers l'edge location offrant la latence la plus faible, et si le contenu s'y trouve, il est diffusé immédiatement. S'il n'y est pas, il est récupéré depuis une origine, comme un bucket S3 ou un serveur HTTP, puis diffusé, tout en étant conservé en cache. Ainsi, à partir de la deuxième requête, la réponse est renvoyée directement depuis le point le plus proche. L'absence de cache ne provoque ni erreur ni attente prolongée pour l'utilisateur. Le transfert vers une zone de disponibilité relève d'un mécanisme d'isolation des défaillances, sans rapport avec le flux de diffusion de contenu.

Le cache régional de périphérie est une couche de cache située entre une edge location et l'origine. Son rôle est de réduire le nombre de fois où il faut aller chercher le contenu jusqu'à l'origine lorsqu'il n'est pas trouvé à la périphérie. L'unité de gestion regroupant les zones de disponibilité est la région, et les zones placées dans le réseau d'un opérateur de télécommunications sont les Wavelength Zones ; ce sont là d'autres notions. Le cache côté appareil de l'utilisateur n'est pas un mécanisme d'AWS, mais une fonctionnalité du navigateur ou du système d'exploitation.

Une zone de disponibilité est une unité d'isolation des défaillances, hébergée dans des installations distinctes et équipée d'une alimentation et d'un réseau redondants. En répartissant des ressources ayant le même rôle sur plusieurs zones, le traitement peut continuer avec le reste même si l'une des zones est intégralement arrêtée. C'est ce qu'on appelle une configuration multi-AZ, point de départ de la conception de la haute disponibilité. La diffusion depuis le point le plus proche relève du rôle des edge locations, l'emplacement des données est un critère de choix de la région, et la réduction du tarif via un engagement sur le volume est une question de modèle tarifaire ; aucun de ces éléments n'est la motivation pour séparer les zones.

Les Local Zones sont un mécanisme permettant d'exécuter des applications sur une infrastructure AWS plus proche des utilisateurs finaux ou des charges de travail, situées dans des villes éloignées de la région. Bien qu'elles ressemblent aux edge locations en traitant de la « proximité », la différence est qu'elles servent à exécuter l'application elle-même, et non à mettre en cache du contenu à diffuser. L'isolation des défaillances au sein d'une région relève des zones de disponibilité, les points dédiés à la diffusion sont les edge locations, et le cache intermédiaire en amont de l'origine est le cache régional de périphérie.

Les Wavelength Zones sont des zones placées dans le réseau d'un opérateur de télécommunications. Comme les Local Zones, il s'agit d'un mécanisme permettant d'exécuter l'application elle-même près des utilisateurs, ce qui diffère par son objectif des edge locations, qui sont des points de cache pour diffuser du contenu. Ce qui est placé entre une edge location et l'origine est le cache régional de périphérie, l'unité d'isolation des défaillances au sein d'une région est la zone de disponibilité, et ce qui délimite la plage d'adresses IP d'un VPC est le sous-réseau.

Une zone de disponibilité étant une unité d'isolation des défaillances hébergée dans des installations distinctes, se préparer à un événement où toute une zone s'arrête n'est possible qu'en répartissant les ressources sur plusieurs zones. Chaque région étant composée d'au moins trois zones séparées, il est possible de répartir la charge sur plusieurs zones au sein d'une même région. Augmenter le nombre de serveurs au sein de la même zone ne satisfait pas l'exigence, car si cette zone tombe, tout s'arrête. CloudFront accélère la diffusion, mais si l'origine s'arrête, le traitement dynamique ne peut pas continuer. Un changement de plan tarifaire est une question de coût, sans rapport avec la disponibilité.