Cloud Computing Models

IaaS, PaaS, SaaS, serverless. Why the cloud changed everything and what it actually offers.

What 'The Cloud' Actually Means

The "cloud" isn't magic. It's someone else's data center, accessible by API, billed by usage.

Pre-cloud (still common in some shops):
• You buy servers
• You rack them in a colocation facility or your own datacenter
• You pay for them whether you use them or not
• Provisioning takes weeks (order, ship, install, configure)
• Scaling up means buying more hardware

Cloud:
• You rent compute by the second/minute/hour
• Provisioning takes seconds via API
• You pay only for what you use
• Scaling is an API call

This shift isn't just operational — it's economic. A startup in 2008 needed $50k+ to launch a basic web service. A startup in 2026 can launch the same thing for $20/month and scale to millions of users without buying any hardware.

The three big public clouds:
• AWS — biggest, oldest, most services. Started 2006.
• GCP — Google's. Strong in data, AI, networking.
• Azure — Microsoft's. Strong in enterprise, Windows, Office integration.

Plus regional clouds (Alibaba, Oracle), specialized clouds (Cloudflare, Fly.io, Render), and on-prem private clouds (OpenStack, VMware).

Once you know one cloud well, the others are easier. The vocabulary differs but the concepts are 80% the same.

The Service Model Spectrum

Cloud services fall on a spectrum from "raw resources" to "fully managed":

   You manage everything                You manage nothing
            │                                     │
            ▼                                     ▼
   ┌──────────┬──────────┬──────────┬──────────┬──────────┐
   │ Bare     │  IaaS    │  CaaS    │  PaaS    │  SaaS    │
   │ Metal    │ (VMs)    │(Containers)│(App Platform)│(Apps)│
   └──────────┴──────────┴──────────┴──────────┴──────────┘
                                                    
                                              FaaS / Serverless
                                              fits between PaaS and SaaS

IaaS — Infrastructure as a Service
You rent virtual machines (and networks, storage). You install OS, configure, run software. You manage everything above the hypervisor.
Examples: AWS EC2, GCP Compute Engine, Azure VMs.

CaaS — Containers as a Service
You hand the platform a container image and configuration. The platform runs it. No OS management.
Examples: AWS ECS/Fargate, GCP Cloud Run, Azure Container Apps, Kubernetes (managed flavors EKS/GKE/AKS).

PaaS — Platform as a Service
You hand the platform code. The platform builds, deploys, scales, monitors. No infrastructure visible.
Examples: Heroku, Render, Railway, Fly.io, AWS App Runner, Vercel, Netlify.

FaaS — Functions as a Service / Serverless
You hand the platform a function. The platform runs it on demand, scales automatically including down to zero. Pay per invocation.
Examples: AWS Lambda, GCP Cloud Functions, Azure Functions, Cloudflare Workers.

SaaS — Software as a Service
The platform runs the software for you. You consume it.
Examples: Gmail, Salesforce, Stripe, Notion.

Higher up the stack = less control + less work. Most apps in 2026 use a mix: PaaS or CaaS for the application, SaaS for everything else (auth, payments, email, monitoring), IaaS only when needed for specific reasons.

Pricing Models — Where Money Goes

Cloud is cheaper than running your own datacenter for variable workloads. It can be MUCH more expensive for steady, predictable workloads. Knowing the pricing models helps you avoid surprises.

Compute pricing:
• On-demand — pay per second/hour, no commitment. Most flexible, most expensive per hour.
• Reserved / Committed Use — commit to 1-3 years, get 30-72% discount. For steady baseline workloads.
• Spot / Preemptible — bid on spare capacity. 60-90% discount. The cloud can take your instance back with 30s-2min notice. For batch jobs, fault-tolerant workloads.
• Savings Plans — flexible commitment to a $/hour amount, applies to any matching instances.

For a typical SaaS app, the right mix is usually: reserved capacity for the baseline, on-demand for spikes, spot for batch processing.

