Methodology

-- Athena over CUR 2.0 (Parquet, Glue partition projection). One payer account,
-- one billing month. Nothing is filtered out: credits, tax and support stay in,
-- because the model has to reconcile to the invoice, not to a flattering subset.
WITH effective AS (
  SELECT
    line_item_usage_start_date                    AS ts,
    line_item_resource_id                         AS resource_id,
    line_item_product_code                        AS service,
    resource_tags['user_tenant']                  AS tenant_tag,
    resource_tags['user_namespace']               AS namespace_tag,
    -- Amortized effective cost. Unblended cost is wrong for unit economics by
    -- exactly your commitment discount, so it is never the basis.
    CASE line_item_line_item_type
      WHEN 'SavingsPlanCoveredUsage'  THEN savings_plan_savings_plan_effective_cost
      WHEN 'DiscountedUsage'          THEN reservation_effective_cost
      WHEN 'SavingsPlanUpfrontFee'    THEN 0        -- amortized into covered usage
      WHEN 'SavingsPlanRecurringFee'  THEN 0
      WHEN 'RIFee'                    THEN 0
      ELSE line_item_unblended_cost
    END                                           AS effective_cost
  FROM cur2.line_items
  WHERE billing_period = '2026-07'
)

-- Shared pool: effective cost with no tenant dimension of its own.
, shared_pool AS (
  SELECT date_trunc('hour', ts) AS h, namespace_tag, SUM(effective_cost) AS cost
  FROM effective
  WHERE tenant_tag IS NULL AND namespace_tag IS NOT NULL
  GROUP BY 1, 2
)

-- Weights come from the application's own request logs, hour by hour, because
-- the tenant mix inside a month is not the tenant mix of the month. Allocating
-- on a monthly total silently charges the night shift to the day shift.
, weights AS (
  SELECT date_trunc('hour', request_ts) AS h,
         namespace,
         tenant_id,
         SUM(cpu_core_seconds + ram_byte_seconds / 4.294967296e9) AS w
  FROM app.request_log            -- your logs. Never leaves your account.
  WHERE request_ts >= DATE '2026-07-01' AND request_ts < DATE '2026-08-01'
  GROUP BY 1, 2, 3
)

, shares AS (   -- per hour, per namespace, the shares sum to exactly 1.0
  SELECT h, namespace, tenant_id,
         w / SUM(w) OVER (PARTITION BY h, namespace) AS share
  FROM weights
)

SELECT s.tenant_id,
       SUM(p.cost * s.share) AS allocated_effective_cost
FROM shared_pool p
JOIN shares s ON s.h = p.h AND s.namespace = p.namespace_tag
GROUP BY 1
ORDER BY 2 DESC;

# Allocated GPU-hours per namespace. A pod holding a GPU is billed for it
# whether or not a kernel ever runs. 1-minute scrape interval assumed; state
# yours, because this divisor is the whole measurement.
sum by (exported_namespace) (
  count_over_time(DCGM_FI_DEV_FB_USED{exported_namespace!=""}[1h])
) / 60

# SM-active-weighted GPU-hours: the fraction of that held time a kernel was
# actually resident on the SMs.
#
# DCGM_FI_DEV_GPU_UTIL is NOT usable for this. It reads near 100% whenever any
# single kernel is resident, so a pod using one SM of 132 reports as saturated.
sum by (exported_namespace) (
  avg_over_time(DCGM_FI_PROF_SM_ACTIVE{exported_namespace!=""}[1h])
)