Storage quotas and chargeback are the two mechanisms a shared storage platform uses to keep consumption in line with what the organization can afford. A quota limits how much a tenant may store. Chargeback, or its lighter form showback, attributes the cost of what was stored to whoever stored it. Without either, a shared platform behaves like a free resource: usage grows without anyone weighing it against value, and the platform team is left explaining a capacity purchase nobody requested.
This post covers how quotas and cost allocation work on shared object storage, the models in common use and the design choices that decide whether teams accept the result.
Consolidating many teams onto one platform lowers unit cost, because capacity, hardware and operations are pooled. It also hides the cost from the people creating it. A project that would have had to justify its own storage purchase now only needs credentials. Data that would once have been cleaned up stays, because keeping it costs the project nothing.
Quotas and chargeback address different halves of the problem. A quota is a control: it stops one tenant from consuming capacity that others were counting on. Chargeback is a signal: it tells each tenant what their usage costs, so that keep-or-delete decisions are made by the people who know the data's value. Platforms that have only quotas tend to drift into quota-increase negotiations. Platforms that have only chargeback can still be filled by a single runaway job.
Cost allocation starts with choosing the unit. Stored capacity is the obvious one, and it is not the only driver of cost on object storage.
| Metric | What it captures | Caveat |
|---|---|---|
| Logical capacity stored | Bytes the tenant wrote | Simple and predictable, ignores protection overhead |
| Raw capacity consumed | Bytes on disk after replication or erasure coding | Reflects real cost, varies with the protection policy chosen |
| Object count | Metadata load | Matters for workloads with many small objects |
| Noncurrent versions and locked data | Capacity held by versioning and retention | Often invisible to the tenant unless reported separately |
| Request volume | Load on the platform | Hard for tenants to predict, rarely worth billing internally |
| Replicated copies at other sites | Capacity at each additional location | Should follow the tenant's own resilience choice |
Most internal platforms settle on capacity as the billing unit, measured as a monthly average, with protection level and number of sites reflected in the rate. Object count and requests are tracked for capacity planning and used for conversations with outlier tenants.
Versioning deserves particular care. A tenant who enables versioning and overwrites data frequently can hold several times the capacity they believe they are using. Reporting current and noncurrent data as separate lines prevents a surprise, as the post on S3 versioning costs explains.
Quotas can be hard or soft. A hard quota rejects writes once the limit is reached. A soft quota raises an alert and lets writes continue. Hard quotas protect the platform and can break an application at an inconvenient moment, so they suit development and test tenants and workloads with predictable growth. Soft quotas with escalating alerts, at 80, 90 and 100 percent, suit production workloads where a failed write is worse than an overrun.
The level at which quotas apply matters as much as their size. Setting them per account or tenant gives each team one number to manage and leaves the split between buckets to them. Quotas should also be set with reference to the platform's real free capacity. If the sum of all quotas greatly exceeds what is installed, the quotas are not protecting anything. Some overcommitment is normal, and it should be a known figure.
Showback reports each tenant's usage and its notional cost without moving money. Chargeback transfers the cost to the tenant's budget. Showback is far easier to introduce. It needs no agreement with finance on transfer pricing, and it produces most of the behavioral effect, since teams that see a monthly figure against their name start asking what it consists of.
Moving to full chargeback makes sense when storage is a large enough cost to warrant the accounting effort, or when the platform is funded by its consumers. It requires a rate that is stable for at least a budget year, a clear statement of what the rate includes and a way for tenants to forecast their bill.
A defensible rate is the platform's total annual cost divided by the capacity expected to be sold. Total cost includes hardware depreciation, software, support, power, space, network and the staff who run it. The divisor should be planned consumed capacity, not installed capacity, because a platform never runs full, and headroom has to be paid for by someone.
Differentiated rates can reflect real cost differences: a higher rate for data kept at two sites than at one, or for a higher-durability protection policy. Rates should not be so finely differentiated that tenants cannot predict them. Two or three service classes, as described in the post on storage service levels, are usually enough. The cost model behind the rate is the same one used in a storage replacement business case.
Three things reliably cause tenants to reject cost allocation. The first is figures they cannot reconcile, where the report shows more capacity than their own tools do, usually because of versions, incomplete multipart uploads or protection overhead. The second is rates that change mid-year. The third is being charged for something they cannot control, such as platform headroom presented as a separate line. Each is avoidable with clear definitions published in advance and a report that breaks usage down by bucket.
Scality RING is multi-tenant, with accounts, buckets and policy-based isolation, which gives a shared platform the tenant boundary that quotas and cost allocation are attached to. It emits operational metrics and logs that the operator keeps locally, so capacity, object counts and growth can be tracked per account and per bucket and fed into whatever reporting or billing process the organization uses.
Erasure coding and replication are selectable per policy, and RING can span multiple sites, so differences in protection level and number of sites can be reflected in service classes with different rates. RING runs on standard x86 servers, and nodes can be added to a live system as tenants grow.
The purpose of both mechanisms is the same: to put the decision about what data is worth keeping in the hands of the people who can judge it, with the cost in front of them.