The cloud is just rented computers + managed services

Strip away the marketing and "the cloud" is one idea: you rent someone else's computers and pre-built services, and you pay only for what you use. A "cloud provider" is a company that runs enormous warehouses full of servers (data centers) and lets anyone, via an API, borrow a slice of that hardware for minutes or years. You ask for a machine and it exists in seconds; you delete it and the bill stops. The three giants — usually called the big three — are AWS (Amazon Web Services), GCP (Google Cloud Platform), and Azure (Microsoft). Each is a different storefront over the same handful of building blocks. Learn the building blocks once and every provider looks familiar; only the product names change.

Why this changed everything: rent vs own

To feel why renting matters, picture the old way: you owned a data center (or rented rack space in one). Before you could serve a single user you had to do capacity planning — guess how much traffic you would have in a year, then buy enough servers up front to cover the peak. Guess too low and your site falls over on launch day; guess too high and you have paid for racks of metal that sit idle. Worse, hardware has lead time: you order servers, wait weeks for delivery, then days to rack, cable, and install them. Scaling up was a purchase order and a loading dock.

The cloud turns that capital purchase into a metered utility, like electricity. Need 200 machines for a Black Friday spike? Request them in the morning, release them that night, pay for the hours you used. There is no lead time and no leftover hardware. This is the deep shift behind everything else in this lesson: capacity becomes elastic and billed by usage instead of bought ahead and owned forever. (The flip side — that idle resources keep billing and that you can rent far more than you need — is exactly why cost discipline, covered at the end, matters.)

Compute: the "how much do I manage?" spectrum

Compute means anything that runs your code. The key mental model is a spectrum of responsibility: a slider from "you manage the entire operating system" on the left to "you manage nothing but a single function" on the right. Sliding right removes operations work (patching, scaling, server upkeep) but also removes control, and it changes the shape of your bill — sometimes per-hour, sometimes per-request. There are three landmarks on this slider.

Rule of thumb: start as far right as the workload allows, because less you manage means fewer 2am pages. Concrete picks: a spiky, event-driven job — say a function that resizes a photo each time one is uploaded, busy in bursts and silent most of the day — loves serverless: it scales to zero between uploads so the quiet hours cost nothing, and absorbs a sudden flood automatically. A steady, high-throughput service handling thousands of requests per second around the clock is usually cheaper on containers or VMs, because per-request billing adds up fast once you are never idle. And if you need a specific OS, a GPU, or custom kernel settings, you may be forced left to a VM.

Storage: object store is the default

There are three shapes of storage, and they are not interchangeable — each answers a different question. Reach for the first one unless you have a concrete reason not to.

A useful intuition: block is "a hard drive for one computer," file is "a shared network drive for many computers," and object is "a giant web-accessible bucket of files keyed by name." Most modern apps keep their bytes in an object store and let a managed database handle the structured data on top of block storage they never see.

Networking: the public/private boundary

Networking decides what can talk to what. Your resources live inside a VPC (Virtual Private Cloud) — your own isolated, private slice of the provider's network, walled off from every other customer. Inside the VPC you carve up the address space into subnets, smaller ranges that act as zones with their own access rules. The crucial distinction is public vs private: a public subnet has a route to the internet and resources in it can be reached from outside; a private subnet has no inbound path from the internet — things in it can only be reached from within your VPC.

Sitting at the front is a load balancer: a single entry point that distributes incoming traffic across many identical app instances so no one machine is overwhelmed, and that runs health checks — periodic pings to each instance — so it stops routing requests to any instance that has crashed or gone slow. The standard pattern almost everyone uses: put the load balancer in a public subnet so all traffic enters in exactly one controlled place, and keep your app servers and database in private subnets so they are simply unreachable from the open internet. An attacker scanning the internet finds only the load balancer; the database has no public door to knock on.

