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. # Cas d'utilisation du balisage **Topics** + [Tags pour la répartition des coûts et la gestion financière](tags-for-cost-allocation-and-financial-management.md) + [Tags pour les opérations et le support](tags-for-operations-and-support.md) + [Balises pour la sécurité des données, la gestion des risques et le contrôle d'accès](tags-for-data-security-risk-management-and-access-control.md) # Tags pour la répartition des coûts et la gestion financière L'un des premiers cas d'utilisation du balisage auxquels les entreprises sont souvent confrontées est la visibilité et la gestion des coûts et de l'utilisation. Il y a généralement plusieurs raisons à cela : + **Il s'agit généralement d'un scénario bien compris et les exigences sont bien connues.** Par exemple, les équipes financières souhaitent connaître le coût total des charges de travail et de l'infrastructure couvrant plusieurs services, fonctionnalités, comptes ou équipes. L'un des moyens d'obtenir cette visibilité des coûts consiste à étiqueter les ressources de manière cohérente. + **Les balises et leurs valeurs sont clairement définies.** En général, des mécanismes de répartition des coûts existent déjà dans les systèmes financiers d'une organisation, par exemple le suivi par centre de coûts, unité commerciale, équipe ou fonction organisationnelle. + **Retour sur investissement rapide et démontrable.** Il est possible de suivre les tendances d'optimisation des coûts au fil du temps lorsque les ressources sont étiquetées de manière cohérente, par exemple pour les ressources correctement dimensionnées, mises à l'échelle automatique ou planifiées. Comprendre comment vous engagez les coûts vous AWS permet de prendre des décisions financières éclairées. Savoir où vous avez engagé des coûts au niveau des ressources, de la charge de travail, de l'équipe ou de l'organisation vous permet de mieux comprendre la valeur apportée au niveau applicable par rapport aux résultats commerciaux obtenus. Les équipes d'ingénierie n'ont peut-être pas l'expérience de la gestion financière de leurs ressources. Le recrutement d'une personne spécialisée en gestion AWS financière capable de former les équipes d'ingénierie et de développement aux bases de la gestion AWS financière et de créer une relation entre les finances et l'ingénierie afin de promouvoir la culture de la finance FinOps aidera à obtenir des résultats mesurables pour l'entreprise et encouragera les équipes à construire en tenant compte des coûts. La mise en place de bonnes pratiques financières est abordée en profondeur dans le [pilier d'optimisation des coûts](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) du Well-Architected Framework, mais nous aborderons quelques-uns des principes fondamentaux dans ce livre blanc. # Balises d’allocation des coûts La répartition des coûts fait référence à l'attribution ou à la distribution des coûts encourus aux utilisateurs ou aux bénéficiaires de ces coûts selon un processus défini. *Dans le contexte de ce livre blanc, nous divisons la répartition des coûts en deux types : *showback et chargeback*.* Les outils et mécanismes de *présentation* contribuent à accroître la prise en compte des coûts. La *rétrofacturation contribue au* recouvrement des coûts et favorise la prise de conscience des coûts. Le *showback* concerne la présentation, le calcul et le reporting des frais engagés par une entité spécifique, telle qu'une unité commerciale, une application, un utilisateur ou un centre de coûts. Par exemple : « l'équipe d'ingénierie de l'infrastructure était responsable de X dollars de AWS dépenses le mois dernier ». La *rétrofacturation* consiste à imputer les coûts engagés à ces entités par le biais des processus comptables internes d'une organisation, tels que les systèmes financiers ou les bons de journal. Par exemple : « X dollars ont été déduits du AWS budget de l'équipe d'ingénierie de l'infrastructure ». Dans les deux cas, le balisage approprié des ressources peut aider à attribuer le coût à une entité, la seule différence étant de savoir si quelqu'un est censé effectuer un paiement ou non. La gouvernance financière de votre organisation peut nécessiter une comptabilité transparente des coûts engagés au niveau de l'application, de l'unité commerciale, du centre de coûts et de l'équipe. L'attribution des coûts à l'aide de [balises de répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) vous fournit les données nécessaires pour attribuer avec précision les coûts engagés par une entité à partir de ressources étiquetées de manière appropriée. + **Responsabilité** — Veiller à ce que les coûts soient alloués aux personnes responsables de l'utilisation des ressources. Un point de service ou un groupe unique peut être responsable de l'examen des dépenses et des rapports. + **Transparence financière** — Affichez une vision claire des allocations de trésorerie destinées à l'informatique en créant des tableaux de bord efficaces et une analyse des coûts significative pour les dirigeants. + **Investissements informatiques éclairés** : suivez le retour sur investissement en fonction du projet, de l'application ou du secteur d'activité, et permettez aux équipes de prendre de meilleures décisions commerciales, par exemple en allouant davantage de fonds aux applications génératrices de revenus. En résumé, les balises de répartition des coûts peuvent vous aider à savoir : + Qui est responsable des dépenses et qui est chargé de les optimiser ? + Quelle charge de travail, quelle application ou quel produit est à l'origine des dépenses ? Quel environnement ou quelle scène ? + Quels sont les domaines de dépenses qui augmentent le plus rapidement ? + Quel montant de dépenses peut être déduit d'un AWS budget en fonction des tendances passées ? + Quel a été l'impact des efforts d'optimisation des coûts sur des charges de travail, des applications ou des produits particuliers ? L'activation des balises de ressources pour la répartition des coûts aide à définir des pratiques de mesure au sein de l'organisation qui peuvent être utilisées pour fournir une visibilité de l' AWS utilisation et accroître la transparence en matière de responsabilisation en matière de dépenses. Il met également l'accent sur la création d'un niveau de granularité approprié en ce qui concerne la visibilité des coûts et de l'utilisation et sur l'influence des comportements de consommation dans le cloud par le biais de rapports sur la répartition des coûts et du suivi des KPI. # Élaboration d'une stratégie de répartition des coûts ## Définition et mise en œuvre d'un modèle de répartition des coûts Créez un compte et une structure de coûts pour les ressources déployées dans AWS. Établissez la relation entre les coûts liés aux AWS dépenses, la manière dont ces coûts ont été engagés et qui ou quoi les a engagés. Les structures de coûts communes sont basées sur AWS Organizations les Comptes AWS environnements et les entités au sein de vos organisations, telles qu'un secteur d'activité ou une charge de travail. Les structures de coûts peuvent être basées sur plusieurs attributs afin de permettre l'examen des coûts de différentes manières ou à différents niveaux de granularité, par exemple en cumulant les coûts des différentes charges de travail au secteur d'activité qu'elles desservent. Lorsque vous choisissez une structure de coûts qui correspond aux résultats souhaités, évaluez les mécanismes de répartition des coûts en fonction de la *facilité de mise en œuvre* par rapport à la *précision souhaitée.* Cela peut inclure des considérations relatives à la responsabilité, à la disponibilité des outils et aux changements culturels. Les trois modèles de répartition des coûts les plus courants sur lesquels AWS les clients partent généralement sont les suivants : + **Basé sur les comptes** : ce modèle nécessite le moins d'efforts et fournit une grande précision pour les showbacks et les rétrofacturations. Il convient aux organisations ayant une structure de compte définie (et est conforme aux recommandations du livre blanc [Organizing Your AWS Environment Using Multiple](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) Accounts). Cela permet une visibilité claire des coûts par compte. Pour la visibilité et la répartition des coûts, vous pouvez utiliser [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)les [rapports sur les coûts et l'utilisation](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html), ainsi que [AWS les budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) pour le suivi et le suivi des coûts. Ces outils fournissent des options de filtrage et de regroupement par Comptes AWS. Du point de vue de la répartition des coûts, ce modèle ne doit pas nécessairement reposer sur un étiquetage précis des ressources individuelles. + **Par unité commerciale ou par équipe** : coût imputable aux équipes, aux unités commerciales ou aux organisations au sein d'une entreprise. Ce modèle nécessite un effort modéré, fournit une grande précision pour les showbacks et les rétrofacturations, et convient aux organisations qui ont une structure de compte définie (généralement en utilisant AWS Organizations), avec une séparation entre les différentes équipes, applications et types de charge de travail. Cela permet une visibilité claire des coûts entre les équipes et les applications et, en tant qu'avantage supplémentaire, réduit le risque d'atteindre les [quotas de AWS service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) en une seule fois Compte AWS. Par exemple, chaque équipe peut avoir cinq comptes (`prod`,`staging`,`test`,`dev`,`sandbox`), et aucune équipe ou application ne partagera le même compte. Avec une telle structure, [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) fournira alors la fonctionnalité permettant de regrouper les comptes ou d'autres balises (« méta-tagging ») en catégories, qui peuvent être suivies dans les outils mentionnés dans l'exemple précédent. Il est important de noter qu'il est AWS Organizations possible de baliser les comptes et les unités organisationnelles (OUs), mais ces balises ne seront pas applicables à la répartition des coûts et aux rapports de facturation (c'est-à-dire que vous ne pouvez pas regrouper ou filtrer vos coûts AWS Cost Explorer par unité d'organisation). AWS Cost Categories doit être utilisée à cette fin. + **Basé sur des balises** : ce modèle demande plus d'efforts que les deux précédents et fournira une grande précision pour les présentations et les rétrofacturations en fonction des exigences et de l'objectif final. Nous vous recommandons vivement d'adopter les pratiques décrites dans le livre blanc [Organiser votre AWS environnement à l'aide de comptes multiples](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), mais en réalité, les clients se retrouvent souvent avec des structures de comptes mixtes et complexes dont la migration prend du temps. La mise en œuvre d'une stratégie de balisage rigoureuse et efficace est essentielle dans ce scénario, suivie de l'[activation des balises pertinentes pour la répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) dans la console Billing and Cost Management (dans ce cas AWS Organizations, les balises ne peuvent être activées pour la répartition des coûts qu'à partir du compte Management Payer). Une fois les balises activées pour la répartition des coûts, les outils de visibilité et de répartition des coûts mentionnés dans les méthodes précédentes peuvent être utilisés pour les showbacks et les rétrofacturations. Notez que les balises de répartition des coûts ne sont pas rétrospectives et n'apparaîtront dans les outils de reporting de facturation et de suivi des coûts qu'une fois qu'elles auront été activées pour la répartition des coûts. En résumé, si vous devez suivre les coûts par unité commerciale, vous pouvez utiliser [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) pour regrouper les comptes liés au sein de AWS l'organisation en conséquence et afficher ce regroupement dans les rapports de facturation. Lorsque vous créez des comptes distincts pour les environnements de production et non liés à la production, vous pouvez également filtrer les coûts liés aux environnements dans des outils tels que [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), ou suivre ces coûts à l'aide de [AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html). Enfin, si votre cas d'utilisation nécessite un suivi des coûts plus précis, par exemple par charge de travail ou application individuelle, vous pouvez étiqueter les ressources de ces comptes en conséquence, [activer ces clés de balise pour la répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) sur le compte de gestion, puis filtrer ce coût par clés de balise dans les outils de reporting de facturation. ## Mise en place de processus de reporting et de suivi des coûts Commencez par identifier les types de coûts importants pour les parties prenantes internes (par exemple, les dépenses quotidiennes, le coût par compte, le coût par X, les coûts amortis). Ce faisant, vous pouvez atténuer les risques budgétaires associés à des dépenses inattendues ou anormales plus rapidement que d'attendre la AWS facture finalisée. Les balises fournissent l'attribution qui permet ces scénarios de reporting. Les informations tirées des rapports peuvent éclairer vos actions afin d'atténuer l'impact des dépenses anormales et imprévues sur les budgets financiers. En cas d'augmentation inattendue des coûts, il est important d'évaluer s'il y a eu une augmentation inattendue de la valeur livrée afin de déterminer si et quelles mesures sont nécessaires. Lorsque vous élaborez une stratégie de balisage pour soutenir la répartition des coûts, gardez à l'esprit les éléments suivants : + **AWS Organizations**- La répartition des coûts au sein de plusieurs comptes peut être effectuée par compte, par groupe de comptes ou par groupe de balises créé pour les ressources de ces comptes. Les balises créées pour les ressources résidant dans des comptes individuels ne AWS Organizations peuvent être utilisées pour la répartition des coûts qu'à partir du compte de gestion. + **AWS Compte** - La répartition des coûts au sein d'un compte Compte AWS peut être effectuée par des dimensions supplémentaires telles que les services ou les régions. Il est possible de baliser davantage les ressources d'un compte et de travailler avec les groupes de ces balises de ressources. + **Balises de répartition des coûts** - Les balises créées par l'utilisateur et les balises AWS générées peuvent être activées pour la répartition des coûts, si nécessaire. L'activation de balises pour la répartition des coûts dans la console de facturation (du compte de gestion intégré AWS Organizations) facilite les showbacks et les rétrofacturations. + **Cost Categories** - Les catégories de AWS coûts permettent de regrouper des comptes et des balises de regroupement (« méta-tagging ») au sein d'une AWS organisation, ce qui permet également d'analyser les coûts liés à ces catégories à l'aide d'outils tels que AWS Cost Explorer les AWS budgets et le rapport sur les AWS coûts et l'utilisation. ## Réalisation d'une rétrofacturation et d'une rétrofacturation pour les unités commerciales, les équipes ou les organisations de l'entreprise Attribuez les coûts à l'aide de votre processus de répartition des coûts, soutenu par votre structure de coûts et vos balises de répartition des coûts. Les tags peuvent être utilisés pour donner un aperçu aux équipes qui ne sont pas directement responsables du paiement des coûts, mais qui sont responsables de ces coûts. Cette approche permet de prendre conscience de leur contribution aux dépenses et de la manière dont ces coûts sont engagés. Procédez à la rétrofacturation aux équipes directement responsables des coûts afin de récupérer les dépenses liées aux ressources qu'elles ont consommées et de les informer de ces coûts et de la manière dont ils ont été engagés. ## Mesure et diffusion de l'efficence ou de la valeur KPIs Convenez d'un ensemble de mesures de coût unitaire ou d'indicateurs de performance clés pour mesurer l'impact de vos investissements en gestion financière dans le cloud. Cet exercice crée un langage commun entre les acteurs technologiques et commerciaux, et raconte une histoire basée sur l'eficience, plutôt qu'une histoire centrée uniquement sur les dépenses globales absolues. Pour plus d'informations, consultez ce blog qui explique [comment les indicateurs unitaires peuvent aider à harmoniser les fonctions commerciales](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/). ## Allocation de dépenses non allouables Selon les pratiques comptables de l'organisation, les différents types de frais peuvent nécessiter un traitement différent. Identifiez les ressources ou les catégories de coûts qui ne peuvent pas être étiquetées. En fonction des services utilisés et de ceux qu'il est prévu d'utiliser, convenez des mécanismes permettant de traiter et de mesurer ces dépenses non allouables. Par exemple, consultez la liste des ressources prises en charge par [Groupes de ressources AWS et Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html) dans le *guide de l'utilisateur de Groupes de ressources AWS and Tags*. Certains frais liés à des remises basées sur des engagements, tels que Reserved Instances (RI) et Savings Plans (SP), constituent un exemple courant de catégorie de coûts qui ne peut pas être étiquetée. Bien que les frais d'abonnement et les frais SP et RI non utilisés ne puissent pas être étiquetés avant d'apparaître dans les outils de reporting de facturation, vous pouvez suivre la manière dont les remises RI et SP s'appliquent aux comptes, aux ressources et à leurs tags AWS Organizations après coup. Par exemple, AWS Cost Explorer il est possible d'examiner le coût amorti, de regrouper les dépenses en fonction des clés de balise pertinentes et d'appliquer des filtres adaptés à votre cas d'utilisation. Dans le rapport sur les AWS coûts et l'utilisation (CUR), vous pouvez filtrer les lignes correspondant à l'utilisation couverte par les remises RI et SP (pour en savoir plus, consultez la section sur les cas d'utilisation de la [documentation CUR](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)) et sélectionner les colonnes qui ne concernent que vous. Chaque clé de balise activée pour la répartition des coûts sera présentée dans sa propre colonne distincte à la fin du rapport CUR, de la même manière qu'elle est présentée dans d'autres rapports de facturation existants, tels que le [rapport mensuel de répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html). Pour des références supplémentaires, consultez les [AWS Well-Architected](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/) Labs pour obtenir des exemples d'informations sur les coûts et l'utilisation à partir des données CUR. ## Génération de rapports Outre les AWS outils disponibles pour faciliter les showbacks et les rétrofacturations, il existe toute une gamme d'autres solutions AWS créées ou tierces qui peuvent aider à surveiller le coût des ressources étiquetées et à mesurer l'efficacité de la stratégie de balisage. En fonction des exigences et de l'objectif final de l'organisation, on peut soit investir du temps et des ressources dans la création de solutions personnalisées, soit acheter des outils fournis par l'un des [partenaires de compétence en outils de AWS Cloud gestion](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall). Si vous décidez de créer votre propre outil de répartition *des coûts basé sur une source unique de vérité* avec des paramètres contrôlés adaptés à l'entreprise, le rapport sur les AWS coûts et l'utilisation (CUR) fournit les données les plus détaillées sur les coûts et l'utilisation et permet de créer des tableaux de bord d'optimisation personnalisés, permettant le filtrage et le regroupement par comptes, services, catégories de coûts, balises de répartition des coûts et de nombreuses autres dimensions. Parmi les solutions basées sur le Cur développées par AWS Cur qui peuvent être utilisées comme l'un de ces outils, consultez les [tableaux de bord Cloud Intelligence](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) sur le site Web de Well-Architected Labs AWS . # Tags pour les opérations et le support Un AWS environnement comportera plusieurs comptes, ressources et charges de travail avec des exigences opérationnelles différentes. Les balises peuvent être utilisées pour fournir du contexte et des conseils aux équipes opérationnelles d'assistance afin d'améliorer la gestion de vos services. Les balises peuvent également être utilisées pour assurer la transparence de la gouvernance opérationnelle des ressources gérées. Certains des principaux facteurs à l'origine d'une définition cohérente des balises opérationnelles sont les suivants : + **Pour filtrer les ressources lors des activités d'infrastructure automatisées.** Par exemple, lors du déploiement, de la mise à jour ou de la suppression de ressources. Une autre solution est la mise à l'échelle des ressources pour optimiser les coûts et réduire l'utilisation en dehors des heures de bureau. Voir la solution [AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler/) pour un exemple pratique. + **Identifier les ressources isolées ou obsolètes.** Les ressources qui ont dépassé leur durée de vie définie ou qui ont été signalées comme devant être isolées par des mécanismes internes doivent être étiquetées de manière appropriée afin d'aider le personnel de soutien dans son enquête. Les ressources obsolètes doivent être étiquetées avant leur isolation, leur archivage et leur suppression. + **Support requis pour un groupe de ressources.** Les ressources ont souvent des exigences de support différentes. Par exemple, ces exigences peuvent être négociées entre les équipes ou définies dans le cadre de la criticité d'une application. Des conseils supplémentaires sur les modèles opérationnels sont disponibles dans le [pilier de l'excellence opérationnelle](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html). + **Améliorez le processus de gestion des incidents.** En balisant les ressources avec des balises qui offrent une plus grande transparence dans le processus de gestion des incidents, les équipes d'assistance et les ingénieurs ainsi que les équipes de gestion des incidents majeurs (MIM) peuvent gérer les événements plus efficacement. + **Sauvegardes.** Les balises peuvent également être utilisées pour identifier la fréquence à laquelle vos ressources doivent être sauvegardées, ainsi que l'emplacement des copies de sauvegarde ou l'endroit où les restaurer. [Conseils prescriptifs pour les approches de sauvegarde et de restauration](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html) sur. AWS + **Corriger.** L'application de correctifs aux instances mutables en cours d'exécution AWS est essentielle à la fois dans le cadre de votre stratégie globale de correction et dans le cadre de la correction des vulnérabilités de type « jour zéro ». Des conseils plus détaillés sur la stratégie globale d'application des correctifs peuvent être trouvés dans les directives [prescriptives](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). [La correction des vulnérabilités de type « zero-day » est abordée dans ce blog.](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) + **Observabilité opérationnelle**. La traduction d'une stratégie de KPI opérationnels en balises de ressources aidera les équipes opérationnelles à mieux déterminer si les objectifs sont atteints afin d'améliorer les exigences commerciales. L'élaboration d'une stratégie d'indicateurs clés de performance est un sujet distinct, mais elle a tendance à se concentrer sur une entreprise qui fonctionne de manière stable ou sur laquelle mesurer l'impact et les résultats du changement. Les [KPI Dashboards](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (AWS Well-Architected labs) et l'Operations KPI Workshop (un service [proactif de Support aux AWS entreprises](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) permettent tous deux de mesurer les performances de manière stable. L'article de blog sur la stratégie d' AWS entreprise [Measuring the Success of Your Transformation](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/) explore la mesure des KPI pour un programme de transformation, tel que la modernisation informatique ou la migration d'une solution sur site vers. AWS # Activités d'infrastructure automatisées Les balises peuvent être utilisées dans un large éventail d'activités d'automatisation lors de la gestion de l'infrastructure. L'utilisation de [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html), par exemple, vous permettra de gérer les automatisations et les runbooks sur les ressources spécifiées par la paire clé-valeur définie que vous créez. Pour les nœuds gérés, vous pouvez définir un ensemble de balises pour suivre ou cibler les nœuds par système d'exploitation et environnement. Vous pouvez ensuite exécuter un script de mise à jour pour tous les nœuds d'un groupe ou vérifier l'état de ces nœuds. Les [ressources de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) peuvent également être étiquetées pour affiner et suivre vos activités automatisées. L'automatisation du cycle de vie de démarrage et d'arrêt des ressources de l'environnement peut permettre une réduction significative des coûts pour toute organisation. Le [planificateur d'instance activé AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/) est un exemple de solution capable de démarrer et d'arrêter des instances Amazon EC2 et Amazon RDS lorsqu'elles ne sont pas nécessaires. Par exemple, les environnements de développement utilisant des instances Amazon EC2 ou Amazon RDS qui ne doivent pas nécessairement être exécutées le week-end n'exploitent pas le potentiel d'économie que peut apporter la fermeture de ces instances. En analysant les besoins des équipes et de leurs environnements, et en étiquetant correctement ces ressources pour automatiser leur gestion, vous pouvez utiliser votre budget de manière efficace. *Exemple de balise de planification utilisée par le planificateur d'instance sur une instance Amazon EC2 :* ``` { "Tags": [ { "Key": "Schedule", "ResourceId": "i-1234567890abcdef8", "ResourceType": "instance", "Value": "mon-9am-fri-5pm" } ] } ``` # Cycle de vie des charges **Vérifiez l'exactitude des données opérationnelles à l'appui.** Assurez-vous que les balises associées au cycle de vie de votre charge de travail font l'objet de révisions périodiques et que les parties prenantes concernées participent à ces révisions. *Tableau 7 — Révision des balises opérationnelles dans le cadre du cycle de vie de la charge de travail* | Cas d’utilisation | Clé de tag | Justification | Exemple de valeurs | | --- | --- | --- | --- | | Titulaire du compte | example-inc:account-owner:owner | Le propriétaire du compte et les ressources qu'il contient. | ops-center, dev-ops, app-team | | Avis du titulaire du compte | example-inc:account-owner:review | Vérification de la mise à jour et de l'exactitude des informations relatives à la propriété du compte. | | | Propriétaire des données | example-inc:data-owner:owner | Le propriétaire des données résidant sur les comptes. | bi-team, logistics, security | | Examen par le propriétaire des données | example-inc:data-owner:review | Vérification de la mise à jour et de l'exactitude des informations relatives à la propriété des données. | | ## Affectation de balises aux comptes suspendus avant de migrer vers l'unité d'organisation suspendue Avant de suspendre un compte et de passer à l'unité d'organisation suspendue, comme indiqué dans le livre blanc [Organiser votre AWS environnement à l'aide de plusieurs comptes](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), des balises doivent être ajoutées au compte afin de faciliter le suivi et l'audit internes du cycle de vie d'un compte. Par exemple, une URL relative ou une référence de ticket sur le système de billetterie ITSM d'une organisation, qui indique la piste d'audit d'une application suspendue. *Tableau 8 - Ajouter des balises opérationnelles lorsque le cycle de vie de la charge de travail entre dans une nouvelle phase* | Cas d’utilisation | Clé de tag | Justification | Exemple de valeurs | | --- | --- | --- | --- | | Titulaire du compte | example-inc:account-owner:owner | Le propriétaire du compte et les ressources qu'il contient. | ops-center, dev-ops, app-team | | Propriétaire des données | example-inc:data-owner:owner | Le propriétaire des données résidant sur les comptes. | bi-team, logistics, security | | Date de suspension | example-inc:suspension:date | Date à laquelle le compte a été suspendu | | | Approbation de la suspension | example-inc:suspension:approval | Le lien vers l'approbation de la suspension du compte | workload/deprecation | # Gestion des incidents Les tags peuvent jouer un rôle essentiel dans toutes les phases de la gestion des incidents, qu'il s'agisse de l'enregistrement des incidents, de la priorisation, de l'investigation, de la communication, de la résolution ou de la clôture. Les balises peuvent indiquer où un incident doit être enregistré, l'équipe ou les équipes qui doivent être informées de l'incident et la priorité d'escalade définie. Il est important de se rappeler que les balises ne sont pas cryptées. Pensez donc aux informations que vous y stockez. De plus, dans les organisations, les équipes et les chaînes hiérarchiques, les responsabilités changent. Pensez donc à stocker un lien vers un portail sécurisé où ces informations peuvent être gérées plus efficacement. Il n'est pas nécessaire que ces balises soient exclusives. Par exemple, l'ID d'application peut être utilisé pour rechercher les chemins d'escalade dans un portail de gestion des services informatiques. Assurez-vous qu'il est clairement indiqué dans vos définitions opérationnelles que cette balise est utilisée à des fins multiples. Les balises relatives aux exigences opérationnelles peuvent également être détaillées, afin d'aider les responsables des incidents et le personnel des opérations à affiner leurs objectifs en réponse à un incident ou à un événement. Les liens relatifs (vers l'URL de la base de connaissances) pour les [runbooks](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html) et les [playbooks](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html) peuvent être inclus sous forme de balises pour aider les équipes répondantes à identifier le processus, la procédure et la documentation correspondants. *Tableau 9 - Utiliser des balises opérationnelles pour informer la gestion des incidents* | Cas d’utilisation | Clé de tag | Justification | Exemple de valeurs | | --- | --- | --- | --- | | Gestion des incidents | example-inc:incident-management:escalationlog | Le système utilisé par l'équipe d'assistance pour enregistrer les incidents | jira, servicenow, zendesk | | Gestion des incidents | example-inc:incident-management:escalationpath | La voie de l'escalade | ops-center, dev-ops, app-team | | Répartition des coûts et gestion des incidents | example-inc:cost-allocation:CostCenter | Surveillez les coûts par centre de coûts. Il s'agit d'un exemple de balise à double usage dans laquelle le centre de coûts est utilisé comme code d'application pour la journalisation des incidents. | 123-\$1 | | Sauvegarde planifiée | example-inc:backup:schedule | Backup planning de la ressource | Daily | | Playbook/Gestion des incidents | example-inc:incident-management:playbook | Playbook documenté | webapp/incident/playbook | # Application de correctifs Organisations peuvent automatiser leur stratégie d'application de correctifs pour les environnements informatiques mutables et maintenir les instances mutables conformes à la ligne de base de correctifs définie pour cet environnement d'application en utilisant AWS Systems Manager Patch Manager et. AWS Lambda**Une stratégie de balisage pour les instances mutables au sein de ces environnements peut être gérée en affectant ces instances à des **groupes de correctifs** et à des fenêtres de maintenance.** Consultez les exemples suivants pour un split Dev → Test → Prod. AWS des instructions prescriptives sont disponibles pour la [gestion des correctifs des instances mutables](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). *Tableau 10 - Les balises opérationnelles peuvent être spécifiques à l'environnement* | Développement | Intermédiaire | Production | | --- | --- | --- | | 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
| Les vulnérabilités de type « jour zéro » peuvent également être gérées en définissant des balises pour compléter votre stratégie d'application de correctifs. Reportez-vous à la section [Éviter les vulnérabilités de type « jour zéro » grâce à l'application de correctifs de sécurité le jour même à l'aide de AWS Systems Manager](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) pour obtenir des instructions détaillées. # Observabilité opérationnelle L'observabilité est nécessaire pour obtenir des informations exploitables sur les performances de vos environnements et vous aider à détecter et à étudier les problèmes. Il a également un objectif secondaire qui vous permet de définir et de mesurer des indicateurs de performance clés (KPIs) et des objectifs de niveau de service (SLOs) tels que le temps de disponibilité. Pour la plupart des entreprises, KPIs les opérations importantes sont le temps moyen de détection (MTTD) et le temps moyen de reprise (MTTR) après un incident. Tout au long de l'observabilité, le contexte est important, car les données sont collectées, puis les balises associées sont collectées. Quel que soit le service, l'application ou le niveau d'application sur lequel vous vous concentrez, vous pouvez filtrer et analyser pour ce jeu de données spécifique. Les tags peuvent être utilisés pour automatiser l'intégration aux CloudWatch alarmes afin que les bonnes équipes puissent être alertées lorsque certains seuils métriques sont dépassés. Par exemple, une clé de balise `example-inc:ops:alarm-tag` et la valeur qu'elle contient peuvent indiquer la création de l' CloudWatch alarme. Une solution illustrant cela est décrite dans [Utiliser des balises pour créer et gérer des CloudWatch alarmes Amazon pour les instances Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/). La configuration d'un trop grand nombre d'alarmes peut facilement créer une tempête d'alertes, lorsqu'un grand nombre d'alarmes ou de notifications submergent rapidement les opérateurs et réduisent leur efficacité globale alors que les opérateurs trient et hiérarchisent manuellement les alarmes individuelles. Un contexte supplémentaire pour les alarmes peut être fourni sous forme de balises, ce qui signifie que des règles peuvent être définies au sein d'Amazon EventBridge pour garantir que l'accent est mis sur le problème en amont plutôt que sur les dépendances en aval. Le rôle des opérations parallèles DevOps est souvent négligé, mais pour de nombreuses organisations, les équipes opérationnelles centrales fournissent toujours une première réponse essentielle en dehors des heures normales de bureau. (Vous trouverez plus de détails sur ce modèle dans le [livre blanc sur l'excellence opérationnelle](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html).) Contrairement à l' DevOps équipe responsable de la charge de travail, elle n'a généralement pas les mêmes connaissances approfondies. Le contexte fourni par les balises dans les tableaux de bord et les alertes peut donc les diriger vers le runbook adapté au problème, ou lancer un runbook automatique (voir le billet de blog Automating [Amazon CloudWatch ](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) Alarms with). AWS Systems Manager # Balises pour la sécurité des données, la gestion des risques et le contrôle d'accès Organisations ont des besoins et des obligations variés à satisfaire en ce qui concerne la gestion appropriée du stockage et du traitement des données. La classification des données est un précurseur important pour plusieurs cas d'utilisation, tels que le contrôle d'accès, la conservation des données, l'analyse des données et la conformité. # Sécurité des données et gestion des risques Au sein d'un AWS environnement, vous aurez probablement des comptes soumis à des exigences de conformité et de sécurité différentes. Par exemple, vous pouvez disposer d'un sandbox pour développeurs et d'un compte hébergeant l'environnement de production pour une charge de travail hautement réglementée, telle que le traitement des paiements. En les isolant dans différents comptes, vous pouvez [appliquer des contrôles de sécurité distincts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment), [restreindre l'accès aux données sensibles](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data) et réduire la portée de l'audit pour les charges de travail réglementées. L'adoption d'une norme unique pour toutes les charges de travail peut être source de défis. Bien que de nombreux contrôles s'appliquent de la même manière dans un environnement, certains sont excessifs ou non pertinents pour les comptes qui n'ont pas besoin de respecter des cadres réglementaires spécifiques et pour les comptes dans lesquels aucune donnée personnelle identifiable ne sera jamais présente (par exemple, un sandbox pour développeurs ou des comptes de développement de charge de travail). Cela conduit généralement à des résultats de sécurité faussement positifs qui doivent être triés et corrigés sans aucune action, ce qui réduit les efforts nécessaires aux résultats qui devraient faire l'objet d'une enquête. *Tableau 11 — Exemples de balises de sécurité des données et de gestion des risques* | Cas d’utilisation | Clé de tag | Justification | Exemple de valeurs | | --- | --- | --- | --- | | Gestion des incidents | example-inc:incident- management:escalationlog | Le système utilisé par l'équipe d'assistance pour enregistrer les incidents | jira, servicenow, zendesk | | Gestion des incidents | example-inc:incident- management:escalationpath | La voie de l'escalade | ops-center, dev-ops, app-team | | Classification des données | example-inc:data:classification | Classifiez les données à des fins de conformité et de gouvernance | Public, Private, Confidential, Restricted | | Conformité d’ | example-inc:compliance:framework | Identifie le cadre de conformité auquel la charge de travail est soumise | PCI-DSS, HIPAA | La gestion manuelle des différents contrôles dans un AWS environnement est à la fois chronophage et source d'erreurs. L'étape suivante consiste à automatiser le déploiement des contrôles de sécurité appropriés et à configurer l'inspection des ressources en fonction de la classification de ce compte. En appliquant des balises aux comptes et aux ressources qu'ils contiennent, le déploiement des contrôles peut être automatisé et configuré en fonction de la charge de travail. **Exemple : ** Une charge de travail inclut un compartiment Amazon S3 dont la balise `example-inc:data:classification` contient la valeur`Private`. L'automatisation des outils de sécurité déploie une AWS Config règle `s3-bucket-public-read-prohibited` qui vérifie les paramètres de blocage de l'accès public du compartiment Amazon S3, la politique du compartiment et la liste de contrôle d'accès au compartiment (ACL), confirmant que la configuration du compartiment est adaptée à la classification des données. Pour garantir que le contenu du compartiment est conforme à la classification, [Amazon Macie peut être configuré pour vérifier la présence d'informations personnelles identifiables (PII](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/)). Le blog [Utiliser Amazon Macie pour valider la classification des données des compartiments S3](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) explore ce modèle de manière plus approfondie. Certains environnements réglementaires, tels que les assurances et les soins de santé, peuvent être soumis à des politiques obligatoires de conservation des données. La conservation des données à l'aide de balises, associée aux politiques de cycle de vie d'Amazon S3, peut être un moyen simple et efficace de définir les transitions d'objets vers un autre niveau de stockage. Les règles du cycle de vie d'Amazon S3 peuvent également être utilisées pour faire expirer des objets afin de les supprimer après l'expiration de la période de conservation obligatoire. Reportez-vous à [Simplifiez le cycle de vie de vos données en utilisant des balises d'objet avec Amazon S3 Lifecycle](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/) pour un guide détaillé de ce processus. En outre, lors du tri ou du traitement d'une constatation de sécurité, les balises peuvent fournir à l'enquêteur un contexte important qui aide à qualifier le risque et à impliquer les équipes appropriées pour enquêter ou atténuer le résultat. # Tags pour la gestion des identités et le contrôle d'accès Lors de la gestion du contrôle d'accès dans un AWS environnement doté de balises AWS IAM Identity Center, les balises peuvent activer plusieurs modèles de mise à l'échelle. Plusieurs modèles de délégation peuvent être appliqués, certains sont basés sur le balisage. Nous les aborderons individuellement et fournirons des liens pour en savoir plus sur chacun d'entre eux. # ABAC pour les ressources individuelles Les utilisateurs et les rôles IAM de l'IAM Identity Center prennent en charge le contrôle d'accès basé sur les attributs (ABAC), qui vous permet de définir l'accès aux opérations et aux ressources en fonction de balises. ABAC permet de réduire le besoin de mettre à jour les politiques d'autorisation et vous aide à baser l'accès sur les attributs des employés figurant dans le répertoire de votre entreprise. Si vous utilisez déjà une stratégie multi-comptes, l'ABAC peut être utilisé en complément du contrôle d'accès basé sur les rôles (RBAC) pour fournir à plusieurs équipes opérant sur le même compte un accès granulaire à différentes ressources. Par exemple, les utilisateurs du centre d'identité IAM ou les rôles IAM peuvent inclure des conditions visant à limiter l'accès à des instances Amazon EC2 spécifiques qui, autrement, devraient être explicitement répertoriées dans chaque politique pour y accéder. Étant donné qu'un modèle d'autorisation ABAC repose sur des balises pour accéder aux opérations et aux ressources, il est important de prévoir des garde-fous pour empêcher tout accès involontaire. SCPs peut être utilisé pour protéger les tags au sein de votre organisation en autorisant uniquement la modification des tags sous certaines conditions. Les blogs [Sécurisation des balises de ressources utilisées pour l'autorisation à l'aide d'une politique de contrôle des services AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) et [des limites d'autorisations pour les entités IAM fournissent des](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) informations sur la manière de mettre en œuvre cette politique. Lorsque des instances Amazon EC2 à longue durée de vie sont utilisées pour prendre en charge des pratiques opérationnelles plus traditionnelles, cette approche peut être utilisée. Le [blog Configure IAM Identity Center ABAC pour les instances Amazon EC2 et le gestionnaire de session Systems Manager décrivent](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) plus en détail cette forme de contrôle d'accès basé sur les attributs. Comme indiqué précédemment, tous les types de ressources ne prennent pas en charge le balisage, et parmi ceux qui le sont, tous ne prennent pas en charge l'application de politiques de balises. Il est donc conseillé d'évaluer cela avant de commencer à implémenter cette stratégie sur un Compte AWS. Pour en savoir plus sur les services compatibles avec ABAC, consultez la section [AWS Services compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).