system-design

Cloud Provider Primitives (AWS / GCP / Azure Rosetta Stone)

Every cloud offers the same dozen building blocks under different names. Learn the categories once, and the specific products become a lookup table.

Prerequisites: Building Blocks (Part 2), Containers Time to read: ~16 minutes

The idea

🚨 You don’t need to memorize hundreds of cloud products. Every cloud provides the same fundamental categories — compute, storage, networking, databases, messaging — and the trick is knowing the category and what it does. The specific product name (EC2 vs Compute Engine vs Virtual Machines) is trivia you can look up; understanding what a load balancer or an object store is is the real knowledge, and you already have it from Part 2.

🎙️ In an interview, use generic terms (“a load balancer,” “object storage,” “a managed message queue”) unless the interviewer is cloud-specific. Naming AWS products isn’t the skill; knowing what component you need is. This chapter is a translation table so you’re not lost when someone says “S3” or “Pub/Sub.”

The Rosetta Stone

Category	What it is	AWS	GCP	Azure
Virtual machines	Compute	EC2	Compute Engine	Virtual Machines
Serverless functions	FaaS	Lambda	Cloud Functions	Functions
Serverless containers	Run a container, managed	Fargate / App Runner	Cloud Run	Container Apps
Kubernetes	Orchestration	EKS	GKE	AKS
Object storage	Blobs	S3	Cloud Storage	Blob Storage
Block storage	Disk volumes	EBS	Persistent Disk	Managed Disks
File storage	Network filesystem	EFS	Filestore	Azure Files
Relational DB	Managed SQL	RDS / Aurora	Cloud SQL / AlloyDB	Azure SQL / DB
NoSQL key-value	Managed NoSQL	DynamoDB	Firestore / Bigtable	Cosmos DB
In-memory cache	Redis/Memcached	ElastiCache	Memorystore	Cache for Redis
Message queue	Queue	SQS	Cloud Tasks / Pub/Sub	Queue Storage / Service Bus
Pub/sub / streaming	Events	SNS / Kinesis / MSK	Pub/Sub / Dataflow	Event Hubs / Event Grid
Load balancer	LB	ELB (ALB/NLB)	Cloud Load Balancing	Load Balancer / App Gateway
CDN	CDN	CloudFront	Cloud CDN	Azure CDN / Front Door
DNS	DNS	Route 53	Cloud DNS	Azure DNS
API gateway	Gateway	API Gateway	API Gateway / Apigee	API Management
Secrets	Secrets	Secrets Manager	Secret Manager	Key Vault
Key management	KMS	KMS	Cloud KMS	Key Vault
Identity/access	IAM	IAM	Cloud IAM	Entra ID / RBAC
Data warehouse	Analytics	Redshift	BigQuery	Synapse
Monitoring	Observability	CloudWatch	Cloud Monitoring	Monitor
Object → event	Trigger on storage change	S3 events	Eventarc	Event Grid

🚨 The pattern: every cloud has one of each. When you design “load balancer → app servers → cache → database → object storage,” you’re picking one product from each row. The architecture is cloud-agnostic; only the names change.

The regions/AZ hierarchy

🚨 A universal concept that shapes availability and latency, and it comes up:

Region (geographic area: us-east-1, europe-west1)
  └─ Availability Zone (AZ) — an isolated datacenter with independent power/network
       └─ Your resources

Availability Zones are isolated failure domains within a region — separate power, cooling, networking, close enough for low-latency sync replication. 🚨 Deploy across multiple AZs by default — it protects against a single datacenter failure cheaply (an AZ can fail; your service survives). → Availability
Regions are far apart (different cities/countries). Multi-region protects against a whole-region failure and serves users geographically, but is expensive and complex. → Multi-Region & DR

The default posture: multi-AZ (cheap resilience), single-region until you need multi-region (geography or region-failure protection). Data residency (compliance) can force multi-region.

Managed vs self-hosted

🚨 The recurring cloud decision, and a strong interview point: almost every primitive comes as a managed service (the cloud runs it) or you self-host it (run it yourself on VMs/containers).

Managed (RDS, ElastiCache, MSK): the cloud handles patching, backups, failover, scaling, and availability. ✅ Vastly less operational burden — no on-call for the database, automated backups and failover. ❌ Costs more (2-3× the raw compute), less control (versions, config, extensions), some lock-in.

Self-hosted (Postgres on EC2): you run everything. ✅ Full control, cheaper in dollars. ❌ Expensive in engineer-hours — you’re on call for it, you build backups and failover and test them.

🎙️ The default answer for most teams is managed: “I’d use the managed database — automated backups, multi-AZ failover, and patching are things I’d otherwise have to build *and test. Self-hosting makes sense at a scale where the cost difference funds a dedicated team.”* Choosing managed is not a cop-out; it’s the sensible default, and saying so signals maturity. → Choosing a Database

Cloud-specific things worth knowing

