本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 了解分割成本配置資料
您可以使用成本和用量報告 (AWS CUR) 來追蹤 Amazon ECS 和 Amazon EKS 容器成本。使用分割成本分配資料，您可以根據您的容器工作負載如何使用共用運算和記憶體資源，將容器成本分配給個別業務單位和團隊。分割成本分配資料會將新容器層級資源 （即 ECS 任務和 Kubernetes Pod) 的成本和用量資料引入 AWS CUR。先前， AWS CUR 僅支援 EC2 執行個體層級的成本。分割成本分配資料會透過查看每個容器的 EC2 執行個體資源耗用量來產生容器層級的成本，並根據執行個體的攤銷成本，以及執行個體上執行的容器所耗用的 CPU 和記憶體資源百分比來產生成本。
對於與 Amazon EKS 搭配使用的加速運算執行個體，分割成本分配資料包含專用處理器以及 CPU 和記憶體的資源分配。這涵蓋 NVIDIA 和 AMD GPUs、 AWS Trainium 和 AWS Inferentia 加速器。此功能僅適用於 Amazon EKS 環境，並提供這些加速運算資源的 Pod 層級資源保留資料。這可讓您追蹤和配置使用這些特殊處理器的工作負載成本，例如 AI/ML 應用程式和其他運算密集型任務。如需加速運算執行個體的目前清單，請參閱[加速運算](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)。
分割成本分配資料為 AWS CUR 中的每個容器化資源 ID （即 ECS 任務和 Kubernetes Pod) 引入新的用量記錄和新的成本指標資料欄。如需詳細資訊，請參閱[分割明細項目詳細資訊](https://docs.aws.amazon.com/cur/latest/userguide/split-line-item-columns.html)。
在 AWS CUR 中包含分割成本分配資料時，每個 ECS 任務和 Kubernetes Pod 每小時會新增兩個新的用量記錄，以反映 CPU 和記憶體成本。若要估計每天 AWS CUR 中的新明細項目數量，請使用下列公式：
對於 ECS： `(number of tasks * average task lifetime * 2) * 24`
對於 EKS： `(number of pods * average pod lifetime * 2) * 24`
例如，如果您有 1，000 個 Pod 在 10 個 EC2 執行個體的叢集中每小時執行一次，且 Pod 的生命週期少於 1 小時，則：
`(1000 * 1 * 2) * 24 = 48,000 new usage records in AWS CUR`
對於 Amazon EKS 中的加速運算執行個體，每個 Kubernetes Pod 每小時會新增三個新的用量記錄，以反映加速器、CPU 和記憶體成本。若要估計每天 AWS CUR 中的新明細項目數量，請使用下列公式：
對於具有加速運算的 EKS： `(number of pods * average pod lifetime * 3) * 24`
例如，如果您有 1，000 個 Pod 在 10 個 EC2 執行個體的叢集中每小時執行一次，且每個 Pod 的生命週期少於一小時，則： `(1000 * 1 * 3) * 24 = 72,000 new usage records in AWS CUR`
**注意**
對於 ECS：在 AWS 成本分配標籤方面，您可以針對成本和用量報告使用 Amazon ECS 受管標籤或使用者新增標籤。這些標籤適用於所有新的 ECS 分割成本分配資料用量記錄。如需詳細資訊，請參閱[標記您的 ECS 資源以進行計費](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html#tag-resources-for-billing)。
對於 EKS：分割成本分配資料會為某些 Kubernetes 屬性建立新的成本分配標籤。這些標籤包括 `aws:eks:cluster-name`、`aws:eks:deployment`、`aws:eks:namespace`、`aws:eks:workload-name`、 `aws:eks:node`和 `aws:eks:workload-type`。
`aws:eks:cluster-name`、 `aws:eks:namespace`和 `aws:eks:node`會以回溯方式填入叢集、命名空間和節點的名稱。
`aws:eks:workload-type` 只有在只有一個管理 Pod 的工作負載，且 是內建工作負載之一時，才會填入 。工作負載類型包括 `ReplicaSet`、`StatefulSet`、`DaemonSet`、 `Job`或 `ReplicationController`，並`aws:eks:workload-name`包含工作負載的名稱。如需詳細資訊，請參閱 *Kubernetes 文件*中的[工作負載](https://kubernetes.io/docs/concepts/workloads/)。
`aws:eks:deployment` 只會填入工作負載類型 `ReplicaSet`。這是建立 的部署`ReplicaSet`。
這些標籤適用於所有新的 EKS 分割成本分配資料用量記錄。預設會針對成本分配啟用這些標籤。如果您之前已使用並停用`aws:eks:cluster-name`標籤，則分割成本分配資料會保留此設定，而不會啟用標籤。您可以從[成本分配標籤](https://console.aws.amazon.com/billing/home#/tags)主控台頁面啟用它。
# 啟用分割成本分配資料
**注意**
Cost Explorer 中不提供分割成本分配資料。它可在舊版成本和用量報告 (CUR) 和成本和用量報告 2.0 (CUR 2.0) 中搭配資料匯出使用。
這是選擇透過成本管理偏好設定分割成本分配資料的先決條件。
**選擇加入分割成本分配資料**
1. 開啟「帳單和成本管理」主控台，網址為 [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/)。
1. 在導覽窗格中，選擇**成本管理偏好設定**。
1. 在**一般**下，在**分割成本分配資料**區段中，選擇下列項目：
+ **Amazon Elastic Container Service (Amazon ECS)** 僅選擇加入 Amazon ECS。
+ **Amazon Elastic Kubernetes Service (Amazon EKS)** 僅選擇加入 Amazon EKS。對於 Amazon EKS，請選擇下列選項：
+ **資源請求**：這只會透過 Kubernetes Pod CPU 和記憶體資源配置 Amazon EC2。這將鼓勵應用程式團隊只佈建他們所需的內容。
+ **Amazon Managed Service for Prometheus**：這會透過較高的 Kubernetes Pod CPU 和記憶體資源請求和實際使用率來配置您的 Amazon EC2 成本。這可確保每個應用程式團隊支付其使用量的費用。若要進一步了解如何設定 Amazon Managed Service for Prometheus，請參閱《*Amazon Managed Service for Prometheus 使用者指南*》中的[設定](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-setting-up.html)。
先決條件：您必須在 中啟用所有功能 AWS Organizations。若要進一步了解，請參閱 *Organizations 使用者指南*中的[啟用組織中的所有功能](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)。
+ **Amazon CloudWatch Container Insights**：這可為使用共用 EC2 執行個體執行多個應用程式容器的叢集提供更精細的成本可見性，從而更好地分配 EKS 叢集的共用成本。
**注意**
只有一般和付款人帳戶可以存取 AWS Cost Management 偏好設定，並且可以選擇加入分割成本分配資料。選擇加入後，成員帳戶就可以在成本和用量報告中檢視資料。
如果您選擇資源請求，則分割成本分配資料只會使用以記憶體和 CPU 請求設定的 Pod。未請求任何用量的 Pod 不會看到任何分割成本資料。
如果您選擇 Amazon Managed Service for Prometheus，則需要啟用 AWS Organizations 中的所有功能。如需詳細資訊，請參閱[啟用組織中的所有功能](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)。此外，分割成本分配資料會建立新的服務連結角色，以存取 AWS 分割成本分配資料使用或管理的服務和資源。
對於加速運算執行個體，僅支援資源請求選項。這些執行個體不支援 Amazon Managed Service for Prometheus 或 Amazon CloudWatch Container Insights。使用加速運算執行個體時，系統會預設為 資源請求，以計算加速器、CPU 和記憶體成本，即使已啟用其他測量選項。
選擇加入後，您可以在報告建立步驟一或之後編輯報告詳細資訊，選擇讓報告中包含容器層級資源的成本和用量資料。
**在報告中包含成本和用量資料**
1. 開啟「帳單和成本管理」主控台，網址為 [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/)。
1. 在導覽窗格的**舊版頁面**下，選擇**成本和用量報告**。
1. 無論是建立新報告或編輯現有報告，在**指定報告詳細資訊**頁面的報告**內容**下，選取**分割成本分配資料**。
**注意**
您也可以使用 AWS CUR API 或 AWS Command Line Interface (CLI) 來管理您的分割成本分配資料偏好設定。
分割成本分配資料可讓整個合併帳單系列 （付款人和連結帳戶） 中所有 Amazon ECS 和 Amazon EKS 容器物件的成本可見性。啟動後，分割成本分配資料會自動掃描任務和容器。它會擷取容器工作負載的遙測用量資料，並準備當月的精細成本資料。
**注意**
資料最多可能需要 24 小時才能在 AWS CUR 中顯示。
如需管理 Billing and Cost Management 主控台頁面存取權的詳細資訊，請參閱[管理存取許可的概觀](https://docs.aws.amazon.com/cost-management/latest/userguide/control-access-billing.html)。
如需 AWS Cost Management 偏好設定和控制 Cost Explorer 存取的相關資訊，請參閱[控制 Cost Explorer 的存取](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html)。
# 分割成本分配資料的範例
以下範例的目的是向您展示如何計算分割成本分配資料，方法是計算個別 Amazon ECS 服務的成本、Amazon ECS 叢集中的任務，以及 Amazon EKS 叢集中的 Kubernetes 命名空間和 Pod。整個範例中使用的速率僅供說明之用。
**注意**
此範例示範在 Amazon EKS 叢集中執行的 Kubernetes 命名空間和 Pod。然後，我們可以將相同的成本模型套用至在 Amazon ECS 叢集中執行的 Amazon ECS 服務和任務。
您在一小時內有下列用量：
+ 具有兩個命名空間和四個 Pod 的單一執行個體 (m5.xlarge) 共用叢集，在完整小時內執行。
+ 執行個體組態為 4 個 vCPU 和 16 GB 的記憶體。
+ 執行個體的攤銷成本為每小時 1 美元。
根據 9：1 的比率，分割成本分配資料使用 CPU 和記憶體的相對單位權重。這衍生自 中的每小時每個 vCPU 和每小時每 GB 價格[AWS Fargate](https://aws.amazon.com/fargate/pricing/)。
## 步驟 1：計算 CPU 和記憶體的單位成本
`Unit-cost-per-resource = Hourly-instance-cost/((Memory-weight * Memory-available) + (CPU-weight * CPU-available))`
= \$11/( (1 \$1 16GB) \$1 (9 \$1 4vCPU)) = \$10.02
`Cost-per-vCPU-hour = CPU-weight * Unit-cost-per-resource`
= 9 \$1 \$10.02 = \$10.17
`Cost-per-GB-hour = Memory-weight * Unit-cost-per-resource`
= 1 \$1 \$10.02 = \$10.02
****
| 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 美元 | 0.17 美元 | 0.02 美元 |
## 步驟 2：計算配置的容量和執行個體未使用的容量
+ 已配置容量：從父 EC2 執行個體配置給 Kubernetes Pod 的記憶體和 vCPU，定義為已使用和預留容量的上限。
**注意**
如果記憶體或 vCPU 用量資料無法使用，則會改用保留資料。如需詳細資訊，請參閱 [Amazon ECS 用量報告](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/usage-reports.html)或 [Amazon EKS 成本監控](https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring.html)。
+ 執行個體未使用的容量：vCPU 和記憶體的未使用容量。
`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)` = 最大值 (4 – 4.9， 0) = 0
`Instance-Unused-memory = Max (Memory-available - SUM(Allocated-memory), 0)` = 最大值 (16 – 14， 0) = 2 GB
在此範例中，執行個體具有 CPU over subscription，歸因於使用比保留更多的 vCPU 的 Pod2。
****
| 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 |
## 步驟 3：計算分割用量比率
+ 分割使用率：Kubernetes Pod 使用的 CPU 或記憶體與 EC2 執行個體上可用的整體 CPU 或記憶體相比的百分比。
+ 未使用的比率：Kubernetes Pod 使用的 CPU 或記憶體與 EC2 執行個體上使用的整體 CPU 或記憶體相比的百分比 （即不會考慮執行個體上未使用的 CPU 或記憶體）。
`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/ 16GB = 0.250
`Pod1-vCPU-unused-ratio = Pod1-vCPU-split-usage-ratio / (Total-CPU-split-usage-ratio – Instance-unused-CPU)` （如果 Instance-unused-CPU 為 0，則設為 0)
= 0 （因為 Instance-unused-CPU 為 0)
`Pod1-Memory-unused-ratio = Pod1-Memory-split-usage-ratio / (Total-Memory-split-usage-ratio – Instance-unused-memory)` （如果 Instance-unused-memory 為 0，則設為 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 | |
## 步驟 4：計算分割成本和未使用的成本
+ 分割成本：根據 Kubernetes Pod 配置的 CPU 和記憶體用量，EC2 執行個體成本的每次使用成本分配費用。
+ 未使用的執行個體成本：執行個體上未使用的 CPU 或記憶體資源的成本。
`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 \$10.17) \$1 (0.25 \$1 16GB \$1 \$10.02) = \$10.22
`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 \$10.17) \$1 (0.286 \$1 0.125 \$1 16 \$1 \$10.02) = \$10.01
`Pod1-Total-split-cost = Pod1-Split-cost + Pod1-Unused-cost`
= 0.23 美元
****
| Pod name | Namespace | Split-cost | Unused-cost | Total-split-cost |
| --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 0.22 美元 | 0.01 美元 | 0.23 美元 |
| Pod2 | Namespace2 | 0.38 美元 | 0.02 美元 | 0.40 美元 |
| Pod3 | Namespace1 | 0.18 美元 | 0.01 美元 | 0.19 美元 |
| Pod4 | Namespace2 | 0.18 美元 | 0.01 美元 | 0.19 美元 |
| Unused | Unused | 0.04 美元 | | |
| | | 1 美元 | 0.04 美元 | 1 美元 |
服務成本是與每個命名空間相關聯的 Pod 成本總和。
Namespace1 的總成本 = \$10.23 \$1 \$10.19 = \$10.42
Namespace2 的總成本 = \$10.40 \$1 \$10.19 = \$10.59
## 範例 AWS CUR
如果您有 Savings Plans 涵蓋帳單期間 EC2 執行個體的整個用量，則會使用 計算攤銷成本savingsPlan/SavingsPlanEffectiveCost。
![\[Table showing EC2 instance usage details with Savings Plans and cost breakdown.\]](http://docs.aws.amazon.com/zh_tw/cur/latest/userguide/images/savings-plan-entire-usage.png)
如果您的 Savings Plans 涵蓋計費期間 EC2 執行個體的部分用量，而 EC2 執行個體的其餘用量是以隨需費率計費，則 EC2 執行個體攤銷成本會使用 savingsPlan/SavingsPlanEffectiveCost（適用於 SavingsPlanCoveredUsage) \$1 lineItem/UnblendedCost（適用於隨需用量） 來計算。
![\[Table showing EC2 instance usage details, costs, and savings plan information.\]](http://docs.aws.amazon.com/zh_tw/cur/latest/userguide/images/savings-plan-partial-usage.png)
# 加速執行個體的分割成本分配資料範例
下列範例的目的是向您展示如何透過計算 Amazon EKS 叢集中 Kubernetes 命名空間和 Pod 的成本來計算分割成本分配資料。整個範例中使用的速率僅供說明之用。
您在一小時內有下列用量：
+ 跨兩個命名空間執行四個 Pod 的單一 EC2 執行個體，您想要了解每個命名空間的成本。
+ EC2 執行個體是具有 8 個 GPU、64 個 vCPU 和 488 GB RAM 的 p3.16xlarge。
+ 執行個體的攤銷成本為每小時 10 美元。
分割成本分配資料會根據 9：1 的 GPU：(cpu： 記憶體） 相對比率，標準化每個資源的成本。這表示 GPU 單位的成本是 CPU 和記憶體單位的 9 倍。然後，CPU 和記憶體的權重為 9：1。對於非加速 EC2 執行個體，將採用目前的預設行為，即 cpu：記憶體權重預設為 9：1。
## 步驟 1：計算單位成本
根據 EC2 執行個體上的 cpu 和記憶體資源，並使用上述比率，分割成本分配資料會先計算每個 GPU、vCPU-hr 和 GB-hr 的單位成本。
`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`
**表 1：單位成本計算**
| 執行個體 | 執行個體類型 | vCPU 可用 | 可用的 GPU | \$1\$1 | 可用的記憶體 | 每小時攤銷成本 | 每個 vCPU 小時的成本 | 每個 GPU 小時的成本 | 每小時每 GB 的成本 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 執行個體 1 | p3.16xlarge | 64 | 8 | | 488 | 10 美元 | 0.05 USD | 0.50 美元 | 0.005 |
## 步驟 2：計算已配置和未使用的容量
已配置容量
從父 EC2 執行個體配置給 Kubernetes Pod 的 GPU、vcpu 和記憶體，定義為容量上限 （預留、已使用）
執行個體未使用的容量
GPU、vcpu 和記憶體的未使用容量
`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`
在此範例中，執行個體具有 CPU over subscription，歸因於使用更多 GPU 和 vcpu 的 Pod 2。
**表 2：計算已配置和未使用的容量**
| Pod 名稱 | 命名空間 | vcpu 預留 | vcpu 已使用 | vcpu 已配置 | GPU 預留 | 使用的 GPU | GPU 已配置 | 預留的記憶體 | 使用的記憶體 | 已配置的記憶體 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | 命名空間 1 | 16 | 4 | 16 | 1 | 1 | 1 | 100 | 60 | 100 |
| Pod 2 | 命名空間 2 | 16 | 18 | 18 | 2 | 3 | 3 | 100 | 140 | 140 |
| Pod 3 | 命名空間 1 | 16 | 4 | 16 | 2 | 1 | 2 | 100 | 60 | 100 |
| Pod 4 | 命名空間 2 | 16 | 4 | 16 | 2 | 2 | 2 | 100 | 40 | 100 |
| 未使用的 | 未使用的 | 0 | 34 | 0 | 1 | 1 | 0 | 88 | 188 | 48 |
| \$1\$1\$1 | | 64 | 32 | 66 | 8 | 8 | 8 | 488 | 488 | 488 |
## 步驟 3：計算分割用量和使用率
分割用量比率
相較於 EC2 執行個體上可用的整體 CPU 或記憶體，Kubernetes Pod 使用的 CPU 或記憶體百分比。
未使用的比率
與 EC2 執行個體上使用的整體 CPU 或記憶體相比，Kubernetes Pod 使用的 CPU 或記憶體的百分比 （即不會考慮執行個體上未使用的 CPU 或記憶體）。
相較於 EC2 執行個體上可用的整體 CPU 或記憶體，Kubernetes Pod 使用的 CPU 或記憶體百分比。
`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`
**表 3：運算使用率比率**
| Pod 名稱 | 命名空間 | vcpu 使用率 | vcpu 分割比率 | GPU 使用率 | GPU 分割比率 | 記憶體使用率 | 記憶體分割比率 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | 命名空間 1 | 0.242 | 0 | 0.125 | 0 | 0.205 | 0.227 |
| Pod 2 | 命名空間 2 | 0.277 | 0 | 0.375 | 0 | 0.287 | 0.318 |
| Pod 3 | 命名空間 1 | 0.242 | 0 | 0.25 | 0 | 0.205 | 0.227 |
| Pod 4 | 命名空間 2 | 0.242 | 0 | 0.25 | 0 | 0.205 | 0.227 |
| 未使用的 | 未使用的 | 0 | | | | 0.098 | |
| | | 1 | 0 | 1 | 0 | 1 | 1 |
## 步驟 4：計算分割成本和未使用的成本
分割成本
根據 Kubernetes Pod 配置的 CPU 和記憶體用量，EC2 執行個體成本的每次使用費用分配
未使用的執行個體成本
執行個體上未使用的 CPU 或記憶體資源的成本
`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`
【注意：未使用的成本 = 未使用的使用率比率 \$1 資源總計 \$1 資源每小時成本】
**表 4 - 叢集內執行的所有 Pod 每小時計算的分割和未使用的成本摘要**
| Pod 名稱 | 命名空間 | 分割成本 | 未使用的成本 | 總成本 |
| --- | --- | --- | --- | --- |
| Pod 1 | 命名空間 1 | 1.85 美元 | 0.06 美元 | 1.91 美元 |
| Pod 2 | 命名空間 2 | 3.18 美元 | 0.09 美元 | 3.26 美元 |
| Pod 3 | 命名空間 1 | 2.35 美元 | 0.06 美元 | 2.41 美元 |
| Pod 4 | 命名空間 2 | 2.35 美元 | 0.06 美元 | 2.41 美元 |
| 總計 | | | | 10 美元 |
# 在 EKS 中使用 Kubernetes 標籤進行成本分配
分割成本分配資料支援 Kubernetes 標籤作為 Amazon EKS 叢集的成本分配標籤。雖然這些標籤會自動匯入為使用者定義的成本分配標籤，但它們需要在管理帳戶層級啟用。啟用後，您可以使用它們來使用成本中心、應用程式、業務單位和環境等自訂屬性，將成本和用量報告 (CUR) 中的 Pod 層級成本歸納。
此功能可協助組織在跨團隊、專案或部門的共用 EKS 環境中準確追蹤和分配成本。使用 Kubernetes 標籤，您可以根據您的特定業務需求和組織設計來配置 Kubernetes 成本。
## 先決條件
將 Kubernetes 標籤與分割成本分配資料搭配使用的先決條件：
+ 您需要在 AWS Billing and Cost Management 主控台中啟用分割成本分配資料。這必須在管理帳戶層級啟用。如需詳細資訊，請參閱[啟用分割成本分配資料](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html)。
+ 您需要要追蹤分割成本分配資料的 EKS 叢集。這可以是現有的叢集，也可以建立新的叢集。如需詳細資訊，請參閱《[Amazon EKS 使用者指南》中的建立 Amazon EKS 叢集](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)。 **
+ 您必須在 EKS 叢集中將標籤指派給 Pod。如需如何在 Kubernetes 中建立標籤的詳細資訊，請參閱 *Kubernetes 文件*中的[標籤和選取器](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)。
## 在 EKS 中使用 Kubernetes 標籤
分割成本分配資料支援每個 Pod 最多 50 個 Kubernetes 標籤，這些標籤會在匯入為成本分配標籤之前依字母順序排序。超過前 50 個的所有標籤都會自動捨棄。如果您需要在達到 50 個標籤限制後新增新的成本分配標籤，您必須先移除現有的標籤，並確保您的新標籤在按字母順序排序時落在前 50 個標籤內。
**注意**
有些 AWS 受管服務會自動將標籤新增至 EKS Pod。這些標籤會計入每個 Pod 的 50 個標籤限制，並會出現在您的成本分配標籤頁面上。
雖然 Kubernetes 標籤沒有大小限制，但成本分配標籤具有特定的字元限制：標籤索引鍵為 128 個字元，標籤值為 256 個字元。超過這些字元限制的標籤將被捨棄，不會顯示為成本分配標籤。基於成本分配目的，建議建立遵循這些字元限制的標籤。
匯入的 Kubernetes 標籤會顯示為成本分配標籤，且必須在付款人帳戶層級啟用。如需成本分配標籤和啟用的詳細資訊，請參閱[使用使用者定義的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)。適用下列成本分配標籤限制：每個資源 50 個使用者定義標籤，每個付款人帳戶 500 個使用者定義標籤。系統產生的標籤不會計入這些限制。
**注意**
在您建立使用者定義的標籤並將其套用至資源後，標籤索引鍵最多可能需要 24 小時才會出現在您的成本分配標籤頁面上。啟用標籤後，可能需要額外 24 小時才會變成作用中。
## 管理 Kubernetes 標籤和成本分配標籤
您可以在 EKS 中新增、刪除和編輯 Kubernetes 標籤，以及停用相關聯的成本分配標籤。以下說明每個動作的預期行為。
**新增標籤**
您可以將新的 Kubernetes 標籤新增至 Pod。如果未達到標籤限制 50，則會匯入新標籤，並以成本分配標籤的形式提供，然後可以啟用。不過，如果已達到 50 的限制，即使新標籤落在前 50 個標籤的字母排序順序內，也不會匯入新標籤。您必須先停用現有的成本分配標籤，才能匯入新的標籤。
**編輯標籤**
Kubernetes 不允許您編輯標籤金鑰。若要變更標籤索引鍵，您必須將其移除並新增標籤。不過，您可以編輯標籤值，這些值將反映在您的下一個 CUR 中。
**刪除標籤**
您可以從 EKS Pod 移除標籤。請注意，移除標籤不會自動停用其相關聯的成本分配標籤。分割成本分配資料將繼續填入 CUR，直到您明確停用成本分配標籤為止。
**停用成本分配標籤**
您可以停用從 Kubernetes 標籤建立的任何成本分配標籤。停用後，資料將不再填入各自的資料欄中，且資料欄將從下個月的 CUR 中刪除。
## 成本分配的 Kubernetes 標籤管理最佳實務
Kubernetes 標籤在共用成本分配建模方面提供很大的靈活性。為了最大化此功能的潛力，我們建議您遵循這些最佳實務，以最佳化您的成本管理方法。
**了解標籤限制**
50-label-per-pod 限制是根據字母排序。成本分配只會匯入前 50 個按字母順序排列的標籤。若要確保包含關鍵標籤，請仔細規劃標籤命名，以確保按字母順序排序時，重要的標籤會出現在前 50 內。
**下列字元限制條件**
AWS 成本分配標籤有下列字元限制：
+ 標籤索引鍵：128 個字元
+ 標籤值：256 個字元
雖然 Kubernetes 允許較長的標籤，但任何超過這些限制的標籤都不會匯入。在這些限制內設計您的標籤，以確保成功追蹤成本分配。
**在容量為 時新增標籤**
當 Pod 達到 50 個標籤限制，而且您需要新增成本分配標籤時，請依照下列步驟執行：
1. 檢閱現有的標籤，並識別要停用的成本分配標籤。
1. 停用選取的標籤。
1. 新增成本分配標籤。
1. 確認新標籤落在前 50 個按字母順序排序的標籤內。
**注意**
請記住，成本分配只會使用前 50 個按字母順序排序的標籤。
# 將分割成本分配資料與 Amazon Managed Service for Prometheus 搭配使用
分割 Amazon EKS 的成本資料需要您從叢集收集和存放指標，包括記憶體和 CPU 用量。Amazon Managed Service for Prometheus 可用於此目的。
當您選擇加入分割成本分配資料，且您的 Amazon Managed Service for Prometheus 工作區開始接收兩個必要的指標 (`container_cpu_usage_seconds_total` 和 `container_memory_working_set_bytes`) 後，分割成本分配資料會識別指標並自動使用它們。
**注意**
兩個必要指標 (`container_cpu_usage_seconds_total` 和 `container_memory_working_set_bytes`) 存在於預設 Prometheus 湊集組態，以及 AWS 受管收集器隨附的預設組態中。不過，如果您自訂這些組態，請勿從 `container_cpu_usage_seconds_total`和 `container_memory_working_set_bytes`指標重新標記、修改或移除下列標籤：`name`、 `namespace`和 `pod`。如果您重新標記、修改或移除這些標籤，可能會影響指標的擷取。
您可以使用 Amazon Managed Service for Prometheus 從單一區域中的單一用量帳戶收集 EKS 指標。Amazon Managed Service for Prometheus 工作區必須位於該帳戶和區域中。對於您要監控成本的每個用量帳戶和區域，您需要一個 Amazon Managed Service for Prometheus 執行個體。您可以在 Amazon Managed Service for Prometheus 工作區中收集多個叢集的指標，只要它們位於相同的用量帳戶和區域即可。
下列各節說明如何將正確的指標從 EKS 叢集傳送至 Amazon Managed Service for Prometheus 工作區。
## 先決條件
使用 Amazon Managed Service for Prometheus 搭配分割成本分配資料的先決條件：
+ 您需要在 AWS Billing and Cost Management 主控台中啟用分割成本分配資料。如需詳細資訊，請參閱[啟用分割成本分配資料](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html)。選擇分割成本分配資料會在每個用量帳戶中建立服務連結角色，以查詢該帳戶中 Amazon EKS 叢集指標的 Amazon Managed Service for Prometheus。如需詳細資訊，請參閱[分割成本分配資料的服務連結角色](https://docs.aws.amazon.com/cost-management/latest/userguide/split-cost-allocation-data-SLR.html)。
+ 您需要要追蹤分割成本分配資料的 EKS 叢集。這可以是現有的叢集，也可以建立新的叢集。如需詳細資訊，請參閱《[Amazon EKS 使用者指南》中的建立 Amazon EKS 叢集](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)。 **
**注意**
您將需要 `EKS cluster ARN`、 `security group IDs`和至少兩個 `subnet IDs`（在不同可用區域中） 以供後續步驟使用。
（選用） 將 EKS 叢集的身分驗證模式設定為 `API`或 `API_AND_CONFIG_MAP`。
+ 您需要與 EKS 叢集位於相同帳戶和區域中的 Amazon Managed Service for Prometheus 執行個體。如果您還沒有，您可以建立一個。如需建立 Amazon Managed Service for Prometheus 執行個體的詳細資訊，請參閱《*Amazon Managed Service for Prometheus 使用者指南*》中的[建立工作區](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html)。
**注意**
您將需要`Amazon Managed Service for Prometheus workspace ARN`在後續步驟中使用 。
## 將 EKS 指標轉送至 Amazon Managed Service for Prometheus
擁有 EKS 叢集和 Amazon Managed Service for Prometheus 執行個體後，您可以將指標從叢集轉送到執行個體。您可以透過兩種方式傳送指標。
+ [選項 1：使用 AWS 受管收集器。](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#use-managed-collector)這是將指標從 EKS 叢集傳送至 Amazon Managed Service for Prometheus 的最簡單方法。不過，它有限制，最多每 30 秒只會抓取一次指標。
+ [選項 2：建立您自己的 Prometheus 代理程式。](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent)在這種情況下，您可以更好地控制抓取組態，但您必須在建立代理程式之後對其進行管理。
### 選項 1：使用 AWS 受管收集器
使用 AWS 受管收集器 (*抓取器*) 是將指標從 EKS 叢集傳送至 Amazon Managed Service for Prometheus 執行個體的最簡單方法。下列程序會逐步引導您建立 AWS 受管收集器。如需詳細資訊，請參閱《*Amazon Managed Service for Prometheus 使用者指南*》中的[AWS 受管收集器](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html)。
**注意**
AWS 受管收集器的最短湊集間隔為 30 秒。如果您有短期 Pod，建議將抓取器間隔設定為 15 秒。若要使用 15 秒的抓取器間隔，請使用選項 2 [建立您自己的 Prometheus 代理程式](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent)。
建立 AWS 受管收集器有三個步驟：
1. 建立抓取器組態。
1. 建立抓取器。
1. 設定 EKS 叢集以允許抓取器存取指標。
*步驟 1：建立抓取器組態*
若要建立抓取器，您必須具有抓取器組態。您可以使用預設組態，或建立自己的組態。以下是取得抓取器組態的三種方式：
+ 使用 CLI AWS 取得預設組態，方法是呼叫：
```
aws amp get-default-scraper-configuration
```
+ 建立您自己的組態。如需詳細資訊，請參閱《*Amazon Managed Service for Prometheus 使用者指南*》中的 [Scraper 組態](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration)說明。
+ 複製《*Amazon Managed Service for Prometheus 使用者指南*》中相同的 [Scraper 組態](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration)指示所提供的範例組態。
您可以編輯抓取器組態、修改抓取間隔或篩選抓取的指標，例如。
若要篩選抓取的指標，只包含分割成本分配資料所需的兩個指標，請使用下列抓取器組態：
```
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
```
擁有抓取器組態後，您必須進行 base64 編碼，以便在*步驟 2 *中使用。組態是文字 YAML 檔案。若要編碼檔案，請使用網站，例如 [https://www.base64encode.org/](https://www.base64encode.org/)。
*步驟 2：建立抓取器*
現在您有一個組態檔案，您需要建立您的抓取器。根據先決條件區段中概述的變數，使用下列 AWS CLI 命令建立抓取器。您必須將來自 EKS 叢集的資訊用於 **、** 和 ** 欄位，將 ** 取代為您在上一個步驟中建立的抓取器組態，並將 ** 取代為您的 Amazon Managed Service for Prometheus 工作區 ARN。
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn=,securityGroupIds=[],subnetIds=[]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration={workspaceArn=""}
```
記下`scraperId`在*步驟 3 中傳回以供使用的 *。
*步驟 3：設定 EKS 叢集以允許抓取器存取指標*
如果您的 EKS 叢集的身分驗證模式設定為 `API`或 `API_AND_CONFIG_MAP`，則您的湊集器將自動擁有正確的叢集內存取政策，而湊集器將可存取您的叢集。不需要進一步的組態，且指標應流向 Amazon Managed Service for Prometheus。
如果您的 EKS 叢集的身分驗證模式未設定為 `API`或 `API_AND_CONFIG_MAP`，您將需要手動設定叢集，以允許抓取器透過 ClusterRole 和 ClusterRoleBinding 存取您的指標。若要了解如何啟用這些許可，請參閱《*Amazon Managed Service for Prometheus 使用者指南*》中的[手動設定 EKS 叢集以進行抓取器存取](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup)。
一旦抓取器處於作用中狀態，請確認兩個指標 (`container_cpu_usage_seconds_total` 和 `container_memory_working_set_bytes`) 都已推送到您的 Amazon Managed Service for Prometheus 工作區。
```
awscurl --service="aps" --region="" "https://aps-workspaces..amazonaws.com/workspaces//api/v1/label/__name__/values"
```
輸出：
```
{
"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"
]
}
```
### 選項 2：建立您自己的 Prometheus 代理程式
如果您無法使用 AWS 受管收集器，或已經有自己的 Prometheus 伺服器，您可以使用自己的 Prometheus 執行個體做為代理程式，從您的 EKS 叢集抓取指標並將其傳送至 Amazon Managed Service for Prometheus。
如需如何使用您自己的 Prometheus 執行個體做為代理程式的詳細說明，請參閱《*Amazon Managed Service for* [Prometheus 使用者指南》中的使用 Prometheus 執行個體做為收集器](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-ingest-with-prometheus.html)。
以下是 Prometheus 湊集組態範例，其中包含分割成本分配資料所需的 Prometheus 伺服器湊集間隔和容器指標。如果您有短期 Pod，建議將預設 Prometheus 伺服器湊集間隔從 30 秒降至 15 秒。請注意，這可能會導致高 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
```
如果您遵循《*Amazon Managed Service for* [Prometheus 使用者指南》中的使用 Helm 從新的 Prometheus 伺服器設定擷取](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-metrics-new-Prometheus.html)，則可以更新您的湊集組態。
**更新您的湊集組態**
1. `my_prometheus_values_yaml` 從指南編輯 ，並在 `server`區塊中包含範例湊集組態。
1. 使用 *Amazon Managed Service for Prometheus 使用者指南*`prometheus-namespace`中的 `prometheus-chart-name`和 執行下列命令。
```
helm upgrade prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace -f my_prometheus_values_yaml
```
若要進一步了解`scrape_interval`或使用非全域 scrape\$1interval，請參閱 [Prometheus 湊集組態](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)。
或者，您可以使用具有 Prometheus Receiver、Prometheus Remote Write Exporter 和 AWS Sigv4 Authentication Extension 的 AWS Distro for OpenTelemetry 收集器，以實現對 Amazon Managed Service for Prometheus 的遠端寫入存取。
**注意**
設定 Prometheus 代理程式後，與 AWS 受管收集器不同，您需負責將代理程式保持在最新狀態並執行 以收集指標。
## 估算 Amazon Managed Service for Prometheus 成本
您可以使用 AWS 定價計算器來估計將 Amazon Managed Service for Prometheus 用於分割成本分配資料的成本。
**為您的預估值設定 Amazon Managed Service for Prometheus**
1. 在 https：//[https://calculator.aws/\$1/ ](https://calculator.aws/#/)開啟 AWS 定價計算器。
1. 選擇 **Create estimate (建立估計)**。
1. 在**新增服務**頁面上，在搜尋欄位中輸入 **Amazon Managed Service for Prometheus**，然後選擇**設定**。
1. 在**描述**欄位中，輸入預估的描述。
1. 選擇一個**區域**。
1. 選取**使用您的基礎設施詳細資訊計算成本**。此選項可讓您根據目前或提議的基礎設施設定，預估擷取、儲存和查詢範例成本。
1. 針對 ** EC2 執行個體數量**，輸入整個合併帳單系列 （包括所有帳戶和區域） 中所有叢集的 EC2 執行個體總數。如果您使用 AWS Fargate，請使用 Fargate 任務的數量做為 EC2 執行個體計數的代理。
1. 分割成本分配資料需要兩個指標： `container_cpu_usage_seconds_total`和 `container_memory_working_set_bytes`。對於**每個 EC2 執行個體的 Prometheus 指標**，請輸入 2。
1. 分割成本分配資料建議 15 秒的抓取間隔。針對**指標收集間隔 （以秒為單位）**，輸入 15。如果您使用不同的間隔 （例如 30 秒），請將此變更為您設定的間隔。
1. 分割成本分配資料不會對其他參數強加任何特定要求，因此請根據您的業務需求，為其餘輸入參數輸入適當的值。
1. 選擇**儲存並新增服務**。
# 搭配 Amazon CloudWatch Container Insights 使用分割成本分配資料
分割 Amazon EKS 的成本資料需要您從叢集收集和存放指標，包括記憶體和 CPU 使用量。Amazon CloudWatch Container Insights 可用於此目的。
選擇加入分割成本分配資料，並在 EKS 叢集上使用 EKS 可觀測性附加元件設定 CloudWatch 代理程式後，分割成本分配資料便會開始接收`ContainerInsights`命名空間中的兩個必要指標 `(pod_cpu_usage_total` 和 `pod_memory_working_set`)，並自動使用這些指標。若要檢視 EKS 的完整容器指標集，請參閱《[Amazon CloudWatch 使用者指南》中的 Amazon EKS 和 Kubernetes Container Insights 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html)。 *Amazon CloudWatch *
下列各節說明如何從 EKS 叢集傳送正確的指標，以分割成本分配資料。
## 先決條件
使用 Amazon CloudWatch Container Insights 搭配分割成本分配資料的先決條件：
+ 您需要在 AWS Billing and Cost Management 主控台中啟用分割成本分配資料。如需詳細資訊，請參閱[啟用分割成本分配資料](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html)。
+ 您需要要追蹤分割成本分配資料的 EKS 叢集。這可以是現有的叢集，也可以建立新的叢集。如需詳細資訊，請參閱《[Amazon EKS 使用者指南》中的建立 Amazon EKS 叢集](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)。 **
## 設定 Amazon CloudWatch Container Insights 轉送 EKS 指標
您需要設定 CloudWatch 代理程式，才能轉送 EKS 指標。您可以使用 [Amazon CloudWatch 可觀測性 EKS 附加元件或 Amazon CloudWatch 可觀測性 Helm Chart](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html)，在 EKS 叢集上安裝 CloudWatch 代理程式和 Fluent 位元代理程式。如需如何安裝和設定 CloudWatch 代理程式的詳細資訊，請參閱《[Amazon CloudWatch 使用者指南》中的安裝 Amazon CloudWatch 可觀測性 EKS 附加元件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html)。 *Amazon CloudWatch *
以下是 CloudWatch 代理程式和 EKS 附加元件所需的最低版本：
+ CloudWatch 代理程式版本：v1.300045.0
+ CloudWatch 可觀測性 EKS 附加元件版本：v2.0.1-eksbuild.1
## 估算 Amazon CloudWatch 成本
啟用此功能以將 Amazon CloudWatch Container Insights 與分割成本分配資料搭配使用，將兩個新指標新增至 Amazon CloudWatch Container Insights： `pod_cpu_usage_total`和 `pod_memory_working_set`。如需這些指標的詳細資訊，請參閱《[Amazon CloudWatch 使用者指南》中的 Amazon EKS 和 Kubernetes Container Insights 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html)。 *Amazon CloudWatch *
**了解與功能相關的成本**
1. 在 https：//[https://aws.amazon.com/cloudwatch/pricing/](https://aws.amazon.com/cloudwatch/pricing/) 開啟 Amazon CloudWatch 定價。
1. 導覽至**付費方案**區段。
1. 選擇**容器洞見**索引標籤。
1. 如需成本的詳細計算，請導覽至**定價範例**區段，並參閱**範例 13 - Container Insights for Amazon EKS 和 Kubernetes**。