Cloud Fundamentals
Beginner 12 min read Cloud Fundamentals

Cloud Deployment Models

Public, private, hybrid and multi-cloud

Public, private, hybrid and multi-cloud describe who runs your infrastructure and where. Each trades control, cost and resilience differently.

public cloudprivate cloudhybrid cloudmulti-cloudon-premises
Prerequisites: What is Cloud Computing?
Before we start

What you will learn

  • Differentiate public, private, hybrid and multi-cloud by ownership and location
  • Explain hybrid cloud's workload-routing promise
  • Recognize the added cost and complexity of multi-cloud
In 60 seconds

Public cloud is someone else's pooled infrastructure; private cloud is dedicated infrastructure (yours or hosted for your company); hybrid joins both; multi-cloud spreads you across two or more providers.

Introduction

What is this?

Deployment models describe who owns, hosts and operates your infrastructure. Public cloud uses a shared multi-tenant provider. Private cloud uses infrastructure dedicated to your organization — on-premises software-defined data centers or single-tenant hosted. Hybrid cloud connects public and private so workloads can move between them. Multi-cloud means deliberately operating across two or more public providers, usually for resilience, compliance or best-of-breed services.

Motivation

Why do you need it?

  • Regulation (finance, health data) can dictate where data may live and who may touch it — a private or region-constrained model.
  • Hybrid lets legacy systems stay home while new analytics and burst workloads run in the cloud.
  • Multi-cloud hedges provider outages and lock-in, at the cost of duplicated tooling and expertise.
  • The decision is a risk/compliance trade-off as much as a technology one.
Think about it

Mental model

Imagine

Owning a restaurant, catering your own, or ordering from two food vendors

Think of

Private, hybrid, multi-cloud

Own the kitchen (private), rent capacity from a catering service (public), blend both for big events (hybrid), or keep two vendors to never miss a meal (multi-cloud).

Mechanics

How it works

  • Public cloud: the provider pools physical resources and isolates tenants; you share hardware with others behind abstractions.
  • Private cloud: dedicated hardware with cloud-style self-service — usually a virtualized stack you operate within your own walls.
  • Hybrid: a private environment plus public cloud joined by private connectivity (VPN, dedicated link) with unified tooling.
  • Multi-cloud: two or more public providers run separate portions of your estate; traffic and data flow across provider boundary.
  • Choosing a model is choosing where the operational line sits between you and vendors — and where auditable data lives.

Deployment models mapped by ownership and location.

Public
Private
Hybrid
Multi-cloud
Real world

In production

  • A bank keeps card processing on-prem (compliance) while running marketing analytics in the public cloud over a private VPN connection — hybrid.
  • A media company runs the same autoscaling platform on AWS and GCP with DNS-based traffic splitting to stay resilient to a provider outage — multi-cloud.
  • A hospital with strict data-residency uses a single provider's dedicated infrastructure region, functionally private for PHI workloads.
Guidelines

Best practices

  • Choose a deployment model per workload, not per company — the bank's analytics never needed to be private.
  • If hybrid, invest in private connectivity and consistent identity between both worlds first.
  • For multi-cloud, standardize on portable layers (containers, standard DNS, gitops) or you pay twice for everything.
  • Document the data-residency requirement that drives each model choice — future teams need the reason.
Watch out

Common mistakes

  • Going multi-cloud 'for resilience' but running every workload in one provider anyway because tooling is duplicated.
  • Running a private cloud with no cloud-like automation — that's just a data center with a fancy name.
  • Forgetting egress/data-transfer costs exist at every boundary in hybrid and multi-cloud designs.
  • Splitting related services across clouds and paying network latency and consistency debts.
Root cause analysis

Common issues

Error
VPN between premises and cloud flaps during peak
Root cause

Tunnel bandwidth saturation or unreliable public transport

Fix

Measure utilization, raise tunnel limits, or move to a dedicated connection for steady high-throughput flows.

Error
Compliance audit flags data in the wrong region
Root cause

A backup or replica job cross-replicates PHI to a non-approved region

Fix

Enforce region constraints with data residency guardrails (e.g. org policies/S3 bucket policies setting allowed regions).

When things break

Debugging tips

  • In hybrid, first determine which side of the boundary the fault is on — check the VPN/direct-connect link health before app code.
  • For multi-cloud latency, measure inter-cloud RTT; some 'split' designs cross the ocean twice per request.
  • Trace data-residency failures at the storage layer: is the bucket/region allowed by policy to hold this data?
  • Compare failures against provider status pages; multi-cloud value is only realized if you can actually fail over.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

A bank runs card processing on dedicated hardware in its own building and analytics in the public cloud over a private link. Which model is this?

2

Multi-cloud guarantees lower total cost because providers compete.

Go deeper

Official documentation

NIST SP 800-145 — deployment models
spec
AWS — Hybrid cloud resources
docs