Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Grundlegendes zu Kostenaufteilungszuweisungsdaten
Sie können Kosten- und Nutzungsberichte (AWS CUR) verwenden, um Ihre Amazon ECS- und Amazon EKS-Containerkosten zu verfolgen. Mithilfe von Daten zur geteilten Kostenzuweisung können Sie Ihre Containerkosten einzelnen Geschäftseinheiten und Teams zuordnen, je nachdem, wie Ihre Container-Workloads gemeinsam genutzte Rechen- und Speicherressourcen verbrauchen. Daten zur geteilten Kostenzuweisung führen Kosten- und Nutzungsdaten für neue Ressourcen auf Containerebene (d. h. ECS-Aufgaben und Kubernetes-Pods) in CUR ein. AWS Bisher unterstützte AWS CUR nur Kosten auf EC2-Instanzebene. Daten zur geteilten Kostenzuweisung generieren Kosten auf Containerebene, indem sie den Ressourcenverbrauch der EC2-Instances jedes Containers betrachten. Außerdem werden Kosten generiert, die auf den amortisierten Kosten der Instance und dem Prozentsatz der CPU- und Speicherressourcen basieren, die von den Containern verbraucht werden, die auf der Instance ausgeführt wurden.
Bei beschleunigten Recheninstanzen, die mit Amazon EKS verwendet werden, umfassen die Daten zur geteilten Kostenzuweisung neben CPU und Arbeitsspeicher auch die Ressourcenzuweisung für spezialisierte Prozessoren. Dies gilt für NVIDIA- und AMD- GPUs, AWS Trainium- und AWS Inferentia-Beschleuniger. Die Funktion ist nur für Amazon EKS-Umgebungen verfügbar und stellt Ressourcenreservierungsdaten auf Pod-Ebene für diese beschleunigten Rechenressourcen bereit. Auf diese Weise können Sie die Kosten für Workloads verfolgen und zuordnen, die diese speziellen Prozessoren verwenden, z. B. für KI/ML-Anwendungen und andere rechenintensive Aufgaben. [Eine aktuelle Liste der beschleunigten Recheninstanzen finden Sie unter Accelerated Computing.](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
Daten zur geteilten Kostenzuweisung führen neue Nutzungsdatensätze und neue Spalten für Kostenmetriken für jede containerisierte Ressourcen-ID (d. h. ECS-Task und Kubernetes-Pod) in CUR ein. AWS [Weitere Informationen finden Sie unter Details zu Einzelposten aufteilen.](https://docs.aws.amazon.com/cur/latest/userguide/split-line-item-columns.html)
Wenn Daten zur geteilten Kostenzuweisung in AWS CUR aufgenommen werden, werden zwei neue Nutzungsdatensätze für jede ECS-Aufgabe und jeden Kubernetes-Pod pro Stunde hinzugefügt, um die CPU- und Speicherkosten widerzuspiegeln. Verwenden Sie die folgende Formel, um die Anzahl neuer Zeilenposten in AWS CUR pro Tag zu schätzen:
Für ECS: `(number of tasks * average task lifetime * 2) * 24`
Für EKS: `(number of pods * average pod lifetime * 2) * 24`
Wenn Sie beispielsweise 1.000 Pods pro Stunde in einem Cluster von 10 EC2-Instances ausführen und die Lebensdauer des Pods weniger als 1 Stunde beträgt, dann gilt Folgendes:
`(1000 * 1 * 2) * 24 = 48,000 new usage records in AWS CUR`
Für beschleunigte Recheninstanzen in Amazon EKS werden drei neue Nutzungsdatensätze für jeden Kubernetes-Pod pro Stunde hinzugefügt, um die Accelerator-, CPU- und Speicherkosten widerzuspiegeln. Verwenden Sie die folgende Formel, um die Anzahl neuer Zeilenposten in AWS CUR pro Tag zu schätzen:
Für EKS mit beschleunigter Datenverarbeitung: `(number of pods * average pod lifetime * 3) * 24`
Wenn Sie beispielsweise 1.000 Pods pro Stunde in einem Cluster von 10 EC2-Instances ausführen und die Lebensdauer für jeden Pod weniger als eine Stunde beträgt, dann gilt Folgendes: `(1000 * 1 * 3) * 24 = 72,000 new usage records in AWS CUR`
**Anmerkung**
Für ECS: Wenn es um AWS Kostenzuordnungs-Tags geht, können Sie von Amazon ECS verwaltete Tags oder von Benutzern hinzugefügte Tags für Ihre Kosten- und Nutzungsberichte verwenden. Diese Tags gelten für alle neuen ECS-Datenverwendungsdatensätze zur geteilten Kostenverrechnung. Weitere Informationen finden Sie unter [Kennzeichnen Ihrer ECS-Ressourcen für die Abrechnung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html#tag-resources-for-billing).
Für EKS: Geteilte Kostenzuordnungsdaten erstellen neue Kostenzuordnungs-Tags für einige Kubernetes-Attribute. Zu diesen Tags gehören`aws:eks:cluster-name`,`aws:eks:deployment`,`aws:eks:namespace`, `aws:eks:node``aws:eks:workload-name`, und. `aws:eks:workload-type`
`aws:eks:cluster-name``aws:eks:namespace`, und `aws:eks:node` werden rückwirkend mit dem Namen des Clusters, Namespace und Knotens gefüllt.
`aws:eks:workload-type`wird nur aufgefüllt, wenn es genau einen Workload gibt, der den Pod verwaltet, und es handelt sich dabei um einen der integrierten Workloads. Zu den Workload-Typen gehören `ReplicaSet` `StatefulSet``Job`,,`DaemonSet`, oder`ReplicationController`, und sie `aws:eks:workload-name` enthalten den Namen des Workloads. Weitere Informationen finden Sie unter [Workloads](https://kubernetes.io/docs/concepts/workloads/) in der *Kubernetes-Dokumentation*.
`aws:eks:deployment`wird nur für den Workload-Typ aufgefüllt. `ReplicaSet` Es ist die Bereitstellung, die eine erstellt`ReplicaSet`.
Diese Tags gelten für alle neuen Datenverwendungsdatensätze zur Aufteilung der EKS-Kostenzuweisung. Diese Tags sind standardmäßig für die Kostenzuweisung aktiviert. Wenn Sie das `aws:eks:cluster-name` Tag zuvor verwendet und deaktiviert haben, wird bei geteilten Kostenzuordnungsdaten diese Einstellung beibehalten und das Tag nicht aktiviert. Sie können es auf der Konsolenseite mit den [Tags für die Kostenzuweisung](https://console.aws.amazon.com/billing/home#/tags) aktivieren.
# Daten zur geteilten Kostenzuweisung aktivieren
**Anmerkung**
Daten zur geteilten Kostenzuweisung sind im Cost Explorer nicht verfügbar. Sie sind in älteren Kosten- und Nutzungsberichten (CUR) und Kosten- und Nutzungsberichten 2.0 (CUR 2.0) mit Datenexporten verfügbar.
Es ist eine Voraussetzung, dass Sie sich in den Einstellungen für das Kostenmanagement für die Aufteilung der Kostenzuordnungsdaten entscheiden.
**Um sich für die Aufteilung der Kostenzuweisungsdaten zu entscheiden**
1. Öffnen Sie die Fakturierungs- und Kostenverwaltungskonsole unter [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Wählen Sie im Navigationsbereich die Option **Kostenmanagement-Einstellungen** aus.
1. Wählen Sie unter **Allgemein** im Bereich **Geteilte Kostenzuordnungsdaten** eine der folgenden Optionen aus:
+ **Amazon Elastic Container Service (Amazon ECS)**, um sich nur für Amazon ECS anzumelden.
+ **Amazon Elastic Kubernetes Service (Amazon EKS)**, um sich nur für Amazon EKS anzumelden. Wählen Sie für Amazon EKS zwischen den folgenden Optionen:
+ **Ressourcenanfragen**: Dadurch werden Ihrem Amazon EC2 nach Kubernetes-Pod nur CPU- und Speicherressourcen zugewiesen. Dadurch werden Anwendungsteams ermutigt, nur das bereitzustellen, was sie benötigen.
+ **Amazon Managed Service für Prometheus**: Dadurch werden Ihre Amazon EC2 EC2-Kosten entsprechend der Anzahl der CPU- und Speicherressourcenanforderungen des Kubernetes-Pods und der tatsächlichen Auslastung aufgeteilt. Dadurch wird sichergestellt, dass jedes Anwendungsteam für das bezahlt, was es nutzt. Weitere Informationen zur Einrichtung von Amazon Managed Service für Prometheus finden Sie unter [Einrichtung](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-setting-up.html) im *Amazon Managed Service for Prometheus* Benutzerhandbuch.
Voraussetzung: Sie müssen alle Funktionen in aktivieren. AWS Organizations Weitere Informationen finden Sie unter [Aktivieren aller Funktionen in Ihrer Organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) im *Benutzerhandbuch für Organizations*.
+ **Amazon CloudWatch Container Insights**: Dies bietet eine detailliertere Kostentransparenz für Ihre Cluster, die mehrere Anwendungscontainer mit gemeinsam genutzten EC2-Instances ausführen, und ermöglicht so eine bessere Kostenzuweisung für die gemeinsamen Kosten Ihrer EKS-Cluster.
**Anmerkung**
Nur reguläre Konten und Zahlerkonten haben Zugriff auf die AWS Cost Management Einstellungen und können sich für die Aufteilung der Kostenzuweisungsdaten entscheiden. Nach der Anmeldung können Mitgliedskonten die Daten in den Kosten- und Nutzungsberichten einsehen.
Wenn Sie sich für Ressourcenanfragen entscheiden, werden nur die mit Speicher- und CPU-Anforderungen konfigurierten Pods für die geteilte Kostenzuweisung verwendet. Für Pods, die keine Nutzung angefordert haben, werden keine Daten zur Aufteilung der Kosten angezeigt.
Wenn Sie sich für Amazon Managed Service for Prometheus entscheiden, müssen Sie alle Funktionen in AWS Organizations aktivieren. Weitere Informationen finden Sie unter [Alle Funktionen in Ihrer Organisation aktivieren](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html). Darüber hinaus wird mit Daten zur geteilten Kostenverrechnung eine neue dienstbezogene Rolle erstellt, die den Zugriff auf AWS Dienste und Ressourcen ermöglicht, die von Daten zur geteilten Kostenverrechnung genutzt oder verwaltet werden.
Für beschleunigte Recheninstanzen wird nur die Option Ressourcenanforderung unterstützt. Weder Amazon Managed Service for Prometheus noch Amazon CloudWatch Container Insights werden für diese Instances unterstützt. Wenn beschleunigte Recheninstanzen verwendet werden, verwendet das System standardmäßig die Ressourcenanforderung, um die Beschleuniger-, CPU- und Speicherkosten zu berechnen, auch wenn andere Messoptionen aktiviert sind.
Sobald Sie sich angemeldet haben, können Sie wählen, ob Kosten- und Nutzungsdaten für Ressourcen auf Containerebene in Ihren Bericht aufgenommen werden sollen, entweder im ersten Schritt der Berichtserstellung oder zu einem späteren Zeitpunkt, indem Sie die Berichtsdetails bearbeiten.
**Um Kosten- und Nutzungsdaten in Ihren Bericht aufzunehmen**
1. Öffnen Sie die Fakturierungs- und Kostenverwaltungskonsole unter [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Wählen Sie im Navigationsbereich unter **Ältere Seiten** die Option **Kosten- und Nutzungsberichte** aus.
1. Unabhängig davon, ob Sie einen neuen Bericht erstellen oder einen vorhandenen Bericht bearbeiten, wählen Sie auf der Seite **Berichtsdetails angeben** unter **Berichtsinhalt** die Option **Kostenverteilungsdaten aufteilen** aus.
**Anmerkung**
Sie können auch die AWS CUR-API oder die AWS Command Line Interface (CLI) verwenden, um Ihre Dateneinstellungen für die Aufteilung der Kosten zu verwalten.
Geteilte Kostenzuordnungsdaten ermöglichen Kostentransparenz für alle Amazon ECS- und Amazon EKS-Containerobjekte in Ihrer gesamten konsolidierten Fakturierungsfamilie (Zahler und verknüpfte Konten). Nach der Aktivierung suchen die Daten zur geteilten Kostenzuweisung automatisch nach Aufgaben und Containern. Es nimmt die Telemetriedaten für Ihre Container-Workloads auf und bereitet die detaillierten Kostendaten für den aktuellen Monat auf.
**Anmerkung**
Es kann bis zu 24 Stunden dauern, bis die Daten in CUR sichtbar sind. AWS
Informationen zur Verwaltung des Zugriffs auf die Konsolenseiten für Billing and Cost Management finden Sie unter [Überblick über die Verwaltung von Zugriffsberechtigungen](https://docs.aws.amazon.com/cost-management/latest/userguide/control-access-billing.html).
Informationen zu AWS Cost Management Einstellungen und zur Steuerung des Zugriffs auf den Cost Explorer finden Sie unter [Steuern des Zugriffs auf den Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html).
# Beispiel für Daten zur Aufteilung der Kosten
Das folgende Beispiel soll Ihnen zeigen, wie Daten zur geteilten Kostenzuweisung berechnet werden, indem die Kosten einzelner Amazon ECS-Services, Aufgaben in Amazon ECS-Clustern sowie Kubernetes-Namespace und Pods in Amazon EKS-Clustern berechnet werden. Die im gesamten Beispiel verwendeten Tarife dienen nur zur Veranschaulichung.
**Anmerkung**
Das Beispiel zeigt den Kubernetes-Namespace und die Pods, die in Amazon EKS-Clustern ausgeführt werden. Wir können dann dasselbe Kostenmodell auf Amazon ECS-Services und Aufgaben anwenden, die in einem Amazon ECS-Cluster ausgeführt werden.
Sie haben in einer einzigen Stunde die folgende Nutzung:
+ Gemeinsamer Cluster mit einer einzigen Instanz (m5.xlarge) mit zwei Namespaces und vier Pods, der für die Dauer einer vollen Stunde läuft.
+ Die Instanzkonfiguration umfasst 4 vCPUs und 16 GB Arbeitsspeicher.
+ Die amortisierten Kosten der Instanz belaufen sich auf 1 USD/Stunde.
Bei den Daten zur geteilten Kostenzuweisung werden relative Gewichte pro Einheit für CPU und Arbeitsspeicher verwendet, die auf einem Verhältnis von 9:1 basieren. Dies ergibt sich aus den Preisen pro vCPU pro Stunde und pro GB pro Stunde in [AWS Fargate](https://aws.amazon.com/fargate/pricing/).
## Schritt 1: Berechnen Sie die Kosten pro Einheit für CPU und Arbeitsspeicher
`Unit-cost-per-resource = Hourly-instance-cost/((Memory-weight * Memory-available) + (CPU-weight * CPU-available))`
= 1 \$1/ ((1 \$1 16 GB) \$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 |
## Schritt 2: Berechnen Sie die zugewiesene Kapazität und die ungenutzte Kapazität der Instanz
+ Zugewiesene Kapazität: Der Arbeitsspeicher und die vCPU, die dem Kubernetes-Pod von der übergeordneten EC2-Instance zugewiesen wurden, definiert als das Maximum an genutzter und reservierter Kapazität.
**Anmerkung**
Wenn Speicher- oder vCPU-Nutzungsdaten nicht verfügbar sind, werden stattdessen Reservierungsdaten verwendet. Weitere Informationen finden Sie unter [Amazon ECS-Nutzungsberichte](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/usage-reports.html) oder [Amazon EKS-Kostenüberwachung](https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring.html).
+ Ungenutzte Kapazität der Instanz: Die ungenutzte Kapazität von vCPU und Arbeitsspeicher.
`Pod1-Allocated-vCPU = Max (1 vCPU, 0.1 vCPU)`= 1 vCPU
`Pod1-Allocated-memory = Max (4 GB, 3 GB)`= 4 GB
`Instance-Unused-vCPU = Max (CPU-available - SUM(Allocated-vCPU), 0)`= Maximal (4 — 4,9, 0) = 0
`Instance-Unused-memory = Max (Memory-available - SUM(Allocated-memory), 0)`= Max (16 — 14, 0) = 2 GB
In diesem Beispiel hat die Instanz CPU-Over-Abonnement, was Pod2 zugeschrieben wird, das mehr vCPU verwendet hat als reserviert war.
****
| 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 bis 4,9 | | | 16 |
## Schritt 3: Berechnen Sie die Aufteilung der Nutzungsquoten
+ Aufgeteiltes Nutzungsverhältnis: Der Prozentsatz der vom Kubernetes-Pod genutzten CPU oder des Speichers im Vergleich zur gesamten auf der EC2-Instance verfügbaren CPU oder Arbeitsspeicher.
+ Verhältnis ungenutzter Speicher: Der Prozentsatz der vom Kubernetes-Pod genutzten CPU oder des Speichers im Vergleich zur gesamten CPU- oder Speicherbelegung auf der EC2-Instance (d. h. ohne Berücksichtigung der ungenutzten CPU oder des ungenutzten Speichers auf der 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 GB/16 GB = 0,250
`Pod1-vCPU-unused-ratio = Pod1-vCPU-split-usage-ratio / (Total-CPU-split-usage-ratio – Instance-unused-CPU)`(auf 0 gesetzt, wenn Instance-unused-CPU 0 ist)
= 0 (seit Instance-unused-CPU ist 0)
`Pod1-Memory-unused-ratio = Pod1-Memory-split-usage-ratio / (Total-Memory-split-usage-ratio – Instance-unused-memory)`(auf 0 gesetzt, wenn 0 Instance-unused-memory ist)
= 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 | |
## Schritt 4: Berechne die geteilten Kosten und die ungenutzten Kosten
+ Geteilte Kosten: Die Aufteilung der Kosten pro Nutzung der EC2-Instance-Kosten auf der Grundlage der zugewiesenen CPU- und Speichernutzung durch den Kubernetes-Pod.
+ Kosten für ungenutzte Instances: Die Kosten für ungenutzte CPU- oder Speicherressourcen auf der 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 GB \$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 |
Die Kosten des Dienstes sind die Summe der Kosten für Pods, die jedem Namespace zugeordnet sind.
Gesamtkosten für Namespace1 = 0,23\$1 \$1 0,19\$1 = 0,42\$1
Gesamtkosten von Namespace2 = 0,40\$1 \$1 0,19\$1 = 0,59\$1
## AWS Beispiel CUR
Wenn Sie über einen Savings Plans verfügen, der die gesamte Nutzung der EC2-Instance im Abrechnungszeitraum abdeckt, werden die amortisierten Kosten anhand von berechnet. savingsPlan/SavingsPlanEffectiveCost
![\[Table showing EC2 instance usage details with Savings Plans and cost breakdown.\]](http://docs.aws.amazon.com/de_de/cur/latest/userguide/images/savings-plan-entire-usage.png)
Wenn Sie einen Savings Plans haben, der die teilweise Nutzung der EC2-Instance im Abrechnungszeitraum abdeckt und der Rest der EC2-Instance-Nutzung zu On-Demand-Tarifen abgerechnet wird, werden die amortisierten Kosten für die EC2-Instance anhand von savingsPlan/SavingsPlanEffectiveCost (for SavingsPlanCoveredUsage) \$1 lineItem/UnblendedCost (für On-Demand-Nutzung) berechnet.
![\[Table showing EC2 instance usage details, costs, and savings plan information.\]](http://docs.aws.amazon.com/de_de/cur/latest/userguide/images/savings-plan-partial-usage.png)
# Beispiel für Daten zur geteilten Kostenzuweisung für beschleunigte Instances
Das folgende Beispiel soll Ihnen zeigen, wie Daten zur geteilten Kostenzuweisung berechnet werden, indem die Kosten für Kubernetes-Namespace und Pods in Amazon EKS-Clustern berechnet werden. Die im gesamten Beispiel verwendeten Tarife dienen nur zur Veranschaulichung.
Sie haben in einer einzigen Stunde die folgende Nutzung:
+ Eine einzelne EC2-Instance, die vier Pods in zwei Namespaces ausführt, und Sie möchten die Kosten der einzelnen Namespaces verstehen.
+ Die EC2-Instance ist p3.16xlarge mit 8 GPU, 64 vCPU und 488 GB RAM.
+ Die amortisierten Kosten der Instance belaufen sich auf 10 USD/Stunde.
Daten zur geteilten Kostenzuweisung normalisieren die Kosten pro Ressource auf der Grundlage eines relativen Verhältnisses von GPU: (CPU: Speicher) von 9:1. Dies bedeutet, dass eine GPU-Einheit 9-mal so viel kostet wie eine Einheit von CPU und Speicher. CPU und Speicher wird dann ein Gewicht von 9:1 zugewiesen. Für eine nicht beschleunigte EC2-Instance wird das aktuelle Standardverhalten übernommen, nämlich CPU: Die Speichergewichtung ist standardmäßig 9:1.
## Schritt 1: Berechnen Sie die Stückkosten
Basierend auf den CPU- und Speicherressourcen auf der EC2-Instance und unter Verwendung des oben genannten Verhältnisses berechnen die Split Cost Allocation-Daten zunächst die Stückkosten pro GPU vCPU vCPU-Stunde und GB-Stunde.
`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`
**Tabelle 1: Berechnung der Stückkosten**
| Instance | Instance-Typ | vCPU verfügbar | GPU verfügbar | \$1\$1 | Speicher verfügbar | Amortisierte Kosten pro Stunde | Kosten pro vCPU-Stunde | Kosten pro GPU-Stunde | Kosten pro GB-Stunde |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Instance 1 | p3.16xgroß | 64 | 8 | | 488 | 10\$1 | \$10.05 | 0,50\$1 | 0,005 |
## Schritt 2: Berechnen Sie die zugewiesene und ungenutzte Kapazität
Zugewiesene Kapazität
Die GPU, vCPU und der Speicher, die dem Kubernetes-Pod von der übergeordneten EC2-Instance zugewiesen wurden, definiert als Maximum an (reservierter, genutzter) Kapazität
Ungenutzte Kapazität der Instance
Die ungenutzte Kapazität von GPU, vCPU und Arbeitsspeicher
`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`
In diesem Beispiel hat die Instanz mehr CPU als Abonnement, was Pod 2 zugeschrieben wird, der mehr GPU und vCPU verbrauchte als reserviert war.
**Tabelle 2: Berechnung der zugewiesenen und ungenutzten Kapazität**
| Pod-Name | Namespace | vcpu reserviert | vcpu verwendet | vcpu zugewiesen | GPU reserviert | Verwendete GPU | GPU zugewiesen | Speicher reserviert | Verwendeter Speicher | Zugewiesener Speicher |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Namespace 1 | 16 | 4 | 16 | 1 | 1 | 1 | 100 | 60 | 100 |
| Pod 2 | Namespace 2 | 16 | 18 | 18 | 2 | 3 | 3 | 100 | 140 | 140 |
| Pod 3 | Namespace 1 | 16 | 4 | 16 | 2 | 1 | 2 | 100 | 60 | 100 |
| Kapsel 4 | Namespace 2 | 16 | 4 | 16 | 2 | 2 | 2 | 100 | 40 | 100 |
| Nicht verwendet | Nicht verwendet | 0 | 34 | 0 | 1 | 1 | 0 | 88 | 188 | 48 |
| \$1\$1\$1 | | 64 | 32 | 66 | 8 | 8 | 8 | 488 | 488 | 488 |
## Schritt 3: Berechnen Sie die Aufteilung der Nutzungs- und Nutzungsquoten
Aufgeteiltes Nutzungsverhältnis
Der Prozentsatz der vom Kubernetes-Pod genutzten CPU oder des Speichers im Vergleich zur gesamten verfügbaren CPU oder dem auf der EC2-Instance verfügbaren Speicher.
Anteil ungenutzter Anteil
Der Prozentsatz der vom Kubernetes-Pod genutzten CPU oder des Speichers im Vergleich zur gesamten CPU- oder Speicherbelegung auf der EC2-Instance (d. h. ohne Berücksichtigung der ungenutzten CPU oder des ungenutzten Speichers auf der Instance).
Der Prozentsatz der vom Kubernetes-Pod genutzten CPU oder des Speichers im Vergleich zur gesamten auf der EC2-Instance verfügbaren CPU oder des gesamten Speichers.
`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`
**Tabelle 3: Rechenauslastungsquoten**
| Pod-Name | Namespace | vCPU-Auslastung | vCPU-Aufteilungsverhältnis | GPU-Auslastung | GPU-Aufteilungsverhältnis | Speichernutzung | Verhältnis der Speicheraufteilung |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Namespace 1 | 0,242 | 0 | 0.125 | 0 | 0,205 | 0.227 |
| Pod 2 | Namespace 2 | 0,277 | 0 | 0,375 | 0 | 0,287 | 0,318 |
| Pod 3 | Namespace 1 | 0,242 | 0 | 0,25 | 0 | 0,205 | 0.227 |
| Kapsel 4 | Namespace 2 | 0,242 | 0 | 0,25 | 0 | 0,205 | 0.227 |
| Nicht verwendet | Nicht verwendet | 0 | | | | 0,098 | |
| | | 1 | 0 | 1 | 0 | 1 | 1 |
## Schritt 4: Berechne die geteilten Kosten und die ungenutzten Kosten
Kosten aufteilen
Die Aufteilung der Kosten pro Nutzung der EC2-Instance auf der Grundlage der zugewiesenen CPU- und Speichernutzung durch die Kubernetes-Pods
Kosten für ungenutzte Instances
Die Kosten für ungenutzte CPU- oder Speicherressourcen auf der 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`
[Hinweis: Ungenutzte Kosten = Verhältnis ungenutzter Nutzwert x Gesamtressource x Stundenkosten der Ressource]
**Tabelle 4 — Zusammenfassung der aufgeteilten und ungenutzten Kosten, die jede Stunde für alle Pods berechnet werden, die innerhalb des Clusters ausgeführt werden**
| Pod-Name | Namespace | Kosten aufteilen | Ungenutzte Kosten | Gesamtkosten |
| --- | --- | --- | --- | --- |
| Pod 1 | Namespace 1 | 1,85\$1 | 0,06 USD | 1,91\$1 |
| Pod 2 | Namespace 2 | 3,18\$1 | 0,09\$1 | 3,26\$1 |
| Pod 3 | Namespace 1 | 2,35\$1 | 0,06 USD | 2,41\$1 |
| Kapsel 4 | Namespace 2 | 2,35\$1 | 0,06 USD | 2,41\$1 |
| Gesamt | | | | 10\$1 |
# Verwendung von Kubernetes-Labels für die Kostenzuweisung in EKS
Geteilte Kostenzuordnungsdaten unterstützen Kubernetes-Labels als Kostenzuweisungs-Tags für Amazon EKS-Cluster. Diese Labels werden zwar automatisch als benutzerdefinierte Kostenzuweisungs-Tags importiert, müssen jedoch auf Verwaltungskontoebene aktiviert werden. Nach der Aktivierung können Sie mithilfe von benutzerdefinierten Attributen wie Kostenstelle, Anwendung, Geschäftseinheit und Umgebung Kosten auf Pod-Ebene in Ihren Kosten- und Nutzungsberichten (CUR) zuordnen.
Diese Funktion hilft Unternehmen dabei, Kosten in gemeinsam genutzten EKS-Umgebungen über Teams, Projekte oder Abteilungen hinweg genau zu verfolgen und zuzuweisen. Mithilfe von Kubernetes-Labels können Sie Ihre Kubernetes-Kosten auf der Grundlage Ihrer spezifischen Geschäftsanforderungen und Ihres Organisationsdesigns zuordnen.
## Voraussetzungen
Als Voraussetzungen für die Verwendung von Kubernetes-Labels mit Daten zur geteilten Kostenzuweisung gelten folgende Voraussetzungen:
+ Sie müssen die Daten zur geteilten Kostenzuweisung in der AWS Billing and Cost Management-Konsole aktivieren. Dies muss auf der Ebene des Verwaltungskontos aktiviert werden. Einzelheiten finden Sie unter Daten zur [geteilten Kostenzuweisung aktivieren](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Sie benötigen einen EKS-Cluster, für den Sie Daten zur geteilten Kostenzuweisung verfolgen möchten. Dies kann ein vorhandener Cluster sein, oder Sie können einen neuen erstellen. Weitere Informationen finden Sie unter [Erstellen eines Amazon EKS-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) im *Amazon EKS-Benutzerhandbuch*.
+ Sie müssen Ihren Pods im EKS-Cluster Labels zugewiesen haben. *Weitere Informationen zum Erstellen von Labels in Kubernetes finden Sie unter [Labels and Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) in der Kubernetes-Dokumentation.*
## Arbeiten mit Kubernetes-Labels in EKS
Geteilte Kostenzuordnungsdaten unterstützen bis zu 50 Kubernetes-Labels pro Pod, die alphabetisch sortiert werden, bevor sie als Kostenzuweisungs-Tags importiert werden. Alle Labels, die über die ersten 50 hinausgehen, werden automatisch verworfen. Wenn Sie nach Erreichen der Obergrenze von 50 Etiketten ein neues Kostenzuordnungs-Tag hinzufügen müssen, müssen Sie zunächst ein vorhandenes Etikett entfernen und sicherstellen, dass Ihr neues Etikett bei alphabetischer Sortierung unter die ersten 50 fällt.
**Anmerkung**
Einige AWS verwaltete Dienste fügen EKS-Pods automatisch Labels hinzu. Diese Labels werden auf das Limit von 50 Labels pro Pod angerechnet und werden auf der Seite mit den Tags für die Kostenzuweisung angezeigt.
Kubernetes-Labels haben zwar keine Größenbeschränkungen, für Kostenzuweisungs-Tags gelten jedoch spezifische Zeichenbeschränkungen: 128 Zeichen für Tag-Schlüssel und 256 Zeichen für Tag-Werte. Beschriftungen, die diese Zeichenbeschränkungen überschreiten, werden verworfen und nicht als Kostenzuweisungs-Tags dargestellt. Es wird empfohlen, Beschriftungen zu erstellen, die diese Zeichenbeschränkungen einhalten, um die Kosten zuzuordnen.
Die importierten Kubernetes-Labels werden als Tags für die Kostenzuweisung angezeigt und müssen auf Ebene des Zahlerkontos aktiviert werden. Weitere Informationen zu Kostenzuweisungs-Tags und zur Aktivierung finden Sie unter [Verwenden von benutzerdefinierten](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) Kostenzuweisungs-Tags. Es gelten die folgenden Grenzwerte für Kostenzuweisungs-Tags: 50 benutzerdefinierte Tags pro Ressource und 500 benutzerdefinierte Tags pro Zahlerkonto. Vom System generierte Stichwörter werden nicht auf diese Grenzwerte angerechnet.
**Anmerkung**
Nachdem Sie benutzerdefinierte Tags erstellt und auf Ihre Ressourcen angewendet haben, kann es bis zu 24 Stunden dauern, bis die Tagschlüssel auf der Seite mit den Stichwörtern für die Kostenzuweisung angezeigt werden. Sobald Sie die Tags aktiviert haben, kann es weitere 24 Stunden dauern, bis sie aktiv werden.
## Verwaltung von Kubernetes-Labels und Kostenzuweisungs-Tags
Sie können Kubernetes-Labels in EKS hinzufügen, löschen und bearbeiten sowie die zugehörigen Kostenzuweisungs-Tags deaktivieren. Im Folgenden wird das erwartete Verhalten für jede Aktion beschrieben.
**Ein neues Label hinzufügen**
Sie können einem Pod ein neues Kubernetes-Label hinzufügen. Wenn das Label-Limit von 50 nicht erreicht wurde, wird das neue Label importiert und als Kostenzuweisungs-Tag angeboten, das dann aktiviert werden kann. Wenn das Limit von 50 jedoch erreicht wurde, wird das neue Label nicht importiert, auch wenn es in die alphabetische Sortierreihenfolge der ersten 50 Labels fällt. Sie müssen zuerst ein vorhandenes Kostenzuordnungs-Tag deaktivieren, um ein neues Etikett importieren zu können.
**Ein Label bearbeiten**
In Kubernetes können Sie einen Labelschlüssel nicht bearbeiten. Um einen Labelschlüssel zu ändern, müssen Sie ihn entfernen und ein neues Label hinzufügen. Sie können jedoch Labelwerte bearbeiten, die in Ihrer nächsten CUR berücksichtigt werden.
**Löschen eines Labels**
Sie können ein Etikett aus EKS-Pods entfernen. Beachten Sie, dass durch das Entfernen eines Labels nicht automatisch das zugehörige Kostenzuweisungs-Tag deaktiviert wird. Daten zur geteilten Kostenzuweisung werden weiterhin in CUR übernommen, bis Sie das Kostenzuordnungs-Tag explizit deaktivieren.
**Deaktivierung eines Kostenzuweisungs-Tags**
Sie können jedes Kostenzuweisungs-Tag deaktivieren, das aus Kubernetes-Labels erstellt wurde. Nach der Deaktivierung werden die entsprechenden Spalten nicht mehr mit Daten gefüllt, und die Spalte wird aus der CUR des nächsten Monats gelöscht.
## Bewährte Methoden für die Verwaltung von Kubernetes-Labels für die Kostenzuweisung
Kubernetes-Labels bieten eine erhebliche Flexibilität bei der Modellierung der gemeinsamen Kostenzuweisung. Um das Potenzial dieser Funktion voll auszuschöpfen, empfehlen wir, die folgenden Best Practices zu befolgen, um Ihren Kostenmanagementansatz zu optimieren.
**Grundlegendes zu Bezeichnungsbeschränkungen**
Das label-per-pod Limit von 50 basiert auf einer alphabetischen Sortierung. Für die Kostenzuweisung werden nur die ersten 50 alphabetisch sortierten Etiketten importiert. Um sicherzustellen, dass wichtige Beschriftungen enthalten sind, sollten Sie die Benennung Ihrer Etiketten sorgfältig planen, um sicherzustellen, dass wichtige Etiketten in alphabetischer Reihenfolge unter den ersten 50 erscheinen.
**Folgende Zeichenbeschränkungen**
AWS Für Tags zur Kostenzuweisung gelten die folgenden Zeichenbeschränkungen:
+ Tag-Schlüssel: 128 Zeichen
+ Tag-Werte: 256 Zeichen
Kubernetes erlaubt zwar längere Labels, aber Labels, die diese Grenzwerte überschreiten, werden nicht importiert. Gestalten Sie Ihre Labels innerhalb dieser Grenzen, um eine erfolgreiche Nachverfolgung der Kostenzuweisung sicherzustellen.
**Hinzufügen neuer Etiketten, wenn die Kapazität ausgeschöpft ist**
Wenn ein Pod das Limit von 50 Labels erreicht hat und Sie ein neues Label für die Kostenzuweisung hinzufügen müssen, gehen Sie wie folgt vor:
1. Überprüfe die vorhandenen Labels und identifiziere ein Kostenzuweisungs-Tag, das du deaktivieren möchtest.
1. Deaktiviert das ausgewählte Tag.
1. Fügen Sie das neue Label für die Kostenzuweisung hinzu.
1. Stellen Sie sicher, dass das neue Etikett zu den ersten 50 alphabetisch sortierten Bezeichnungen gehört.
**Anmerkung**
Denken Sie daran, dass nur die ersten 50 alphabetisch sortierten Bezeichnungen für die Kostenzuweisung verwendet werden.
# Verwenden von Daten zur geteilten Kostenzuweisung mit Amazon Managed Service für Prometheus
Um die Kostendaten für Amazon EKS aufzuteilen, müssen Sie Metriken aus Ihren Clustern sammeln und speichern, einschließlich Speicher- und CPU-Auslastung. Amazon Managed Service für Prometheus kann für diesen Zweck verwendet werden.
Sobald Sie sich für die Aufteilung der Kostenzuordnungsdaten entschieden haben und Ihr Amazon Managed Service for Prometheus-Workspace beginnt, die beiden erforderlichen Metriken (`container_cpu_usage_seconds_total`und`container_memory_working_set_bytes`) zu empfangen, erkennen die geteilten Kostenzuordnungsdaten die Metriken und verwenden sie automatisch.
**Anmerkung**
Die beiden erforderlichen Metriken (`container_cpu_usage_seconds_total`und`container_memory_working_set_bytes`) sind in der Standardkonfiguration von Prometheus Scrape und der Standardkonfiguration mit einem AWS verwalteten Collector enthalten. Wenn Sie diese Konfigurationen jedoch anpassen, dürfen Sie die folgenden Bezeichnungen in den Metriken und nicht neu `container_memory_working_set_bytes` kennzeichnen, ändern oder entfernen:`name`, `container_cpu_usage_seconds_total` und. `namespace` `pod` Wenn Sie diese Labels umbenennen, ändern oder entfernen, kann sich dies auf die Erfassung Ihrer Metriken auswirken.
Sie können Amazon Managed Service for Prometheus verwenden, um EKS-Metriken von einem einzigen Nutzungskonto in einer einzigen Region zu sammeln. Der Amazon Managed Service for Prometheus Workspace muss sich in diesem Konto und dieser Region befinden. Sie benötigen eine Amazon Managed Service for Prometheus-Instance für jedes Nutzungskonto und jede Region, für die Sie die Kosten überwachen möchten. Sie können Metriken für mehrere Cluster im Amazon Managed Service for Prometheus Workspace sammeln, sofern sie sich im selben Nutzungskonto und in derselben Region befinden.
In den folgenden Abschnitten wird beschrieben, wie Sie die richtigen Metriken von Ihrem EKS-Cluster an den Amazon Managed Service for Prometheus Workspace senden.
## Voraussetzungen
Als Voraussetzungen für die Nutzung von Amazon Managed Service for Prometheus mit geteilten Kostenzuweisungsdaten:
+ Sie müssen die Daten zur geteilten Kostenzuweisung in der AWS Billing and Cost Management-Konsole aktivieren. Einzelheiten finden Sie unter Daten zur [geteilten Kostenzuweisung aktivieren](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html). Wenn Sie sich für die Aufteilung der Kostenzuweisungsdaten entscheiden, wird in jedem Nutzungskonto eine serviceverknüpfte Rolle erstellt, um Amazon Managed Service for Prometheus nach den Amazon EKS-Cluster-Metriken in diesem Konto abzufragen. Weitere Informationen finden Sie unter [Servicebezogene Rollen für](https://docs.aws.amazon.com/cost-management/latest/userguide/split-cost-allocation-data-SLR.html) Daten zur geteilten Kostenzuweisung.
+ Sie benötigen einen EKS-Cluster, für den Sie Daten zur geteilten Kostenzuweisung verfolgen möchten. Dies kann ein vorhandener Cluster sein, oder Sie können einen neuen erstellen. Weitere Informationen finden Sie unter [Erstellen eines Amazon EKS-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) im *Amazon EKS-Benutzerhandbuch*.
**Anmerkung**
Sie benötigen die `EKS cluster ARN``security group IDs`, und mindestens zwei `subnet IDs` (in unterschiedlichen Verfügbarkeitszonen), um sie in späteren Schritten verwenden zu können.
(optional) Stellen Sie den Authentifizierungsmodus Ihres EKS-Clusters entweder auf `API` oder ein`API_AND_CONFIG_MAP`.
+ Sie benötigen eine Amazon Managed Service for Prometheus-Instance in demselben Konto und derselben Region wie Ihr EKS-Cluster. Wenn Sie noch keine haben, können Sie eine erstellen. Weitere Informationen zur Erstellung einer Amazon Managed Service for Prometheus-Instance finden [Sie unter Erstellen eines Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) im *Amazon Managed Service for Prometheus-Benutzerhandbuch*.
**Anmerkung**
Sie benötigen den, um ihn in späteren Schritten verwenden `Amazon Managed Service for Prometheus workspace ARN` zu können.
## Weiterleiten von EKS-Metriken an Amazon Managed Service for Prometheus
Sobald Sie über einen EKS-Cluster und eine Amazon Managed Service for Prometheus-Instance verfügen, können Sie die Metriken vom Cluster an die Instance weiterleiten. Sie können Metriken auf zwei Arten senden.
+ [Option 1: Verwenden Sie einen AWS verwalteten Collector.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#use-managed-collector) Dies ist die einfachste Methode, Metriken von einem EKS-Cluster an Amazon Managed Service for Prometheus zu senden. Es ist jedoch begrenzt, dass Metriken höchstens alle 30 Sekunden abgerufen werden.
+ [Option 2: Erstellen Sie Ihren eigenen Prometheus-Agenten.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent) In diesem Fall haben Sie mehr Kontrolle über die Scraping-Konfiguration, müssen den Agenten jedoch verwalten, nachdem Sie ihn erstellt haben.
### Option 1: Verwendung eines verwalteten Collectors AWS
Die Verwendung eines AWS verwalteten Collectors (eines *Scrapers*) ist die einfachste Methode, Metriken von einem EKS-Cluster an eine Amazon Managed Service for Prometheus-Instance zu senden. Das folgende Verfahren führt Sie Schritt für Schritt durch die Erstellung eines verwalteten Collectors AWS . Ausführlichere Informationen finden Sie unter [AWS Managed Collectors](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) im *Amazon Managed Service for Prometheus User Guide*.
**Anmerkung**
AWS Managed Collectors haben ein Mindest-Scrape-Intervall von 30 Sekunden. Wenn Sie kurzlebige Pods haben, wird empfohlen, das Scraper-Intervall auf 15 Sekunden festzulegen. Um ein Scraper-Intervall von 15 Sekunden zu verwenden, verwenden Sie Option 2, um [Ihren eigenen Prometheus-Agenten zu erstellen](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent).
Es gibt drei Schritte, um einen verwalteten Collector zu erstellen AWS :
1. Erstellen Sie eine Scraper-Konfiguration.
1. Erstellen Sie den Scraper.
1. Konfigurieren Sie Ihren EKS-Cluster so, dass der Scraper auf Metriken zugreifen kann.
*Schritt 1: Erstellen Sie eine Scraper-Konfiguration*
Um einen Scraper zu erstellen, benötigen Sie eine Scraper-Konfiguration. Sie können eine Standardkonfiguration verwenden oder eine eigene erstellen. Es gibt drei Möglichkeiten, eine Scraper-Konfiguration zu erhalten:
+ Rufen Sie die Standardkonfiguration mit der AWS CLI ab, indem Sie Folgendes aufrufen:
```
aws amp get-default-scraper-configuration
```
+ Erstellen Sie Ihre eigene Konfiguration. Einzelheiten finden Sie in den [Scraper-Konfigurationsanweisungen](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) im *Amazon Managed Service for Prometheus* User Guide.
+ Kopieren Sie die Beispielkonfiguration, die in derselben [Scraper-Konfigurationsanleitung](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) im *Amazon Managed Service for Prometheus* User Guide enthalten ist.
Sie können die Scraper-Konfiguration bearbeiten, um beispielsweise das Scrape-Intervall zu ändern oder um die gescrapten Metriken zu filtern.
Verwenden Sie die folgende Scraper-Konfiguration, um die gesammelten Metriken so zu filtern, dass sie nur die beiden enthalten, die für die geteilte Kostenzuweisung benötigt werden:
```
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
```
*Sobald Sie die Scraper-Konfiguration haben, müssen Sie sie für die Verwendung in Schritt 2 base64-kodieren.* Die Konfiguration ist eine YAML-Textdatei. [Verwenden Sie zum Kodieren der Datei eine Website wie https://www.base64encode.org/.](https://www.base64encode.org/)
*Schritt 2: Erstellen Sie den Scraper*
Nachdem Sie eine Konfigurationsdatei haben, müssen Sie Ihren Scraper erstellen. Erstellen Sie einen Scraper mit dem folgenden AWS CLI-Befehl, der auf den im Abschnitt Voraussetzungen beschriebenen Variablen basiert. Sie müssen Informationen aus Ihrem EKS-Cluster für die ** Felder, und verwenden ****, sie durch die Scraper-Konfiguration ** ersetzen, die Sie im vorherigen Schritt erstellt haben, und sie durch Ihren Amazon Managed Service for Prometheus Workspace ARN ** ersetzen.
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn=,securityGroupIds=[],subnetIds=[]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration={workspaceArn=""}
```
*Notieren Sie sich`scraperId`, was zur Verwendung in Schritt 3 zurückgegeben wird.*
*Schritt 3: Konfigurieren Sie Ihren EKS-Cluster so, dass der Scraper auf Metriken zugreifen kann*
Wenn der Authentifizierungsmodus Ihres EKS-Clusters auf entweder `API` oder eingestellt ist`API_AND_CONFIG_MAP`, verfügt Ihr Scraper automatisch über die richtige Cluster-Zugriffsrichtlinie, und die Scraper haben Zugriff auf Ihren Cluster. Es ist keine weitere Konfiguration erforderlich, und die Metriken sollten an Amazon Managed Service for Prometheus übertragen werden.
Wenn der Authentifizierungsmodus Ihres EKS-Clusters nicht auf `API` oder eingestellt ist`API_AND_CONFIG_MAP`, müssen Sie den Cluster manuell konfigurieren, damit der Scraper über ein und auf Ihre Metriken zugreifen kann. ClusterRole ClusterRoleBinding Informationen zum Aktivieren dieser Berechtigungen finden Sie unter [Manuelles Konfigurieren eines EKS-Clusters für den Scraper-Zugriff](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) im *Amazon Managed Service for Prometheus Benutzerhandbuch*.
Sobald der Scraper aktiv ist, stellen Sie sicher, dass beide Metriken (`container_cpu_usage_seconds_total`und`container_memory_working_set_bytes`) an Ihren Amazon Managed Service for Prometheus-Workspace übertragen werden.
```
awscurl --service="aps" --region="" "https://aps-workspaces..amazonaws.com/workspaces//api/v1/label/__name__/values"
```
Ausgabe:
```
{
"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: Erstellen Sie Ihren eigenen Prometheus-Agenten
Wenn Sie den AWS Managed Collector nicht verwenden können oder bereits über einen eigenen Prometheus-Server verfügen, können Sie Ihre eigene Prometheus-Instance als Agent verwenden, um Metriken aus Ihrem EKS-Cluster abzurufen und an Amazon Managed Service for Prometheus zu senden.
Detaillierte Anweisungen zur Verwendung Ihrer eigenen Prometheus-Instance als Agent finden Sie unter [Verwenden einer Prometheus-Instance als Collector](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-ingest-with-prometheus.html) im *Amazon Managed Service for* Prometheus-Benutzerhandbuch.
Im Folgenden finden Sie ein Beispiel für eine Prometheus-Scrape-Konfiguration, die das Prometheus-Server-Scrape-Intervall und die für Split-Cost-Allocation-Daten erforderlichen Container-Metriken umfasst. Wenn Sie kurzlebige Pods haben, wird empfohlen, das standardmäßige Prometheus-Server-Scrape-Intervall von 30 Sekunden auf 15 Sekunden zu senken. Beachten Sie, dass dies zu einer hohen Speicherauslastung Prometheus Prometheus-Servers führen kann.
```
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
```
Wenn Sie im *Amazon Managed Service for Prometheus Benutzerhandbuch* [die Option Aufnahme von einem neuen Prometheus-Server mithilfe von Helm einrichten](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-metrics-new-Prometheus.html) befolgt haben, können Sie Ihre Scrape-Konfiguration aktualisieren.
**Um Ihre Scrape-Konfiguration zu aktualisieren**
1. Bearbeiten Sie es `my_prometheus_values_yaml` anhand der Anleitung und fügen Sie die Beispiel-Scrape-Konfiguration in den `server` Block ein.
1. Führen Sie den folgenden Befehl mit `prometheus-chart-name` und `prometheus-namespace` aus dem *Amazon Managed Service for Prometheus User* Guide aus.
```
helm upgrade prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace -f my_prometheus_values_yaml
```
[Weitere Informationen zu `scrape_interval` oder zur Verwendung eines nicht-globalen scrape\$1interval finden Sie unter Prometheus-Scrape-Konfiguration.](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)
Alternativ können Sie den AWS Distro for OpenTelemetry Collector verwenden, der über einen Prometheus Receiver, einen Prometheus Remote Write Exporter und die AWS Sigv4 Authentication Extension verfügt, um Remote-Schreibzugriff auf Amazon Managed Service for Prometheus zu erhalten.
**Anmerkung**
Sobald Sie Ihren Prometheus-Agenten eingerichtet haben, sind Sie im Gegensatz zu AWS Managed Collectors dafür verantwortlich, den Agenten auf dem neuesten Stand zu halten und die Metriken zu sammeln.
## Schätzung der Kosten für Amazon Managed Service für Prometheus
Sie können den AWS Preisrechner verwenden, um die Kosten für die Nutzung von Amazon Managed Service for Prometheus für Daten zur geteilten Kostenzuweisung zu schätzen.
**So konfigurieren Sie Amazon Managed Service für Prometheus für Ihren Kostenvoranschlag**
1. [Öffnen Sie den AWS Preisrechner unter https://calculator.aws/\$1/.](https://calculator.aws/#/)
1. Wählen Sie **Create estimate (Schätzung erstellen)** aus.
1. **Geben Sie auf der Seite **Service hinzufügen** **Amazon Managed Service for Prometheus** in das Suchfeld ein und wählen Sie dann Configure aus.**
1. Geben Sie im Feld **Beschreibung** eine Beschreibung für Ihren Kostenvoranschlag ein.
1. Region wählen **Region**.
1. Wählen Sie **Die Kosten anhand Ihrer Infrastrukturdetails berechnen** aus. Mit dieser Option können Sie Ihre Kosten für Aufnahme, Speicherung und Stichproben für Abfragen auf der Grundlage Ihrer aktuellen oder geplanten Infrastrukturkonfiguration schätzen.
1. Geben Sie unter **Anzahl der EC2-Instances** die Gesamtzahl der EC2-Instances in all Ihren Clustern für Ihre gesamte konsolidierte Fakturierungsfamilie (einschließlich aller Konten und Regionen) ein. Wenn Sie verwenden AWS Fargate, verwenden Sie die Anzahl der Fargate-Aufgaben als Proxy für die Anzahl Ihrer EC2-Instances.
1. Für Daten zur geteilten Kostenzuweisung sind zwei Metriken erforderlich: `container_cpu_usage_seconds_total` und. `container_memory_working_set_bytes` Geben Sie für **Prometheus-Metriken pro EC2-Instances den Wert 2** ein.
1. Daten zur geteilten Kostenzuweisung deuten auf ein Scrape-Intervall von 15 Sekunden hin. Geben Sie für **Intervall zur Erfassung von Messwerten (in Sekunden)** den Wert 15 ein. Wenn Sie ein anderes Intervall verwendet haben (z. B. 30 Sekunden), ändern Sie dieses auf das von Ihnen festgelegte Intervall.
1. Bei geteilten Kostenzuordnungsdaten bestehen keine spezifischen Anforderungen für die anderen Parameter. Geben Sie daher entsprechend Ihren Geschäftsanforderungen entsprechende Werte für die übrigen Eingabeparameter ein.
1. Wählen Sie **Service speichern und hinzufügen**.
# Verwenden von Daten zur geteilten Kostenzuweisung mit Amazon CloudWatch Container Insights
Um die Kostendaten für Amazon EKS aufzuteilen, müssen Sie Metriken aus Ihren Clustern sammeln und speichern, einschließlich Speicher- und CPU-Auslastung. Amazon CloudWatch Container Insights kann für diesen Zweck verwendet werden.
Sobald Sie sich für die Aufteilung der Kostenzuordnungsdaten entschieden und den CloudWatch Agenten mit dem EKS-Observability-Add-on auf Ihrem EKS-Cluster eingerichtet haben, erhalten die geteilten Kostenzuordnungsdaten die beiden erforderlichen Metriken `pod_memory_working_set` (`(pod_cpu_usage_total`und) im `ContainerInsights` Namespace und verwenden sie automatisch. Den vollständigen Satz an Container-Metriken für EKS finden Sie unter [Amazon EKS- und Kubernetes Container Insights-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) im * CloudWatch Amazon-Benutzerhandbuch*.
In den folgenden Abschnitten wird beschrieben, wie Sie die richtigen Metriken aus Ihrem EKS-Cluster an Split-Kostenzuordnungsdaten senden.
## Voraussetzungen
Als Voraussetzungen für die Verwendung von Amazon CloudWatch Container Insights mit geteilten Kostenzuweisungsdaten:
+ Sie müssen die Daten zur geteilten Kostenzuweisung in der AWS Billing and Cost Management-Konsole aktivieren. Einzelheiten finden Sie unter Daten zur [geteilten Kostenzuweisung aktivieren](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Sie benötigen einen EKS-Cluster, für den Sie Daten zur geteilten Kostenzuweisung verfolgen möchten. Dies kann ein vorhandener Cluster sein, oder Sie können einen neuen erstellen. Weitere Informationen finden Sie unter [Erstellen eines Amazon EKS-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) im *Amazon EKS-Benutzerhandbuch*.
## Einrichtung von Amazon CloudWatch Container Insights zur Weiterleitung von EKS-Metriken
Sie müssen den CloudWatch Agenten einrichten und konfigurieren, um EKS-Metriken weiterzuleiten. Sie können entweder das [Amazon CloudWatch Observability EKS-Add-on oder das Amazon CloudWatch Observability Helm-Diagramm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) verwenden, um den CloudWatch Agenten und den Fluent-Bit-Agenten auf einem EKS-Cluster zu installieren. Weitere Informationen zur Installation und Einrichtung des CloudWatch Agenten finden Sie unter [Installieren des Amazon CloudWatch Observability EKS-Add-ons](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html) im * CloudWatch Amazon-Benutzerhandbuch*.
Im Folgenden sind die Mindestversionen aufgeführt, die für den CloudWatch Agenten und das EKS-Add-on erforderlich sind:
+ CloudWatch Agentenversion: v1.300045.0
+ CloudWatch EKS-Zusatzversion für Observability: v2.0.1-eksbuild.1
## Schätzung Ihrer Amazon-Kosten CloudWatch
Durch die Aktivierung der Funktion zur Verwendung von Amazon CloudWatch Container Insights mit Daten zur geteilten Kostenzuweisung werden Amazon CloudWatch Container Insights um zwei neue Metriken erweitert: `pod_cpu_usage_total` und`pod_memory_working_set`. Einzelheiten zu diesen Metriken finden Sie unter [Amazon EKS- und Kubernetes Container Insights-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) im * CloudWatch Amazon-Benutzerhandbuch*.
**Um die mit der Funktion verbundenen Kosten zu verstehen**
1. Öffnen Sie Amazon CloudWatch Pricing at [https://aws.amazon.com/cloudwatch/pricing/](https://aws.amazon.com/cloudwatch/pricing/).
1. Navigieren Sie zum Abschnitt „**Kostenpflichtiges Abonnement“.**
1. Wählen Sie den Tab **Container Insights**.
1. Eine detaillierte Berechnung der Kosten finden Sie im Abschnitt **Preisbeispiele** und sehen Sie sich **Beispiel 13 — Container Insights for Amazon EKS and Kubernetes** an.