Core Primitives

Cloud models showed the ladder of abstraction. This page goes to the bottom of it — the raw materials every rung is built from. Cloud providers publish catalogues of hundreds of services with hundreds of names, and it is genuinely overwhelming until you notice the trick: almost all of them are combinations of just four primitives. Compute, storage, networking, and identity. Learn these four and the catalogue stops being a wall of jargon and becomes recognizable shapes.

The good news is you already understand them. Each maps directly onto something earlier in this book. This page’s job is to show you that the cloud didn’t invent new concepts — it put a rentable, API-driven wrapper around the Linux, networking, and security ideas you’ve already learned.

   ┌───────────────────────────────────────────────────────────────┐
   │                         IDENTITY (IAM)                          │  ← the spine: who may
   │           who may do what to every box below                    │     touch the other three
   ├──────────────┬──────────────────┬────────────────────────────┤
   │   COMPUTE     │     STORAGE        │        NETWORKING           │
   │  (VMs, fns)   │ (block/object/file)│  (VPC, subnets, sec groups) │
   │  runs code    │   keeps bytes      │   connects + isolates       │
   └──────────────┴──────────────────┴────────────────────────────┘

Compute — where code runs

Compute is the primitive that executes your code. In its rawest form it’s a virtual machine: a slice of a physical server, carved out by virtualization, that boots an OS and looks for all the world like a Linux box you own. AWS calls them EC2 instances, GCP calls them Compute Engine instances, Azure calls them VMs — same primitive, different name.

A VM gives you the process model, the filesystem, and systemd you already know — there’s nothing cloud-specific about a running VM except that you rented it by API and can destroy it the same way. An instance type (e.g. t3.medium, n2-standard-4) is just a named bundle of vCPU and RAM; bigger types cost more per hour.

Above the raw VM, compute climbs the same abstraction ladder as everything else:

   raw VM ──► container on a VM ──► managed container ──► function (serverless)
   you patch    you ship an          provider runs        you ship a function;
   the OS       image, run it        the image at scale    it runs only on a request
   ◄──────────────── more control ──── more convenience ───────────────►

A container is a lighter unit of compute on top of a VM; a function (Lambda, Cloud Functions) is compute so abstracted that there’s no server you see at all — covered when we reach scale-to-zero and serverless.

Storage — where bytes live

Compute is ephemeral — a VM can die, and with immutable infrastructure it’s meant to. So state has to live somewhere durable and separate. The cloud gives you three distinct storage primitives, and using the wrong one is a classic, expensive mistake:

Type	Abstraction	Attaches as	Good for	Cloud names
Block	a raw virtual disk	one VM at a time, like a hard drive	databases, OS disks, anything needing a filesystem you control	EBS, Persistent Disk
Object	a flat key → blob store, over HTTP	nothing — you GET/PUT by API	images, backups, logs, static assets, anything web-scale	S3, GCS, Blob Storage
File	a shared network filesystem (NFS/SMB)	many VMs at once	shared files across a fleet, legacy apps expecting a mount	EFS, Filestore

The distinction is how you talk to it. Block storage is a disk: you format it, mount it, and a filesystem sits on top — it behaves exactly like the filesystem on any Linux machine, and like a disk, one VM owns it at a time. Object storage is not a filesystem at all — there are no directories, no mounting; there’s a flat namespace of keys, and you GET/PUT whole objects over HTTP. That constraint is why it scales to petabytes and serves the public web cheaply. File storage is the network share you mount on many machines at once.

Object storage is not a folder, and treating it like one bites people

S3-style “paths” with slashes are an illusion — the key is just a string; there are no real directories. You can’t append to an object, you can’t lock it, and listing millions of keys is slow and metered. Reach for object storage for whole-blob, write-once, read-many workloads (backups, assets, logs). Reach for block storage when you need a real filesystem with random writes, like a database’s data directory.

Networking — how things connect and stay isolated

Renting compute and storage is useless if they can’t talk — and dangerous if they talk to the wrong things. Cloud networking is the network stack you learned, expressed as rentable, software-defined objects:

