GPU cost attribution

23 of 63 provisioned GPUs have no pod requesting them, $100,846/mo

What to do.Scale the affected node groups down to the number of GPUs actually requested. Where a node group exists for burst capacity, set its floor to zero and let the cluster autoscaler bring it up on a pending pod.

10 tagged non-production instances run continuously, $6,495/mo

What to do.Stop non-production instances outside working hours with an EventBridge schedule or an autoscaler floor of zero. GPU instances should be stopped rather than resized, because the accelerator is the entire cost.

Commitment purchased and not consumed: $1,216/mo of Reserved Instance capacity and $760/mo of Savings Plan commitment

What to do.Sell unused Standard RIs on the Reserved Instance Marketplace where the term allows, or move workloads onto the committed instance families so the commitment is consumed. Savings Plan commitments cannot be sold; the recovery is to shift eligible usage onto them before the term ends.

14 production GPU instances run continuously at on-demand rates, $232,885/mo

Assumption.The recoverable figure assumes a 20% rate reduction from a one-year no-upfront Compute Savings Plan, and assumes this capacity is still wanted twelve months from now. Verify the current discount for these families against AWS pricing before committing; if the workload is being migrated or retired inside the term, this finding does not apply.

What to do.Size a Compute Savings Plan to the observed floor of GPU usage, not to the peak. Commit to the level that has been running every day of the period and leave the rest on demand.

9 untagged instances read as non-production and run continuously, $11,916/mo

Assumption.These resources carry no Environment tag. Each is classified from its account, its name, or its instance family, and the signals are listed per resource below. The finding holds if the client confirms the classification; strike any row that is wrong and the total falls by that row's cost.

What to do.Confirm the classification, tag the resources so this stops being an inference, then schedule them off outside working hours.

4 EBS volumes and snapshots billed for the full period with no associated compute, $320/mo

Assumption.A CUR does not carry EBS attachment state, so this is inferred from a volume billing every day of the period while nothing in the account consumed compute hours against it. Confirm with `aws ec2 describe-volumes --filters Name=status,Values=available` before deleting anything. Snapshots that are the only copy of a dataset are not waste regardless of what the billing says.

What to do.Snapshot then delete volumes confirmed as available. For snapshots, apply a lifecycle policy rather than deleting by hand.

$22,326/mo on NVIDIA V100 (p3), superseded silicon

What is missing.Whether a newer family is cheaper for these workloads depends on model size, precision, memory footprint and batch size. None of that is in a Cost and Usage Report. Closing this gap needs one benchmark run of the real workload on a current-generation instance, measuring throughput per dollar rather than utilization. That is a day of work per distinct workload and it is the only thing that will settle it.

What to do.Benchmark the largest single workload on a current-generation instance before changing anything. Do not migrate a fleet on the strength of a spec sheet.

$482,302/mo of GPU spend has no utilization telemetry (100% of GPU spend)

What is missing.No per-GPU utilization data exists for these instances, so no statement can be made about whether the silicon did work. Closing this gap means running the NVIDIA DCGM exporter with profiling metrics enabled and scraping DCGM_FI_PROF_SM_ACTIVE and DCGM_FI_PROF_PIPE_TENSOR_ACTIVE into Prometheus. Note that DCGM_FI_DEV_GPU_UTIL, the metric on most default dashboards, does not close this gap: it reports whether a kernel was resident, not how much of the chip it used. On a T4 measured on 2026-09-04, a workload reporting 20% GPU utilization was using 0.2% of the streaming multiprocessors.

What to do.Deploy the DCGM exporter with container labelling enabled (--container-labels), which is off by default and is what makes per-pod attribution possible. Two weeks of data is enough to size the next engagement.

Showing the 25 largest of 40 resources. The full list is in the machine-readable findings file that accompanies this report.

$160,357/mo of GPU capacity is claimed by a pod but has no utilization data

What is missing.A pod holding a GPU proves the accelerator is reserved, not that it is busy. Whether these GPUs are doing work needs DCGM_FI_PROF_SM_ACTIVE and DCGM_FI_PROF_PIPE_TENSOR_ACTIVE scraped per pod, which requires the DCGM exporter with --container-labels enabled. That flag is off by default, which is why these metrics are usually missing even in clusters that already run the exporter.

What to do.Deploy the DCGM exporter with container labelling, scrape for two weeks, then re-run this audit. Nothing should be resized before that data exists.