Deployment Models

What a deployment model is

A service model (infrastructure, platform or software as a service: IaaS, PaaS, SaaS — see Service Models) says what you rent: raw infrastructure, a platform or a finished application. A deployment model says where that cloud runs and who shares it. The two are independent: you can run platform services in a public cloud or in your own private cloud.

The United States National Institute of Standards and Technology (NIST) defines four deployment models in its definition of cloud computing, SP 800-145: public, private, community and hybrid. Multi-cloud is not in that 2011 document, but it has become common enough that AZ-900 and Cloud+ now expect you to know it.

Public cloud

In a public cloud, a provider owns and operates the data centers, hardware and software, and sells capacity to anyone over the internet. Amazon Web Services (AWS), Microsoft Azure and Google Cloud are the best-known examples. Customers share the same physical infrastructure (multi-tenancy) but are isolated from each other by virtualization, separate accounts and strict access controls.

• Advantages: no hardware to buy, capacity in minutes, pay only for what you use, a huge catalog of managed services, and data centers all over the world.
• Disadvantages: less control over where and how things run, costs that grow quietly when nobody watches them, dependence on one provider's services and prices, and data rules that may limit which data you can put there.

"Shared" does not mean "public to everyone". Your virtual machines, storage and networks are private to your account unless you configure them otherwise — and misconfiguring them is the most common way cloud data leaks.

Private cloud

A private cloud is cloud infrastructure used by one organization only. It can run in two places:

• On-premises: in the organization's own data center, run by its own staff.
• Hosted: on dedicated hardware in a provider's data center. The hardware is not shared with other customers, even though someone else owns the building and often runs the platform.

What makes it a cloud

Many organizations call their virtualized data center a private cloud. It only earns the name if it has the characteristics that define cloud computing (see What Is Cloud Computing?):

• Self-service: a team can create a virtual machine or network through a portal or an application programming interface (API), without filing a ticket and waiting three days for an administrator.
• Resource pooling: hardware is shared by all teams and handed out automatically.
• Elasticity: capacity can grow and shrink quickly, within the limits of the hardware that was bought.
• Measured service: usage is metered per team, so it can be reported or charged back.

Software such as OpenStack or VMware Cloud Foundation provides these functions on your own hardware. The honest trade-off: you get control and predictable costs, but you still buy hardware for your peak, you need people who can run the platform, and your catalog of services is much smaller than a public provider's.

Hybrid cloud

A hybrid cloud combines private or on-premises infrastructure with a public cloud, connected so they work together: shared identities, a private network link, and workloads or data that move or cooperate between them. Two separate environments that never talk to each other are not hybrid; they are just two environments.

Typical reasons:

• Data stays on-premises. A hospital keeps patient records in its own data center for legal reasons, while its appointment website runs in the public cloud and queries the records through a private connection.
• Cloud bursting. The normal load runs on your own hardware; only the peaks overflow to the public cloud.
• Gradual migration. Moving hundreds of applications takes years; during that time, the environment is hybrid whether you planned it or not.
• Latency or connectivity. A factory needs its machine controls to keep working when the internet link is down.

Cloud bursting in numbers

Bursting pays off when peaks are high but short. This example uses a web shop whose own data center has eight servers, each handling 100 requests per second. The cloud price is fictitious and round; only the pattern matters.

import math

# Requests per second a web shop must handle on a sale day, hour 0 to 23.
demand = [120, 90, 70, 60, 60, 80, 150, 300, 520, 640, 700, 760,
          820, 800, 760, 700, 680, 720, 900, 1100, 1250, 1000, 600, 250]

PER_SERVER = 100           # requests per second one server handles
ON_PREM_SERVERS = 8        # capacity in the own data center
CLOUD_PRICE = 0.40         # fictitious price per cloud server-hour

burst_hours = 0
server_hours = 0
for hour, rps in enumerate(demand):
    needed = math.ceil(rps / PER_SERVER)
    extra = max(0, needed - ON_PREM_SERVERS)
    if extra:
        burst_hours += 1
        server_hours += extra
        print(f"{hour:02d}:00  {rps:5} req/s  -> {extra} cloud server(s)")

peak = math.ceil(max(demand) / PER_SERVER)
print(f"Hours with burst: {burst_hours} of 24")
print(f"Cloud server-hours: {server_hours}, cost {server_hours * CLOUD_PRICE:.2f}")
print(f"Servers needed on-premises to cover the peak alone: {peak}")

12:00    820 req/s  -> 1 cloud server(s)
18:00    900 req/s  -> 1 cloud server(s)
19:00   1100 req/s  -> 3 cloud server(s)
20:00   1250 req/s  -> 5 cloud server(s)
21:00   1000 req/s  -> 2 cloud server(s)
Hours with burst: 5 of 24
Cloud server-hours: 12, cost 4.80
Servers needed on-premises to cover the peak alone: 13

