These divided costs are enriched with tags from nodes, pods, tasks, and volumes. You can use these tags to break down costs by any associated dimensions.
Compute
For Kubernetes compute allocation, a Kubernetes node is joined with its associated host instance costs. The node’s cluster name and all node tags are added to the entire compute cost for the node. This allows you to associate cluster-level dimensions with the cost of the instance, without considering the pods scheduled to the node.
Next, Datadog looks at all of the pods running on that node for the day. The cost of the node is allocated to the pod based on the resources it has used and the length of time it ran. This calculated cost is enriched with all of the pod’s tags.
Note: Only tags from pods and nodes are added to cost metrics. To include labels, enable labels as tags for nodes and pods.
All other costs are given the same value and tags as the source metric aws.cost.amortized
.
Persistent volume storage
For Kubernetes Persistent Volume storage allocation, Persistent Volumes (PV), Persistent Volume Claims (PVC), nodes, and pods are joined with their associated EBS volume costs. All associated PV, PVC, node, and pod tags are added to the EBS volume cost line items.
Next, Datadog looks at all of the pods that claimed the volume on that day. The cost of the volume is allocated to a pod based on the resources it used and the length of time it ran. These resources include the provisioned capacity for storage, IOPS, and throughput. This allocated cost is enriched with all of the pod’s tags.
AWS ECS on EC2
For ECS allocation, Datadog determines which tasks ran on each EC2 instance used for ECS. If you enable AWS Split Cost Allocation, the metrics allocate ECS costs by usage instead of reservation, providing more granular detail.
Based on resources the task has used, Datadog assigns the appropriate portion of the instance’s compute cost to that task. The calculated cost is enriched with all of the task’s tags and all of the container tags (except container names) running in the task.
AWS ECS on Fargate
ECS tasks that run on Fargate are already fully allocated in the CUR. CCM enriches that data by adding out-of-the-box tags and container tags to the AWS Fargate cost.
Data transfer
For Kubernetes data transfer allocation, a Kubernetes node is joined with its associated data transfer costs from the CUR. The node’s cluster name and all node tags are added to the entire data transfer cost for the node. This allows you to associate cluster-level dimensions with the cost of the data transfer, without considering the pods scheduled to the node.
Next, Datadog examines the daily workload resources running on that node. The node cost is allocated to the workload level according to network traffic volume usage. This calculated cost is enriched with all of the workload resource’s tags.
Note: Only tags from pods and nodes are added to cost metrics. To include labels, enable labels as tags for nodes and pods.
Network Performance Monitoring must be enabled on all AWS hosts to allow accurate data transfer cost allocation. If some hosts do not have Network Performance Monitoring enabled, the data transfer costs for these hosts is not allocated and may appear as an n/a
bucket depending on filter and group-by conditions.
Datadog supports data transfer cost allocation using standard 6 workload resources only. For custom workload resources, data transfer costs can be allocated down to the cluster level only, and not the node/namespace level.
Compute
For Kubernetes compute allocation, a Kubernetes node is joined with its associated host instance costs. The node’s cluster name and all node tags are added to the entire compute cost for the node. This allows you to associate cluster-level dimensions with the cost of the instance, without considering the pods scheduled to the node.
Next, Datadog looks at all of the pods running on that node for the day. The cost of the node is allocated to the pod based on the resources it has used and the length of time it ran. This calculated cost is enriched with all of the pod’s tags.
Note: Only tags from pods and nodes are added to cost metrics. To include labels, enable labels as tags for nodes and pods.
All other costs are given the same value and tags as the source metric azure.cost.amortized
.
Compute
For Kubernetes compute allocation, a Kubernetes node is joined with its associated host instance costs. The node’s cluster name and all node tags are added to the entire compute cost for the node. This allows you to associate cluster-level dimensions with the cost of the instance, without considering the pods scheduled to the node.
Next, Datadog looks at all of the pods running on that node for the day. The cost of the node is allocated to the pod based on the resources it has used and the length of time it ran. This calculated cost is enriched with all of the pod’s tags.
Note: Only tags from pods and nodes are added to cost metrics. To include labels, enable labels as tags for nodes and pods.
All other costs are given the same value and tags as the source metric gcp.cost.amortized
.
Agentless Kubernetes costs
To view the costs of GKE clusters without enabling Datadog Infrastructure Monitoring, use GKE cost allocation. Enable GKE cost allocation on unmonitored GKE clusters to access this feature set.
Limitations and differences from the Datadog Agent
- There is no support for tracking workload idle costs.
- The cost of individual pods are not tracked, only the aggregated cost of a workload and the namespace. There is no
pod_name
tag. - GKE enriches data using pod labels only and ignores any Datadog tags you add.
- The full list of limitations can be found in the official GKE documentation.
To enable GKE cost allocation, see the official GKE documentation.