Define Unit Cost Metrics

Why

Absolute cost is meaningless without business context. A 20% cost increase alongside 40% revenue growth is a success, not a failure. Traditional cost allocation tells you who owns the infrastructure cost, but not what it costs to serve a customer, process a transaction, or run a feature. Unit economics answers the question every executive eventually asks: “Are we getting more efficient as we scale, or just spending more?”

Cost Allocation vs Unit Economics
═══════════════════════════════════════════════════════════════

  Cost Allocation:
    "The Payments team spent $85K last month on AWS."
    → Useful for showback. Cannot answer efficiency.

  Unit Economics:
    "Cost per transaction = $0.0023 (down from $0.0031 in Q1)."
    → Connects spend to output. Proves scaling efficiency.

What

Define key unit cost metrics for your most important workloads — cost per transaction, cost per active user, cost per GB processed, or cost per revenue unit. This requires joining cloud billing data with business activity data (transactions, users, API calls).

How

Select Workloads and Business Drivers

Start with your top 3–5 workloads by spend. For each, identify the business metric that best represents “output”:

The first workload is the hardest. Subsequent ones follow the pattern. Choose a well-understood workload with reliable activity data for your first implementation.

Instrument Activity Metrics

You need a source of business activity volume. Where you get this depends on your architecture:

Option A — Application-level metrics (simplest):

Pull transaction counts, user counts, or request volumes from your existing observability stack (Datadog, Prometheus, CloudWatch custom metrics, Application Insights). Most applications already emit these.

Option B — OpenTelemetry with business context (most powerful):

Inject business context (tenant ID, tier, feature version) into request telemetry using OpenTelemetry Baggage. This enables per-customer, per-tier, and per-feature cost attribution.

OpenTelemetry Approach
═══════════════════════════════════════════════════════════════

  Request arrives with business context:
    POST /api/checkout
    Headers:
      x-tenant-id: customer-A
      x-tenant-tier: professional
      x-feature-id: v2.031

  OpenTelemetry propagates this as Baggage through
  every service in the request chain.

  Each service unpacks Baggage into Span Attributes:
    bucket.name = "my-bucket"
    tenant = "customer-A"
    tier = "professional"
    operation.type = "upload"

  Metrics aggregated by tenant + operation + resource
  → join with billing data → cost per tenant per operation

Option C — Database / data warehouse join:

If activity data lives in a separate system (CRM, product analytics, data warehouse), export it and join with billing data in your analytics layer.

Calculate Unit Cost

Formula: Unit Cost = Cloud Cost for Workload / Business Activity Volume

Example query (BigQuery / Athena):

SELECT
  DATE_TRUNC(billing_month, MONTH) AS month,
  workload_tag AS workload,
  SUM(billed_cost) AS total_cost,
  activity.volume AS activity_volume,
  ROUND(SUM(billed_cost) / activity.volume, 4) AS cost_per_unit
FROM billing_data b
JOIN activity_metrics activity
  ON b.workload_tag = activity.workload
  AND b.billing_month = activity.month
WHERE workload_tag = 'checkout-api'
GROUP BY month, workload
ORDER BY month

Build the Unit Economics Dashboard

Deliverable Checklist

• Top 3–5 workloads selected with business drivers
• Activity metric source identified per workload
• Activity data accessible and joinable with billing data
• Unit cost calculated for at least one workload
• Unit economics dashboard live with trend view
• Methodology documented (formula, data sources, refresh cadence)