Common cost gotchas:
• Egress (data leaving the cloud) — usually $0.05-$0.09/GB. A small download endpoint can cost more than your entire compute bill.
• Cross-region data transfer — even WITHIN the same cloud
• NAT Gateway data processing — $0.045/GB on top of egress in AWS
• Inter-AZ traffic — also charged on AWS
• Idle resources — load balancers, NAT gateways, EIPs charge by hour even when unused

A good rule of thumb: if your monthly cloud bill is rising fast and you're not getting more users, it's almost always egress, NAT, or forgotten resources.

Free tiers exist for every cloud — generous enough to run small projects free indefinitely if you stay within them. Use this for learning. Set up billing alerts before anything else.

The Shared Responsibility Model

Critical security concept that bites teams who don't understand it.

In the cloud, security is shared between provider and customer. The split depends on the service:

                    IaaS (VMs)              SaaS
   ─────────────────────────────────────────────────
   Customer data        YOU                  YOU
   App config            YOU                  YOU
   Identity / access     YOU                  YOU
   App code              YOU                  PROVIDER
   Runtime / OS          YOU                  PROVIDER
   Hypervisor            PROVIDER             PROVIDER
   Physical hardware     PROVIDER             PROVIDER
   Network               PROVIDER             PROVIDER
   Datacenter            PROVIDER             PROVIDER

Common misunderstandings:
• "AWS handles security" — they handle THEIR security. You handle yours.
• "S3 is secure by default" — buckets used to default to public; data leaks because of YOUR config, not AWS's
• "Lambda is serverless so I don't think about security" — your function code can still be vulnerable
• "We use a managed database" — your password rotation, network access rules, backup strategy are still yours

The provider's job: physical security, hypervisor security, basic network infrastructure, service availability.

YOUR job: who can access what, how data is encrypted, what services your accounts can use, monitoring for attacks, patching things you operate.

Compliance certifications (SOC 2, PCI, HIPAA) are also shared. AWS being SOC 2 compliant doesn't make YOUR app SOC 2 compliant. You inherit the infrastructure controls but still need your own controls.

Multi-Region & Multi-Cloud

Cloud regions are geographic locations (us-east-1, eu-west-1, ap-south-1). Within a region are availability zones (typically 3) — separate datacenters with independent power and networking, connected by low-latency links.

The progression of cloud reliability:
1. Single AZ — okay for dev. One datacenter outage takes you down.
2. Multi-AZ within one region — standard for production. AZ outages are common; region outages rare.
3. Multi-region — for disaster recovery and global reach. Complex.
4. Multi-cloud — running on AWS AND GCP. Even more complex. Usually overkill.

Most production apps:
• Run multi-AZ in one region for reliability
• Use multi-region only when latency for global users matters or compliance requires it (data residency)
• Avoid multi-cloud unless there's a specific reason (vendor lock-in concerns, regulation)

Multi-cloud sounds nice ("we won't be locked in") but in practice:
• Your tooling is harder (different APIs, IAM models, networking)
• You can't use cloud-specific managed services optimally
• Your team has to know two clouds well
• Cross-cloud egress is expensive

In 2026, most pragmatic teams pick one cloud, become excellent at it, and accept the lock-in as the cost of leverage. Use Kubernetes if you want a portable application platform — that's lock-in to K8s but not to a specific cloud's runtime.

Picking a Cloud

For someone starting out:

• AWS — most jobs, biggest ecosystem, most resources. The "default" choice.
• GCP — best if you do data/ML. Great networking. Cleaner IAM.
• Azure — strong in enterprise, .NET, Microsoft shops.
• Cloudflare — simpler, fast, great for edge / CDN / Workers.
• Fly.io / Render / Railway — easiest to learn, best for small projects, build skills.

Suggestions:
• Learn AWS first if you want broad employability
• Use a simpler platform (Fly, Render) for personal projects to focus on app development
• Don't try to learn all three big clouds at once

The next two lessons cover AWS and GCP core services. They're the most common, and the patterns transfer to Azure and others. Pick one to focus on, but skim both — concepts overlap heavily.