Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Élaboration de votre stratégie de balisage Comme c'est le cas pour de nombreuses pratiques opérationnelles, la mise en œuvre d'une stratégie de balisage est *un processus d'itération et d'amélioration*. Commencez modestement avec votre priorité immédiate et développez le schéma de balisage selon vos besoins. ![\[Schéma illustrant une représentation graphique de l'itération de la stratégie de marquage et du cycle d'amélioration\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) Tout au long de ce processus, l'appropriation est essentielle à la responsabilisation et au progrès. Les balises pouvant être utilisées à diverses fins, la stratégie globale de balisage peut être divisée en domaines de responsabilité au sein d'une organisation. Le balisage permet une approche programmatique des activités qui dépendent de la caractérisation des ressources. L'éventail des parties prenantes pouvant bénéficier du marquage dépendra de la taille de l'organisation et des pratiques opérationnelles. Les grandes entreprises peuvent tirer parti de la définition claire des responsabilités des équipes impliquées dans l'élaboration et la mise en œuvre d'une stratégie de marquage. Certaines parties prenantes peuvent être chargées d'identifier les besoins (définition des cas d'utilisation) en matière de balisage ; d'autres peuvent être responsables de la maintenance, de la mise en œuvre et de l'amélioration de la stratégie de balisage. En attribuant la propriété, vous êtes bien placé pour mettre en œuvre les différents aspects de la stratégie. Le cas échéant, cette propriété peut être formalisée sous forme de politique et documentée dans une matrice de responsabilité (par exemple, RACI : responsable, responsable, consulté et informé) ou dans un modèle de responsabilité partagée. Dans les petites entreprises, les équipes peuvent jouer plusieurs rôles dans une stratégie de balisage, de la définition des exigences à la mise en œuvre et à l'application. # Définition des besoins et des cas d'utilisation Commencez à élaborer votre stratégie en dialoguant avec les parties prenantes qui ont un besoin sous-jacent fondamental de consommer des métadonnées. Ces équipes définissent les métadonnées avec lesquelles les ressources doivent être étiquetées pour soutenir leurs activités, telles que le reporting, l'automatisation et la classification des données. Ils décrivent la manière dont les ressources doivent être organisées et les politiques auxquelles elles doivent être associées. Voici des exemples de rôles et de fonctions que ces parties prenantes peuvent avoir dans les organisations : + Les services **financiers** **et les secteurs d'activité** doivent comprendre la valeur de l'investissement en le mettant en relation avec les coûts afin de hiérarchiser les mesures à prendre pour remédier à l'inefficacité. Comprendre les *coûts par rapport à la valeur générée* permet d'identifier les secteurs d'activité ou les offres de produits qui échouent. Cela permet de prendre des décisions éclairées concernant le maintien du support, l'adoption d'une alternative (par exemple, l'utilisation d'une offre SaaS ou un service géré) ou le retrait d'une offre commerciale non rentable. + La **gouvernance** et la **conformité** doivent comprendre la catégorisation des données (par exemple, publiques, sensibles ou confidentielles), savoir si une charge de travail spécifique est ou non couverte par un audit par rapport à une norme ou à une réglementation spécifique, et quel est l'importance du service (si le service ou l'application est essentiel pour l'entreprise) afin d'appliquer les contrôles et la supervision appropriés, tels que les autorisations, les politiques et la surveillance. + Les **opérations** et le **développement** doivent comprendre le cycle de vie de la charge de travail, les étapes de mise en œuvre de leurs produits pris en charge et la gestion des étapes de lancement (par exemple, développement, test, répartition de la production) ainsi que les priorités de support associées et les exigences de gestion des parties prenantes. Les tâches telles que les sauvegardes, les correctifs, l'observabilité et la dépréciation doivent également être définies et comprises. + **La sécurité de l'information (InfoSec)** et **les opérations de sécurité (SecOps)** décrivent les contrôles à appliquer et ceux qui sont recommandés. InfoSec définit normalement la mise en œuvre des contrôles et SecOps est généralement responsable de la gestion de ces contrôles. En fonction de votre cas d'utilisation, de vos priorités, de la taille de votre organisation et de vos pratiques opérationnelles, vous devrez peut-être être représenté par différentes équipes au sein de l'organisation, telles que les finances (y compris les achats), la sécurité de l'information, l'activation du cloud et les opérations cloud. Vous devez également être représenté par les propriétaires des applications et des processus pour les fonctions telles que l'application de correctifs, la sauvegarde et la restauration, la surveillance, la planification des tâches et la reprise après sinistre. Ces représentants aident à définir, à mettre en œuvre et à mesurer l'efficacité de la stratégie de marquage. Ils devraient [https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM) à partir des parties prenantes et de leurs cas d'utilisation, et animer un atelier interfonctionnel. Au cours de l'atelier, ils ont l'occasion de partager leurs points de vue et leurs besoins, et de contribuer à l'élaboration d'une stratégie globale. Des exemples de participants et de leur implication dans divers cas d'utilisation sont décrits plus loin dans ce livre blanc. Les parties prenantes définissent et valident également les clés pour les balises obligatoires, et peuvent recommander l'étendue des balises facultatives. Par exemple, les équipes financières peuvent avoir besoin de relier une ressource à un centre de coûts interne, à une unité commerciale ou aux deux. Ils peuvent donc exiger que certaines clés de balise, telles que `CostCenter` et`BusinessUnit`, soient rendues obligatoires. Les équipes de développement individuelles peuvent décider d'utiliser des balises supplémentaires à des fins d'automatisation`EnvironmentName`, telles que`OptIn`, ou`OptOut`. Les principales parties prenantes doivent s'entendre sur l'approche de la stratégie de marquage et documenter les réponses aux questions liées à la conformité et à la gouvernance, telles que : + Quels sont les cas d'utilisation à traiter ? + Qui est responsable du balisage des ressources (mise en œuvre) ? + Comment les balises sont-elles appliquées et quelles méthodes et quelles automatisations seront utilisées (proactives ou réactives) ? + Comment mesure-t-on l'efficacité et les objectifs du balisage ? + À quelle fréquence la stratégie de marquage doit-elle être revue ? + Qui est à l'origine des améliorations ? Comment cela se fait-il ? Les fonctions commerciales, telles que Cloud Enablement, Cloud Business Office et Cloud Platform Engineering, peuvent alors jouer un rôle de facilitateur dans le processus d'élaboration de la stratégie de balisage, contribuer à son adoption et garantir la cohérence de son application en mesurant les progrès, en supprimant les obstacles et en réduisant les efforts dupliqués. # Définition et publication d'un schéma de balisage Utilisez une approche cohérente pour baliser vos AWS ressources, à la fois pour les balises obligatoires et facultatives. Un schéma de balisage complet vous aide à atteindre cette cohérence. Les exemples suivants peuvent vous aider à démarrer : + Acceptez les clés de tag obligatoires + Définissez des valeurs acceptables et des conventions de dénomination des balises (majuscules ou minuscules, tirets ou traits de soulignement, hiérarchie, etc.) + Confirmez que les valeurs ne constituent pas des informations personnelles identifiables (PII) + Décidez qui peut définir et créer de nouvelles clés de balise + Convenez de la manière d'ajouter de nouvelles valeurs de balises obligatoires et de la manière de gérer les balises facultatives Consultez le tableau des [catégories de balisage](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) suivant, qui peut être utilisé comme référence pour ce que vous pouvez inclure dans votre schéma de balisage. Vous devez tout de même déterminer la convention que vous utiliserez pour la clé de balise et les valeurs autorisées pour chacune d'entre elles. Le schéma de balisage est le document dans lequel vous le définissez pour votre environnement. *Tableau 6 — Exemple de schéma de balisage définitif* | Cas d’utilisation | Clé de tag | Justification | Valeurs autorisées (listées ou préfixe/sufix de valeurs) | Utilisé pour la répartition des coûts | Types de ressources | Scope | Obligatoire | | --- | --- | --- | --- | --- | --- | --- | --- | | Répartition des coûts | example-inc:cost-allocation:ApplicationId | Suivez les coûts par rapport à la valeur générée par chaque secteur d'activité | DataLakeX, RetailSiteX | Y | Tous | Tous | Obligatoire | | Répartition des coûts | example-inc:cost-allocation:BusinessUnitId | Surveillez les coûts par unité commerciale | Architecture, DevOps, Finance | Y | Tous | Tous | Obligatoire | | Répartition des coûts | example-inc:cost-allocation:CostCenter | Surveillez les coûts par centre de coûts | 123-\$1 | Y | Tous | Tous | Obligatoire | | Répartition des coûts | example-inc:cost-allocation:Owner | Quel responsable du budget est responsable de cette charge de travail | Marketing, RetailSupport | Y | Tous | Tous | Obligatoire | | Contrôle d’accès | example-inc:access-control:LayerId | SubComponent Identification/couche pour accorder l'accès aux ressources en fonction du rôle | DB\$1Layer, Web\$1Layer, App\$1Layer | N | Tous | Tous | Facultatif | |  Automatisation | example-inc:automation:EnvironmentId | Mettre en œuvre la planification des environnements de test et de développement, également appelée étape du cycle de vie du développement logiciel (SDLC) | Prod, Dev, Test, Sandbox | N | EC2, RDS, EBS | Tous | Obligatoire | | DevOps | example-inc:operations:Owner | Qui team/squad est responsable de la création et de la maintenance de la ressource | Squad01 | N | Tous | Tous | Obligatoire | | Reprise après sinistre | example-inc:disaster-recovery:rpo | Définir l'objectif du point de récupération (RPO) pour une ressource | 6h, 24h | N | S3, EBS | Prod | Obligatoire | | Classification des données | example-inc:data:classification | Classifiez les données à des fins de conformité et de gouvernance | Public, Private, Confidential, Restricted | N | S3, EBS | Tous | Obligatoire | | Conformité d’ | example-inc:compliance:framework | Identifie le cadre de conformité auquel la charge de travail est soumise | PCI-DSS, HIPAA | N | Tous | Prod | Obligatoire | Une fois le schéma de balisage défini, gérez-le dans un référentiel contrôlé par version accessible à toutes les parties prenantes concernées pour une référence facile et des mises à jour traçables. Cette approche améliore l'eficacité et favorise l'agilité. # AWS Organizations — Politiques relatives aux tags Les politiques vous AWS Organizations permettent d'appliquer des types de gouvernance supplémentaires au Comptes AWS sein de votre organisation. Une [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) est la façon dont vous pouvez exprimer votre schéma de balisage au format JSON afin que la plateforme puisse signaler et éventuellement appliquer le schéma dans votre AWS environnement. La politique de balises définit les valeurs acceptables pour une clé de balise pour des types de ressources spécifiques. Cette politique peut prendre la forme d'une liste de valeurs ou d'un préfixe suivi d'un caractère générique ()`*`. L'approche du préfixe simple est moins rigoureuse qu'une liste discrète de valeurs mais nécessite moins de maintenance. Les exemples suivants montrent comment définir une politique de balisage pour valider les valeurs acceptables pour une clé donnée. À partir de la définition tabulaire conviviale du schéma, vous pouvez transcrire ces informations en une ou plusieurs politiques de balises. Des politiques distinctes peuvent être utilisées pour soutenir la délégation de propriété ou certaines politiques peuvent ne s'appliquer que dans des scénarios spécifiques. ## ExampleInc- CostAllocation .json Voici un exemple de politique de balises qui rend compte des balises de répartition des coûts : ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } } } ``` ## ExampleInc- DisasterRecovery .json Voici un exemple de politique de balises qui rend compte des balises Disaster Recovery : ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` Dans cet exemple, la politique de `ExampleInc-CostAllocation` balises est attachée à l'unité d'`Workloads`organisation et s'applique donc à tous les comptes de l'unité d'organisation `Prod` et de `Test` l'enfant OUs. De même, la politique en matière de `ExampleInc-DisasterRecovery` balises est attachée à l'unité d'`Prod`organisation et ne s'applique donc qu'aux comptes situés en dessous de cette unité d'organisation. Le livre blanc sur l'[organisation de votre environnement à l'aide de comptes multiples](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) explore plus en détail les structures d'UO recommandées. ![\[Schéma illustrant l'attachement des politiques de balises à une structure d'UO et la politique effective\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) En regardant le `marketing-prod` compte dans le diagramme, les deux politiques de balises s'appliquent à ce compte. Nous avons donc le concept d'une *politique efficace*, qui est la convolution des politiques d'un type donné qui s'appliquent à un compte. Si vous gérez principalement vos ressources manuellement, vous pouvez consulter la politique effective en consultant la section [Resource Groups & Tag Editor:Tag policies](https://console.aws.amazon.com/resource-groups/tag-policies) de la console. Si vous utilisez l'infrastructure sous forme de code (IaC) ou des scripts pour gérer vos ressources, vous pouvez utiliser l'appel d'[https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html)API. # Implémentation et application du balisage Dans cette section, nous allons vous présenter les outils disponibles pour les stratégies de gestion des ressources suivantes : manuel, infrastructure en tant que code (iAc) et integration/continuous livraison continue (CI/CD). La dimension clé de ces approches est un taux de déploiement de plus en plus fréquent. ## Ressources gérées manuellement Il s'agit généralement de charges de travail qui entrent dans les [étapes de base ou de migration de l'adoption](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html). Il s'agit souvent de charges de travail simples, largement statiques, créées à l'aide de procédures écrites traditionnelles ou migrées telles quelles à l'aide d'outils tels *que* ceux AWS Application Migration Service issus d'un environnement sur site. Les outils de migration, tels que Migration Hub et Application Migration Service, peuvent appliquer des balises dans le cadre du processus de migration. Toutefois, si les balises n'ont pas été appliquées lors de la migration initiale ou si le schéma de balisage a changé depuis, l'[éditeur de balises](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) (une fonctionnalité du AWS Management Console) vous permet de rechercher des ressources à l'aide de divers critères de recherche et d'ajouter, de modifier ou de supprimer des balises en bloc. Les critères de recherche peuvent inclure des ressources avec ou sans la présence d'une balise ou d'une valeur particulière. L'API AWS Resource Tagging vous permet d'exécuter ces fonctions par programmation. À mesure que ces charges de travail sont modernisées, des types de ressources tels que les groupes Auto Scaling sont introduits. Ces types de ressources permettent une plus grande élasticité et une meilleure résilience. Le groupe Auto Scaling gère les instances Amazon EC2 en votre nom, mais vous souhaiterez peut-être toujours que les instances EC2 soient étiquetées de manière cohérente avec les ressources créées manuellement. Un [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) permet de spécifier les balises que l'Auto Scaling doit appliquer aux instances qu'il crée. Lorsque les ressources d'une charge de travail sont gérées manuellement, il peut être utile d'automatiser le balisage des ressources. Différentes solutions sont disponibles. Une approche consiste à utiliser AWS Config Rules, qui permet de vérifier `required_tags` puis de démarrer une fonction Lambda pour les appliquer. AWS Config Rules est décrit plus en détail plus loin dans ce livre blanc. ## Ressources gérées par l'infrastructure en tant que code (IaC) AWS CloudFormation fournit un langage commun pour le provisionnement de toutes les ressources d'infrastructure de votre AWS environnement. CloudFormation les modèles sont des fichiers JSON ou YAML qui créent AWS des ressources de manière automatisée. Lorsque vous créez des AWS ressources à l'aide de CloudFormation modèles, vous pouvez utiliser la propriété CloudFormation Resource Tags pour appliquer des balises aux types de ressources pris en charge lors de leur création. La gestion des balises ainsi que des ressources avec IaC permet de garantir la cohérence. Lorsque des ressources sont créées par AWS CloudFormation, le service applique automatiquement un ensemble de balises AWS définies aux ressources créées par le AWS CloudFormation modèle. Il s'agit des types suivants : ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` Vous pouvez facilement définir un groupe de ressources en fonction de la AWS CloudFormation pile. Ces balises AWS définies sont héritées par les ressources créées par la pile. Toutefois, pour les instances Amazon EC2 au sein d'un groupe Auto Scaling, [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)elles doivent être définies dans la définition du groupe Auto Scaling dans votre AWS CloudFormation modèle. Sinon, si vous utilisez un [modèle de lancement EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) avec le groupe Auto Scaling, vous pouvez définir les balises dans sa définition. Il est recommandé d'utiliser des [modèles de lancement EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) avec des groupes Auto Scaling ou avec un service de AWS conteneur. Ces services peuvent contribuer à garantir un balisage cohérent de vos instances Amazon EC2 et à prendre en charge [l'Auto Scaling sur plusieurs types d'instances et options d'achat](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/), ce qui peut améliorer la résilience et optimiser vos coûts de calcul. AWS CloudFormation Les [Hooks](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) fournissent aux développeurs un moyen de maintenir les principaux aspects de leur application conformes aux normes de leur organisation. Les hooks peuvent être configurés pour fournir un *avertissement* ou *empêcher le déploiement*. Cette fonctionnalité est particulièrement adaptée pour vérifier les éléments de configuration clés de vos modèles, par exemple si un groupe Auto Scaling est configuré pour appliquer des balises définies par le client à toutes les instances Amazon EC2 qu'il lance, ou pour s'assurer que tous les compartiments Amazon S3 sont créés avec les paramètres de chiffrement requis. Dans les deux cas, l'évaluation de cette conformité est repoussée au début du processus de déploiement avec des AWS CloudFormation hooks avant le déploiement. AWS CloudFormation permet de détecter lorsqu'une ressource (voir [Ressources prenant en charge la détection des dérives](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) fournie à partir d'un modèle a été modifiée et que les ressources ne correspondent plus aux configurations de modèle attendues. C'est ce que l'on appelle *la dérive*. Si vous utilisez l'automatisation pour appliquer des balises aux ressources gérées via IaC, vous les modifiez, ce qui introduit la dérive. Lors de l'utilisation d'IaC, il est actuellement recommandé de gérer toutes les exigences de balisage dans le cadre des modèles IaC, d'implémenter des AWS CloudFormation hooks et de publier des ensembles de règles AWS CloudFormation Guard pouvant être utilisés par l'automatisation. ## Ressources gérées par le pipeline CI/CD À mesure que la maturité d'une charge de travail augmente, il est probable que des techniques telles que l'intégration continue et le déploiement continu (CI/CD) soient adoptées. Ces techniques contribuent à réduire les risques liés au déploiement en facilitant le déploiement plus fréquent de petites modifications grâce à une automatisation accrue des tests. Une stratégie d'observabilité qui détecte les comportements inattendus introduits par un déploiement peut automatiquement annuler le déploiement avec un impact minimal sur les utilisateurs. À mesure que l'on en arrive au stade du déploiement des dizaines de fois par jour, il n'est tout simplement plus pratique d'appliquer des balises rétroactivement. Tout doit être exprimé sous forme de code ou de configuration, contrôler les versions et, dans la mesure du possible, testé et évalué avant le déploiement en production. Dans le [modèle combiné de développement et d'exploitation (DevOps)](https://aws.amazon.com/devops/what-is-devops/), de nombreuses pratiques prennent en compte les considérations opérationnelles sous forme de code et les valident au début du cycle de vie du déploiement. Idéalement, vous devez effectuer ces vérifications le plus tôt possible dans le processus (comme le montrent les AWS CloudFormation crochets), afin d'être sûr que votre AWS CloudFormation modèle respecte vos politiques avant qu'il ne quitte la machine du développeur. [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) fournit les moyens de rédiger des règles de conformité préventives pour tout ce que vous pouvez définir. CloudFormation Le modèle est validé par rapport aux règles de l'environnement de développement. De toute évidence, cette fonctionnalité a de nombreuses applications, mais dans ce livre blanc, nous allons simplement examiner quelques exemples qui garantiraient qu'elle [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)est toujours utilisée. Voici un exemple de règle de CloudFormation garde : ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` Dans l'exemple de code, nous filtrons le modèle pour toutes les ressources de ce type`AutoScalingGroup`, puis nous appliquons deux règles : + **`tags_asg_automation_EnvironmentId`**- Vérifie qu'une balise avec cette clé existe, qu'elle possède une valeur comprise dans la liste de valeurs autorisées et qu'elle `PropagateAtLaunch` est définie sur `true` + **`tags_asg_costAllocation_CostCenter`**- Vérifie qu'une balise existe avec cette clé, qu'elle possède une valeur commençant par la valeur du préfixe définie et qu'elle `PropagateAtLaunch` est définie sur `true` ## Exécution Comme décrit précédemment, **Resource Groups & Tag Editor** permet d'identifier les domaines dans lesquels vos ressources ne répondent pas aux exigences de balisage définies dans les politiques OUs de balises appliquées à l'organisation. L'accès à l'outil de console **Resource Groups & Tag Editor** depuis le compte d'un membre de l'organisation vous indique les politiques qui s'appliquent à ce compte et les ressources du compte qui ne répondent pas aux exigences de la politique de balises. En cas d'accès depuis le compte de gestion (et si l'*accès aux **politiques de balises** est activé* dans les services sous AWS Organizations), il est possible de vérifier la [conformité aux politiques de balises pour tous les comptes associés de l'organisation](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). Dans la politique de balises elle-même, vous pouvez activer l'application pour des types de ressources spécifiques. Dans l'exemple de politique suivant, nous avons ajouté l'application de telle sorte que toutes les ressources, `ec2:instance` quels que `ec2:volume` soient leur type, doivent être conformes à la politique. Il existe certaines limites connues, telles que la nécessité d'une balise sur une ressource pour qu'elle soit évaluée par la politique de balises. Voir [Ressources qui soutiennent l'application de politiques de balises](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html) pour obtenir une liste. ### ExampleInc-Coût-allocation.json Voici un exemple de politique de balises qui and/or applique les balises de répartition des coûts dans les rapports : ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config est un service qui vous permet d'évaluer, d'auditer et d'évaluer les configurations de vos AWS ressources (voir [Types de ressources pris en charge par AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)). Dans le cas du balisage, nous pouvons l'utiliser pour identifier les ressources dépourvues de balises avec des clés spécifiques, en utilisant la `required_tags` règle (voir [Types de ressources pris en charge par required\$1tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)). À partir de l'exemple précédent, nous pouvons tester l'existence de la clé sur toutes les instances Amazon EC2. Dans les cas où la clé n'existe pas, l'instance sera enregistrée comme non conforme. Ce AWS CloudFormation modèle décrit une AWS Config règle permettant de tester la présence des clés obligatoires décrites dans le tableau, sur les compartiments Amazon S3, les instances Amazon EC2 et les volumes Amazon EBS. ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` Pour les environnements où les ressources sont gérées manuellement, une AWS Config règle peut être améliorée pour ajouter automatiquement la clé de balise manquante aux ressources à l'aide d'une correction automatique via une AWS Lambda fonction. Bien que cela fonctionne bien pour les charges de travail statiques, cela devient progressivement moins efficace lorsque vous commencez à gérer vos ressources via iAC et des pipelines de déploiement. **AWS Organizations — Les politiques de contrôle des services (SCPs)** sont un type de politique d'organisation que vous pouvez utiliser pour gérer les autorisations au sein de votre organisation. SCPsoffrent un contrôle centralisé des autorisations maximales disponibles pour tous les comptes de votre organisation ou unité organisationnelle (UO). SCPs concernent uniquement les utilisateurs et les rôles gérés par des comptes faisant partie de l'organisation. Bien qu'ils n'affectent pas directement les ressources, ils limitent les autorisations des utilisateurs et des rôles, y compris les autorisations pour les actions de balisage. En ce qui concerne le balisage, cela SCPs peut fournir une granularité supplémentaire pour l'application des balises, en plus de ce que les politiques en matière de balises peuvent fournir. Dans l'exemple suivant, la politique refusera les `ec2:RunInstances` demandes où le `example-inc:cost-allocation:CostCenter` tag n'est pas présent. Ce qui suit est un SCP refusé : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ Il n'est pas possible de retrouver la politique de contrôle des services effective qui s'applique à un compte lié dès sa conception. Lorsque vous appliquez le balisage SCPs, la documentation doit être mise à la disposition des développeurs afin qu'ils puissent s'assurer que leurs ressources sont conformes aux politiques appliquées à leurs comptes. Fournir un accès en lecture seule aux CloudTrail événements de leur compte peut aider les développeurs à déboguer lorsque leurs ressources ne sont pas conformes. # Mesurer l'efficacité du marquage et apporter des améliorations Après avoir mis en œuvre une stratégie de balisage, il est important de mesurer son efficacité par rapport aux cas d'utilisation cibles. La mesure de l'efficacité varie selon les cas d'utilisation. Par exemple : + **Attribution des coûts** : vous pouvez mesurer la couverture des ressources par balisage en fonction des dépenses à l'aide d'outils tels que le [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)[rapport sur les AWS coûts et l'utilisation](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/). Par exemple, vous pouvez suivre le *pourcentage de ressources étiquetées ou non étiquetées* qui génèrent des frais, en particulier en surveillant des clés de balise spécifiques. + **Automatisation** - Vous souhaiterez peut-être vérifier si le résultat souhaité a été atteint. Par exemple, si les instances Amazon EC2 hors production sont suspendues en dehors des heures de bureau, audit des heures de démarrage et de fin des instances. [Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) intégré au compte de gestion fournit des fonctionnalités supplémentaires permettant d'analyser le respect des politiques de balises pour tous les comptes associés de votre organisation. Sur la base des résultats de la mesure de l'efficacité de votre balisage, déterminez si des améliorations ou des modifications sont nécessaires dans l'une des étapes telles que la définition des cas d'utilisation, la mise en œuvre ou l'application du schéma de balisage. Apportez les modifications nécessaires et répétez le cycle jusqu'à ce que l'efficacité souhaitée soit atteinte. Dans l'exemple d'attribution des coûts, vous pouvez examiner le pourcentage d'amélioration. Étant donné que ce sont les développeurs et les opérateurs qui doivent effectuer le balisage proprement dit des ressources, il est essentiel qu'ils en prennent possession. Ce n'est pas la seule responsabilité supplémentaire que les équipes assument généralement dans leur parcours d' AWS adoption. Une responsabilité accrue en matière de sécurité et de coût liés au développement et à l'exploitation de leurs applications est également importante. Organisations utilisent souvent des objectifs et des cibles pour motiver l'adoption de nouvelles pratiques. Cela peut donc également s'appliquer ici.