IAM is the security backbone — 🚨 every cloud has an identity/access system, and getting IAM right (least privilege, roles not keys, workload identity) is central to cloud security. Overly-permissive IAM is a top breach cause.
The metadata endpoint (169.254.169.254) — instance credentials, and the SSRF target behind the Capital One breach.
Networking (VPC) — every cloud has virtual private networks, subnets, security groups/firewall rules. Everything runs inside a VPC; security groups control what talks to what (deny by default).
Spot / preemptible instances — deeply discounted, but can be reclaimed anytime. Great for fault-tolerant batch work. → Cost Optimization
Egress pricing — 🚨 data out to the internet is expensive; between AZs is billed; between regions more so. This dominates cost for data-heavy systems. → Cost

Multi-cloud and lock-in

⚖️ A trade-off that comes up:

Lock-in — using a cloud’s proprietary services (DynamoDB, BigQuery) ties you to that cloud. The managed convenience comes with dependency.

Multi-cloud (running on several clouds) reduces lock-in and single-provider risk, but 🚨 is genuinely expensive and complex — you can’t use the best proprietary services, everything must work on the lowest common denominator, and you double the operational surface.

🎙️ The pragmatic position: “I’d optimize for one cloud and its managed services rather than multi-cloud — the proprietary services are a big productivity win, and true multi-cloud portability costs more than the lock-in risk usually justifies. If portability matters, I’d use portable abstractions (Kubernetes, Terraform, open formats) rather than actually running on multiple clouds.” Most “multi-cloud” is aspiration; committing to one cloud well is usually the better call.

⚖️ Trade-offs

Choice	Gain	Cost
Managed services	Minimal ops burden; reliability built in	2-3× cost; less control; lock-in
Self-hosted	Control; cheaper dollars	Expensive engineer-hours; you build/test everything
Multi-AZ	Cheap resilience to datacenter failure	Slight cross-AZ latency/cost
Multi-region	Region-failure protection, geo-latency	Expensive, complex
Single cloud	Best proprietary services, simpler	Lock-in
Multi-cloud	No lock-in, no single-provider risk	Complexity, LCD services, doubled ops

In the real world

Managed services are the default for most companies because the operational leverage is enormous — a small team can run a globally-distributed, highly-available system using managed databases, queues, and storage that would otherwise require a large ops team. This is the cloud’s core value proposition.
Egress cost surprises are a recurring theme — teams design systems that shuffle large amounts of data across regions or out to the internet, then get a bill dominated by data transfer. It’s why CDN usage and keeping data flows local matter for cost.
The multi-cloud dream vs reality — many organizations aspire to multi-cloud for resilience and negotiating leverage, but few achieve genuine portability; most run primarily on one cloud with minor presence on another, because true multi-cloud sacrifices the proprietary services that make the cloud worthwhile.

🚨 Interview traps

Naming specific cloud products when generic terms suffice — say “object storage,” not “S3,” unless the interviewer is AWS-specific. Understanding the component matters, not the brand.
Not knowing the managed-vs-self-hosted trade-off — managed is usually the sensible default.
Not deploying multi-AZ by default — it’s cheap resilience.
Ignoring egress cost for data-heavy systems.
Proposing multi-cloud casually without acknowledging its real cost.
Overly-permissive IAM — a top breach cause.

🎙️ Soundbites

“Every cloud has the same categories — compute, object storage, managed SQL, a queue, a load balancer, a CDN — just under different names. I’d describe the architecture generically and the products are a lookup table.”
“Multi-AZ by default — it’s cheap resilience against a single datacenter failure. Multi-region only when geography or region-failure protection justifies the cost and complexity.”
“I’d use the managed database — automated backups, multi-AZ failover, and patching are things I’d otherwise have to build and, more importantly, test. Self-hosting makes sense at a scale where the savings fund a dedicated team.”
“Egress is the cost surprise — data out to the internet and across regions is expensive, so I’d keep data flows local and lean on a CDN.”
“I’d commit to one cloud and its managed services rather than multi-cloud. The proprietary services are a real productivity win, and genuine multi-cloud portability costs more than the lock-in risk usually justifies.”

🛠️ Try it

1. Map a design to three clouds. Take any architecture from Part 12 and pick the specific products from each of AWS, GCP, and Azure. Notice the architecture doesn’t change — only the names. That’s the whole point: the design is cloud-agnostic.

2. Deploy across AZs. Deploy a service across two availability zones (managed load balancer distributing across them). Then simulate an AZ failure (or read how the cloud handles it) and confirm the service survives. That’s the cheap resilience of multi-AZ.

3. Managed vs self-hosted, priced. For a real workload, price a managed database (RDS) against self-hosting Postgres on EC2 — including a fraction of an engineer’s salary for operations. Find where the crossover is. It’s usually much later than the raw compute difference suggests.

4. Find the egress cost. For a data-heavy scenario (serving media, cross-region replication), compute the monthly egress cost. Compare storage cost to transfer cost. For media, egress usually dominates — which is the argument for a CDN.

