# Cloud Platforms, Explained (AWS / GCP / Azure) > What 'the cloud' actually sells, the handful of building blocks that matter across AWS, GCP, and Azure, and how to stay sane about bills, permissions, and lock-in. --- # Cloud Platforms, Explained (AWS / GCP / Azure) You've heard "we run on AWS" or "let's spin up a VM on GCP" a hundred times, and you've probably nodded along. Then you opened the AWS console once, saw a sidebar with two hundred service names you'd never heard of, and quietly closed the tab. That reaction is correct. Nobody knows all of them. Nobody is supposed to. Here's the secret the console hides: underneath the sprawl, a cloud platform sells a very small number of things, and AWS, Google Cloud, and Azure all sell the *same* small number of things with different names. Once you have that mental model, the two hundred service names stop being a wall and become a catalog you can skim. This guide gives you that model - the shape, not the encyclopedia. ## How to read this - **Want the gist fast?** Read [Phase 1](01-what-the-cloud-sells.md) - it installs the one idea everything else hangs on. Then skim the vendor-mapping table in [Phase 2](02-the-building-blocks.md). - **Want it to finally make sense?** Read in order. Each phase builds on the last: what the cloud *is*, the blocks it's made of, and how to choose among them without getting burned. ## The phases 1. **[What "The Cloud" Actually Sells](01-what-the-cloud-sells.md)** - renting computing on demand instead of owning servers, and why all three big platforms are the same shape underneath. 2. **[The Building Blocks (Across Vendors)](02-the-building-blocks.md)** - the five or six pieces that matter - compute, object storage, managed databases, networking, identity - name-mapped across AWS, GCP, and Azure in one table. 3. **[IaaS vs PaaS vs Serverless, and Staying Sane](03-iaas-paas-serverless.md)** - the spectrum from raw VMs to managed platforms to functions, and the three gotchas that actually hurt: surprise bills, IAM complexity, and lock-in. > Deliberately out of scope: this is the mental model, not a certification course. We don't walk through > the console click-by-click, and we don't cover any single service in depth. When you're ready to > *manage* cloud resources as code instead of clicking, that's a different skill - > [Infrastructure as Code with Terraform](/guides/infrastructure-as-code-terraform). --- # What "The Cloud" Actually Sells The word "cloud" does a lot of damage. It sounds like a place, something far away and slightly magical. That framing is exactly why the AWS console feels overwhelming - you're looking for a *place* and finding a hardware store with two hundred aisles. So let's swap the metaphor for something true. The cloud is a company that owns enormous buildings full of computers, and rents them to you by the hour. That's the whole business. Everything else - the two hundred service names, the dashboards, the acronyms - is just different *ways* of renting those computers and the things attached to them. Once you believe that, the rest is detail. ## The thing it replaces: owning the servers Before the cloud, running software for other people meant *buying physical machines*. You'd estimate how much traffic you might get, buy enough servers to handle the busiest day you could imagine, rack them in a room (or rent data-center space), keep them powered and cooled, and replace the disks when they died - paying for all of it up front, whether anyone used your software or not. Every painful part of that - the up-front cost, the guessing, the idle machines, the 3am drive to swap a dead drive - is a problem the cloud was built to delete. Hold the old way in your head and the cloud's whole pitch becomes obvious. **The old way, drawn out:** ```text OWNING SERVERS THE CLOUD ───────────── ───────── Buy 10 machines up front → Rent 1 machine, by the hour (guess your busiest day) Need 10 more at lunch? Rent them. Quiet at 3am? Give them back. Pay whether used or not → Pay only for the hours you used You replace dead disks → Someone else's job ``` ## What it sells, in four buckets Strip away the names and a cloud platform sells four kinds of thing. Almost every service you'll ever see is one of these wearing a costume. **1. Compute - rented machines that run your code.** A computer with a CPU and memory that you can turn on, run your program on, and turn off. Sometimes it's a whole virtual machine you control; sometimes it's a smaller slice (a container, or just a single function). This is the engine. **2. Storage - places to keep data that don't vanish when a machine turns off.** Compute is temporary by nature; turn the machine off and its local disk may go with it. Storage is the durable shelf: files, images, backups, database contents - things that must still be there tomorrow. **3. Network - the wiring that connects all of it.** Private networks so your machines can talk to each other safely, public addresses so the internet can reach the parts you *want* reached, load balancers to spread traffic, and the rules (firewalls) that say who's allowed in. **4. Managed services - the cloud running a hard piece of software *for* you.** This is the bucket that makes the cloud feel huge, and it's the most valuable one. Instead of installing, configuring, patching, and babysitting a database (or a message queue, or a search index) yourself, you click a button and the cloud runs it, keeps it alive, backs it up, and hands you a connection string. You rent the *outcome*, not just the machine. 📝 **Managed service.** A piece of infrastructure software (a database, a queue, a cache, etc.) that the cloud provider operates on your behalf - installation, patching, scaling, and backups are their job, not yours. You pay more than running it raw, and in return you stop being its sysadmin. > ⏭️ Fuzzy on what a "server" even is under all this? The ground-level version - > what a server is, what runs on it, how requests reach it - is in > [What a Server Is](/guides/what-a-server-is). This guide assumes that much. ## The pricing model: you pay for what you use The default cloud deal is *metered*, like electricity. You don't buy a server; you rent capacity and a meter runs while you use it. Leave a machine running 24/7 and you pay for 24/7; run it for an hour and shut it down, and (for many services) you pay for roughly an hour. Storage is metered by how much data you're keeping and how often you read it; network often charges for data flowing *out* to the internet. This is the whole appeal, and the whole danger. The upside is real: a two-person startup can rent the same caliber of infrastructure as a giant company and pay only for what it actually uses. The danger is the mirror image: a meter that runs while you're not looking doesn't stop on its own. A machine you forgot to turn off, or a job stuck in a loop, bills you the entire time. ⚠️ **The meter never sleeps.** "Pay for what you use" quietly includes "pay for what you *forgot you were using*." A test server left running over a long weekend, an oversized database nobody downsized after launch - these don't error out, they just bill. We come back to taming this with budgets and alerts in [Phase 3](03-iaas-paas-serverless.md); for now, just hold the instinct: *anything you turn on, you are paying for until you turn it off.* ## The big three are the same shape Here's the part that makes the whole landscape navigable. **AWS, Google Cloud (GCP), and Azure are not three different worlds - they're three brands selling the same four buckets.** Each one has compute, object storage, managed databases, networking, and an identity system. They named everything differently, the consoles look different, and the deep details differ. But the *shape* is shared. ```text COMPUTE OBJECT MANAGED PRIVATE IDENTITY / (a VM) STORAGE DATABASE NETWORK PERMISSIONS ───────── ───────── ────────── ───────── ────────── AWS EC2 S3 RDS VPC IAM Google (GCP) Compute Cloud Cloud SQL VPC IAM Engine Storage Azure Virtual Blob Azure SQL Virtual Entra ID / Machines Storage Database Network RBAC ``` *What this table is telling you:* the columns are the concepts worth learning; the cells are just what each vendor decided to call them. Learn the columns once and you can read all three platforms. We unpack each column properly in [Phase 2](02-the-building-blocks.md). 💡 **Key point.** Don't learn "AWS." Learn the *concepts* - compute, storage, network, managed services, identity - and treat each vendor's service names as a translation layer. That knowledge moves with you between jobs; memorized service names mostly don't. ## A note on plain talk: which one is "best"? You'll see endless arguments about AWS vs GCP vs Azure. The real answer: for the building blocks in this guide, they're far more alike than different, and which one a company uses is usually decided by history, existing contracts, and which one the team already knows - not a clean technical win. AWS is the oldest and broadest; GCP is often praised for data and Kubernetes heritage; Azure tends to show up where an organization already lives in the Microsoft world. Those are tendencies, not laws - any concrete "X is faster/cheaper" claim depends on the specific service and workload, so don't trust a blanket version of it (including from me). ## Recap 1. The cloud is **rented computing on demand** - it deletes the up-front cost and guesswork of owning physical servers. 2. It sells four buckets: **compute** (machines), **storage** (durable data), **network** (the wiring), and **managed services** (the cloud running hard software for you). 3. Pricing is **metered** - pay for what you use, which is the appeal *and* the trap, because the meter doesn't stop on its own. 4. **AWS, GCP, and Azure are the same shape** with different names; learn the concepts, treat the names as translation. Now that you know the buckets, let's open them and name the pieces across all three vendors. --- # The Building Blocks (Across Vendors) In Phase 1 you learned the four buckets. Now we open them and name the five or six pieces you'll meet on almost any project - enough that when a teammate says "put it in S3" or "give the function an IAM role," you know exactly what they mean, on any of the three platforms. Each block gets what it is, what it's for (and *not* for), a real command, and what each vendor calls it. The full name-mapping table is at the end. ## 1. Compute - a machine to run your code A computer you rent: CPU, memory, a disk, an operating system. Pick a size, it boots, and you run your program on it like a laptop, except it lives in the provider's data center. The classic form is a **virtual machine (VM)**: a full computer, simulated in software, that behaves like a real one - this is where your application server, background workers, and batch jobs run. "Spin up an instance" means *rent one of these and boot it*. 📝 **Virtual machine (VM).** A complete simulated computer carved out of a bigger physical one. It has its own OS and feels like a dedicated machine, though the provider may run several VMs on the same hardware. To your code, it's just "a Linux box." Example (AWS): ```console $ aws ec2 run-instances --image-id ami-0abcd1234 --instance-type t3.micro --count 1 { "Instances": [ { "InstanceId": "i-0a1b2c3d4e5f67890", "InstanceType": "t3.micro", "State": { "Name": "pending" } } ] } ``` *What just happened:* AWS returned an `InstanceId` - your handle for that machine - with state `pending`, meaning it's booting. From the moment it reaches `running`, the meter is on until you stop it. **What each vendor calls it:** AWS **EC2** (Elastic Compute Cloud), GCP **Compute Engine**, Azure **Virtual Machines**. ## 2. Object storage - a bottomless bucket for files A place to store **files** - images, videos, backups, logs, uploads - that's effectively limitless, very durable, and reached by a name rather than a file path. You `put` a file under a key and later `get` it back by that key; no disk to mount. Each file is an **object**, living in a container called a **bucket**. Anything file-shaped lands here because it's cheap per gigabyte and you never run out of room. ⚠️ **Object storage is not a database and not a hard drive.** You can't query it ("give me all uploads from June"), and you can't edit byte 4,000 in place - you replace the whole object. It's for *whole files you read and write as a unit*, not *structured data you query or rows you update*. Reaching for object storage when you needed a database is one of the most common early cloud mistakes. Example (S3): ```console $ aws s3 cp report.pdf s3://acme-uploads/reports/report.pdf upload: ./report.pdf to s3://acme-uploads/reports/report.pdf ``` *What just happened:* The file is stored under the key `reports/report.pdf` in bucket `acme-uploads`. That `reports/` looks like a folder, but object storage is a flat namespace of keys - slashes are just for readability. **What each vendor calls it:** AWS **S3** (Simple Storage Service), GCP **Cloud Storage**, Azure **Blob Storage**. ## 3. Managed databases - a database without the sysadmin job The headline *managed service* from Phase 1. You still get a real database - usually PostgreSQL or MySQL - but you don't install it, patch it, configure replication, or set up backups by hand. Choose the engine and size, click create, and the provider hands you a hostname and port, then keeps it running, patched, and backed up. This lets a small team have a well-run production database without hiring the person who runs databases - the trade is cost (a premium over raw VMs) and less control over the deep knobs. Example (RDS): ```console $ aws rds create-db-instance \ --db-instance-identifier acme-prod \ --engine postgres \ --db-instance-class db.t3.medium \ --allocated-storage 50 \ --master-username admin { "DBInstance": { "DBInstanceIdentifier": "acme-prod", "Engine": "postgres", "DBInstanceStatus": "creating" } } ``` *What just happened:* `creating` means RDS is provisioning the machine, installing PostgreSQL, and wiring up automated backups. Minutes later you get an endpoint to connect to - no `apt install postgresql` required. **What each vendor calls it:** AWS **RDS** (Relational Database Service), GCP **Cloud SQL**, Azure **Azure SQL Database** / **Azure Database for PostgreSQL/MySQL**. > 📝 "Relational" means tables, rows, and SQL - the same Postgres/MySQL you may already know. All three > also sell other database *kinds* (key-value, document, graph), but managed-relational is the one > you'll meet first and most often. ## 4. Networking (VPC) - your own private slice of the network By default you don't want your database exposed to the open internet. A **VPC** (Virtual Private Cloud) is your own private, walled-off network *inside* the provider - machines talk to each other freely, but the outside world can't reach in unless you explicitly open a door. A typical setup: web servers sit in a part reachable from the internet (through a load balancer); the database sits in a part that isn't, accepting connections only from those web servers. Most "my app can't reach the database" mysteries are network rules, not code - a security group blocking the connection, or a database placed where the app can't reach it - so when connectivity breaks, look here first. 📝 **VPC (Virtual Private Cloud).** A logically isolated network you own within the provider. Your instances, databases, and load balancers live inside it with private addresses; you control exactly which traffic is allowed in from the internet and which stays internal. **What each vendor calls it:** AWS **VPC**, GCP **VPC**, Azure **Virtual Network (VNet)**. (Two of three literally agree on the name.) ## 5. Identity & permissions (IAM) - who is allowed to do what **IAM** (Identity and Access Management) decides *who* (a person, or a piece of software) is allowed to do *what* (read this bucket, start that machine, touch nothing else) - it's the lock on every door in the cloud. The non-obvious part: IAM isn't only for *people*. Your running code gets an identity too, via a **role** - "this machine may read the `acme-uploads` bucket and nothing else" - so your code reads files without a password or key hard-coded into it. That confuses everyone at first, because we're used to identities being human. 📝 **Role.** A bundle of permissions that an identity - often running software, not a person - *assumes* to do its job. Roles are how code gets permissions without hard-coded credentials. Example (who am I): ```console $ aws sts get-caller-identity { "UserId": "AIDAEXAMPLE12345", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/nika" } ``` *What just happened:* AWS identified the credentials you're acting as - IAM user `nika`. Every command is checked against what *that* identity is allowed to do; if `nika` lacked permission, the command would have been denied regardless of how correct it was. ⚠️ **IAM is where people grant too much "to make it work."** When something is denied, the tempting fix is broad, sweeping permissions so the error goes away - that's how over-permissioned systems are born, and a leaked over-permissioned credential turns a small mistake into a big breach. The real fix: grant the *specific* permission the action needed. More on why IAM is the gotcha that scales worst in [Phase 3](03-iaas-paas-serverless.md). **What each vendor calls it:** AWS **IAM**, GCP **IAM**, Azure **Entra ID** (formerly Azure AD) for identities plus **RBAC** for permissions. ## The cheat sheet: one concept, three names The left column is what's worth learning; the rest is translation. | Concept | What it's for | AWS | GCP | Azure | |---|---|---|---|---| | **Compute (VM)** | Run your code | EC2 | Compute Engine | Virtual Machines | | **Object storage** | Store files / blobs | S3 | Cloud Storage | Blob Storage | | **Managed relational DB** | A database, run for you | RDS | Cloud SQL | Azure SQL Database | | **Private network** | Isolate & control traffic | VPC | VPC | Virtual Network (VNet) | | **Identity / permissions** | Who can do what | IAM | IAM | Entra ID + RBAC | 💡 **Key point.** Five rows cover the large majority of everyday cloud conversation across all three platforms. The other one-hundred-and-ninety service names are variations and specializations layered on top of these. ## Recap 1. **Compute** - rented machines that run your code. 2. **Object storage** - a bottomless bucket for *files*; not a database, not an editable disk. 3. **Managed databases** - a real database the provider runs, patches, and backs up for you. 4. **Networking** - your private walled-off network; where connectivity is granted or denied. 5. **Identity** - who, human or code, is allowed to do what. You now have the nouns. The last question is how *managed* you want each piece to be - and the trade-offs hiding in that choice. --- # IaaS vs PaaS vs Serverless, and Staying Sane There's one more dimension to the building blocks, and it quietly shapes every cloud decision: *how much of the work do you want to do yourself?* The same outcome - "run my code" - can be bought at several levels of done-for-you, from "here's a bare machine, you handle everything" to "here's a place to paste a function, we handle the rest." This phase gives you that spectrum, then names the three things that turn an otherwise fine cloud setup into a bad week - and how to defuse each before it bites. ## The spectrum: IaaS → PaaS → Serverless It's one dial, not three separate worlds. As you slide toward "more managed," you do *less operations work* - and you also get *less control* and bind yourself a little tighter to the provider. Nothing here is "better"; they're trades. ```mermaid flowchart LR IaaS["IaaS (raw VM)
You: OS, runtime, deploy, code
Them: the hardware

