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.
# Comprendre les données de répartition des coûts
Vous pouvez utiliser les rapports sur les coûts et l'utilisation (AWS CUR) pour suivre les coûts de vos conteneurs Amazon ECS et Amazon EKS. À l'aide de données de répartition des coûts, vous pouvez affecter les coûts de vos conteneurs à des unités commerciales et à des équipes individuelles, en fonction de la manière dont vos charges de travail de conteneurs consomment les ressources de calcul et de mémoire partagées. Les données de répartition des coûts fractionnés introduisent les données de coût et d'utilisation des nouvelles ressources au niveau du conteneur (c'est-à-dire les tâches ECS et les pods Kubernetes) dans le CUR. AWS Auparavant, AWS CUR ne prenait en charge les coûts qu'au niveau de l'instance EC2. Les données de répartition des coûts génèrent des coûts au niveau du conteneur en examinant la consommation de ressources de chaque instance EC2 de chaque conteneur, et génèrent des coûts basés sur le coût amorti de l'instance et le pourcentage de ressources de processeur et de mémoire consommées par les conteneurs exécutés sur l'instance.
Pour les instances de calcul accéléré utilisées avec Amazon EKS, les données de répartition des coûts incluent l'allocation de ressources pour les processeurs spécialisés, ainsi que le processeur et la mémoire. Cela couvre les accélérateurs NVIDIA et AMD GPUs, AWS Trainium et AWS Inferentia. Cette fonctionnalité est disponible uniquement pour les environnements Amazon EKS et fournit des données de réservation de ressources au niveau des pods pour ces ressources informatiques accélérées. Cela vous permet de suivre et d'allouer les coûts pour les charges de travail qui utilisent ces processeurs spécialisés, telles que les applications d'intelligence artificielle et d'apprentissage automatique et d'autres tâches gourmandes en calculs. Pour obtenir la liste actuelle des instances de calcul accéléré, consultez la section [Calcul accéléré](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing).
Les données de répartition des coûts fractionnés introduisent de nouveaux enregistrements d'utilisation et de nouvelles colonnes de mesures de coûts pour chaque ID de ressource conteneurisée (c'est-à-dire, tâche ECS et pod Kubernetes) dans CUR. AWS Pour plus d'informations, consultez la section [Détails des articles fractionnés](https://docs.aws.amazon.com/cur/latest/userguide/split-line-item-columns.html).
Lorsque vous incluez des données de répartition des coûts dans le AWS CUR, deux nouveaux enregistrements d'utilisation sont ajoutés pour chaque tâche ECS et chaque pod Kubernetes par heure afin de refléter les coûts du processeur et de la mémoire. Pour estimer le nombre de nouvelles rubriques en AWS CUR par jour, utilisez la formule suivante :
Pour ECS : `(number of tasks * average task lifetime * 2) * 24`
Pour EKS : `(number of pods * average pod lifetime * 2) * 24`
Par exemple, si 1 000 pods s'exécutent chaque heure sur un cluster de 10 instances EC2 et que la durée de vie du pod est inférieure à 1 heure, alors :
`(1000 * 1 * 2) * 24 = 48,000 new usage records in AWS CUR`
Pour les instances de calcul accéléré dans Amazon EKS, trois nouveaux enregistrements d'utilisation sont ajoutés pour chaque pod Kubernetes par heure afin de refléter les coûts de l'accélérateur, du processeur et de la mémoire. Pour estimer le nombre de nouvelles rubriques en AWS CUR par jour, utilisez la formule suivante :
Pour EKS avec calcul accéléré : `(number of pods * average pod lifetime * 3) * 24`
Par exemple, si 1 000 pods s'exécutent chaque heure sur un cluster de 10 instances EC2 et que la durée de vie de chaque pod est inférieure à une heure, alors : `(1000 * 1 * 3) * 24 = 72,000 new usage records in AWS CUR`
**Note**
Pour ECS : en ce qui concerne les balises de répartition des AWS coûts, vous pouvez utiliser des balises gérées par Amazon ECS ou des balises ajoutées par l'utilisateur pour vos rapports sur les coûts et l'utilisation. Ces balises s'appliquent à tous les nouveaux enregistrements d'utilisation des données de répartition des coûts partagés ECS. Pour plus d'informations, consultez la section [Marquage de vos ressources ECS pour la facturation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html#tag-resources-for-billing).
Pour EKS : les données de répartition des coûts fractionnées créent de nouvelles balises de répartition des coûts pour certains attributs Kubernetes. Ces balises incluent `aws:eks:cluster-name``aws:eks:deployment`,`aws:eks:namespace`,`aws:eks:node`,`aws:eks:workload-name`, et`aws:eks:workload-type`.
`aws:eks:cluster-name``aws:eks:namespace`, et `aws:eks:node` sont renseignés rétrospectivement avec le nom du cluster, de l'espace de noms et du nœud.
`aws:eks:workload-type`n'est renseigné que s'il existe exactement une charge de travail gérant le pod et s'il s'agit de l'une des charges de travail intégrées. Les types de charge de travail incluent `ReplicaSet` `StatefulSet``Job`,`DaemonSet`,, ou`ReplicationController`, et `aws:eks:workload-name` inclut le nom de la charge de travail. Pour plus d'informations, consultez la section [Charges de travail](https://kubernetes.io/docs/concepts/workloads/) dans la documentation de *Kubernetes*.
`aws:eks:deployment`est renseigné uniquement pour le type de charge de travail`ReplicaSet`. C'est le déploiement qui crée un`ReplicaSet`.
Ces balises s'appliquent à tous les nouveaux enregistrements d'utilisation des données de répartition des coûts partagés d'EKS. Ces balises sont activées par défaut pour la répartition des coûts. Si vous avez déjà utilisé et désactivé le `aws:eks:cluster-name` tag, les données de répartition des coûts fractionnés conservent ce paramètre et n'activent pas le tag. Vous pouvez l'activer depuis la page de console [des balises de répartition des coûts](https://console.aws.amazon.com/billing/home#/tags).
# Activation des données de répartition des coûts fractionnés
**Note**
Les données de répartition des coûts fractionnés ne sont pas disponibles dans Cost Explorer. Il est disponible dans les anciens rapports sur les coûts et l'utilisation (CUR) et dans le rapport sur les coûts et l'utilisation 2.0 (CUR 2.0) avec exportations de données.
Il est indispensable d'opter pour le fractionnement des données de répartition des coûts via les préférences de gestion des coûts.
**Pour choisir de fractionner les données de répartition des coûts**
1. Ouvrez la console Billing and Cost Management à l'adresse [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Dans le volet de navigation, choisissez les **préférences de gestion des coûts**.
1. Sous **Général**, dans la section **Données de répartition des coûts fractionnée**, choisissez l'une des options suivantes :
+ **Amazon Elastic Container Service (Amazon ECS)** pour souscrire à Amazon ECS uniquement.
+ **Amazon Elastic Kubernetes Service (Amazon EKS) pour souscrire à Amazon** EKS uniquement. Pour Amazon EKS, choisissez l'une des options suivantes :
+ **Demandes de ressources** : cela alloue uniquement les ressources du processeur et de la mémoire du pod Amazon EC2 by Kubernetes. Cela encouragera les équipes de candidature à ne fournir que ce dont elles ont besoin.
+ **Amazon Managed Service for Prometheus** : cela répartit vos coûts Amazon EC2 en fonction du montant le plus élevé entre les demandes de ressources de processeur et de mémoire du pod Kubernetes et l'utilisation réelle. Cela garantit que chaque équipe d'application paie pour ce qu'elle utilise. Pour en savoir plus sur la configuration d'Amazon Managed Service pour Prometheus, [consultez](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-setting-up.html) le guide de l'utilisateur d'*Amazon Managed Service pour Prometheus*.
Prérequis : vous devez activer toutes les fonctionnalités dans AWS Organizations. Pour en savoir plus, consultez la section [Activation de toutes les fonctionnalités de votre organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) dans le *guide de l'utilisateur des Organisations*.
+ **Amazon CloudWatch Container Insights** : cela fournit une visibilité plus précise des coûts pour vos clusters exécutant plusieurs conteneurs d'applications à l'aide d'instances EC2 partagées, ce qui permet une meilleure allocation des coûts pour les coûts partagés de vos clusters EKS.
**Note**
Seuls les comptes réguliers et payeurs ont accès aux AWS Cost Management préférences et peuvent choisir de partager les données de répartition des coûts. Une fois inscrits, les comptes membres peuvent consulter les données dans les rapports sur les coûts et l'utilisation.
Si vous choisissez des demandes de ressources, seuls les pods configurés avec des demandes de mémoire et de processeur sont utilisés par les données de répartition des coûts fractionnés. Les pods qui n'ont fait l'objet d'aucune demande d'utilisation ne verront aucune donnée de partage des coûts.
Si vous choisissez Amazon Managed Service pour Prometheus, vous devez activer toutes les fonctionnalités dans Organizations. AWS Pour plus d'informations, consultez la section [Activation de toutes les fonctionnalités de votre organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html). En outre, les données de répartition des coûts créent un nouveau rôle lié au service, qui permet d'accéder aux AWS services et aux ressources utilisés ou gérés par des données de répartition des coûts partagés.
Pour les instances de calcul accéléré, seule l'option de demande de ressources est prise en charge. Ni Amazon Managed Service for Prometheus ni CloudWatch Amazon Container Insights ne sont pris en charge pour ces instances. Lors de l'utilisation d'instances de calcul accéléré, le système utilise par défaut la demande de ressource pour calculer les coûts de l'accélérateur, du processeur et de la mémoire, même si d'autres options de mesure sont activées.
Une fois que vous vous êtes inscrit, vous pouvez choisir d'inclure les données de coût et d'utilisation des ressources au niveau du conteneur dans votre rapport lors de la première étape de création du rapport ou ultérieurement en modifiant les détails du rapport.
**Pour inclure les données relatives aux coûts et à l'utilisation dans votre rapport**
1. Ouvrez la console Billing and Cost Management à l'adresse [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Dans le volet de navigation, sous **Legacy Pages**, sélectionnez **Cost and Usage Reports**.
1. Que vous créiez un nouveau rapport ou modifiiez un rapport existant, sur la page **Spécifier les détails du rapport**, sous **Contenu du rapport**, sélectionnez **Fractionner les données de répartition des coûts**.
**Note**
Vous pouvez également utiliser l'API AWS CUR ou la AWS Command Line Interface (CLI) pour gérer vos préférences en matière de données de répartition des coûts.
Les données de répartition des coûts fractionnées permettent une visibilité des coûts pour tous les objets de conteneur Amazon ECS et Amazon EKS dans l'ensemble de votre famille de facturation consolidée (payeur et comptes liés). Une fois activées, les données de répartition des coûts fractionnés scannent automatiquement les tâches et les conteneurs. Il ingère les données d'utilisation de la télémétrie pour les charges de travail de vos conteneurs et prépare les données de coûts granulaires pour le mois en cours.
**Note**
La visibilité des données dans le AWS CUR peut prendre jusqu'à 24 heures.
Pour plus d'informations sur la gestion de l'accès aux pages de la console Billing and Cost Management, consultez la section [Présentation de la gestion des autorisations d'accès](https://docs.aws.amazon.com/cost-management/latest/userguide/control-access-billing.html).
Pour plus d'informations sur les AWS Cost Management préférences et le contrôle de l'accès à Cost Explorer, consultez la section [Contrôle de l'accès à Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html).
# Exemple de données de répartition des coûts fractionnés
L'objectif de l'exemple suivant est de vous montrer comment les données de répartition des coûts partagés sont calculées en calculant le coût des services Amazon ECS individuels, des tâches dans les clusters Amazon ECS, ainsi que de l'espace de noms et des pods Kubernetes dans les clusters Amazon EKS. Les taux utilisés dans cet exemple sont fournis à titre indicatif uniquement.
**Note**
L'exemple montre l'espace de noms et les pods Kubernetes exécutés dans des clusters Amazon EKS. Nous pouvons ensuite appliquer le même modèle de coût au service Amazon ECS et aux tâches exécutées dans un cluster Amazon ECS.
Vous pouvez utiliser les produits suivants en une heure :
+ Cluster partagé à instance unique (m5.xlarge) avec deux espaces de noms et quatre pods, fonctionnant pendant une heure complète.
+ La configuration de l'instance est de 4 vCPU et 16 Go de mémoire.
+ Le coût amorti de l'instance est de 1 dollar de l'heure.
Les données de répartition des coûts divisés utilisent des poids unitaires relatifs pour le processeur et la mémoire sur la base d'un ratio de 9:1. Ceci est dérivé des prix par vCPU par heure et par Go par heure en. [AWS Fargate](https://aws.amazon.com/fargate/pricing/)
## Étape 1 : Calculez le coût unitaire du processeur et de la mémoire
`Unit-cost-per-resource = Hourly-instance-cost/((Memory-weight * Memory-available) + (CPU-weight * CPU-available))`
= 1\$1 (1 \$1 16 Go) \$1 (9\$1 4 vCPU)) = 0,02\$1
`Cost-per-vCPU-hour = CPU-weight * Unit-cost-per-resource`
= 9\$1 0,02\$1 = 0,17\$1
`Cost-per-GB-hour = Memory-weight * Unit-cost-per-resource`
= 1\$1 0,02\$1 = 0,02\$1
****
| Instance | Instance type | vCPU-available | Memory-available | Amortized-cost-per-hour | Cost-per-vCPU-hour | Cost-per-GB-hour |
| --- | --- | --- | --- | --- | --- | --- |
| Instance1 | m5.xlarge | 4 | 16 | 1\$1 | 0,17\$1 | 0,02\$1 |
## Étape 2 : Calculez la capacité allouée et la capacité inutilisée de l'instance
+ Capacité allouée : mémoire et vCPU alloués au pod Kubernetes depuis l'instance EC2 parent, définis comme le maximum de capacité utilisée et réservée.
**Note**
Si les données d'utilisation de la mémoire ou du vCPU ne sont pas disponibles, les données de réservation seront utilisées à la place. Pour plus d'informations, consultez les [rapports d'utilisation d'Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/usage-reports.html) ou la [surveillance des coûts Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring.html).
+ Capacité inutilisée de l'instance : capacité inutilisée du vCPU et de la mémoire.
`Pod1-Allocated-vCPU = Max (1 vCPU, 0.1 vCPU)`= 1 vCPU
`Pod1-Allocated-memory = Max (4 GB, 3 GB)`= 4 Go
`Instance-Unused-vCPU = Max (CPU-available - SUM(Allocated-vCPU), 0)`= Maximum (4 — 4,9, 0) = 0
`Instance-Unused-memory = Max (Memory-available - SUM(Allocated-memory), 0)`= Maximum (16 — 14, 0) = 2 Go
Dans cet exemple, le processeur de l'instance est dépassé par abonnement, attribué à Pod2 qui a utilisé plus de vCPU que ce qui était réservé.
****
| Pod name | Namespace | Reserved-vCPU | Used-vCPU | Allocated-vCPU | Reserved-memory | Used-memory | Allocated-memory |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 1 | 0.1 | 1 | 4 | 3 | 4 |
| Pod2 | Namespace2 | 1 | 1.9 | 1.9 | 4 | 6 | 6 |
| Pod3 | Namespace1 | 1 | 0.5 | 1 | 2 | 2 | 2 |
| Pod4 | Namespace2 | 1 | 0.5 | 1 | 2 | 2 | 2 |
| Unused | Unused | | | 0 | | | 2 |
| | | | | 4,9 | | | 16 |
## Étape 3 : Calculez les ratios d'utilisation fractionnés
+ Taux d'utilisation fractionné : pourcentage du processeur ou de la mémoire utilisé par le pod Kubernetes par rapport à l'ensemble du processeur ou de la mémoire disponible sur l'instance EC2.
+ Taux d'utilisation : pourcentage de processeur ou de mémoire utilisé par le pod Kubernetes par rapport à l'ensemble du processeur ou de la mémoire utilisé sur l'instance EC2 (c'est-à-dire sans tenir compte du processeur ou de la mémoire inutilisés de l'instance).
`Pod1-vCPU-split-usage-ratio = Allocated-vCPU / Total-vCPU`
= 1 vCPU/4,9 vCPU = 0,204
`Pod1-Memory-split-usage-ratio = Allocated-GB / Total-GB`
= 4 GO/16 GO = 0,250
`Pod1-vCPU-unused-ratio = Pod1-vCPU-split-usage-ratio / (Total-CPU-split-usage-ratio – Instance-unused-CPU)`(défini sur 0 si Instance-unused-CPU c'est 0)
= 0 (puisque Instance-unused-CPU c'est 0)
`Pod1-Memory-unused-ratio = Pod1-Memory-split-usage-ratio / (Total-Memory-split-usage-ratio – Instance-unused-memory)`(défini sur 0 si Instance-unused-memory c'est 0)
= 0,250/(1-0,125) = 0,286
****
| Pod name | Namespace | vCPU-split-usage-ratio | vCPU-unused-ratio | Memory-split-usage-ratio | Memory-unused-ratio |
| --- | --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 0,204 | 0 | 0,250 | 0,286 |
| Pod2 | Namespace2 | 0,388 | 0 | 0,375 | 0,429 |
| Pod3 | Namespace1 | 0,204 | 0 | 0.125 | 0.143 |
| Pod4 | Namespace2 | 0,204 | 0 | 0.125 | 0.143 |
| Unused | Unused | 0 | | 0.125 | |
| | | 1 | | 1 | |
## Étape 4 : Calculez le coût partagé et les coûts non utilisés
+ Coût partagé : allocation du coût par utilisation du coût de l'instance EC2 en fonction du processeur alloué et de l'utilisation de la mémoire par le pod Kubernetes.
+ Coût d'instance non utilisé : coût des ressources de processeur ou de mémoire non utilisées sur l'instance.
`Pod1-Split-cost = (Pod1-vCPU-split-usage-ratio * vCPU-available * Cost-per-vCPU-hour) + (Pod1-Memory-split-usage-ratio * Memory-available * Cost-per-GB-hour)`
= (0,204 \$1 4 vCPU \$1 0,17\$1) \$1 (0,25 \$1 16 Go\$1 0,02\$1) = 0,22\$1
`Pod1-Unused-cost = (Pod1-vCPU-unused-ratio * Instance-vCPU-unused-ratio * vCPU-available * Cost-per-VCPU-hour) + (Pod1-Memory-unused-ratio * Instance-Memory-unused ratio * Memory-available * Cost-per-GB-hour)`
= (0 \$1 0 \$1 4 \$1 0,17\$1) \$1 (0,286 \$1 0,125 \$1 16 \$1 0,02\$1) = 0,01\$1
`Pod1-Total-split-cost = Pod1-Split-cost + Pod1-Unused-cost`
= 0,23\$1
****
| Pod name | Namespace | Split-cost | Unused-cost | Total-split-cost |
| --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 0,22\$1 | 0,01\$1 | 0,23\$1 |
| Pod2 | Namespace2 | 0,38\$1 | 0,02\$1 | 0,40\$1 |
| Pod3 | Namespace1 | 0,18\$1 | 0,01\$1 | 0,19\$1 |
| Pod4 | Namespace2 | 0,18\$1 | 0,01\$1 | 0,19\$1 |
| Unused | Unused | 0,04\$1 | | |
| | | 1\$1 | 0,04\$1 | 1\$1 |
Le coût du service est la somme du coût des pods associés à chaque espace de noms.
Coût total de Namespace1 = 0,23\$1 \$1 0,19\$1 = 0,42\$1
Coût total de Namespace2 = 0,40\$1 \$1 0,19\$1 = 0,59\$1
## Exemple de AWS CUR
Si vous avez un Savings Plans couvrant l'utilisation complète de l'instance EC2 au cours de la période de facturation, les coûts amortis sont calculés à l'aide de. savingsPlan/SavingsPlanEffectiveCost
![\[Table showing EC2 instance usage details with Savings Plans and cost breakdown.\]](http://docs.aws.amazon.com/fr_fr/cur/latest/userguide/images/savings-plan-entire-usage.png)
Si vous disposez d'un plan Savings couvrant l'utilisation partielle de l'instance EC2 au cours de la période de facturation et que le reste de l'utilisation de l'instance EC2 est facturé aux tarifs à la demande, les coûts amortis de l'instance EC2 sont calculés en utilisant savingsPlan/SavingsPlanEffectiveCost (pour SavingsPlanCoveredUsage) \$1 lineItem/UnblendedCost (pour une utilisation à la demande).
![\[Table showing EC2 instance usage details, costs, and savings plan information.\]](http://docs.aws.amazon.com/fr_fr/cur/latest/userguide/images/savings-plan-partial-usage.png)
# Exemple de données de répartition des coûts fractionnés pour les instances accélérées
L'objectif de l'exemple suivant est de vous montrer comment les données de répartition des coûts partagés sont calculées en calculant le coût de l'espace de noms et des pods Kubernetes dans les clusters Amazon EKS. Les taux utilisés dans cet exemple sont fournis à titre indicatif uniquement.
Vous pouvez utiliser les produits suivants en une heure :
+ Instance EC2 unique qui exécute quatre pods dans deux espaces de noms, et vous souhaitez comprendre les coûts de chaque espace de noms.
+ L'instance EC2 est une instance p3.16xlarge avec 8 GPU, 64 vCPU et 488 Go de RAM.
+ Le coût amorti de l'instance est de 10 \$1/heure.
Les données de répartition des coûts normalisent le coût par ressource sur la base d'un ratio relatif GPU : (cpu : mémoire) de 9:1. Cela implique qu'une unité de processeur graphique coûte 9 fois plus cher qu'une unité de processeur et de mémoire. Une pondération de 9:1. est ensuite attribuée au processeur et à la mémoire. Pour une instance EC2 non accélérée, le comportement par défaut actuel sera adopté, à savoir cpu : le poids de la mémoire par défaut est de 9:1.
## Étape 1 : Calculez le coût unitaire
Sur la base des ressources du processeur et de la mémoire de l'instance EC2 et en utilisant le ratio mentionné ci-dessus, les données de répartition des coûts calculent d'abord le coût unitaire par GPU, vCPU-hr et GB-h.
`GPU-Weight =9`
`GPU+Memory-Weight =1`
`CPU-Weight=1*.9=.9`
`Memory-Weight=1*0.1=0.1`
`Hourly-Instance-Cost=$10`
`GPU-Available=8`
`Memory-Available=488`
`CPU-Available=64`
`UnitCostPerResource = Hourly-Instance-Cost/(( GPU-Weight * GPU-Available) + (Memory-Weight * Memory-Available) + (CPU-Weight * CPU-Available)) = $10/((9*8gpu)+ (0.1 * 488GB) + (.9 * 64vcpu)) = $0.056`
`Cost-per-GPU-Hour = GPU-Weight * UnitCostPerResource = 9 * $0.056 = $0.504`
`Cost-per-vcpu-Hour = CPU-Weight * UnitCostPerResource = .9 * $0.056 = $0.05`
`Cost-per-GB-Hour = Memory-Weight * UnitCostPerResource = .1 * $0.056 = $0.00506`
**Tableau 1 : Calcul du coût unitaire**
| Instance | Type d'instance | vCPU disponible | GPU disponible | \$1\$1 | Mémoire disponible | Coût horaire amorti | Coût par heure de processeur virtuel | Coût par heure de processeur graphique | Coût par Go par heure |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Instance 1 | p3.16xlarge | 64 | 8 | | 488 | 10\$1 | 0,05 USD | 0,50\$1 | 0.005 |
## Étape 2 : Calculez la capacité allouée et inutilisée
Capacité allouée
Le GPU, le processeur virtuel et la mémoire alloués au pod Kubernetes par l'instance EC2 parente, définis comme la capacité maximale (réservée, utilisée)
Capacité inutilisée de l'instance
La capacité inutilisée du GPU, du processeur virtuel et de la mémoire
`Pod1-Allocated-GPU = Max (1 GPU, 1 GPU) = 1 GPU`
`Pod1-Allocated-vcpu = Max (16 vcpu, 4 vcpu) = 16 vcpu`
`Pod1-Allocated-Memory = Max (100 GB, 60 GB) = 100 GB`
`Instance-Unused-GPU = Max (GPU-Available - SUM(Allocated-vcpu), 0)`
`= Max (8 – 8, 0) = 0`
`Instance-Unused-vcpu = Max (CPU-Available - SUM(Allocated-vcpu), 0)`
`= Max (16 – 18, 0) = 0`
`Instance-Unused-Memory = Max (Memory-Available - SUM(Allocated-Memory), 0)`
`= Max (488 – 440, 0) = 48 GB`
Dans cet exemple, le processeur de l'instance est supérieur à l'abonnement, attribué au Pod 2 qui a utilisé plus de GPU et de vcpu que ce qui était réservé.
**Tableau 2 : Calcul de la capacité allouée et inutilisée**
| Nom du pod | Namespace | vcpu Réservé | vcpu utilisé | vcpu alloué | GPU réservé | GPU utilisé | GPU alloué | Mémoire réservée | Mémoire utilisée | Mémoire allouée |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Espace de noms 1 | 16 | 4 | 16 | 1 | 1 | 1 | 100 | 60 | 100 |
| Pod 2 | Espace de noms 2 | 16 | 18 | 18 | 2 | 3 | 3 | 100 | 140 | 140 |
| Pod 3 | Espace de noms 1 | 16 | 4 | 16 | 2 | 1 | 2 | 100 | 60 | 100 |
| Capsule 4 | Espace de noms 2 | 16 | 4 | 16 | 2 | 2 | 2 | 100 | 40 | 100 |
| Non utilisé | Non utilisé | 0 | 34 | 0 | 1 | 1 | 0 | 88 | 188 | 48 |
| \$1\$1\$1 | | 64 | 32 | 66 | 8 | 8 | 8 | 488 | 488 | 488 |
## Étape 3 : Calculez le partage de l'utilisation et des ratios d'utilisation
Taux d'utilisation fractionné
Pourcentage de processeur ou de mémoire utilisé par le pod Kubernetes par rapport à l'ensemble du processeur ou de la mémoire disponible sur l'instance EC2.
Ratio non utilisé
Le pourcentage de processeur ou de mémoire utilisé par le pod Kubernetes par rapport à l'ensemble du processeur ou de la mémoire utilisé sur l'instance EC2 (c'est-à-dire sans tenir compte du processeur ou de la mémoire inutilisés de l'instance).
Pourcentage de processeur ou de mémoire utilisé par le Kubernetes Pod par rapport à l'ensemble du processeur ou de la mémoire disponible sur l'instance EC2.
`Pod1-GPU-Utilization-Ratio = Allocated-GPU / Total-GPU`
`= 1 gpu / 8 gpu = 0.125`
`Pod1-vcpu-Utilization-Ratio = Allocated-vcpu / Total-vcpu`
`= 16 vcpu / 66 vcpu = 0.24`
`Pod1-Memory-Utilization-Ratio = Allocated-GB / Total-GB`
`= 100 GB/ 488GB = 0.205`
`Pod1-GPU-Split-Ratio = Pod1-GPU-Utilization-Ratio / (Total-GPU-Utilization-Ratio – Instance-Unused-GPU). Set to 0 if Instance-Unused-GPU = 0`
`= 0 since Instance-Unused-GPU is 0`
`Pod1-vcpu-Split-Ratio = Pod1-CPU-Utilization-Ratio / (Total-CPU-Utilization-Ratio – Instance-Unused-CPU). Set to 0 if Instance-Unused-CPU = 0`
`= 0 since Instance-Unused-CPU is 0`
`Pod1-Memory-Split-Ratio = Pod-Memory-Utilization-Ratio / (Total-Utilization-Ratio – Instance-Unused-Memory). Set to 0 if Instance-Unused-Memory = 0`
`= 0.204/ (1-0.102) = 0.227`
**Tableau 3 : Ratios d'utilisation du calcul**
| Nom du pod | Namespace | Utilisation du processeur virtuel | Rapport de division du processeur | Utilisation du GPU | Rapport de division du processeur graphique | Utilisation de la mémoire | Rapport de répartition de la mémoire |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Espace de noms 1 | 0,242 | 0 | 0.125 | 0 | 0,205 | 0.227 |
| Pod 2 | Espace de noms 2 | 0,277 | 0 | 0,375 | 0 | 0,287 | 0,318 |
| Pod 3 | Espace de noms 1 | 0,242 | 0 | 0.25 | 0 | 0,205 | 0.227 |
| Capsule 4 | Espace de noms 2 | 0,242 | 0 | 0.25 | 0 | 0,205 | 0.227 |
| Non utilisé | Non utilisé | 0 | | | | 0,098 | |
| | | 1 | 0 | 1 | 0 | 1 | 1 |
## Étape 4 : Calculez le coût partagé et les coûts non utilisés
Coût partagé
La répartition du coût par utilisation du coût de l'instance EC2 en fonction de l'utilisation du processeur et de la mémoire alloués par les pods Kubernetes
Coût d'instance non utilisé
Le coût des ressources de processeur ou de mémoire non utilisées sur l'instance
`Pod1-Split-Cost = (Pod1-GPU-Utilization-Ratio * GPU-Available * Cost per GPU-Hour) + (Pod1-vcpu-Utilization-Ratio * vcpu-Available * Cost per vcpu-Hour) + (Pod1-Memory-Utilization-Ratio * Memory-Available * Cost per GB-Hour)`
`= (.125*8gpu*$0.504) + (0.242 * 64 vcpu * $0.05) + (0.204 * 488GB * $0.00506) = 0.504+ 0.774 + 0.503 = $1.85`
`Pod1-Unused-Cost = (GPU-Split-Ratio * Unused-Cost) + (vcpu-Split-Ratio * Unused-Cost) + (Memory-Split-Ratio * Unused-Cost)`
`= (0*0*8*$0.504) + (0 * $0.05) + (0.227 *.102*488GB*$.00506) = $0.06`
`Pod1-Total-Split-Cost = Pod1-Split-Cost + Pod1-Unused-Cost = $1.85 + $0.06 = $1.91`
[Remarque : coût inutilisé = ratio d'utilité inutilisé \$1 ressource totale \$1 coût horaire de la ressource]
**Tableau 4 - Résumé des coûts divisés et non utilisés calculés chaque heure pour tous les pods fonctionnant au sein du cluster**
| Nom du pod | Namespace | Coût partagé | Coût non utilisé | Coût total |
| --- | --- | --- | --- | --- |
| Pod 1 | Espace de noms 1 | 1,85\$1 | 0,06 \$1 | 1,91\$1 |
| Pod 2 | Espace de noms 2 | 3,18\$1 | 0,09\$1 | 3,26\$1 |
| Pod 3 | Espace de noms 1 | 2,35\$1 | 0,06 \$1 | 2,41\$1 |
| Capsule 4 | Espace de noms 2 | 2,35\$1 | 0,06 \$1 | 2,41\$1 |
| Total | | | | 10\$1 |
# Utilisation d'étiquettes Kubernetes pour la répartition des coûts dans EKS
Les données de répartition des coûts fractionnés prennent en charge les étiquettes Kubernetes en tant que balises de répartition des coûts pour les clusters Amazon EKS. Bien que ces étiquettes soient automatiquement importées sous forme de balises de répartition des coûts définies par l'utilisateur, elles doivent être activées au niveau du compte de gestion. Une fois activés, vous pouvez les utiliser pour attribuer les coûts au niveau des modules dans vos rapports de coûts et d'utilisation (CUR) à l'aide d'attributs personnalisés tels que le centre de coûts, l'application, l'unité commerciale et l'environnement.
Cette fonctionnalité aide les organisations à suivre et à répartir avec précision les coûts dans les environnements EKS partagés entre les équipes, les projets ou les départements. À l'aide des étiquettes Kubernetes, vous pouvez répartir vos coûts Kubernetes en fonction de vos besoins commerciaux spécifiques et de la conception organisationnelle.
## Conditions préalables
Comme conditions préalables à l'utilisation d'étiquettes Kubernetes avec des données de répartition des coûts fractionnés :
+ Vous devez activer les données de répartition des coûts dans la console AWS Billing and Cost Management. Cela doit être activé au niveau du compte de gestion. Pour plus de détails, consultez la section [Activation des données de répartition des coûts fractionnés](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Vous avez besoin d'un cluster EKS pour lequel vous souhaitez suivre les données de répartition des coûts. Il peut s'agir d'un cluster existant ou vous pouvez en créer un nouveau. Pour plus d'informations, consultez la section [Création d'un cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) dans le *guide de l'utilisateur Amazon EKS*.
+ Des étiquettes doivent être attribuées à vos pods dans le cluster EKS. *Pour plus d'informations sur la création d'étiquettes dans Kubernetes, consultez la section [Étiquettes et sélecteurs](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) dans la documentation de Kubernetes.*
## Utilisation des étiquettes Kubernetes dans EKS
Les données de répartition des coûts fractionnés prennent en charge jusqu'à 50 étiquettes Kubernetes par pod, qui sont triées par ordre alphabétique avant d'être importées sous forme de balises de répartition des coûts. Toutes les étiquettes situées au-delà des 50 premières sont automatiquement supprimées. Si vous devez ajouter une nouvelle étiquette de répartition des coûts après avoir atteint la limite de 50 étiquettes, vous devez d'abord supprimer une étiquette existante et vous assurer que votre nouvelle étiquette se situe dans les 50 premières lorsqu'elle est triée par ordre alphabétique.
**Note**
Certains services AWS gérés ajoutent automatiquement des étiquettes aux modules EKS. Ces étiquettes sont prises en compte dans la limite de 50 étiquettes par dosette et apparaîtront sur votre page d'étiquettes de répartition des coûts.
Bien que les étiquettes Kubernetes ne soient soumises à aucune restriction de taille, les balises de répartition des coûts ont des limites de caractères spécifiques : 128 caractères pour les clés de balise et 256 caractères pour les valeurs des balises. Les étiquettes qui dépassent cette limite de caractères seront supprimées et ne seront pas présentées sous forme de balises de répartition des coûts. Il est recommandé de créer des libellés respectant ces limites de caractères à des fins de répartition des coûts.
Les étiquettes Kubernetes importées apparaissent sous forme de balises de répartition des coûts et doivent être activées au niveau du compte payeur. Pour plus d'informations sur les balises de répartition des coûts et l'activation, consultez la section [Utilisation des balises de répartition des coûts définies par](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) l'utilisateur. Les limites de balises de répartition des coûts suivantes s'appliquent : 50 balises définies par l'utilisateur par ressource et 500 balises définies par l'utilisateur par compte payeur. Les balises générées par le système ne sont pas prises en compte dans ces limites.
**Note**
Une fois que vous avez créé et appliqué des balises définies par l'utilisateur à vos ressources, l'affichage des clés de balise sur votre page de balises de répartition des coûts peut prendre jusqu'à 24 heures. Une fois que vous avez activé les tags, il faut parfois 24 heures supplémentaires pour qu'ils deviennent actifs.
## Gestion des étiquettes Kubernetes et des balises de répartition des coûts
Vous pouvez ajouter, supprimer et modifier des étiquettes Kubernetes dans EKS, ainsi que désactiver les balises de répartition des coûts associées. Ce qui suit décrit le comportement attendu pour chaque action.
**Ajouter une nouvelle étiquette**
Vous pouvez ajouter une nouvelle étiquette Kubernetes à un pod. Si la limite de 50 étiquettes n'est pas atteinte, la nouvelle étiquette sera importée et proposée sous forme d'étiquette de répartition des coûts, qui pourra ensuite être activée. Toutefois, si la limite de 50 est atteinte, la nouvelle étiquette ne sera pas importée même si elle se situe dans l'ordre alphabétique des 50 premières étiquettes. Vous devez d'abord désactiver une étiquette de répartition des coûts existante pour en importer une nouvelle.
**Modification d'une étiquette**
Kubernetes ne vous permet pas de modifier une clé d'étiquette. Pour modifier une clé d'étiquette, vous devez la supprimer et ajouter une nouvelle étiquette. Vous pouvez toutefois modifier les valeurs des étiquettes, qui seront reflétées dans votre prochain CUR.
**Supprimer une étiquette**
Vous pouvez retirer une étiquette des capsules EKS. Notez que la suppression d'une étiquette ne désactive pas automatiquement l'étiquette de répartition des coûts associée. Les données de répartition des coûts fractionnés continueront à être renseignées dans le CUR jusqu'à ce que vous désactiviez explicitement l'étiquette de répartition des coûts.
**Désactivation d'une balise de répartition des coûts**
Vous pouvez désactiver n'importe quelle balise de répartition des coûts créée à partir des étiquettes Kubernetes. Une fois désactivée, les données ne figureront plus dans les colonnes respectives et la colonne sera supprimée du CUR du mois suivant.
## Bonnes pratiques de gestion des étiquettes Kubernetes pour la répartition des coûts
Les étiquettes Kubernetes offrent une flexibilité significative dans la modélisation de la répartition des coûts partagés. Pour optimiser le potentiel de cette fonctionnalité, nous vous recommandons de suivre ces meilleures pratiques afin d'optimiser votre approche de gestion des coûts.
**Comprendre les limites des étiquettes**
La label-per-pod limite de 50 est basée sur le tri alphabétique. Seules les 50 premières étiquettes classées par ordre alphabétique seront importées pour la répartition des coûts. Pour vous assurer que les étiquettes essentielles sont incluses, planifiez soigneusement le nom de votre étiquette afin de vous assurer que les étiquettes importantes apparaissent dans les 50 premières lorsqu'elles sont triées par ordre alphabétique.
**Respect des contraintes de caractère**
AWS les balises de répartition des coûts ont les limites de caractères suivantes :
+ Clés de tag : 128 caractères
+ Valeurs des balises : 256 caractères
Bien que Kubernetes autorise les étiquettes plus longues, les étiquettes dépassant ces limites ne seront pas importées. Concevez vos étiquettes dans le respect de ces limites pour garantir un suivi efficace de la répartition des coûts.
**Ajouter de nouvelles étiquettes lorsque la capacité est atteinte**
Lorsqu'un module a atteint la limite de 50 étiquettes et que vous devez ajouter une nouvelle étiquette de répartition des coûts, procédez comme suit :
1. Passez en revue les étiquettes existantes et identifiez une étiquette de répartition des coûts à désactiver.
1. Désactivez le tag sélectionné.
1. Ajoutez le nouveau libellé de répartition des coûts.
1. Vérifiez que la nouvelle étiquette figure parmi les 50 premières étiquettes triées par ordre alphabétique.
**Note**
N'oubliez pas que seules les 50 premières étiquettes triées par ordre alphabétique sont utilisées pour la répartition des coûts.
# Utilisation des données de répartition des coûts avec Amazon Managed Service pour Prometheus
Pour diviser les données de coûts pour Amazon EKS, vous devez collecter et stocker les métriques de vos clusters, y compris l'utilisation de la mémoire et du processeur. Amazon Managed Service for Prometheus peut être utilisé à cette fin.
Une fois que vous avez choisi de fractionner les données de répartition des coûts et que votre espace de travail Amazon Managed Service for Prometheus commence à recevoir les deux mesures requises `container_cpu_usage_seconds_total` (`container_memory_working_set_bytes`et), les données de répartition des coûts fractionnées reconnaissent les mesures et les utilisent automatiquement.
**Note**
Les deux métriques requises (`container_cpu_usage_seconds_total`et`container_memory_working_set_bytes`) sont présentes dans la configuration par défaut de Prometheus Scrape et dans la configuration par défaut fournie avec un collecteur géré. AWS Toutefois, si vous personnalisez ces configurations, ne renommez pas, ne modifiez pas ou ne supprimez pas les libellés suivants `container_memory_working_set_bytes` des métriques `container_cpu_usage_seconds_total` et : `name``namespace`, et`pod`. Si vous réétiquetez, modifiez ou supprimez ces étiquettes, cela peut avoir un impact sur l'assimilation de vos indicateurs.
Vous pouvez utiliser Amazon Managed Service for Prometheus pour collecter des métriques EKS à partir d'un seul compte d'utilisation, dans une seule région. L'espace de travail Amazon Managed Service for Prometheus doit se trouver dans ce compte et dans cette région. Vous avez besoin d'une instance Amazon Managed Service for Prometheus pour chaque compte d'utilisation et chaque région pour lesquels vous souhaitez surveiller les coûts. Vous pouvez collecter des statistiques pour plusieurs clusters dans l'espace de travail Amazon Managed Service for Prometheus, à condition qu'ils appartiennent au même compte d'utilisation et à la même région.
Les sections suivantes décrivent comment envoyer les mesures correctes depuis votre cluster EKS vers l'espace de travail Amazon Managed Service for Prometheus.
## Conditions préalables
Comme condition préalable à l'utilisation d'Amazon Managed Service pour Prometheus avec des données de répartition des coûts partagés :
+ Vous devez activer les données de répartition des coûts dans la console AWS Billing and Cost Management. Pour plus de détails, consultez la section [Activation des données de répartition des coûts fractionnés](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html). L'option de fractionnement des données de répartition des coûts crée un rôle lié au service dans chaque compte d'utilisation pour interroger Amazon Managed Service for Prometheus pour obtenir les métriques du cluster Amazon EKS de ce compte. Pour plus d'informations, consultez la section [Rôles liés aux services pour les données de répartition des coûts fractionnés](https://docs.aws.amazon.com/cost-management/latest/userguide/split-cost-allocation-data-SLR.html).
+ Vous avez besoin d'un cluster EKS pour lequel vous souhaitez suivre les données de répartition des coûts. Il peut s'agir d'un cluster existant ou vous pouvez en créer un nouveau. Pour plus d'informations, consultez la section [Création d'un cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) dans le *guide de l'utilisateur Amazon EKS*.
**Note**
Vous aurez besoin du `EKS cluster ARN``security group IDs`, et d'au moins deux `subnet IDs` (dans des zones de disponibilité différentes) pour les utiliser ultérieurement.
(facultatif) Définissez le mode d'authentification de votre cluster EKS sur `API` ou`API_AND_CONFIG_MAP`.
+ Vous avez besoin d'une instance Amazon Managed Service for Prometheus associée au même compte et à la même région que votre cluster EKS. Si vous n'en avez pas déjà un, vous pouvez en créer un. Pour plus d'informations sur la création d'une instance Amazon Managed Service for Prometheus, [consultez la section Créer un espace de travail dans le guide de l'utilisateur d'](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html)*Amazon Managed Service for Prometheus*.
**Note**
Vous en aurez besoin `Amazon Managed Service for Prometheus workspace ARN` pour les utiliser dans les étapes ultérieures.
## Transmission des métriques EKS vers Amazon Managed Service pour Prometheus
Une fois que vous disposez d'un cluster EKS et d'une instance Amazon Managed Service for Prometheus, vous pouvez transférer les métriques du cluster vers l'instance. Vous pouvez envoyer des métriques de deux manières.
+ [Option 1 : utilisez un collecteur AWS géré.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#use-managed-collector) Il s'agit de la méthode la plus simple pour envoyer des métriques depuis un cluster EKS vers Amazon Managed Service for Prometheus. Cependant, il est limité à ne récupérer les métriques que toutes les 30 secondes au maximum.
+ [Option 2 : créez votre propre agent Prometheus.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent) Dans ce cas, vous avez davantage de contrôle sur la configuration du scraping, mais vous devez gérer l'agent après l'avoir créé.
### Option 1 : utilisation d'un collecteur AWS géré
L'utilisation d'un collecteur AWS géré (un *scraper*) est le moyen le plus simple d'envoyer des métriques d'un cluster EKS vers une instance Amazon Managed Service for Prometheus. La procédure suivante vous explique comment créer un collecteur AWS géré. Pour plus d'informations, consultez la section « [Collecteurs AWS gérés](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) » dans le guide de l'utilisateur d'*Amazon Managed Service for Prometheus*.
**Note**
AWS les collecteurs gérés ont un intervalle de récupération minimum de 30 secondes. Si vous avez des capsules à courte durée de vie, il est recommandé de régler l'intervalle entre votre grattoir à 15 secondes. Pour utiliser un intervalle de 15 secondes, utilisez l'option 2 pour [créer votre propre agent Prometheus](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent).
La création d'un collecteur AWS géré se fait en trois étapes :
1. Créez une configuration de grattoir.
1. Créez le grattoir.
1. Configurez votre cluster EKS pour permettre au scraper d'accéder aux métriques.
*Étape 1 : Création d'une configuration de scraper*
Pour créer un grattoir, vous devez disposer d'une configuration de grattoir. Vous pouvez utiliser une configuration par défaut ou créer la vôtre. Voici trois méthodes pour obtenir une configuration de scraper :
+ Obtenez la configuration par défaut à l'aide de la AWS CLI, en appelant :
```
aws amp get-default-scraper-configuration
```
+ Créez votre propre configuration. Pour plus de détails, consultez les instructions de [configuration de Scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) dans le guide de l'*utilisateur d'Amazon Managed Service for Prometheus*.
+ Copiez l'exemple de configuration fourni dans les mêmes instructions de [configuration de Scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) dans le guide de l'*utilisateur d'Amazon Managed Service for Prometheus*.
Vous pouvez modifier la configuration du scraper, pour modifier l'intervalle de scrape ou pour filtrer les métriques qui sont scrapées, par exemple.
Pour filtrer les indicateurs extraits afin d'inclure uniquement les deux nécessaires pour les données de répartition des coûts partagés, utilisez la configuration de scraper suivante :
```
global:
scrape_interval: 30s
#external_labels:
#clusterArn:
scrape_configs:
- job_name: kubernetes-nodes-cadvisor
scrape_interval: 30s
scrape_timeout: 10s
scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- regex: (.+)
replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor
source_labels:
- __meta_kubernetes_node_name
target_label: __metrics_path__
- replacement: kubernetes.default.svc:443
target_label: __address__
metric_relabel_configs:
- source_labels: [__name__]
regex: 'container_cpu_usage_seconds_total|container_memory_working_set_bytes'
action: keep
```
*Une fois que vous avez la configuration du scraper, vous devez l'encoder en base64 pour l'utiliser à l'étape 2.* La configuration est un fichier texte YAML. Pour encoder le fichier, utilisez un site Web tel que [https://www.base64encode.org/](https://www.base64encode.org/).
*Étape 2 : Création du grattoir*
Maintenant que vous disposez d'un fichier de configuration, vous devez créer votre scraper. Créez un scraper à l'aide de la commande AWS CLI suivante, en fonction des variables décrites dans la section des prérequis. Vous devez utiliser les informations de votre cluster EKS pour les ** champs**, et**, les remplacer par ** la configuration scraper que vous avez créée à l'étape précédente et les remplacer par l'ARN de votre ** espace de travail Amazon Managed Service for Prometheus.
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn=,securityGroupIds=[],subnetIds=[]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration={workspaceArn=""}
```
Notez le `scraperId` qui est renvoyé pour utilisation à l'*étape 3*.
*Étape 3 : configurer votre cluster EKS pour permettre au scraper d'accéder aux métriques*
Si le mode d'authentification de votre cluster EKS est défini sur l'`API`un ou l'autre`API_AND_CONFIG_MAP`, votre scraper disposera automatiquement de la bonne politique d'accès interne au cluster et les scrapers auront accès à votre cluster. Aucune autre configuration n'est requise et les métriques devraient être transmises à Amazon Managed Service for Prometheus.
Si le mode d'authentification de votre cluster EKS n'est pas défini sur `API` ou`API_AND_CONFIG_MAP`, vous devrez configurer manuellement le cluster pour permettre au scraper d'accéder à vos métriques via un ClusterRole et ClusterRoleBinding. Pour savoir comment activer ces autorisations, consultez la section [Configuration manuelle d'un cluster EKS pour l'accès au scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) dans le guide de l'utilisateur d'*Amazon Managed Service for Prometheus*.
Une fois que le scraper est actif, vérifiez que les deux métriques (`container_cpu_usage_seconds_total`et`container_memory_working_set_bytes`) sont transmises à votre espace de travail Amazon Managed Service for Prometheus.
```
awscurl --service="aps" --region="" "https://aps-workspaces..amazonaws.com/workspaces//api/v1/label/__name__/values"
```
Sortie :
```
{
"status": "success",
"data": [
"container_cpu_usage_seconds_total",
"container_memory_working_set_bytes",
"scrape_duration_seconds",
"scrape_samples_post_metric_relabeling",
"scrape_samples_scraped",
"scrape_series_added",
"up"
]
}
```
### Option 2 : créer votre propre agent Prometheus
Si vous ne pouvez pas utiliser le collecteur AWS géré ou si vous possédez déjà votre propre serveur Prometheus, vous pouvez utiliser votre propre instance Prometheus comme agent pour extraire les métriques de votre cluster EKS et les envoyer à Amazon Managed Service for Prometheus.
Pour obtenir des instructions détaillées sur l'utilisation de votre propre instance Prometheus en tant qu'agent, consultez la section [Utilisation d'une instance Prometheus en tant que collecteur dans le guide de l'utilisateur d'*Amazon* Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-ingest-with-prometheus.html).
Voici un exemple de configuration de Prometheus Scrape qui inclut l'intervalle de scrape du serveur Prometheus et les métriques de conteneur requises pour les données de répartition des coûts partagés. Si vous avez des pods de courte durée, il est recommandé de réduire l'intervalle de capture par défaut du serveur Prometheus de 30 secondes à 15 secondes. Notez que cela peut entraîner une utilisation élevée de la mémoire du serveur Prometheus.
```
global:
scrape_interval: 30s
#external_labels:
#clusterArn:
scrape_configs:
- job_name: kubernetes-nodes-cadvisor
scrape_interval: 30s
scrape_timeout: 10s
scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- regex: (.+)
replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor
source_labels:
- __meta_kubernetes_node_name
target_label: __metrics_path__
- replacement: kubernetes.default.svc:443
target_label: __address__
metric_relabel_configs:
- source_labels: [__name__]
regex: 'container_cpu_usage_seconds_total|container_memory_working_set_bytes'
action: keep
```
Si vous avez suivi la [section Configurer l'ingestion depuis un nouveau serveur Prometheus à l'aide](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-metrics-new-Prometheus.html) de Helm dans le guide de l'*utilisateur d'Amazon Managed Service for Prometheus, vous pouvez mettre à jour* votre configuration de scrape.
**Pour mettre à jour la configuration de votre scrape**
1. Modifiez `my_prometheus_values_yaml` à partir du guide et incluez l'exemple de configuration de scrape dans le `server` bloc.
1. Exécutez la commande suivante en utilisant `prometheus-chart-name` et `prometheus-namespace` depuis le guide de l'*utilisateur d'Amazon Managed Service for Prometheus*.
```
helm upgrade prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace -f my_prometheus_values_yaml
```
[Pour en savoir plus sur `scrape_interval` ou comment utiliser un scrape\$1interval non global, reportez-vous à la configuration de Prometheus scrape.](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)
Vous pouvez également utiliser le AWS Distro for OpenTelemetry Collector doté d'un récepteur Prometheus, d'un exportateur d'écriture à distance Prometheus et de l'extension d'authentification Sigv4 pour accéder en écriture à distance à AWS Amazon Managed Service for Prometheus.
**Note**
Une fois que vous avez configuré votre agent Prometheus, AWS contrairement aux agents gérés, vous êtes chargé de le tenir à jour et de le faire fonctionner pour collecter des statistiques.
## Estimation des coûts de votre service géré Amazon pour Prometheus
Vous pouvez utiliser le calculateur de AWS prix pour estimer le coût d'utilisation d'Amazon Managed Service for Prometheus pour les données de répartition des coûts partagés.
**Pour configurer Amazon Managed Service pour Prometheus pour votre estimation**
1. Ouvrez le calculateur de AWS prix sur [https://calculator.aws/\$1/](https://calculator.aws/#/).
1. Choisissez **Create estimate (Créer une estimation)**.
1. **Sur la page **Ajouter un service**, saisissez **Amazon Managed Service for Prometheus** dans le champ de recherche, puis choisissez Configurer.**
1. Dans le champ **Description**, entrez une description pour votre estimation.
1. Choisissez une **Region**.
1. Sélectionnez **Calculer le coût à l'aide des détails de votre infrastructure**. Cette option vous permet d'estimer les coûts liés à l'ingestion, au stockage et aux échantillons de requêtes en fonction de la configuration de votre infrastructure actuelle ou proposée.
1. Pour **Nombre d'instances EC2**, entrez le nombre total d'instances EC2 dans tous vos clusters pour l'ensemble de votre famille de facturation consolidée (y compris tous les comptes et régions). Si vous utilisez AWS Fargate, utilisez le nombre de tâches Fargate comme proxy pour le nombre d'instances EC2.
1. Les données de répartition des coûts fractionnées nécessitent deux mesures : `container_cpu_usage_seconds_total` et`container_memory_working_set_bytes`. Pour les **métriques Prometheus par instance EC2, entrez 2.**
1. Les données de répartition des coûts divisés suggèrent un intervalle de récupération de 15 secondes. Pour **Intervalle de collecte métrique (en secondes)**, entrez 15. Si vous avez utilisé un intervalle différent (par exemple, 30 secondes), remplacez-le par l'intervalle que vous avez défini.
1. Les données de répartition des coûts fractionnés n'imposent aucune exigence spécifique pour les autres paramètres. Entrez donc des valeurs appropriées pour le reste des paramètres d'entrée conformément aux besoins de votre entreprise.
1. Choisissez **Enregistrer et ajouter un service**.
# Utilisation des données de répartition des coûts fractionnés avec Amazon CloudWatch Container Insights
Pour diviser les données de coûts pour Amazon EKS, vous devez collecter et stocker les métriques de vos clusters, y compris l'utilisation de la mémoire et du processeur. Amazon CloudWatch Container Insights peut être utilisé à cette fin.
Une fois que vous avez choisi de fractionner les données de répartition des coûts et que vous avez configuré l' CloudWatch agent avec le module complémentaire d'observabilité EKS sur votre cluster EKS, les données de répartition des coûts partagées commencent à recevoir les deux métriques requises `pod_memory_working_set` (`(pod_cpu_usage_total`et) dans l'`ContainerInsights`espace de noms et les utilisent automatiquement. Pour consulter l'ensemble complet des métriques de conteneur pour EKS, consultez les métriques [Amazon EKS et Kubernetes Container Insights dans le guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) de l'utilisateur *Amazon CloudWatch *.
Les sections suivantes décrivent comment envoyer les mesures correctes depuis votre cluster EKS pour fractionner les données de répartition des coûts.
## Conditions préalables
Comme condition préalable à l'utilisation d'Amazon CloudWatch Container Insights avec des données de répartition des coûts partagés :
+ Vous devez activer les données de répartition des coûts dans la console AWS Billing and Cost Management. Pour plus de détails, consultez la section [Activation des données de répartition des coûts fractionnés](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Vous avez besoin d'un cluster EKS pour lequel vous souhaitez suivre les données de répartition des coûts. Il peut s'agir d'un cluster existant ou vous pouvez en créer un nouveau. Pour plus d'informations, consultez la section [Création d'un cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) dans le *guide de l'utilisateur Amazon EKS*.
## Configuration d'Amazon CloudWatch Container Insights pour transmettre les métriques EKS
Vous devez installer et configurer l' CloudWatch agent afin de transférer les métriques EKS. Vous pouvez utiliser le [module complémentaire Amazon CloudWatch Observability EKS ou le graphique Amazon CloudWatch Observability Helm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) pour installer l' CloudWatch agent et l'agent Fluent-bit sur un cluster EKS. Pour plus d'informations sur l'installation et la configuration de l' CloudWatch agent, consultez la section [Installer le module complémentaire Amazon CloudWatch Observability EKS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html) dans le *guide de l' CloudWatch utilisateur Amazon*.
Les versions minimales requises pour l' CloudWatch agent et le module complémentaire EKS sont les suivantes :
+ CloudWatch version de l'agent : v1.300045.0
+ CloudWatch Version du module complémentaire Observability EKS : v2.0.1-eksbuild.1
## Estimation de vos CloudWatch coûts Amazon
L'activation de la fonctionnalité d'utilisation d'Amazon CloudWatch Container Insights avec des données de répartition des coûts fractionnés ajoute deux nouvelles mesures à Amazon CloudWatch Container Insights : `pod_cpu_usage_total` et`pod_memory_working_set`. Pour plus de détails sur ces métriques, consultez les métriques [Amazon EKS et Kubernetes Container Insights dans le guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) de l'utilisateur *Amazon CloudWatch *.
**Pour comprendre les coûts associés à la fonctionnalité**
1. Ouvrez Amazon CloudWatch Pricing at [https://aws.amazon.com/cloudwatch/pricing/](https://aws.amazon.com/cloudwatch/pricing/).
1. Accédez à la section **Niveau payant**.
1. Choisissez l'onglet **Container Insights**.
1. Pour un calcul détaillé des coûts, accédez à la section **Exemples de tarification** et reportez-vous à l'**Exemple 13 - Container Insights pour Amazon EKS et Kubernetes**.