Cloud fundamentals and the shared responsibility model

Cloud computing replaces capital expenditure on hardware with on-demand resource consumption billed by the second. That single shift changes how teams design, deploy, and operate software. Before diving into specific services, you need a mental model for the layers of responsibility, the geography of cloud infrastructure, and the trade-offs between managing things yourself and letting the provider handle them.

Service models: IaaS, PaaS, SaaS

Every cloud offering falls somewhere on a spectrum. At one end you manage almost everything. At the other the provider does.

graph LR
  A["On-Premises"] --> B["IaaS"]
  B --> C["PaaS"]
  C --> D["SaaS"]
  style A fill:#e74c3c,color:#fff
  style B fill:#e67e22,color:#fff
  style C fill:#3498db,color:#fff
  style D fill:#2ecc71,color:#fff

From left to right, the provider takes on more operational responsibility.

Infrastructure as a Service (IaaS)

You get virtual machines, storage volumes, and network primitives. You install the OS, patch it, deploy your application, and monitor it. AWS EC2, Google Compute Engine, and Azure Virtual Machines are the canonical examples.

IaaS gives maximum control. You pick the exact kernel version. You tune network buffers. You also own every failure that comes from a misconfigured firewall rule or an unpatched CVE.

Platform as a Service (PaaS)

The provider manages the runtime. You push code and it runs. Heroku, Google App Engine, and Azure App Service fall here. You lose control over the underlying OS but gain deployment speed.

PaaS works well for web applications with predictable traffic patterns. It struggles when you need custom binary dependencies or low-level network access.

Software as a Service (SaaS)

You consume a finished product. Gmail, Slack, Datadog. Your responsibility shrinks to configuration and data governance.

Choosing a model

The decision usually comes down to team size and operational maturity. A startup with two engineers should not run Kubernetes on bare VMs. A regulated enterprise may need IaaS to satisfy compliance controls that PaaS cannot expose.

The shared responsibility model

Security and operations are never entirely the provider’s problem or entirely yours. The shared responsibility model draws a line.

graph TB
  subgraph Provider["Cloud Provider Responsibility"]
      P1["Physical security"]
      P2["Hardware maintenance"]
      P3["Network infrastructure"]
      P4["Hypervisor"]
  end
  subgraph Shared["Shared Controls"]
      S1["Patch management"]
      S2["Configuration"]
      S3["Encryption settings"]
  end
  subgraph Customer["Customer Responsibility"]
      C1["Application code"]
      C2["Identity and access"]
      C3["Data classification"]
      C4["Firewall rules"]
  end
  Provider --> Shared --> Customer

The exact boundary shifts depending on whether you use IaaS, PaaS, or SaaS.

With IaaS, you own OS patching. With PaaS, the provider patches the OS but you still own application-level vulnerabilities. With SaaS, you own access controls and data governance.

Every major provider publishes its own version of this model. AWS calls it the “Shared Responsibility Model.” Azure uses “Shared responsibility in the cloud.” GCP publishes a “Shared fate” approach that emphasizes active collaboration rather than boundary drawing.

The key takeaway: moving to the cloud does not remove your security obligations. It changes which obligations you have.

Regions and availability zones

Cloud providers operate data centers grouped into regions and availability zones (AZs).

A region is a geographic area like us-east-1 (AWS), us-central1 (GCP), or eastus (Azure). Each region contains multiple AZs.

An availability zone is one or more discrete data centers with independent power, cooling, and networking. AZs within a region are connected by low-latency links but are physically separated so a fire or flood in one does not take out another.

Why this matters

• Latency: Place resources close to your users. A European user hitting a server in ap-southeast-1 adds 200+ ms of round-trip time.
• Redundancy: Distribute across at least two AZs. If one AZ fails, the other keeps serving traffic.
• Compliance: Some regulations require data to stay within a specific country or region. GDPR, data residency laws in Brazil, India, and others all impose geographic constraints.

Multi-region design

For global applications you deploy across multiple regions. This adds complexity: data replication lag, conflict resolution, and region-aware routing. Most teams start with a single region and expand when latency or compliance demands it.

Managed services

A managed service is any cloud offering where the provider handles operational tasks like patching, backups, scaling, and high availability. RDS manages your PostgreSQL database. Cloud Pub/Sub manages your message queue. Azure Cosmos DB manages your globally distributed NoSQL store.

Benefits

• Reduced operational burden: No 3 AM pages for a failed replica promotion.
• Built-in best practices: Automatic backups, encryption at rest, multi-AZ replication.
• Faster time to market: Deploy a production database in minutes, not days.

Trade-offs

• Less control: You cannot tune every parameter. Some managed databases do not expose certain configuration knobs.
• Vendor lock-in: Migrating from DynamoDB to another NoSQL store is not trivial.
• Cost at scale: Managed services charge a premium. At very high scale, self-managed infrastructure on reserved instances can be cheaper.

Total cost of ownership

Cloud pricing looks simple on the surface. A VM costs X per hour. In practice, the bill includes compute, storage, network egress, API calls, logging, monitoring, and cross-AZ data transfer.

Compute dominates most cloud bills, but networking costs surprise many teams.

Strategies to control cost

1. Right-size instances: Monitor CPU and memory utilization. If your VM averages 10% CPU, it is too large.
2. Use reserved or committed-use pricing: Commit to 1-3 year terms for predictable workloads and save 30-60%.
3. Spot/preemptible instances: Use for fault-tolerant batch jobs at 60-90% discount.
4. Lifecycle policies: Move old data to cheaper storage tiers automatically.
5. Monitor egress: Data leaving a region or AZ costs money. Architect to minimize unnecessary cross-zone traffic.
6. Tag everything: Assign cost-allocation tags to every resource. You cannot optimize what you cannot measure.

Build vs buy

The total cost of ownership (TCO) calculation goes beyond the monthly bill. Self-managing a PostgreSQL cluster means paying for engineer time to handle upgrades, backups, failover testing, and security patches. If that engineer costs $150K/year and spends 20$30K/year before touching the infrastructure bill. Sometimes the managed service premium is the cheaper option.

Provider comparison at a glance

Each provider has strengths. AWS has the broadest service catalog. GCP leads in data and ML tooling. Azure integrates deeply with the Microsoft ecosystem. Most organizations pick one primary provider and use a second for specific workloads.

What comes next

With the foundational model in place, the next article covers compute services: virtual machines, containers, and serverless. You will learn when to pick each option and how auto-scaling keeps costs aligned with demand.