Copy page

Business models

Cloud Infrastructure / IaaS

The cloud infrastructure pricing pattern: customers consume resources by the hour (or minute, or second), get steep discounts when they commit to reserved capacity in advance, and operate across many regions and many instance types - each with its own published rate. The economic shape rewards customers who commit (predictable revenue), while still serving on-demand workloads at higher unit prices.

Real-world examples. AWS (EC2 hourly + Reserved Instances + Savings Plans + Spot), Hetzner Cloud (hourly with monthly cap), Linode, Vultr, Cloudflare Workers (per-request CPU-time), Fly.io (per-second compute), DigitalOcean Droplets, Scaleway. Common shape: published per-region per-instance-type rate card, three pricing options per resource (on-demand, 1-year reserved, 3-year reserved), per-second billing granularity, monthly cap on hourly accumulation, complex enterprise contracts overlaying everything for top accounts.

The shape of the problem

Cloud infrastructure billing combines almost every operational complexity at once:

• Catalog scale. A real cloud has 200+ instance types × 30+ regions × 3 commitment tiers = 18,000+ priced SKUs. Modeling each as a separate product is operationally untenable.
• Three commitment tiers per SKU. On-demand ("pay for what you use"), Reserved ("commit to 1-3 years for a steep discount"), Spot ("we can interrupt you anytime, deep discount"). The same physical resource flows through different billing paths depending on which contract the customer holds.
• Monthly cap on hourly accumulation. Hetzner's classic model: pay €0.012/hour for a CX22 instance, but cap the monthly bill at €4.51 (the equivalent of ~376 hours / a "monthly equivalent"). After the cap, additional hours that month are free.
• Reserved capacity that customers buy upfront. Customer pays $X today for the right to consume Y instance-hours of a specific SKU over 1-3 years. The reservation must be drawn down by matching usage events; unused reservation typically expires worthless or partially refundable.
• Enterprise contract overlays. Top customers negotiate global discounts, custom commitments, dedicated hardware pricing - which override the standard rate card across the entire account.
• Per-second billing granularity. Resource usage is measured in seconds; the invoice rounds to whatever granularity the SLA mandates. Aggregator behavior matters here.

Kontorion blueprint

Concern	Kontorion primitive
200+ instance types × 30+ regions	Keyed product per resource family, key = region/instance_type
On-demand pricing	Standard price per (product, price_key)
Spot pricing	Separate price with metadata.commitment_type: spot and dynamic rate_expression
Monthly cap on hourly accumulation	rate_expression referencing aggregated hours, capped at monthly equivalent
Per-second granularity	Usage events with fractional value (value: 3600 = 1 hour)
Enterprise contract overlay	Customer price overrides per (customer, product, key)

Build it

1. Define the compute product

Code
curl -X POST https://api.kontorion.eu/v1/products \
  -H "Authorization: Bearer sk_live_..." \
  -d '{
    "name": "Compute Instance Hours",
    "type": "USAGE",
    "price_key_label": "instance_sku",
    "default_price_key": null,
    "unmatched_price_key_policy": "reject",
    "tax_category": "DEFAULT"
  }'

unmatched_price_key_policy: "reject" is the right choice for infrastructure - if the catalog doesn't have a SKU, the bill should bounce loudly, not silently lose revenue.

2. Add prices for instance types and regions

The price key encodes both the region and the instance type:

Code
# US East 1, m5.large, on-demand: $0.096/hour
curl -X POST https://api.kontorion.eu/v1/prices \
  -H "Authorization: Bearer sk_live_..." \
  -d '{
    "product_id": "prod_compute",
    "plan_id": "plan_on_demand",
    "billing_interval": "monthly",
    "billing_interval_count": 1,
    "currency": "USD",
    "price_key": "us-east-1/m5.large",
    "display_name": "m5.large (US East 1) - on-demand",
    "list_price": "9.60",
    "tiers": [{ "up_to": null, "unit_amount": "9.60" }]
  }'

# Same SKU in Frankfurt, slightly more expensive due to local cost structure
curl -X POST https://api.kontorion.eu/v1/prices \
  -H "Authorization: Bearer sk_live_..." \
  -d '{
    "product_id": "prod_compute",
    "plan_id": "plan_on_demand",
    "billing_interval": "monthly",
    "billing_interval_count": 1,
    "currency": "USD",
    "price_key": "eu-central-1/m5.large",
    "display_name": "m5.large (Frankfurt) - on-demand",
    "list_price": "10.60",
    "tiers": [{ "up_to": null, "unit_amount": "10.60" }]
  }'

