Metered access

Every request is checked before any storage work or decryption. A user who runs a script against your app hits a limit, not your bill.

What happens to every request

Step	What happens
Authenticates	Access keys, pre-signed URLs and your identity provider’s tokens resolve to a tenant, or 401. → S3 and identity
Rate-limits	A requests-per-second ceiling per tenant. Over it: 429 with a retry time.
Applies limits	Per-tenant write and read limits, below.
Counts	Reads, writes, refusals, bytes in and out, per tenant per day. Counted by the deployment, never taken from the client witnessed.
Records refusals	Your refused requests go on the public ledger, counted by kind witnessed.

Limits per tenant

Off until your deployment’s terms set them; each tenant can have its own.

Limit	Over it
Daily write budget (bytes per UTC day)	403 QuotaExceeded until midnight UTC
Largest object	413 EntityTooLarge
Daily read cap (GETs of an object per UTC day; a range read is one)	403 ReadQuotaExceeded until midnight UTC

• HEAD, listings and writes are never read-capped.
• Each refusal says the limit, the amount used and when it resets.
• A burst can’t overrun a limit.
• A limit bounds a tenant. Per-user limits inside one shared tenant are yours to set.

Exact rules: S3 compatibility.

Billed reads

A billed read is a successful GET of an object; a range read counts once. HEAD, listings, refusals and server errors are free.

• Off unless agreed: per read, per GB out, or both, in your deployment’s terms.
• One bill per deployment, broken down per tenant.

Reading your usage

On the deployment page: daily charts whose totals match the bill, plus the monthly statement. Each tenant can also read its own requests, bytes and limits for a period.