Glossary
Cloud provisioning
Cloud provisioning is the process of creating and configuring cloud resources, such as virtual machines, volumes, buckets and networks, and making them available to a user or application. In a cloud it is automated: a request through a portal, an API or an infrastructure-as-code tool produces a ready resource without manual work by an administrator.
Why provisioning matters for platform teams
Provisioning is the point where a platform either feels like a cloud or does not. A bucket delivered by API in seconds supports pipelines that create and tear down storage as part of every run. A bucket delivered by ticket in a week pushes teams toward public cloud accounts, shadow storage and copies nobody tracks.
It is also the point where policy is applied. Encryption, quotas, retention, replication and placement are cheapest to get right at creation time and expensive to fix afterwards across thousands of resources. For a platform serving many tenants at petabyte scale, the provisioning path is effectively the enforcement path. Provisioning is the most visible part of wider storage automation, which also covers expansion, repair and lifecycle tasks after a resource exists.
Stages of a provisioning request
- A request names the resource and its parameters: a bucket with a region, a storage class and a retention setting, or a volume with a size and performance tier.
- The control plane authenticates the requester and checks permissions and quotas.
- Placement selects where the resource lives: site, cluster, failure domains, storage class.
- The resource is created and configured with its policies: encryption keys, access policies, lifecycle rules, versioning and lock settings.
- Credentials or connection details are returned and metering starts.
Deprovisioning runs the same path in reverse, and is where most waste originates: resources that are no longer used but were never released keep consuming capacity.
Provisioning methods
| Method | How it works | Where it fits |
|---|---|---|
| Console or portal | A person fills in a form | One-off requests, small teams |
| API or CLI | Scripts and applications call the control plane directly | Pipelines, automated tenant onboarding |
| Infrastructure as code | Declarative files describe resources; a tool such as Terraform plans the changes and applies them | Repeatable environments, change review, multi-site consistency |
| Service catalog | Pre-approved templates offered to users with fixed defaults | Enterprise self-service with built-in policy |
Infrastructure as code adds a record of intent. Because the desired configuration lives in version control, every change is reviewable and an environment can be rebuilt from its definition.
Thick and thin provisioning of storage
Thick provisioning reserves the full allocation at creation. Thin provisioning promises the allocation but consumes physical capacity only as data is written. Thin provisioning lets a platform promise more than it holds. If 50 tenants are each allocated 200 TB, the platform has promised 50 × 200 = 10,000 TB, or 10 PB. Backed by 4 PB of physical capacity, that is an overcommitment of 2.5 to 1, safe only while actual use stays below 4 PB and capacity is added faster than tenants fill it. If the physical pool fills before the promises do, writes fail for every tenant on it at the same moment, which is why thin pools are tracked against physical consumption and growth rate instead of allocations.
What provisioning means for platform teams
- Defaults become policy at scale. Whatever the template sets for encryption, versioning or retention is what thousands of buckets end up with. Since S3 Object Lock requires versioning, a bucket meant for locked data needs versioning from the start, which is simplest when the template sets it.
- Quotas keep the pool forecastable. Per-tenant limits turn individual requests into a predictable total, which feeds hardware procurement lead times directly. On shared platforms, quotas and per-tenant credentials are also the visible edge of multi-tenant storage isolation.
- Drift erodes consistency. Changes made by hand outside the provisioning path leave resources that no longer match their definition. Across many sites, drift is how one site ends up with weaker settings than another.
- Orphaned resources are capacity. Buckets and volumes left behind by finished projects keep occupying petabytes. Tagging owners at creation is what makes them findable later.
- Placement is fixed early. The site, jurisdiction and storage class chosen when a bucket is created decide where its data lives. Changing that later is a data migration, which is why sovereignty and data residency rules are usually encoded in provisioning templates.
- Every request is an audit record. Who created which resource, with what settings, is the evidence auditors and security teams ask for.
Provisioning on Scality RING
Buckets on Scality RING are provisioned through its S3 interface, the same API used against public cloud object storage, so S3-aware tools and infrastructure-as-code providers that target S3 endpoints can create and configure them, including S3 Object Lock settings in governance or compliance mode with retention periods and legal holds. Scality describes RING as offering full S3 fidelity and as multi-tenant by design with hard isolation between tenants. One RING can therefore serve self-service bucket requests from many departments or customers at once.