The Cloud Mental Model

In one line: Every cloud is the same five primitives — compute, storage, network, identity, and a managed-service catalog on top — replicated across regions and zones, and reachable through an API that the web console is just a thin client for.

In plain English

People drown in clouds because they try to learn services (there are hundreds) instead of primitives (there are five). Once you see that "Amazon SQS" is just "a managed queue," "Amazon Athena" is just "SQL over files in object storage," and "AWS Step Functions" is just "a state machine that calls other services," the catalog stops being scary. This page gives you the coordinate system: where things physically live (regions/zones), how you talk to them (the API, not the console), and how to slot any new service into the five-primitive map.

Geography: regions and availability zones

Cloud resources are physical. They live in buildings. The hierarchy:

Provider
 └─ Region            us-east-1 (N. Virginia), eu-west-1 (Ireland), ...
     └─ Availability   us-east-1a, us-east-1b, us-east-1c
        Zone (AZ)       └─ one or more physically isolated data centers,
                           separate power + network, ~same-metro low latency

Two rules that drive most architecture decisions:

• Pick a region for latency and law. Closer region → lower latency to your users. The region also determines which laws apply to your data (EU data in eu-*, etc.). us-east-1 is the oldest, cheapest, has every service first — and is also where the famous internet-wide outages happen because so much depends on it.
• Span AZs for availability. A single AZ can fail (power, flood, fiber cut). Running across 2–3 AZs is the baseline for "we don't go down when one data center does." This is why load balancers, databases, and Kubernetes node groups are all multi-AZ by default in any serious setup.

Worked example: why your "it's slow" bug was geography

A team put their app server in us-east-1 and their Postgres in eu-west-1 because two different engineers set them up. Every query crossed the Atlantic: ~80ms round trip. A page that made 12 sequential queries took ~1 second in network latency alone, before any actual work. The fix was free: move both to the same region. Co-locate compute with its primary database. Cross-region calls are for replication and disaster recovery, not for your hot path.

The truth about the console

The AWS/GCP/Azure web console is a website. When you click "Launch instance," it calls the same public API your code would call. There are three ways to talk to a cloud, in increasing order of professionalism:

Interface	What it is	Use it for
Web console	Point-and-click GUI	Learning, exploring, reading dashboards, emergencies
CLI / SDK	aws, gcloud, az; or boto3, AWS SDK for JS	Scripts, one-off automation, glue
IaC (Terraform)	Declarative files in git	Everything that should exist tomorrow

The professional rule: the console is read-mostly. You look at it. You debug in it. You do not build production infrastructure by clicking, because clicks aren't reviewable, reproducible, or recoverable. Anything you create by hand is "ClickOps" and becomes an undocumented liability the day the person who clicked it leaves. Infrastructure as Code is the whole answer to this.

# The same "list my running VMs" across the three clouds — note how similar:
aws ec2 describe-instances --filters "Name=instance-state-name,Values=running"
gcloud compute instances list --filter="status=RUNNING"
az vm list --query "[?powerState=='VM running']"

The five primitives (your map of everything)

Every cloud service is a managed, branded version of one of these. When you meet a new service, ask "which primitive, plus what managed control plane?"

┌─────────────┬──────────────────────────────────────────────────────────┐
│ COMPUTE     │ Run code. VMs → containers → functions.                    │
│             │ AWS: EC2, ECS/Fargate, Lambda   GCP: GCE, Cloud Run, Fns   │
├─────────────┼──────────────────────────────────────────────────────────┤
│ STORAGE     │ Keep bytes. Object / block / file.                         │
│             │ AWS: S3, EBS, EFS   GCP: GCS, PD, Filestore                │
├─────────────┼──────────────────────────────────────────────────────────┤
│ NETWORK     │ Connect + isolate + route + balance.                       │
│             │ VPC, subnets, security groups, load balancers, DNS         │
├─────────────┼──────────────────────────────────────────────────────────┤
│ IDENTITY    │ Who can do what. IAM principals, roles, policies.          │
├─────────────┼──────────────────────────────────────────────────────────┤
│ MANAGED     │ Everything else = one of the above with the ops removed.   │
│ SERVICES    │ Databases (RDS), queues (SQS), search, ML, analytics...    │
└─────────────┴──────────────────────────────────────────────────────────┘

The catalog explodes because the managed services layer is infinite — but each entry decomposes into the four real primitives plus a control plane. RDS = compute + block storage + network + an API that handles backups/patching/failover. Once you internalize this, "I've never used Amazon Kinesis" becomes "it's a managed append-only log, like Kafka; I'll read the limits page and be productive in an hour."

Highlight: don't learn AWS, learn one cloud's concepts

A beginner asks "should I learn AWS or GCP?" and treats them as different skills. They aren't. The transferable skill is the five-primitive model plus the four deep concepts (compute billing/isolation, VPC networking, IAM, IaC). Learn those once — this chapter uses AWS names because they're the most common — and switching clouds is a vocabulary swap, not a re-education. Hiring managers know this; "AWS experience" on a GCP team is a fine hire.

Account structure (the thing nobody teaches you)

Real organizations don't run everything in one account. They use an account/project per environment and per blast-radius boundary:

• AWS: an Organization containing many accounts (e.g. prod, staging, dev, security-logging, one per team). Accounts are the hard isolation boundary — a mistake in dev literally cannot touch prod resources.
• GCP: an Organization → Folders → Projects hierarchy. The project is the unit of isolation and billing.
• Azure: Management Groups → Subscriptions → Resource Groups.

Why it matters to you as a developer: when you get cloud access at a real company, you'll be handed credentials scoped to one account/project, and "why can't I see the prod database?" is answered by this hierarchy, not by IAM alone. Separate accounts also cap the blast radius of a leaked key and make billing legible (each environment's spend is its own line).

Common mistakes

Where people commonly trip up

• Building prod by clicking in the console. It works once and is unreproducible forever. Use IaC from day one for anything that should outlive the afternoon.
• Defaulting to us-east-1 for an all-European user base. You inherit 100ms of latency and (depending on data) a GDPR problem. Pick the region for your users and your legal jurisdiction.
• Running everything in a single AZ. "It's been fine for months" — until the AZ has a bad day and you're the team that's down while competitors aren't. Multi-AZ is the cheap insurance.
• Treating the console as the source of truth. The console shows current state, not intended state or history. Git (via IaC) is the source of truth; the console is a dashboard.
• Learning service names instead of primitives. Memorizing that "Kinesis" exists is trivia. Knowing it's a managed log and when you'd reach for a log vs a queue is the skill.

Page checkpoint

Checkpoint Quiz

Did the mental model stick?

Required

What's next

→ Continue to Compute — the first and most important primitive: where your code actually runs, and the cost/control tradeoff that shapes every other decision.