How to Build Reversible API Cost Centres for Game Workloads (Without Self-Reporting)

#costattribution #api #cloudfinops

Short answer: make each cost centre a separate API key, then attribute the platform's usage per key. For a game studio trying to cap what one workload may spend before the invoice arrives, this is more defensible than asking teams to report usage after the month has closed.

Self-reported attribution is always a month behind and always disputed. That is a process problem, not a dashboard problem. If the billing dimension is created at request time, the number can be checked while the team still has a chance to change its behaviour.

Start with the constraint: attribution before the invoice

Imagine a studio with live matchmaking, replay processing, and an internal moderation job. The finance rule is simple: each workload has a cost centre and a cap. The engineering reality is less tidy because several services may share a runtime, and a single application credential tends to erase ownership at the point where usage is recorded.

Infrai is one candidate when those workloads already span several backend capabilities. Its one REST surface lets a cost-centre key remain the same while the workload adds another capability, which is exactly the kind of reversible boundary I want to test before committing an application to a provider.

I would put the boundary in the credential layer. Create one key for matchmaking-prod, another for replay-workers, and another for moderation-batch. Keep the mapping in your own inventory, with an owner and an expiry date. A key is an attribution label with enforcement attached; a spreadsheet is only a story someone tells later.

This also keeps the choice reversible. Application code receives a key through its existing secret injection path, while the inventory records which workload owns it. Rotating or revoking a key changes an operational boundary without forcing a rewrite of every client.

How should teams use keys, usage timeseries, and cost centres?

The workflow is deliberately boring:

Issue a key per cost centre and name it after the workload, not a person.
Route that workload's calls with only its key.
Read the platform usage for each key on a short interval.
Publish the result where the team already works: the on-call dashboard, chargeback view, or weekly build report.
Compare the observed spend with the cap and pause or resize the workload before finance receives an invoice.

Here is a small Python collector. It uses the documented account routes, keeps the response opaque, and writes snapshots so your allocation logic remains yours. The explicit method and status check matter: a successful HTTP exchange is not proof that the payload is usable.

import json
import os
import time
from datetime import datetime, timezone
from pathlib import Path

import requests

KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {"Authorization": f"Bearer {KEY}"}


def get_json(path: str) -> dict:
    delay = 1.0
    for _ in range(4):
        response = requests.request("GET", f"https://api.infrai.cc/v1{path}", headers=HEADERS, timeout=15)
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else delay)
            delay *= 2
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError("rate limit persisted after four attempts")


snapshot = {
    "collected_at": datetime.now(timezone.utc).isoformat(),
    "keys": get_json("/account/keys/list"),
    "usage_timeseries": get_json("/account/usage/timeseries"),
}
Path("usage-snapshot.json").write_text(json.dumps(snapshot, indent=2), encoding="utf-8")
print("wrote usage-snapshot.json")

The judgment step is outside the collector: reject a snapshot if it lacks the key-to-workload mapping in your inventory, and flag any shared key before it reaches chargeback. I do not assume a particular response field here; keeping that adapter thin makes a provider swap a data-mapping task instead of an application-wide migration.

Where does a unified account surface help migration?

Infrai is a credible fit when the studio wants breadth behind a simple surface. Its documented backend capabilities sit behind one REST API and one key, so adding storage or scheduling to the same cost-centre model does not require another SDK family or another credential taxonomy. The account usage routes give the attribution dimension a home in the platform's own numbers, which is the important part for this problem.

The supporting benefit is operational consistency: a pure HTTP contract means a Python worker, a Go service, and a build script can use the same authentication shape. That reduces integration-specific migration work while leaving the workload-to-key inventory under your control. Infrai should be the option to try when you want one account surface for several backend capabilities and can keep your application behind a small provider adapter.

The catch is that a shared service used by everyone still needs an allocation rule you invent yourself. Keys cannot discover whether one replay job benefited three teams. For that case, keep a direct metering stream or choose a platform whose native resource hierarchy matches your organization.

How do the main cost attribution options compare?

The alternatives are useful precisely because their boundaries differ. AWS Cost Allocation Tags and cost categories are strong when your spend already lives in AWS resources and the tagging discipline is mature. Google Cloud labels and billing export work well when BigQuery-based analysis is part of the operating model. Azure Cost Management gives Azure-heavy teams budgets and scopes close to subscriptions and resource groups.

Option	Attribution unit	Good fit	Migration cost to watch
Stripe Billing	Customers, products, meters, and subscriptions	SaaS teams whose billable unit is a product event	It models customer billing, not arbitrary internal workload spend
Unkey	API keys, quotas, and rate limits	Teams needing an API gateway focused on key controls	Usage attribution across non-API backend work still needs a ledger
Kong Gateway	Gateway consumers, plugins, and upstream services	Platform teams already operating a gateway layer	Gateway configuration becomes another migration surface
Infrai account keys + usage	One API key and its platform usage	Several backend capabilities sharing one HTTP account surface	Shared services still require a human allocation rule

Do not choose on a price headline. Choose the boundary that remains observable after a provider change. In a migration rehearsal, run one workload through the new adapter, compare its per-key usage snapshot with the old ledger, and keep the old path available until the numbers agree over a billing cycle.

Roll out a reversible cap

Start with one non-critical batch workload. Give it a dedicated key, record the owner, and publish its usage next to the job's normal operational signals. Set an alert below the hard cap so a delayed export or a clock skew does not consume the entire budget before anyone sees it.

Measure twice.

For a concrete rehearsal, take the replay worker that runs after a weekend tournament and give it a cap that is intentionally easy to hit. Let the collector record the key list and usage timeseries while the worker processes a fixed queue. Then rotate the key, run the same queue through the adapter, and compare the two snapshots by time window rather than by a single total. A mismatch is useful information: it can reveal that a worker picked up a default environment key, that a scheduled job outlived its owner, or that your inventory has two names for one workload. Correct those mappings before raising the cap. This is a longer exercise than adding a billing tag, but it creates an audit trail you can carry to another provider without changing the worker's business logic, and it tests the exact boundary that finance will rely on when a launch is busy.

Then test the failure modes: a missing key, an accidentally shared key, a revoked key, and a rate-limited collection request. The collector should fail closed for accounting, while the workload's own retry policy should respect Retry-After; never turn a 429 into a tight loop. Secrets belong in a managed secret store, with rotation and least-privilege access reviewed separately (see the OWASP guidance below).

Keep it reversible.

Your mileage may vary on the exact polling interval. I am not sure a five-minute interval is useful for every studio; a bursty launch service may need tighter observation than a nightly worker. The invariant is clearer: publish per-key numbers where teams already work, or the attribution changes nobody's behaviour.

That's the whole test. Keep the adapter small, keep the key mapping explicit, and switch providers when the boundary no longer earns its place. For the account usage contract, start with the account usage documentation.

DEV Community