EC2, Compute Engine, VMs"] PaaS["PaaS (a platform)
You: your code + config
Them: OS, runtime, scaling

App Engine, Elastic Beanstalk, App Service"] SL["Serverless (functions)
You: one function's code
Them: ALL the rest, incl. idle

Lambda, Cloud Functions, Azure Functions"] IaaS -->|"more managed →
less control, less ops work"| PaaS PaaS --> SL ``` ### IaaS - Infrastructure as a Service (the raw VM) The provider gives you the machine; everything *on* it is yours. You pick the OS, install the runtime, configure the web server, set up deploys, and keep it patched. This is EC2 / Compute Engine / Azure VMs from Phase 2. **The trade:** maximum control and flexibility - it's just a computer, you can do anything - in exchange for maximum operational work. You are the sysadmin. ### PaaS - Platform as a Service (a place to run your app) You hand the platform your *application code* and a little configuration; it provides the operating system, the language runtime, the scaling, and the deploy mechanics. You stop thinking about the machine and think only about your app. 📝 **PaaS.** A managed platform that runs your application for you. You provide code; the provider provides and operates everything underneath it (OS, runtime, scaling). Examples: AWS Elastic Beanstalk, GCP App Engine, Azure App Service. **The trade:** far less ops work than IaaS, at the cost of fitting the platform's expectations (its supported runtimes, its way of deploying, its limits). You give up some control to stop being a sysadmin. ### Serverless - functions that run on demand (FaaS) You upload a single function. The provider runs it *only when something triggers it* - an HTTP request, a file landing in a bucket, a scheduled timer - and you pay only for the time it actually runs. There's no machine to manage, and when nothing's calling it, nothing's running. "Serverless" doesn't mean no servers; it means *you* never see, size, or manage them. 📝 **Serverless / FaaS (Functions as a Service).** You deploy a function, not a machine. The provider runs it on demand, scales it from zero to many automatically, and bills per execution. Examples: AWS Lambda, GCP Cloud Functions, Azure Functions. **The trade:** the least ops work of all, and you pay nothing while idle - wonderful for spiky or occasional workloads. In exchange you accept the platform's constraints (time limits, a "cold start" delay after idle, limited execution environments) and the *deepest* coupling to that provider's way of doing things. 💡 **Key point.** Read the dial as: *more managed = less control + less ops + tighter coupling.* There's no universally right spot. A team that wants to tune everything leans IaaS; a team that wants to ship and not babysit leans PaaS or serverless. Most real systems mix all three. --- ## Staying sane: the three gotchas that actually hurt The platforms work. What ruins people's weeks isn't the technology failing - it's three predictable traps, named here before they bite, with the calm move for each. ### Gotcha 1 - Surprise bills (the meter you forgot) ⚠️ **This is the one that ends up in horror stories.** Because pricing is metered (Phase 1), anything left running bills you silently: a beefy machine spun up "just to test" and never shut down; a managed database sized for launch-day traffic nobody scaled back; a misconfigured job that loops and re-runs; or data egressing to the internet (outbound network transfer is often charged, and it surprises people). No alarm sounds - the invoice just arrives. **The calm move: set a budget with alerts before you do anything else.** Every provider lets you define a spending threshold and get emailed (or paged) when you approach it - the single highest-value ten minutes in any new cloud account. ```console $ aws budgets create-budget --account-id 123456789012 \ --budget '{"BudgetName":"monthly-cap","BudgetLimit":{"Amount":"50","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \ --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"you@example.com"}]}]' ``` *What just happened:* You created a monthly budget called `monthly-cap` and told AWS to email you the moment your *actual* spend crosses 80% of it - turning a silent meter into one that taps you on the shoulder early, while a mistake is still cheap to fix. (GCP and Azure have the same feature: GCP "Budgets & alerts," Azure "Cost Management budgets.") 📝 **A budget alerts you; it does not stop spending.** The cloud won't auto-stop your resources at $50 - it just emails you. Stopping the spend is still your action. Treat the alert as a smoke detector, not a circuit breaker. ### Gotcha 2 - IAM complexity (permissions that grow into a swamp) **Why it bites.** IAM (Phase 2) starts simple and compounds. Each new service needs permission to talk to the others, and the path of least resistance when something is denied is to grant broad, sweeping access "to make it work." Do that a few dozen times and half the identities can do almost anything, nobody remembers why, and a single leaked credential is a catastrophe instead of a contained incident. **The calm move: least privilege, on purpose.** Grant each identity the *specific* permissions its job needs and no more. When you hit an "access denied," resist widening the door - read what was actually denied and grant exactly that. Slower in the moment, dramatically safer over the life of the system. 📝 **Least privilege.** The principle of giving each identity (person or code) only the permissions it genuinely needs. The opposite - "just give it admin" - is the most common and most dangerous IAM shortcut. 🪖 **War story shape.** The breaches you read about are rarely "the hacker defeated the cloud" - far more often "a key with too many permissions leaked, and because it could touch everything, so could whoever found it." Over-permissioning turns a small leak into a big one. That's why this gotcha is worth the friction. ### Gotcha 3 - Lock-in (the exit you didn't plan) The more managed and provider-specific the services you build on, the harder it is to ever leave that provider. Build everything on plain VMs and a standard PostgreSQL database, and you could move to another cloud (or your own servers) with effort but no rewrite. Build deeply on one provider's proprietary serverless triggers, managed queues, and specialized databases, and your application is woven into *that* provider - moving means rewriting. **The clear-eyed framing: lock-in is a trade, not a sin.** Those deeply-managed, provider-specific services are often genuinely the most productive way to ship. The mistake isn't using them; it's using them *without knowing you're making the trade.* Decide deliberately how much portability this system is worth. **The calm move: keep the expensive-to-move parts portable, and manage it all as code.** Your data and core application logic are the painful things to migrate, so favor standard, portable choices there (a normal SQL database over a proprietary one, your own code over platform-specific glue) where it matters. Describe your whole setup in **infrastructure as code** so it's reproducible and reviewable, not a pile of hand-clicked console settings nobody can recreate. > ⏭️ That last point deserves its own skill. Defining your cloud resources in version-controlled files - > so the whole environment can be rebuilt, reviewed, and (partly) re-pointed at another provider - is > exactly what [Infrastructure as Code with Terraform](/guides/infrastructure-as-code-terraform) > teaches. It's the antidote to both "what did we even click to set this up?" and the worst of lock-in. ## Recap 1. **IaaS → PaaS → Serverless is one dial:** more managed means less ops work, less control, and tighter coupling. Pick a spot per workload; most systems mix all three. 2. **Surprise bills:** the meter runs on anything left on. Set a **budget with alerts** first - but know it warns, it doesn't stop. 3. **IAM complexity:** grant **least privilege** on purpose; resist widening permissions "to make it work," because over-permissioning is how small leaks become big breaches. 4. **Lock-in:** it's a deliberate trade, not a sin - keep your data and core logic portable where it matters, and define everything as code. You now have the whole mental model: what the cloud sells, the blocks it's made of, and how to choose among them without getting burned. Next: stop clicking the console and start describing your infrastructure as code, so it's reproducible, reviewable, and yours.