Cloud

What Is Cloud Computing?¶

Cloud computing is the on-demand delivery of compute, storage, and networking resources over a network — paid for as you use them, instead of buying and running your own hardware.

Applies to

These are cloud concepts that apply across providers. Concrete examples may reference AWS, Azure, GCP, or OpenStack, but the ideas are portable. For the technology that makes it all possible, see Virtualization and Hypervisors.

The definition¶

The most widely cited definition (from NIST) describes cloud computing through five essential characteristics. A service is "cloud" when it offers:

On-demand self-service — you provision a server, database, or bucket yourself through a console, API, or CLI, without filing a ticket or waiting for a human.
Broad network access — resources are reached over the network using standard protocols (HTTPS, SSH) from anywhere.
Resource pooling — the provider runs a large shared pool of hardware and hands you a slice of it. You generally don't know or care which physical machine you're on (multi-tenancy).
Rapid elasticity — capacity scales up and down quickly, often automatically, so you can match supply to demand.
Measured/metered service — usage is metered (instance-hours, GB-months, API calls) and you pay only for what you use — pay-as-you-go.

Put simply: someone else owns and operates the data center; you rent capacity by the hour or by the request.

Service models: IaaS, PaaS, SaaS¶

Cloud services sit on a spectrum of how much the provider manages versus how much you manage. The three classic layers are Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

A popular way to remember it is "pizza as a service": making pizza at home means you manage everything; takeaway means the kitchen is theirs but the table is yours; dining out means you just eat. Cloud works the same way — the higher up the stack, the less you operate.

Layer	You manage	Provider manages	Examples
On-premises (no cloud)	Everything: app, runtime, OS, VMs, servers, storage, network, power	Nothing	Your own data center
IaaS	OS, runtime, application, data	Virtualization, servers, storage, network, facility	AWS EC2, Azure VMs, GCP Compute Engine, OpenStack Nova
PaaS	Application code and data only	OS, runtime, scaling, patching, plus everything below	AWS Elastic Beanstalk, Azure App Service, Google App Engine
SaaS	Just your data and configuration	The entire stack, including the application	Microsoft 365, Google Workspace, Salesforce, Gmail

            On-prem    IaaS     PaaS     SaaS
Application   you       you      you    provider
Data          you       you      you      you*
Runtime       you       you   provider  provider
OS            you       you   provider  provider
Virtualization you   provider provider  provider
Servers/HW    you    provider provider  provider
Network/Facility you  provider provider  provider

  (*your data is still yours — the provider runs the software around it)
  More provider responsibility as you move right →

The trade-off is control vs. convenience: IaaS gives you the most control and the most operational work; SaaS gives you the least of both.

Deployment models¶

Where the cloud runs and who can use it defines the deployment model.

Model	What it is	Typical reason to choose it
Public cloud	Shared infrastructure run by a provider, available to anyone over the internet	Speed, scale, no hardware to own
Private cloud	Cloud-style self-service on infrastructure dedicated to one organisation (on-prem or hosted)	Compliance, data residency, control
Hybrid cloud	Public and private joined together, with workloads and data moving between them	Keep sensitive data private, burst to public for scale
Multi-cloud	Using more than one public provider deliberately	Avoid lock-in, use best-of-breed, resilience

A common open-source route to a private cloud is OpenStack — see OpenStack Private Cloud. Public-provider specifics are compared in AWS, Azure & GCP Overview.

Benefits and trade-offs¶

Benefits

Capex → Opex — replace large up-front hardware purchases (capital expenditure) with ongoing usage-based spend (operating expenditure).
Scalability and elasticity — add capacity in minutes, remove it when demand drops, instead of sizing for peak forever.
Speed and reach — launch in new regions or experiment with services without procurement cycles.
Managed services — offload patching, backups, and high availability to the provider where it makes sense.

Trade-offs to manage

Cost control — pay-as-you-go cuts both ways. Idle and forgotten resources, egress (data-transfer-out) charges, and over-provisioning can make a cloud bill larger than expected. Tagging, budgets, and right-sizing matter.
Vendor lock-in — proprietary managed services are convenient but hard to leave. Portable choices (containers, open standards, infrastructure as code) reduce the risk.
Shared responsibility — convenience does not remove your security obligations (see below).
Dependence on connectivity and the provider's reliability — outages and regional failures are yours to design around.

The shared responsibility model¶

Security in the cloud is shared between you and the provider. A useful shorthand:

The provider is responsible for the security of the cloud — the physical facilities, hardware, host hypervisor, and the managed services they operate.
You are responsible for the security in the cloud — your data, OS patching (on IaaS), identity and access management, network rules (security groups/firewalls), and how you configure the services you consume.

The exact line moves with the service model: with IaaS you patch the guest OS; with PaaS the provider does, but you still own access control and your data; with SaaS you mostly own configuration and your data.

        SECURITY *OF* THE CLOUD          SECURITY *IN* THE CLOUD
        (provider's responsibility)      (your responsibility)
   ┌──────────────────────────────┐  ┌──────────────────────────────┐
   │ Physical data centers        │  │ Your data & encryption keys  │
   │ Host hardware & hypervisor   │  │ Identity & access (IAM)      │
   │ Managed-service internals    │  │ Network/firewall config      │
   │ Global infrastructure        │  │ Guest OS patching (IaaS)     │
   └──────────────────────────────┘  └──────────────────────────────┘

The most common cloud breach is misconfiguration

Public storage buckets, over-permissive IAM roles, and open security groups are the classic mistakes — and they fall squarely on the customer side of the line.

Core resource types¶

Almost everything in the cloud is built from three primitives:

Compute — virtual machines (instances), containers, and serverless functions that run your code. Sized by vCPU and memory.
Storage — block storage (virtual disks attached to an instance), object storage (buckets for files and backups, accessed via API), and file storage (shared network filesystems).
Network — virtual private networks/VPCs, subnets, load balancers, public IPs, and the firewall rules (security groups) that connect and protect it all.

These are explored in Cloud Storage and Networking, while container-based compute is covered in Containers and Kubernetes. You can provision all of these repeatably with Terraform, and the underlying Linux skills live in the Linux track.

Verify your work¶

Check your understanding with these conceptual self-tests:

Can you name the five characteristics that make a service "cloud," and explain why a server you racked yourself but reach over SSH is not cloud?
Given a workload, can you decide whether IaaS, PaaS, or SaaS fits — and state what you'd still be responsible for in each case?
Can you explain the difference between hybrid and multi-cloud in one sentence each?
For an IaaS virtual machine, can you list which security tasks are yours and which are the provider's?
Can you map a real example (a database, a web app, an email service) onto the compute/storage/network primitives it uses?

Summary¶

Cloud computing is on-demand, self-service, elastic, metered access to pooled resources over a network. The service models (IaaS, PaaS, SaaS) trade control for convenience as you move up the stack; the deployment models (public, private, hybrid, multi-cloud) decide where it runs and who shares it. The big wins are turning capex into opex and scaling on demand, balanced against cost-control and lock-in risk. Security is always shared — the provider secures of the cloud, you secure in it — and it all reduces to three building blocks: compute, storage, and network.