Covering this peak with owned hardware would mean five extra servers that sit idle 19 hours a day. The calculation leaves out what makes bursting hard in practice: the application must run identically in both places, the cloud servers need fast access to the data, and data leaving the cloud is billed (see Cloud Costs and FinOps).

Tools that blur the line

Providers sell products that bring their cloud to your building or your building into their management tools:

• AWS Outposts: racks or servers owned and managed by AWS, installed in your data center, running a subset of AWS services and connected to an AWS region.
• Azure Arc: lets you manage servers and Kubernetes clusters that run outside Azure — on-premises or in another cloud — from the Azure portal, with Azure policies and monitoring.

Multi-cloud

Multi-cloud means using two or more public cloud providers. It is often combined with hybrid, but it is a different idea: hybrid is about private plus public, multi-cloud about several public providers.

Organizations end up multi-cloud for different reasons:

• Best service for the job: one provider's data analytics, another's identity integration with the office suite.
• Acquisitions: the company you bought runs on another provider — the most common reason, and rarely a strategy.
• Negotiating position and regulation: less dependence on one vendor; some regulators ask banks for an exit plan per critical provider.
• Resilience: surviving the failure of a whole provider. This is the most cited reason and the most expensive to achieve for real.

The real costs are easy to underestimate:

• Every provider has its own identity system, network model, monitoring and billing — teams must learn and secure all of them.
• Traffic between providers crosses the internet or a dedicated link, and outbound data transfer is billed.
• Running one application actively in two clouds means using only the features both offer, or building everything twice.
• Volume discounts are split across providers, so each one sees a smaller customer.

Community and sovereign clouds

Community cloud

NIST's fourth model is the community cloud: infrastructure shared by a specific group of organizations with common requirements, such as government agencies, universities or hospitals. It sits between public (anyone) and private (one organization). As a separate model it is rare today; its role is largely taken over by the government and sovereign offerings below.

Sovereign and government clouds

A sovereign cloud is designed so that data, operations and control stay within one jurisdiction. The large providers run physically and logically separated clouds for governments, such as AWS GovCloud (US) and Azure Government. Azure in China is operated by a local company, 21Vianet, rather than by Microsoft itself.

In Europe, the question is how to keep data under European law when the largest providers are headquartered in the United States. The answers vary and change quickly; at the time of writing:

• Microsoft's EU Data Boundary is a commitment to store and process customer data of European Union (EU) and European Free Trade Association (EFTA) customers within that area for its main cloud services, with documented exceptions.
• The AWS European Sovereign Cloud (generally available since January 2026, first region in Brandenburg, Germany) is separate from AWS's other regions and operated by staff resident in the EU.
• Several providers partner with European companies that operate a cloud on their technology, so that the local partner controls operations and keys.

Whether such arrangements fully shield data from foreign laws — for example the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act), which can require US companies to hand over data they control, wherever it is stored — is debated by lawyers and regulators. Treat data residency (where data is stored) and data sovereignty (whose law applies and who can be compelled to give access) as separate questions, and ask your legal or privacy officer rather than relying on a product name.

Vendor lock-in

Vendor lock-in is a situation in which moving away from a provider costs so much time, money or risk that you effectively cannot. It has several sources:

• Proprietary services: a database, messaging or serverless service that exists only at one provider must be replaced, and the application rewritten around its replacement.
• Data gravity: hundreds of terabytes are slow and expensive to move out, because outbound data transfer is billed.
• Skills and tooling: scripts, monitoring, training and certifications all follow one provider.
• Contracts: multi-year commitments in exchange for discounts.

Reducing lock-in, honestly

Lock-in is not always bad. A fully managed, proprietary service can save a team years of work. The mistake is accepting lock-in without noticing; the sensible approach is to accept it deliberately where the benefit is large, and avoid it where it buys little. Regulation is also moving: the EU Data Act requires cloud providers to make switching easier and to phase out switching charges.

Comparing the models

Choosing a model

Few organizations choose one model once. The useful questions are per workload:

1. Which rules apply to the data? Laws, contracts and sector regulation may restrict where data may be stored and who may access it.
2. How does the load behave? Steady, predictable load is cheap to run on owned hardware; spiky or unpredictable load favors the public cloud.
3. What exists already? A data center with five years of depreciation left, or a mainframe that cannot move, shapes the answer.
4. Which skills does the team have? Running a private cloud or two public clouds well takes people.
5. What does leaving cost? Decide consciously how much lock-in you accept for each workload.

Example scenarios

• A start-up with ten developers: public cloud. No capital to spend on hardware, unpredictable growth, and no staff to run a data center.
• A regional hospital: hybrid. Clinical systems and patient data stay in its own data center or a certified hosting partner; email, office software and the public website come from the cloud.
• A ministry handling classified information: private or a government/sovereign cloud, chosen for control over location, staff and keys.
• A large retailer after an acquisition: multi-cloud by circumstance. The sensible move is often to settle on one main provider per workload rather than to run everything everywhere.