Check yourself

1. Why is it better to think in categories than to memorize cloud products?

Because every cloud provider offers the same fundamental categories — compute, serverless, object storage, block storage, managed SQL, NoSQL, cache, queue, pub/sub, load balancer, CDN, DNS, secrets, KMS — just under different brand names (S3 vs Cloud Storage vs Blob Storage). The real knowledge is understanding what each *category* does and when to use it: what a load balancer is, what object storage is for, when you need a queue. That knowledge is portable across clouds and is what you learned in Part 2. The specific product name is trivia you can look up in seconds and that changes between providers and over time. In an interview, describing "a load balancer in front of app servers, a cache, a managed relational database, and object storage behind a CDN" demonstrates the actual skill — knowing which components the system needs — whereas naming AWS products just shows you've used AWS. Memorizing hundreds of product names is low-value; understanding a dozen categories is high-value and transfers everywhere.

2. What's the difference between an availability zone and a region, and what's the default posture?

An **availability zone (AZ)** is an isolated datacenter within a region — with independent power, cooling, and networking, so it's a separate failure domain — but close enough to other AZs in the same region for low-latency synchronous replication. A **region** is a geographic area (a city or country) containing multiple AZs, and different regions are far apart. The distinction matters for resilience and latency: AZs protect against a single datacenter failure (power outage, fire) while staying fast to replicate between; regions protect against an entire region failing and let you serve users geographically, but are far apart so cross-region communication is slow and expensive. The default posture is **multi-AZ, single-region**: deploy across multiple AZs by default because it's cheap resilience against a datacenter failure (your service survives an AZ outage with minimal cost or latency impact), and stay single-region until you specifically need multi-region — for protection against a whole-region failure, to serve users in distant geographies with low latency, or because data residency compliance requires it. Multi-region is expensive and complex, so you adopt it deliberately, not by default.

3. When should you choose a managed service over self-hosting?

Almost always, for most teams — managed is the sensible default. A managed service (RDS, ElastiCache, managed Kafka) has the cloud provider handle patching, backups, failover, scaling, and high availability, so you don't operate that infrastructure. The trade-off is that it costs more in dollars (typically 2-3× the raw compute) and gives you less control (which versions, configs, and extensions are available) with some lock-in. Self-hosting (running Postgres yourself on VMs) is cheaper in dollars and gives full control, but is far more expensive in engineer-hours: you build and *test* backups and failover, you're on call for the database at 3am, and you own capacity planning and upgrades. The decisive factor is usually that the operational tasks a managed service handles — especially *tested* backups and reliable automated failover — are things teams either don't build well or don't validate, so the managed premium buys reliability you'd struggle to match. Self-hosting makes sense at a scale where the dollar savings genuinely fund a dedicated team to operate it properly, or when you need control the managed service can't provide. Choosing managed is a maturity signal, not laziness.

4. Why does egress cost matter so much for data-heavy systems?

Because cloud providers charge asymmetrically for data movement: data flowing *in* is usually free, but data flowing *out* to the internet is expensive (often $0.05-0.09/GB), data crossing between availability zones is billed, and data crossing between regions costs more still. For compute-heavy or storage-heavy systems this is minor, but for data-heavy systems — serving media, video streaming, large API responses, cross-region replication, feeding analytics pipelines across regions — the volume of data transfer can dominate the total bill, often exceeding compute and storage costs combined. A service serving 100 TB/month of media might pay a few thousand dollars to *store* it and many thousands more to *serve* it. This is why it's a common cost surprise, why keeping data flows local (same AZ, same region) matters, and why CDNs are cost-effective for serving media — CDN egress is cheaper than origin egress and the CDN absorbs most requests, dramatically reducing origin egress. Understanding that egress, not compute, often drives cost for these systems is a strong senior signal in a design discussion.

5. What's the pragmatic position on multi-cloud vs committing to one cloud?

For most organizations, commit to one cloud and use its managed and proprietary services well, rather than pursuing genuine multi-cloud. Multi-cloud (actually running production across several providers) promises reduced lock-in and resilience against a single provider's failure, but the costs are steep and often underappreciated: you can't use each cloud's best proprietary services (DynamoDB, BigQuery, Spanner) because your workloads must run on the lowest common denominator that exists everywhere, you double the operational surface (two sets of tooling, IAM, networking, monitoring to master), and the complexity slows everything down. The proprietary managed services are a large part of what makes a cloud worthwhile, and forgoing them to stay portable usually costs more than the lock-in risk it avoids. The pragmatic middle ground: if portability genuinely matters, achieve it through *portable abstractions* — Kubernetes for orchestration, Terraform for infrastructure, open data formats — which give you an exit path without the cost of actually running multi-cloud today. Most "multi-cloud strategy" is aspiration; the productive move is to commit to one cloud deeply while keeping your architecture portable enough that migrating later is feasible if you ever need to.