A 34-minute working session on what "the cloud" actually is — the service models, the building blocks (compute, storage, networking), who's responsible for security, how the bill really adds up, and how the big three providers compare when you have to choose.
Strip away the marketing and the cloud is a simple trade: instead of buying servers and running a room full of them, you rent capacity from a provider over the internet and pay only for what you use. The real question isn't whether to use it — it's how much of the stack you want to manage yourself.
The catch: convenience has a price, lock-in is real, and a careless configuration can run up a bill or leak data. Everything ahead is about spending that trade wisely.
Move right and the provider takes over more of the stack. You always keep the work that's actually your business.
You rent raw building blocks — virtual machines, disks, networks — and manage the OS and everything above it. Maximum control, maximum responsibility.
Like leasing an empty apartment: walls and plumbing provided, you furnish it.
You push code; the platform runs it — handling the OS, runtime, patching, and scaling. Less control, far less ops.
Like a serviced apartment: you just move in and live there.
You just use finished software over the web — Gmail, Slack, Salesforce. The provider runs all of it; you only manage your data and users.
Like a hotel: someone else owns and runs everything.
Compute is where your code actually executes. The cloud gives you a spectrum: rent a whole virtual machine and manage it yourself, package your app into a lightweight container, or hand the provider a single function and forget servers entirely. Each step right means less control but less to operate.
Same code can run on any of these — the choice is how much of the machine you want to think about.
No main(), no port to bind, no fleet to size — the provider runs this on demand and bills per invocation.
You need a specific OS or kernel, legacy software, GPUs, or steady predictable load where always-on is cheapest.
You want portability, fast deploys, and dense packing — the default for microservices and most web backends today.
Traffic is spiky or low, or it's glue: webhooks, cron jobs, event handlers, lightweight APIs at the edge.
Not all storage is the same. Picking the wrong kind is a common, costly mistake — so it's worth knowing the three primitives every cloud offers and exactly what each is for: object for files at scale, block for disks, and file for shared folders.
Cheap, effectively infinite, reached over HTTP by key. No editing in place — you replace the whole object.
Use — images, video, backups, logs, static sites, data lakes.
S3 · Cloud Storage · Azure Blob
Behaves like a physical hard drive: format it, mount it, read and write blocks. Attached to one instance at a time.
Use— a VM's boot disk, databases, anything needing low-latency random writes.
EBS · Persistent Disk · Azure Disk
A managed network filesystem (NFS / SMB) many machines mount at once, sharing the same directory tree.
Use — shared assets, lift-and-shift apps that expect a POSIX path, content directories.
EFS · Filestore · Azure Files
Default to object storage— it's the cheapest and scales without limit. Reach for block only when a single machine needs a disk (a database, a boot volume), and file only when several machines must share one filesystem. Storage also comes in tiers: hot for frequent access, cold/archive for data you rarely read — moving stale data to a colder tier is one of the easiest ways to cut a bill.
Cloud resources live somewhere physical and talk over a virtual network you control. Four ideas cover almost everything: regions and availability zones (geography), the VPC (your private network), and the load balancer (the traffic cop). The wire-level primitives are in Networking.
One VPC spanning two zones. The load balancer spreads requests across both, so losing a whole data center just removes half the targets.
Run across ≥2 zones behind a load balancer and a single data center failing is a non-event. This is the cheapest reliability win in the cloud.
Put compute in the region closest to your users. A CDN caches static content at edge locations worldwide so it loads from nearby.
Networks get complex fast. Define them as code with Infrastructure as Code so they're reviewable and repeatable.
The single most important security idea in the cloud is knowing where the provider's job ends and yours begins. Get that line wrong and you leave the door open. The tool you use to lock things down is IAM — and the rule there is one word: least privilege.
The exact line shifts by service — more managed (PaaS, SaaS) moves more onto the provider — but your data and access are always yours to protect.
Grant the minimum, widen only when something genuinely breaks. Start from deny, not allow all.
Give workloads short-lived role credentials instead of long-lived access keys baked into code.
Multi-factor on every human login; encrypt data at rest and in transit — usually a single toggle.
Turn on access logging early. You can't investigate an incident you never recorded.
Cloud billing is usage-based: you pay for compute by the second, storage by the gigabyte-month, and — the part that ambushes everyone — data transfer out by the gigabyte. Knowing the four ways to buy compute, and where the hidden charges hide, is how you keep the bill sane.
Bytes flow in free and out at a price — here the egress dwarfs the actual server.
Pay by the second, no commitment, drop it anytime. The default — great for unpredictable or short-lived workloads.
Pro — zero commitment. Con — the most expensive per hour.
Promise 1–3 years of usage for a steep discount (often 40–70%). Best for your steady, always-on baseline.
Pro — large, predictable savings. Con— you're locked in.
Buy spare capacity at up to ~90% off — but the provider can reclaim it with minutes of warning. For fault-tolerant, restartable work.
Pro — cheapest by far. Con — can vanish anytime.
A small always-free allowance plus time-limited credits. Great for learning — but set a budget alertso a mistake can't snowball.
Pro — start at $0. Con — easy to drift past the limits.
AWS, Google Cloud, and Microsoft Azure offer the same primitives under different names. The building blocks you just learned transfer directly — only the labels change. Pick one and go deep; chasing multi-cloud early usually buys complexity, not freedom.
EC2 for VMs · ECS / EKS for containers.
Compute Engine for VMs · GKE for containers.
Virtual Machines · AKS for containers.
S3 (object) · EBS (block) · EFS (file).
Cloud Storage · Persistent Disk · Filestore.
Blob Storage · Managed Disks · Azure Files.
RDS / Aurora (SQL) · DynamoDB (NoSQL).
Cloud SQL / Spanner · Firestore (NoSQL).
Azure SQL · Cosmos DB (NoSQL).
Lambda (functions) · Fargate (serverless containers).
Cloud Functions · Cloud Run (containers).
Azure Functions · Container Apps.
Pro — the broadest, most mature catalog; the biggest community and hiring pool.
Con — sheer breadth is overwhelming; the console and pricing can feel sprawling.
Choose when you want the widest service selection and the deepest ecosystem and docs.
Pro — strong data, analytics, ML, and Kubernetes (its birthplace); clean DX.
Con — smaller service catalog; some products change or retire faster.
Choose when data/ML or containers are central, or you already lean on Google tooling.
Pro — deep Microsoft integration (AD, Office, Windows); strong enterprise sales.
Con — the portal and naming can be inconsistent; best value tied to the MS stack.
Choosewhen you're a Microsoft / Windows / enterprise shop with existing licensing.
Five quick questions on service models, compute, storage, security, and pricing — instant feedback, no sign-in.
Navigate with ← → or scroll · back to library