CCM allocates costs of AWS ECS clusters as well as all Kubernetes clusters, including those managed through Elastic Kubernetes Service (EKS).

The following table presents the list of collected features and the minimal Agent and Cluster Agent versions for each.

1. Configure the AWS Cloud Cost Management integration on the Cloud Costs Setup page.
2. For Kubernetes support, install the Datadog Agent in a Kubernetes environment and ensure that you enable the Orchestrator Explorer in your Agent configuration.
3. For AWS ECS support, set up Datadog Container Monitoring in ECS tasks.
4. Optionally, enable AWS Split Cost Allocation for usage-based ECS allocation.
5. To enable GPU container cost allocation, install the Datadog DCGM integration.
6. To enable Data transfer cost allocation, set up Network Performance Monitoring. Note: additional charges apply

CCM allocates costs of all Kubernetes clusters, including those managed through Azure Kubernetes Service (AKS).

The following table presents the list of collected features and the minimal Agent and Cluster Agent versions for each.

1. Configure the Azure Cost Management integration on the Cloud Costs Setup page.
2. Install the Datadog Agent in a Kubernetes environment and ensure that you enable the Orchestrator Explorer in your Agent configuration.
3. To enable GPU container cost allocation, install the Datadog DCGM integration.

CCM allocates costs of all Kubernetes clusters, including those managed through Google Kubernetes Engine (GKE).

The following table presents the list of collected features and the minimal Agent and Cluster Agent versions for each.

1. Configure the Google Cloud Cost Management integration on the Cloud Costs Setup page.
2. Install the Datadog Agent in a Kubernetes environment and ensure that you enable the Orchestrator Explorer in your Agent configuration.
3. To enable GPU container cost allocation, install the Datadog DCGM integration.

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.

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 only through the standard 6 workload resources. If you use custom workload resources their data transfer costs may only be allocated down to the cluster level 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.

Compute

The cost of a host instance is split into two components: 60% for the CPU and 40% for the memory. If the host instance has GPUs, the cost is split into three components: 95% for the GPU, 3% for the CPU, and 2% for the memory. Each component is allocated to individual workloads based on their resource reservations and usage.

Costs are allocated into the following spend types:

Persistent volume

The cost of an EBS volume has three components: IOPS, throughput, and storage. Each is allocated according to a pod’s usage when the volume is mounted.

Note: Persistent volume allocation is only supported in Kubernetes clusters, and is only available for pods that are part of a Kubernetes StatefulSet.

Compute

The cost of a host instance is split into two components: 60% for the CPU and 40% for the memory. If the host instance has GPUs, the cost is split into three components: 95% for the GPU, 3% for the CPU, and 2% for the memory. Each component is allocated to individual workloads based on their resource reservations and usage.

Costs are allocated into the following spend types:

Compute

The cost of a host instance is split into two components: 60% for the CPU and 40% for the memory. If the host instance has GPUs, the cost is split into three components: 95% for the GPU, 3% for the CPU, and 2% for the memory. Each component is allocated to individual workloads based on their resource reservations and usage.

Costs are allocated into the following spend types:

Kubernetes

In addition to Kubernetes pod and Kubernetes node tags, the following non-exhaustive list of out-of-the-box tags are applied to cost metrics:

Conflicts are resolved by favoring higher-specificity tags such as pod tags over lower-specificity tags such as host tags. For example, a Kubernetes pod tagged service:datadog-agent running on a node tagged service:aws-node results in a final tag service:datadog-agent.

Persistent volume

In addition to Kubernetes pod and Kubernetes node tags, the following out-of-the-box tags are applied to cost metrics.

Amazon ECS

In addition to ECS task tags, the following out-of-the-box tags are applied to cost metrics.

Note: Most tags from ECS containers are applied (excluding container_name).

Data transfer

The following list of out-of-the-box tags are applied to cost metrics associated with Kubernetes workloads:

In addition, some Kubernetes pod tags that are common between all pods on the same node are also applied.

Kubernetes

In addition to Kubernetes pod and Kubernetes node tags, the following non-exhaustive list of out-of-the-box tags are applied to cost metrics:

Kubernetes

In addition to Kubernetes pod and Kubernetes node tags, the following non-exhaustive list of out-of-the-box tags are applied to cost metrics: