Accounts and tenancy
Objective
Section titled “Objective”Read this page to understand the single boundary every other rule is drawn around.
Requirements
Section titled “Requirements”- None
Instructions
Section titled “Instructions”The account is the boundary
Section titled “The account is the boundary”An account is the unit of tenancy, ownership, authorisation and billing. Every resource belongs to exactly one account, every invoice covers one account, and every credential authenticates into one account.
There is no cross-account access in v1. The ARN format reserves room for it without implying it exists.
Accounts and platform projects
Section titled “Accounts and platform projects”PROPOSED: an account maps to exactly one project in the underlying platform, one-to-one and permanently.
A design in which one account spans several projects, or one project serves several accounts, makes both authorisation and metering ambiguous: a usage record could not be attributed to one payer, and a policy could not be evaluated against one owner.
Visibility
Section titled “Visibility”A caller sees only resources in its own account.
A resource in another account is not merely forbidden, it is invisible: the response is byte-identical to the response for a resource that has never existed. Identifiers cannot be probed by observing which of them return a different error.
The complete rule, which every service implements identically:
- Another account’s resource, or no such resource → the service’s not-found error. The two cases are indistinguishable.
- This account, resource exists, policy denies →
UnauthorizedOperationorAccessDenied.
So a denial code confirms existence, and may therefore be returned only within the caller’s own account, where existence is not a secret from them.
Amazon EC2 behaves this way, returning InvalidInstanceID.NotFound for another
account’s instance, and matching it is both correct and compatible.
Account ids
Section titled “Account ids”PROPOSED: twelve decimal digits, never beginning with zero.
Twelve digits because customer tooling and policy documents assume that shape. A numeric id carries no information about the customer.
The leading-zero exclusion is deliberate. An id beginning with zero is parsed as a number by YAML, by spreadsheets, by JSON tooling and by type coercion in infrastructure tools, loses the zero, and then matches nothing. Allocating around the problem costs nothing; discovering it in a customer’s pipeline costs a day.
Account ids are never reused, including after closure.
Isolation
Section titled “Isolation”Resources in different accounts are isolated from one another.
OPEN (Michael): the isolation guarantee that can honestly be stated in v1. This depends on when per-tenant networking ships. Nothing is claimed until it does — an isolation claim that is not true is the single most damaging sentence this documentation could contain.
Lifecycle
Section titled “Lifecycle”| State | Meaning | API access | Resources |
|---|---|---|---|
pending | Created, not verified | Refused | None can exist |
active | Normal | Full | Running |
suspended | Non-payment or abuse | Refused, except reading the account | Retained, still charged |
closing | Closure requested | Refused | Being released |
closed | Closed | Refused | Destroyed |
A suspended account may still read its own state, so that a blocked customer can
find out why they are blocked. Every other action returns AccountSuspended
with HTTP 403.
OPEN (Michael): how long a suspended account is retained before closure, and the notice given before anything is destroyed. A customer whose data is about to be deleted is owed a precise answer.
OPEN (Michael): the retention period for records kept after closure — invoices, tax records and identity details — which is a legal question.
Go further
Section titled “Go further”- ARNs and identifiers
- Errors
- What is a Shelf Cloud account?