Allocations

Allocations are named budgets that organization admins create and share with groups. They are denominated in U.S. dollars or in a custom unit such as core-hours, GPU-hours, or service credits. Under the flexible allocation system, every cloud resource bills an allocation through its resource group.

Navigation

In the sidebar, under Monitor, click Allocations. The page has three tabs:

• My allocations — allocations shared with you. Organization admins see every allocation here.
• All allocations — every allocation in the organization (organization admins only).
• Units — custom units and their SKUs (organization admins only).

Concepts

Managed allocations

A managed allocation is denominated in U.S. dollars and is rated by the platform. Cloud resources, Kubernetes namespaces, and AI usage bill managed allocations. This is the type you'll use for most budgets.

Custom allocations

A custom allocation uses a custom unit such as core-hours. Usage reaches it through usage events posted by the API, the CLI, or an integration such as slurm-tracker. A custom unit can be rated into USD (it then has a cost per unit) or be a pure consumption unit that tracks raw quantities. Cloud resources can only bill allocations rated in USD.

Used and Estimated

• Used — confirmed spend: invoiced cloud costs imported from your cloud providers plus rated usage events.
• Estimated — Used plus real-time estimates for running resources that haven't been invoiced yet (USD allocations only).

If the Allocation Start Date policy is set, both only count spend since the most recent occurrence of that date. Otherwise they count all time.

Parent allocations

An allocation can be nested one level under a parent allocation. A parent's Used includes its children of the same unit, a frozen parent blocks work charged to its children, and a parent's shutdown threshold also shuts down its children's resources. Parents can currently only be set with the CLI (--parent) or the API.

Creating an allocation

Click Add allocation and fill in:

Name

A unique name in your organization. The name is fixed after creation. Cloud costs tagged with a project tag that matches a managed allocation's name (ignoring case) are also billed to that allocation. This project tag matching is legacy and deprecated, and will not be supported in a future release; use resource groups instead. See Cost Attribution.

Type

Managed (USD) or Custom unit. For a custom unit, select the Unit. If none exist, create one on the Units tab first.

Total budget

The budget in the allocation's unit. Decimals are allowed; negative values are not. A budget of 0 means the allocation has no budget: resource groups on it can't start anything new until you set a total. It does not mean unlimited.

Allowed resource types

Managed allocations only. Restrict what the allocation can pay for: AWS, Azure, Google, Oracle, OpenStack, Kubernetes, and AI. Leave All types selected for no restriction. Resource groups on a restricted allocation only appear on matching resource forms, and resources of other types can't be created or moved onto them.

Sharing an allocation

Only organization admins can see a new allocation until it's shared. Open the allocation's row menu and click Manage permissions, then grant a group, or the whole Organization, one of these levels:

• Read — view the allocation and its budget.
• Use — bill the allocation: create resource groups on it, move resource groups onto it, post usage events, and use it for AI requests.
• Admin — Use, plus edit the allocation's total and allowed resource types.

Threshold emails for an allocation go to the members of the groups it's shared with.

How usage reaches an allocation

Viewing usage

The allocations table shows each allocation's Total, Used, Estimated, Remaining, and % Used, and can be filtered by budget status (Over budget, Approaching limit, Within budget). Click an allocation to open its details page, which also lists the Associated resource groups it funds. The Usage events tab lists individual usage events.

To chart spend over time by type, user, or SKU, use Monitor > Reports. See Allocation Cost Dashboard.

Editing an allocation

Open the allocation's row menu and click Edit allocation to change its Total and, for managed allocations, its Allowed resource types. The name, type, and unit are fixed. Changing the total re-arms threshold emails, so users are notified again when the new budget fills up.

Deleting an allocation

Open the allocation's row menu and click Delete. You can't delete an allocation while resource groups bill it; change their allocation or delete them first.

Deleting an allocation also deletes its usage events and costs, and clears it as the default allocation on any cloud account. If it has cloud usage, those costs show as "unknown" afterwards, so export anything you need first.

Units and SKUs

On the Units tab, create custom units for non-dollar budgets.

• Track usage in USD — when on, usage is rated into dollars using the unit's Cost per unit and its pricing rules, which can change over time without rewriting past usage. When off, the unit is a consumption unit that tracks raw quantities.
• SKUs — the billable items within a unit, for example SLURM_NODE_HOUR. Each SKU has a rate multiplier (1× by default) with its own history. Usage events reference a SKU code, and the SKU must belong to the allocation's unit.

A usage event's amount is its quantity × the SKU rate × the unit rate. A unit can't be deleted while allocations use it.

Recording usage events

Usage events can be posted only to custom allocations, by users with Use or Admin on the allocation. Each event carries a quantity (greater than zero), a start and end time, and a SKU code. Only organization admins can attribute usage to another user. See pw billing allocations usage post.

CLI

The pw billing commands manage allocations, units, and SKUs:

• pw billing allocations — ls, get, create, update, rm, permissions, usage, and report.
• pw billing units and pw billing skus.

Tracking Slurm usage

If your organization runs Slurm-managed HPC clusters, the slurm-tracker CLI can post usage from those clusters directly into custom allocations. It runs on a Slurm login or controller node (typically as a cron job every few minutes), maps each Slurm account to an allocation and each Slurm partition to a SKU, and records core-hour consumption as usage events.

See the slurm-tracker README for installation, configuration, and the account-to-allocation mapping format.