01Why this guide
Enterprises were offered a simple deal: move to public cloud and trade capital spend for speed. Many took it, and much of what was promised arrived. Teams provision in minutes. New services appear every month. Nobody waits for hardware.
What arrived with it was less advertised. Bills that move with usage in ways finance cannot model. Architectures built on proprietary services that are expensive to leave. Audit questions about where data sits and who can reach it that the contract answers only in part. Put plainly, the offer was speed in exchange for the estate.
This guide does not argue that public cloud was a mistake. It argues that “public or private” is the wrong question. The right question is where each workload belongs, and on what terms. What follows compares the two models fairly and ends with a checklist for a placement review.
The answer is rarely one cloud. It is the right workload in the right place.
02Two models, two approaches
Public cloud is shared infrastructure delivered by a large provider. You draw capacity from a pool other customers also use, pay for what you consume, and provision it yourself through a portal or an API. Its strengths are real: global reach, elastic scale, self-service and a very broad catalogue of managed services.
Enterprise cloud is a dedicated cloud environment built for one organisation, running in its own data centre or in a colocation facility it chooses. The resources are yours, and so are the administrative control, the security policies and the architecture. Done well, it gives teams the same self-service experience as public cloud. Done badly, it is a virtualisation estate with a ticket queue in front of it.
Where each tends to be used
| Public cloud commonly runs | Enterprise cloud commonly runs |
|---|---|
| Development and test environments | ERP and core business systems |
| Seasonal and bursty workloads | Banking and payments platforms |
| New products and short-lived experiments | Healthcare platforms holding patient records |
| Applications serving users in many countries | Government and public-sector systems |
| Services built on a provider’s managed catalogue | Manufacturing and operational workloads |
The split is not ideological. The left column is work that is variable, short-lived or global. The right column is work that is steady, regulated or tied to one jurisdiction. Most enterprises have both.
03Why organisations are reassessing
The reassessment usually starts in finance, not IT. A programme that looked cheaper at migration looks different a few years into steady operation. Four pressures come up again and again.
Cost that grows with success
Consumption pricing is efficient for variable work and expensive for steady work. As workloads grow, storage accumulates, data moves between services and regions, and charges for transfer, API calls, backups and managed-service premiums that were small at pilot scale become line items finance asks about.
Lock-in that arrives gradually
Nobody chooses lock-in. It accumulates as applications adopt a provider’s proprietary databases, queues, identity and serverless services. Each choice is reasonable on its own. Together they make migration slow and expensive, and they weaken your position at every renewal.
Compliance that needs proof
Regulated organisations must show where data is stored and processed, who accessed it and which controls applied. Residency rules, audit requirements and sector frameworks all ask for evidence, and evidence is harder to produce when part of the stack belongs to someone else.
Budgets finance cannot forecast
With consumption billing, the true cost is known only after the month closes. Finance teams working to annual budgets struggle to forecast it, and engineering teams rarely see the cost of a design decision until it is too late to change it.
None of these is a reason to leave public cloud wholesale. Each is a reason to decide placement deliberately rather than by default.
04Side by side
The table compares the two models on the questions a CIO is actually asked. It is deliberately even-handed: public cloud wins some rows outright, and several depend on how well each model is run.
| Question | Public cloud | Enterprise cloud | Usually favours |
|---|---|---|---|
| Infrastructure ownership | Shared, owned by the provider | Dedicated, owned or leased by you | Depends on whether you want to own it |
| Billing model | Consumption-based, pay per use | Capacity bought up front, allocated internally | Public for variable work, enterprise for steady work |
| Control over data location | Chosen by region; replicas, backups and support access need checking | Set by where the hardware is | Enterprise |
| Customisation | A broad catalogue, within the provider’s design | Architecture shaped to your requirements | Public for breadth, enterprise for control |
| Performance consistency | Can vary with shared resources and regional demand | Consistent on dedicated resources, once sized correctly | Enterprise |
| Elasticity, reach and speed to start | Capacity on demand in many regions | Bounded by what you have installed | Public |
| Compliance responsibility | Shared: the provider secures the platform, you the rest | Yours end to end, with full visibility | Public for inherited controls, enterprise for evidence |
| Exit | Harder the more proprietary services you adopt | Depends on how open the platform is | Enterprise, if the platform is open |
| Budget forecasting | Difficult without strong cost discipline | Easier, though idle capacity is still paid for | Enterprise |
| Governance | Provider tooling plus your own policies | Your policies enforced across the whole estate | Enterprise |
Two rows deserve caution. Enterprise cloud only wins on exit if the platform itself does not become the new lock-in. And it only wins on forecasting if someone is accountable for utilisation, because capacity you bought and do not use is waste too.
05The true cost of cloud
Most comparisons start with the price of a virtual machine. That number is real but rarely decisive. The bill finance sees includes a long tail of line items that are small on their own and significant together.
| Line item | Why it grows | What to ask |
|---|---|---|
| Data transfer and egress | Traffic leaving the provider or crossing regions is charged | What would it cost to move all our data out? |
| Snapshots and backups | Retained copies accumulate quietly | What is our retention policy, and who reviews it? |
| API and request charges | Busy applications make very large numbers of calls | Which services charge per request? |
| Inter-region and inter-zone traffic | Resilient designs replicate constantly | What does our DR design cost to run, not just to build? |
| Load balancers and networking | Charged by the hour and by volume processed | How many are idle or duplicated? |
| Managed databases | A premium over the compute underneath | Is the premium buying operations we would otherwise staff? |
| Monitoring, logging and security services | Priced by volume ingested or resources covered | What do we pay to observe and protect the estate? |
| Premium support | Often tied to the size of the bill | Does support cost rise automatically with usage? |
| Idle and oversized resources | Nobody switches them off | Who owns rightsizing? |
Enterprise cloud has hidden costs of its own, and a fair comparison counts them: hardware and its refresh cycle, power, cooling and space or a colocation contract, software licences, the people who run the platform, and capacity bought for peaks that sits idle the rest of the year.
The price list tells you what a resource costs. The bill tells you what your architecture costs.
Building a fair comparison
- Take a real workload with its usage history, not a reference architecture.
- Price it in both models over its expected life, including the cost of moving in and moving out.
- Include the people: platform operations, cost management and security effort in each model.
- Model growth and a bad month, not just the average.
07Performance and workload suitability
Performance in public cloud is generally good and occasionally uneven. Multi-tenancy means shared hosts, shared storage and shared networks, and a neighbour’s workload or regional demand can affect yours. For latency-sensitive systems, steady high-throughput databases and tightly coupled platforms, consistency matters more than peak speed.
Dedicated resources remove the neighbours. Performance is consistent once capacity is sized correctly, and latency to on-premises systems and local users can be lower. The cost is that you cannot burst beyond what you installed.
| Workload | Usually fits | Why |
|---|---|---|
| Public web applications with variable traffic | Public | Elastic scale absorbs the peaks |
| Burst and seasonal workloads | Public | You pay for the peak only when it happens |
| Applications serving many countries | Public | Reach across regions |
| Development and test | Either | Public for speed; enterprise when test data is sensitive |
| ERP and core business systems | Enterprise | Steady load and close integration with internal systems |
| Core banking and payments | Enterprise | Latency, control and regulatory scrutiny |
| Healthcare and citizen records | Enterprise | Data location and access governance |
| Analytics and AI on sensitive data | Enterprise | Data and models stay under your governance |
| Disaster recovery | Hybrid | A second site of your own, with public cloud as an option for chosen workloads |
Treat the table as a starting point. Placement is decided workload by workload, and it should be revisited when the workload changes.
08Where data lives and who governs it
In public cloud you choose a region, and the primary copy of your data sits there. The harder questions concern everything else: replicas for resilience, backups, logs and telemetry, the location of the control plane, and where the provider’s engineers sit when they need access. Each is a place data can travel, and each can bring another jurisdiction’s law into scope.
Enterprise cloud answers these questions physically. The data lives where the hardware lives, in your data centre or a colocation facility you choose, and access is governed by your own identity system and your own key custody. That does not make a workload compliant by itself, but it makes the answers short and provable.
Questions to settle for every regulated workload
- Where are the primary data, the replicas and the backups, and what could cause them to move?
- Whose law applies to the provider, and could it compel access?
- Who holds the encryption keys, and can the provider decrypt without you?
- Whose directory grants access, and where are authentication decisions made?
- Who can reach the environment for support, from where, and is that access recorded?
- Which local governance requirements apply, and who produces the evidence?
09A decision checklist
Work through these questions one workload at a time. Where most answers point one way, the placement is clear. Where they split, a hybrid design is usually the honest answer.
- Demand. Is the load variable and bursty, or steady? Variable favours public cloud; steady favours enterprise cloud.
- Data. Is it regulated, personal or commercially sensitive, and do rules govern where it may live?
- Jurisdiction. Must the workload answer only to local law, including for backups and support access?
- Performance. Does it need consistent latency or throughput, or proximity to systems on premises?
- Dependency. How many proprietary services would it use, and what would it cost to leave?
- Cost over life. What is the full cost in each model, including transfer, support, people and exit?
- Forecasting. Does finance need a cost it can budget a year ahead?
- Skills. Do you have the team to run dedicated infrastructure, or a partner who will?
- Evidence. Can you prove control to an auditor in each model, and at what effort?
- Reach. Does it serve users across many regions, or mostly in one country?
Write the answers down. A placement decision that is recorded can be revisited when the workload, the regulation or the price changes. One that was made by default cannot.
10Where Oasis Stack fits
The gap enterprise cloud has usually left is the experience. Public cloud gave teams a catalogue, self-service and cost visibility; most private estates gave them a ticket queue. Oasis Enterprise Cloud puts a cloud operating model on infrastructure you own.
- Where it runs — in your own data centre or a colocation facility you choose, on x86 or ARM hardware from the vendor you already buy from, with no lock-in to any infrastructure vendor.
- What it runs above — VMware, Kubernetes, bare metal and GPU, published as services rather than replaced.
- How teams use it — a self-service catalogue of compute, Kubernetes, storage, databases and GPU, with identity, policy and quotas enforced at order time.
- How costs are attributed — business units and subsidiaries run as isolated tenants, with showback and chargeback per team, project or environment.
- How it is licensed — a flat fee per deployment, banded by scale.
- Who runs it — your own teams, or CloudHost operating it for you, with support in three layers.
It does not ask you to leave public cloud. Disaster recovery can run across your own sites, with a public cloud as an optional third site for the workloads you choose. The point is placement: steady, regulated and sensitive work on a cloud you own, and the rest wherever it runs best. See Oasis Enterprise Cloud for the detail and pricing for how the licence works.