internet ─▶ load balancer (public subnet)
              │   distributes traffic + health-checks targets
              ▼
        app servers (private subnet)   ◀─ scaled to many copies
              │
              ▼
        database (private subnet)      ◀─ no public route in

Trace one request through the diagram: a user's browser hits the load balancer (the only public thing); the balancer picks a healthy app server in the private subnet and forwards the request; that app server queries the database, also private; the response flows back out the same path. The internet never touches your app servers or your data directly — that single boundary is the backbone of cloud security.

Identity & access (IAM): least privilege

IAM (Identity and Access Management) answers the question "who can do what to which resource?" Three terms carry it:

• Principal — the actor making a request. It can be a human user, but far more often it is a service (a VM, a function, a container) acting on its own behalf.
• Role / policy — a written set of permissions. A policy is a list of rules like "allow the action read on the bucket backups." A role is a bundle of policies that a principal can assume to gain exactly those permissions and no others.
• Least privilege — the discipline of granting the minimum permissions a principal needs to do its job, and nothing more. The image-resizer function gets read/write on the images bucket — not on the customer database, not on billing, not on "everything."

Why obsess over this? Misconfigured IAM and over-broad permissions are the #1 source of cloud breaches. The reason is structural: in the cloud, security is no longer mainly about a network perimeter — it is about identity, and a single wrong permission is exploitable from anywhere on the internet. Two classic, real examples: a public bucket — an object store left readable by "everyone," quietly exposing millions of customer records to anyone who guesses the URL; and a leaked admin key — long-lived credentials with full power, accidentally committed to a public Git repo, found by bots within minutes and used to spin up servers (often to mine cryptocurrency on your bill) or exfiltrate data. Least privilege is the containment: if that resizer function's key leaks, the blast radius is one image bucket, not your whole account. Treat IAM as a primary security surface, not a checkbox — this connects directly to Security basics and the broader topic of authentication & authorization.

Managed vs self-hosted: who gets paged at 3am

For most pieces of infrastructure you face a choice. Take a database like PostgreSQL. You can self-host it — install Postgres on a VM yourself — or use a managed database (AWS RDS / GCP Cloud SQL / Azure Database) where the provider runs Postgres for you and handles patching, automated backups, failover (promoting a standby copy when the primary dies), and replication, all for a markup on the price.

The tradeoff in one line: managed costs more money so you are not on call for undifferentiated heavy lifting; self-hosted has a cheaper sticker price but you own the hard parts. Make it concrete: it is 3am, the database disk fills up and the primary crashes. On managed, the provider's automation fails over to a standby and your nightly backups are already running and tested — you may not even wake up. Self-hosted, you are the failover plan and you are the one discovering at 3am whether the backups you set up six months ago actually restore. Because the failure modes of stateful systems (databases, queues, caches) are nasty and well-solved by the providers, managed almost always wins for state. Stateless compute, where a crashed instance is just replaced, is where self-managing pays off more often.

Regions, AZs, and resilience

Providers organize the planet into two levels. A region is a broad geographic location — a metro area like "US East (Virginia)" or "Europe (Frankfurt)," often written as a code such as us-east-1. Within each region are several availability zones (AZs) — physically separate data centers with independent power, cooling, and networking, but located close enough to each other (a few miles, linked by fast private fiber) that talking between them is nearly instant.

This split is what makes resilience cheap. Deploying across multiple AZs — multi-AZ — means a whole data center can lose power or literally catch fire and your service stays up. Concrete scenario: you run app servers and a database replica in zone a and zone b. A backhoe cuts power to zone a; the load balancer's health checks notice those instances stopped responding and route every request to zone b, while the managed database fails over to its zone b standby. Users see, at worst, a few seconds of blips. Choosing a region also has two other consequences: latency (put compute in a region near your users — Frankfurt for European users beats Virginia, because light takes real time to cross an ocean), and data residency (laws like the EU's GDPR may require that personal data physically stay within a region, so where you deploy is sometimes a legal decision, not just a performance one).