# c5.xlarge in US East 1, on-demand: $0.17/hour
curl -X POST https://api.kontorion.eu/v1/prices \
  -H "Authorization: Bearer sk_live_..." \
  -d '{
    "product_id": "prod_compute",
    "plan_id": "plan_on_demand",
    "billing_interval": "monthly",
    "billing_interval_count": 1,
    "currency": "USD",
    "price_key": "us-east-1/c5.xlarge",
    "display_name": "c5.xlarge (US East 1) - on-demand",
    "list_price": "17.00",
    "tiers": [{ "up_to": null, "unit_amount": "17.00" }]
  }'

For 18,000 SKUs, this is a script run from your inventory system - one POST per SKU per region per commitment tier.

3. Customer subscribes to on-demand pricing

Code
curl -X POST https://api.kontorion.eu/v1/subscriptions \
  -H "Authorization: Bearer sk_live_..." \
  -d '{
    "customer_id": "cust_acme",
    "plan_id": "plan_on_demand",
    "items": [
      { "product_id": "prod_compute", "quantity": 1 }
    ]
  }'

4. Network meters consumption

The infrastructure metering daemon emits events for every running instance, every aggregation window:

Code
curl -X POST https://api.kontorion.eu/v1/transaction/usage-event \
  -H "Authorization: Bearer sk_live_..." \
  -d '{
    "customer_id": "cust_acme",
    "subscription_id": "sub_acme",
    "product_id": "prod_compute",
    "metric_key": "instance_seconds",
    "price_key": "us-east-1/m5.large",
    "value": 3600,
    "timestamp": "2025-04-15T14:00:00Z",
    "idempotency_key": "i-0abc123_2025041514",
    "metadata": {
      "instance_id": "i-0abc123",
      "az": "us-east-1a"
    }
  }'

Events are submitted with the instance ID as part of the idempotency_key plus the hour - safe against duplicate submissions, distinct per (instance, hour).

5. Enterprise contract: 15% global discount on all compute for one customer

Code
# Iterate over the customer's most-used SKUs and post overrides as
# CUSTOMER_OVERRIDE prices, which take precedence over the catalog price
# for this customer only.
for sku in us-east-1/m5.large us-east-1/m5.xlarge us-east-1/c5.xlarge eu-central-1/m5.large; do
  curl -X POST https://api.kontorion.eu/v1/prices \
    -H "Authorization: Bearer sk_live_..." \
    -d "{
      \"kind\": \"CUSTOMER_OVERRIDE\",
      \"customer_id\": \"cust_acme\",
      \"product_id\": \"prod_compute\",
      \"price_key\": \"$sku\",
      \"currency\": \"USD\",
      \"billing_interval\": \"monthly\",
      \"billing_interval_count\": 1,
      \"discount_percent\": 15,
      \"effective_from\": \"2025-04-15T00:00:00Z\",
      \"effective_to\": \"2026-04-15T00:00:00Z\"
    }"
done

The override applies multiplicatively to the catalog price (or replaces it with a flat rate, depending on the override shape). Reserved capacity rates can be overridden separately for true enterprise contracts.

Variations

• Hetzner-style monthly cap. Replace the simple per-second price with a rate_expression that references the aggregated hours and caps the monthly billable amount at the published cap. Once the customer hits the cap, additional hours produce zero billable amount but still count for analytics.
• Spot pricing with dynamic rates. Add a metadata.commitment_type: spot price with a rate_expression referencing the current spot price (fed in via custom field on the subscription or on the event). Spot interruptions create a usage_event.dropped audit row.
• Per-second billing. Send events with value in seconds (or fractional hours); aggregator sums to whatever granularity the invoice rounds to.
• Egress / bandwidth. Add a separate keyed product for network_bytes_egressed keyed by source/destination region pair. Same pattern, different metric.
• Storage with tiered IOPS. The storage product uses STAIRCASE tiers on provisioned_iops value, plus a separate metered product for accessed-bytes.

What you don't have to build

• 18,000-SKU catalog as 18,000 product records (one keyed product replaces them)
• Per-second granularity reconciliation (aggregator sums events at any precision)
• Enterprise discount overlay across thousands of SKUs (customer price overrides do it per-SKU or globally)
• Spot price interruption auditing (usage_event.dropped captures every interruption)

Next steps

• Pricing - Keyed Prices - the multi-SKU catalog pattern
• Customer Price Overrides - enterprise contract overlays
• Usage Metering - per-second event ingest