A storage platform can have excellent authentication, accurate usage data and a perfectly good billing system—and still produce a confusing service if those pieces disagree about who the customer is and what they are allowed to do.
We keep coming back to the same conclusion while building ScaleStore: access, entitlements, quotas, usage and billing are one product loop.
Start with the thing the customer is allowed to do
Suppose a customer buys a plan with a defined storage entitlement. That commercial decision should eventually become something technical: which resources they can create, what scope their credentials have and which limits RGW will enforce.
If those steps are disconnected, drift is inevitable. The portal says one limit, the cluster enforces another, and billing has a third interpretation.
Billing software should not configure Ceph directly. Commercial plans should map to provider-side quota and usage controls through a clear, auditable path.
Temporary credentials are more than a security feature
Ceph RGW supports STS APIs for temporary credentials in supported configurations. Temporary credentials are attractive because they expire and can be scoped more narrowly than a long-lived key. But the operational value is just as important as the security value.
A temporary session has context: who asked for it, which role or policy constrained it, when it expires and which customer workflow created it. That makes it a better building block for delegated or interactive access than emailing another permanent secret around.
It also creates a product requirement. If the portal can issue temporary access, support and audit workflows must be able to reason about that session without exposing the secret itself.
Quotas sit between product and infrastructure
A quota is easy to describe as a number of bytes. In a commercial service it has several meanings at once.
- For the customer, it is part of the plan they bought.
- For RGW, it is an enforcement setting.
- For the provider, it is a capacity and abuse-control boundary.
- For support, it is a likely explanation when a write starts failing.
That is why quota state needs to be visible from more than one angle. A customer should understand their limit and current usage. An operator should know what is actually enforced provider-side.
Usage is only useful when you trust where it came from
Storage billing often looks simple: multiply used bytes by a price. The hard part is deciding what “used bytes” means, when the measurement was taken, whether it is current and which provider-side source produced it.
We prefer usage records that can be traced back to the operational path rather than numbers copied between systems without provenance. That does not require dumping low-level Ceph data into the customer interface. It does mean the platform should be able to explain how a commercial number was derived.
Once usage is trustworthy, it can serve several purposes: customer visibility, quota warnings, billing inputs, support and capacity planning.
Billing is downstream of identity and usage
An invoice line cannot be more reliable than the identities and usage records underneath it. If a resource cannot be unambiguously tied to the right customer and provider, the finance layer will eventually expose the ambiguity.
For that reason we think billing integration belongs late in the chain. First make customer identity, entitlement, enforcement and usage coherent. Then export the resulting commercial facts to whatever billing workflow the provider uses.
The loop has to close during support
The test is what happens when a customer says, “I cannot upload; I thought I still had capacity.”
A useful operator view should connect the customer to their active credentials or sessions, their entitlement, the quota being enforced, recent usage and the relevant diagnostic events. Not every detail belongs on one screen, but the system should have one consistent answer.
That is what we mean by one product loop. Not one giant database table or one monolithic service, but one model of the customer that stays coherent from access to invoice.