Cloud Fundamentals

1IaaS / PaaS / SaaS / FaaS

The whole cloud is a spectrum of "how much does the provider manage for you?"

The classic analogy is pizza-as-a-service: make it at home (on-prem), take-and-bake (IaaS), delivery (PaaS), dine out (SaaS). As you move up, you trade control for convenience:

• IaaS — raw building blocks: VMs, storage, networks (e.g. EC2). You manage the OS and up. Maximum control.
• PaaS — a managed platform; you deploy code, the provider runs the servers, scaling, and patching (e.g. App Engine, Heroku).
• FaaS / Serverless — you deploy individual functions; the provider runs them on demand and you pay per execution (e.g. Lambda).
• SaaS — finished software you just use (e.g. Gmail). Zero infrastructure.

2Compute options

Compute is where your code runs, and the cloud offers a ladder of abstraction:

• VMs (EC2) — full control, you manage the OS; good for legacy apps or specific needs. You pay while it runs, idle or not.
• Containers (ECS / EKS) — run Docker images (Module 09) with orchestration; the modern default for most services.
• Serverless functions (Lambda) — event-triggered code, auto-scaled to zero, pay per invocation. Brilliant for spiky or event-driven workloads.

The choosing principle: let go of as much operational burden as the workload allows. Steady, high-traffic services often suit containers; sporadic, event-driven tasks suit serverless; only reach for raw VMs when you genuinely need OS-level control.

3Storage — S3 & friends

Cloud storage comes in three shapes, and matching them is a common question:

• Object storage (S3) — store files/blobs as objects with metadata, accessed by key over HTTP. Effectively infinite, cheap, durable. The home for images, backups, static sites, data lakes. Not a filesystem.
• Block storage (EBS) — raw volumes you attach to a VM like a hard disk; low latency, for databases and OS disks.
• File storage (EFS) — a shared network filesystem multiple machines mount at once.

S3 deserves special note: it's the workhorse of the cloud. Its durability ("eleven nines") comes from automatically replicating objects across multiple facilities, and storage classes (Standard → Infrequent Access → Glacier) trade retrieval speed for cost. Knowing object vs block vs file, and reaching for S3 for static assets, is the expected fluency.

4VPC & networking basics

A VPC (Virtual Private Cloud) is your own isolated network within the cloud, where you place your resources. The basic anatomy you should be able to sketch:

Subnets segment the VPC — public ones (e.g. load balancers) can reach the internet via an internet gateway; private ones (app servers, databases) cannot be reached directly, which is exactly what you want for a database. Security groups are stateful virtual firewalls on each resource controlling allowed traffic. The principle is defense in depth (Module 05): your database sits in a private subnet, reachable only from the app tier — never the open internet.

5Managed databases

Running your own database means handling backups, patching, replication, failover, and scaling — undifferentiated heavy lifting. Managed database services (RDS for relational, DynamoDB for NoSQL, ElastiCache for Redis) hand that operational burden to the provider so you focus on your schema and queries (Module 03), not on babysitting servers.

The tradeoff is the usual cloud bargain: less control and some lock-in, in exchange for automated backups, point-in-time recovery, multi-AZ failover, and one-click read replicas. For the vast majority of teams, managed is the right default — you reach for self-managed only with unusual requirements. Mentioning multi-AZ for high availability ties straight back to Module 07.

6IAM — roles & policies

IAM (Identity and Access Management) controls who can do what. The pieces: users and groups (identities), policies (JSON documents granting specific permissions on specific resources), and — the important one — roles (a set of permissions that can be assumed temporarily, including by services).

The senior point is least privilege (Module 05): grant the minimum permissions needed, nothing more. And prefer roles over long-lived keys — a Lambda or EC2 instance should assume a role to get short-lived, automatically-rotated credentials, rather than embedding a static access key that can leak and never expires. "Roles, not hard-coded keys, scoped to least privilege" is the answer that signals real cloud experience.

7Messaging — SQS, SNS, EventBridge

The cloud-native versions of the queues and events from Module 06, fully managed:

• SQS — a managed message queue; one producer to one consumer group, work pulled and processed once. For decoupling and load-leveling.
• SNS — pub/sub fan-out; one message pushed to many subscribers at once. For broadcasting an event.
• EventBridge — an event bus with content-based routing rules; the backbone of event-driven architectures across services and SaaS.

The classic pattern to name is SNS + SQS fan-out: publish once to SNS, which pushes to several SQS queues, each consumed independently and resiliently. It's the Observer pattern (Module 01) as managed infrastructure.

8Serverless patterns

Serverless shines for event-driven, glue-style work. The canonical pattern: an event source (an S3 upload, an API call, a queue message, a schedule) triggers a Lambda that does one job and exits. Compose these and you get whole systems with no servers to manage.

A textbook example: a user uploads an image to S3 → that event triggers a Lambda → the Lambda generates thumbnails and writes them back. No always-on server, automatic scaling, pay only per upload. Other staples: API Gateway + Lambda for HTTP APIs, and scheduled Lambdas replacing cron jobs. The mental model is "functions wired to events" — cheap, scalable, and operationally light, as long as you respect cold starts and time limits.

9Cloud cost thinking

In the cloud, architecture is cost — every design decision has a price, and cost-awareness is a genuine seniority signal. The fundamentals: you pay for what you provision (or invoke), so right-size resources, turn off idle ones, and pick the model that matches the load (reserved/savings plans for steady workloads, on-demand for spiky, spot for interruptible).

The biggest surprises are usually data transfer (egress out of the cloud is expensive — keep chatty services in the same region/AZ) and forgotten resources quietly billing. Tagging, budgets, and alerts catch these. The senior framing: treat cost as a first-class non-functional requirement alongside latency and availability — "the elegant design that bankrupts the company isn't elegant."