Glossary
Private cloud
A private cloud is cloud infrastructure provisioned for the exclusive use of one organization. It offers the self-service, resource pooling and metered usage of a public cloud on infrastructure that organization controls, whether in its own data centers, in a colocation facility or on dedicated hardware run by a provider.
Sovereign, steady and heavily read data
Organizations with tens of petabytes build private clouds mostly for reasons tied to data. Regulated and sovereign datasets often stay on infrastructure the organization controls, in a known jurisdiction, sometimes on networks with no internet path at all. Large datasets read constantly cost less on owned hardware at high utilization than rented by the gigabyte-month with request and egress meters running. Analytics and AI training run faster with compute beside the data. Many private clouds start life as repatriation projects, when a public cloud dataset grows large enough that its recurring bill outweighs the one-time cost of leaving.
The term covers more than storage. A private cloud can offer infrastructure as a service, with virtual machines, networks and volumes requested by API, alongside object and file services, all on hardware dedicated to one organization, whether in its own facilities, a colocation site or a provider's dedicated racks. Most sit inside a wider hybrid cloud, with some workloads and copies in public regions.
Same servers, different operating model
| Aspect | Conventional data center | Private cloud |
|---|---|---|
| Requesting capacity | Ticket and manual allocation | Portal or API, automated |
| Hardware | Bought and sized per application | Shared pool of standard servers |
| Spare capacity | Stranded inside each system | Held once for the whole pool |
| Cost recovery | Project budgets | Metered chargeback or showback |
| Growth | A new system per project | Servers added to the pool |
The hardware can be identical in both columns. What differs is the software layer that pools it and the service model around it: self-service requests, shared headroom and metered consumption in place of tickets, per-project purchases and capacity locked inside individual arrays.
Ordering the next expansion at 92 percent full
In a public cloud the provider carries spare capacity. In a private cloud the organization does, and buys it ahead of demand. Take a pool with 20 PB usable, growing 1.5 PB a quarter, with one quarter of procurement and installation lead time: its next expansion has to be ordered while at least 1.5 PB is still free, at around 92 percent full. Growth that spikes in the meantime has nowhere to go, and a late order leaves tenants facing frozen quotas.
Fill level also sets unit cost. Owned hardware costs the same whether the pool is 50 or 85 percent full, so each stored terabyte gets cheaper as utilization rises, the reverse of a public cloud bill that tracks consumption directly. Smaller, more frequent expansions keep less money parked in idle hardware, provided the storage layer accepts new servers without downtime or manual data moves. Metering closes the loop. When each department sees and pays for its consumption, demand becomes forecastable; without it, the pool fills with data nobody answers for.
The storage team as an internal provider
Running storage as a private cloud turns the storage team into a service provider for the rest of the organization, with the obligations of that role.
- Tenants replace projects. Departments, subsidiaries or customers each get buckets, quotas and keys on shared hardware, and separation between them is an audit requirement, which makes multi-tenant storage a core design property.
- Refreshes happen under live tenants. Hardware generations, expansions and software upgrades roll through while tenants keep writing. A storage layer that needs downtime or a data migration for each one turns every refresh into a negotiation.
- Write-once rules become the platform's job. Lock mode decides whether an administrator can override a tenant's retention: in governance mode any identity holding
s3:BypassGovernanceRetentionthat sendsx-amz-bypass-governance-retention:truecan, while compliance mode binds every user, root as well, for as long as the retain-until date lies ahead. - Air gaps are an option. Disconnected and sovereign deployments exclude any dependency on outside cloud services for management, licensing or updates.
- Suppliers stay interchangeable. A pool built from standard servers lets each expansion come from whichever vendor offers the best price or lead time that year, without tying a decade of growth to one array maker.
- Flat headcount depends on automation. Self-service provisioning, automated repair and scale-out expansion are what let a small team run a pool that doubles in size.
Scality RING and private cloud
RING supplies the object and file layer of a private cloud as software-defined storage on standard x86 servers. Scality lists on-premise, air-gapped and sovereign-cloud deployment options, site-specific IAM and encryption boundaries, and high-concurrency multi-tenancy with hard isolation between tenants. Tenant buckets on RING can carry S3 Object Lock retention in either mode, plus legal holds, on versioned buckets. Expansion happens by adding servers to the running pool, which is the property the fill-level arithmetic above depends on. The compute and network layers of a private cloud sit outside RING and come from other software.