• VPC (Virtual Private Cloud) — your own private, isolated network inside the provider’s cloud. It has a private IP range (e.g. 10.0.0.0/16) and nothing outside it can reach in unless you allow it. It’s your network’s outer boundary.
• Subnets — slices of the VPC’s address range, usually split into public (can reach the internet via a gateway) and private (no direct internet path). The standard pattern puts load balancers in public subnets and databases in private ones, so the database has no route from the open internet at all.
• Security groups — stateful, per-resource firewalls. They are ports & firewalls as a cloud object: a security group on a VM says “allow inbound 443 from the load balancer, allow inbound 5432 from the app tier, deny everything else.” Default-deny, allow by exception.

   ┌─────────────────────── VPC  10.0.0.0/16 ───────────────────────┐
   │                                                                  │
   │  PUBLIC subnet 10.0.1.0/24       PRIVATE subnet 10.0.2.0/24      │
   │  ┌───────────────────┐           ┌───────────────────┐          │
   │  │  Load Balancer    │──────────▶│   App VMs          │          │
   │  │  (SG: allow 443   │           │   (SG: allow 8080  │          │
   │  │   from internet)  │           │    from LB only)   │          │
   │  └───────────────────┘           └─────────┬─────────┘          │
   │         ▲                                    │ allow 5432         │
   │  internet gateway                            ▼ from app only      │
   │                                  ┌───────────────────┐           │
   │                                  │   Database         │           │
   │                                  │   (no public route)│           │
   │                                  └───────────────────┘           │
   └──────────────────────────────────────────────────────────────────┘

This diagram is defense in depth: the database sits in a private subnet with no internet route, and its security group only admits the app tier — two independent barriers, neither relying on the other. It’s the cloud expression of the load-balancing and proxy and network policy patterns you’ve already met.

IAM — the spine that holds it together

The three primitives above are the boxes. Identity and Access Management (IAM) is the answer to “who is allowed to touch which box, and how?” — and it’s drawn as the spine in the opening diagram for a reason: every other primitive is meaningless without it. A storage bucket is only as private as the IAM policy guarding it; a VM is only as safe as the permissions of whoever can terminate it.

IAM is the cloud-account-level expression of the identity, RBAC, and least-privilege ideas from the Security Part. It has the same moving parts:

• Principals — who is acting: a human user, a group, or — most importantly — a role assumed by a machine (a VM, a function, a CI runner). Machines get identities too.
• Policies — what is allowed: documents that grant or deny specific actions (s3:GetObject) on specific resources (arn:…:my-bucket/*), to specific principals.
• Least privilege — the governing principle: grant the minimum needed, nothing more, so a leaked credential or compromised VM can do as little as possible.

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::app-assets/*"
}

This policy lets its principal read objects from one bucket — and nothing else. No write, no delete, no other bucket. That narrowness is the whole point: it’s a shift-left, blast-radius-shrinking control written as reviewable text.

Give machines roles, not long-lived keys

The most leaked secret in the cloud is a long-lived access key pasted into code or a config file. The fix is to give the machine an IAM role: the VM, function, or container assumes a role and receives short-lived, auto-rotating credentials from the platform — no static key to leak. This is the cloud version of the secrets-management rule “don’t store standing credentials.” It removes a manual, dangerous step: hand-copying keys around.

It actually happened — Capital One’s S3 breach (2019)

This is the page’s thread made painfully concrete: the leak came through identity, not a broken lock. In 2019 an attacker exploited a misconfigured web-application firewall running on an EC2 instance to make it fetch credentials from the instance metadata service — the short-lived keys for the firewall’s IAM role. That role had far broader S3 permissions than the firewall actually needed, so those borrowed credentials could list and read storage buckets holding roughly 100 million customer records. Every individual control the cloud gives you was present; the scope was wrong. Had the role followed least privilege — read only the one bucket it used — the same stolen credentials would have been nearly inert. IAM misconfiguration, not hacking, is how most cloud data leaks happen, and this is the canonical example.

The thread: from a forklift to four API calls

The manual, error-prone steps these primitives remove are the most physical in the book: procuring, racking, cabling, and wiring real machines, disks, switches, and access lists by hand. Standing up an app used to mean ordering servers, mounting them, running cables to a switch, configuring a hardware firewall, and managing a binder of who-has-root — weeks of work, every step a place for a typo or a forgotten rule. With cloud primitives, the same architecture is four kinds of API call (compute, storage, network, identity), each expressible as Infrastructure as Code and reviewable as a diff.

Production gets safer because each primitive carries its own guardrail you can encode once and enforce everywhere: private subnets and default-deny security groups make a publicly-reachable database a reviewable mistake rather than a default; least-privilege IAM makes a leaked credential nearly inert. The cost is that there are now four things to get right instead of one box to secure — and IAM misconfiguration, not hacking, is how most cloud data leaks actually happen.

With the raw materials in hand, the next page shows the first thing the cloud does that on-prem never could: grow and shrink compute automatically. On to Autoscaling.

The architect’s lens

Five questions for building on cloud primitives rather than physical kit:

• Why does it exist? Because a provider’s catalogue of hundreds of services is overwhelming until you see they’re combinations of four primitives — compute, storage, networking, identity — a rentable API wrapper around the Linux, networking, and security ideas you already know.
• What problem does it solve? It replaces weeks of procuring, racking, and cabling hardware with four kinds of API call, each expressible as reviewable IaC — and gives each primitive a guardrail you encode once (private subnets, default-deny security groups, least-privilege IAM).
• What are the trade-offs? Now there are four things to get right instead of one box, and the storage choice bites — object storage is not a filesystem (no random writes, no locking), so a database needs block; and IAM misconfiguration, not hacking, is how most cloud leaks happen.
• When should I avoid it? When a workload genuinely needs dedicated/physical hardware or on-prem compliance — otherwise you build on these primitives by default.
• What breaks if I get a primitive wrong? A too-broad IAM role turns one compromised instance into a 100-million-record breach (Capital One, 2019); the right scope would have left the stolen credentials nearly inert.

Check your understanding

1. The page claims hundreds of cloud services reduce to four primitives. Name them, and say in one phrase what each one does.
2. You need to store (a) a Postgres database’s data directory, (b) 50 million user-uploaded images served to the web. Which storage type for each, and why is using object storage for the database a mistake?
3. Walk through the VPC diagram: why does putting the database in a private subnet and restricting its security group to the app tier give you defense in depth rather than redundant effort?
4. What are IAM principals and policies, and why is IAM drawn as the “spine” rather than a fourth box beside the others?
5. Using the book’s thread, contrast standing up an app’s infrastructure before and after cloud primitives, and name one new failure mode the primitives introduce.

Show answers

1. Compute runs your code (VMs, containers, functions). Storage keeps bytes durably (block, object, file). Networking connects and isolates resources (VPC, subnets, security groups). Identity (IAM) controls who may do what to all of the above.
2. (a) Block storage — the database needs a real filesystem with random reads/writes, which block provides and object does not. (b) Object storage (S3-style) — it’s cheap, scales to web volume, and serves blobs over HTTP. Using object storage for the database fails because object stores have no filesystem semantics: no in-place appends, no locking, no random writes — a database can’t run on that.
3. Two independent barriers: the private subnet removes any internet route to the database (a network-layer control), and the security group admits only the app tier (a per-resource firewall). They don’t depend on each other — even if one were misconfigured, the other still stands — which is exactly what defense in depth means.
4. Principals are who is acting (users, groups, or roles assumed by machines); policies are documents granting/denying specific actions on specific resources. IAM is the spine because every other primitive is only as safe as the identity policy guarding it — a bucket, VM, or network is meaningless to secure without controlling who can touch it.
5. Before: physically procuring, racking, cabling, and firewalling machines by hand — weeks of error-prone manual work. After: four kinds of API call, each expressible as reviewable IaC. The new failure mode is IAM misconfiguration — overly broad policies or public buckets — which is how most real cloud data leaks happen.