The cloud provider map: AWS, Azure and GCP
Wednesday, 16:00: another cloud provider promises StayHub 30% off its €101,000 monthly bill if it moves. Karim wants a yes or no by Friday, and you lead the answer.
AWS, Azure and Google Cloud look wildly different, but they sell the same dozen building blocks. Learn the blocks, and the names become labels.
- Problem
A team designs a hotel booking backend, then has to read job ads, docs and architecture diagrams full of names like EC2, Blob Storage, Cloud Run and Cosmos DB.
- Why the simple system fails
Learning each provider as a catalogue of hundreds of product names is overwhelming, and copying one provider's names into your design hard-wires you to it before you've decided anything.
- Engineering concept
Think in generic building blocks (compute, containers, serverless, object storage, SQL, NoSQL, queues, CDN, IAM, private networks). Each provider offers the same blocks under different names, with different details.
- Technology
AWS, Microsoft Azure and Google Cloud equivalents for each block; open standards (containers, PostgreSQL, S3-compatible APIs, OpenTelemetry, Terraform) as portability seams.
- Trade-offs
Proprietary managed services save huge amounts of work but bind you to a provider. Portability costs effort. Pay for it only where leaving is a realistic need.
The problem
2 min- Karim · CTOAnother provider says we'd pay 30% less than our €101,000 a month, plus €150,000 in credits. Yes or no by Friday.
- Maya · Product managerThat's a product team's salary every year.
- Lina · Senior engineer, your mentorYou lead this one. Commit to a first guess.
The big idea
4 minLock-in is an exit cost. Estimate it, then decide like any other investment.
The price list is the easy half. First translate StayHub into generic blocks, then find where each one is tied to our provider. That's where the real cost of moving lives.
How it works
5 min- 1Same blocks, different names
Every (AWS, Azure, Google Cloud) sells the same dozen generic building blocks: VMs, object storage, managed SQL, queues, CDN, IAM. Design with the job; map to brand names after (S3 = Blob Storage = Cloud Storage).
- 2Portable: standards
Our app VMs (plain Linux + setup scripts) and managed PostgreSQL are standards every provider offers. Moving is configuration and a careful data migration, not a rewrite.
- 3Medium: object storage
Copying 60 TB costs about €3,000. But the code calls the provider's SDK in 140 places.
- 4Hard: each provider's own model
Function triggers, retry rules, ~400 IAM policies, dashboards and runbooks are written for one provider. Nothing translates automatically. That's : not good or bad, just a cost.
- 5Seams keep the exit cheap
A seam is a small interface where a provider-specific piece plugs in (an adapter). A move then touches one file, not 140.
Watch a decision being made
4 minYou estimate the exit cost; Lina only checks
Give Karim a yes or no on moving by Friday, with numbers and a plan.
- 1Rate each block's portability
Easy: VMs, PostgreSQL, CDN. Medium: object storage, Kafka. Hard: function triggers, IAM, runbooks.
Why: Lock-in lives in specific places; naming them shows where the cost is.
- 2Price the move
Egress ≈ €3,000; engineering 4 people × 5 months ≈ €250,000; both clouds for 2 months ≈ €200,000. Total ≈ €450,000, break-even ≈ 15 months.
Why: Lina's check: estimates usually forget running both clouds. Even counting all the credits, break-even is ~10 months away.
- 3Compare with alternatives
A 1-year commitment on steady compute: ≈ €12,000/month, no move, no risk. And the pitch is a negotiating tool.
Why: "Move or don't" hides cheaper options.
- 4Lower the next exit cost, write it down
Stay; commit for a year; one sprint wrapping storage and queues behind adapters; an ADR with the exit estimate and a revisit date.
tsexport interface FileStore { put(key: string, body: Uint8Array, type: string): Promise<void>; signedReadUrl(key: string, seconds: number): Promise<string>; }Why: Seams make the next comparison cheaper and honest; the ADR stops the debate restarting from zero.
In real life
3 minSpotify: own data centres to Google Cloud
- Has publicly described migrating from its own data centres to Google Cloud
- Goal: focus engineers on the product, not data centres
- A multi-year, dedicated effort
Fits when running infrastructure distracts from the product.
37signals: cloud to its own servers
- Has publicly described leaving the cloud for owned hardware, citing large yearly savings
- Steady workloads and a team able to run hardware
- Gave up elasticity and managed services
Fits steady load, a capable ops team and a big, stable bill.
What goes wrong
3 minTimeouts, ordering, consistency and limits differ.
List the guarantees you rely on and check each before porting.
The big costs of moving are people and double-running.
Estimate the full exit cost; compare with commitment discounts.
You operate what a provider already runs, every week, for a move that may never come.
Managed services where they remove toil; seams where they're cheap.
Trade-offs
3 min| Strategy | Fits | You pay |
|---|---|---|
| All-in on one provider | Speed matters most; leaving unlikely | Highest exit cost |
| One provider, portable seams | Most companies with traction | Some discipline and extra code |
| Cloud-agnostic platform | Deploying into customers' clouds | You run databases and clusters yourself |
- Karim · CTO€30,000 a month is €360,000 a year. Paid back in 15 months, then pure savings. Let's move.
- Omar · On-call SREFive months of the platform team migrating. And that assumes their prices stay 30% lower once we're locked into them.
- Karim · CTOThen we'd negotiate with them.
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- Whether to move at all: ~€450,000 up front vs a commitment saving ~€12,000/month now.
- Where to add seams, in order: object storage first, then the queue. No rewrite you didn't ask for.
- Which behaviour must stay identical in any swap: delivery, timeouts, retries, permissions.
Introduce a FileStore seam for object storage. Today the S3 SDK is called directly in about 140 places. Plan first: list the operations we actually use, then one FileStore interface, one S3 adapter holding every SDK call, and call sites changed to use it. Same buckets, keys and signed URL expiry. No second provider's adapter, no queue changes. Show the interface, how many files change and how you'll split commits. When done, run the tests and prove no file outside the adapter imports the S3 SDK.
- The interface lists only operations used today, not a speculative "every cloud" layer.
- A search shows the S3 SDK imported only inside the adapter.
- The test suite passed, and commits are small enough to review.
- It copies settings between "equivalent" services without checking defaults.
- It proposes moving everything to plain VMs "to avoid lock-in".
- It builds adapters for three clouds when you asked for one seam.
Check yourself
2 minSelect all that apply.
Next module: two engineers spend a whole Monday untangling a merge, and a hotfix that was "in main" turns out to be missing from production.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Interactive simulation, Visual diagram, Analogy, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
You estimate the exit cost; Lina only checks
Give Karim a yes or no on moving to the other provider by Friday, with numbers, and a plan for whichever answer you choose.
- 1Translate to generic blocks
List every service StayHub uses and its generic block: app VMs (set up by scripts), managed PostgreSQL, object storage, queue + functions, managed Kafka, CDN, IAM, private network.
Why: You can only compare like with like once brand names become jobs.
- 2Rate each block's portability
Easy: app VMs, PostgreSQL, CDN. Medium: object storage (140 SDK calls), Kafka, network. Hard: function triggers, ~400 IAM policies, runbooks and dashboards.
Why: Lock-in lives in specific places. Naming them shows where the cost really is.
- 3Price the move
Egress ≈ €3,000; engineering ≈ 4 people × 5 months ≈ €250,000; dual running ≈ 2 months × €101,000 ≈ €200,000. Total ≈ €450,000, break-even ≈ 15 months. (The €150,000 of credits only pay for usage on the new cloud; even counted in full, break-even is still about 10 months away.)
Why: A rough number beats a feeling. Lina's check: include running both clouds, which estimates usually forget.
- 4Compare with alternatives
A 1-year commitment on steady compute: ≈ €12,000/month, no move, no risk. And the pitch's prices can be used to negotiate.
Why: "Move or don't" hides the cheaper options. The best decision is often a third one.
- 5Lower the next exit cost and write it down
Recommend: stay; commit for a year; spend one sprint wrapping storage and queues behind adapters; record an ADR with the exit estimate and a revisit date.
Why: Seams make the next comparison cheaper and more honest. An ADR stops the same debate from restarting from zero.
| Where lock-in hides | Why it's sticky | Containment |
|---|---|---|
| Proprietary databases | Data model + query API + volume to migrate | Standard engines for core data unless a proprietary one clearly earns it |
| IAM and networking | Every resource references them | Infrastructure as code; policies in modules |
| Function triggers and event wiring | Glue spread over many configs | Keep business logic in plain code that triggers call |
| Data egress | Moving terabytes costs time and money | Know your volumes; estimate before you need to |
| Team skills and runbooks | People, dashboards, habits | Document; use open tooling where cheap |
Interactive simulation
Visual diagram
One booking backend, drawn with generic blocks. Click a block to see its name on each cloud.
Analogy
- Supermarket chainsEvery chain sells milk, bread, pastaCloud providersEvery cloud sells the same blocks
- Supermarket chainsA list saying "milk, bread, pasta"Cloud providersDesigning with generic blocks
- Supermarket chains"Chain A's house-brand sauce"Cloud providersA provider-only service
- Supermarket chainsThe same branded pasta everywhereCloud providersOpen standards like PostgreSQL
Where the analogy breaks: switching supermarkets takes one trip. Switching clouds means moving data, rewriting permissions and retesting everything, which can take months.
Check your understanding
Practice ladder
Translate an Azure diagram
Explain Warm-upBergHotels runs its own systems on Azure. Their architecture diagram shows:
Front Door → Container Apps → Azure Database for PostgreSQL, plus Blob Storage for documents and Service Bus for messages between services, with Entra ID for staff logins.
- Write each one as a generic building block.
- Give the closest equivalents on the provider StayHub uses (AWS names).
- Which two would take the most care if StayHub ever had to run a copy of its integration inside BergHotels' Azure account?
Finish the storage adapter
Code PracticeLina's FileStore seam is in place. Fill in the two methods of the local-disk adapter used in development and tests, so booking code can run without any cloud. Then say why tests should use this adapter rather than the real cloud.
import { mkdir, writeFile } from "node:fs/promises";
import path from "node:path";
export class LocalDiskFileStore implements FileStore {
constructor(private root: string) {}
async put(key: string, body: Uint8Array, contentType: string): Promise<void> {
// gap A: ___
}
async signedReadUrl(key: string, seconds: number): Promise<string> {
// gap B: ___
}
}Make the email pipeline portable
Design PracticeStayHub's confirmation emails run as: booking service → provider queue → provider function (triggered by the queue) → email API. The function's code mixes three things: parsing the provider's event format, building the email, and calling the email API. Retry and dead-letter settings live only in the provider's console.
A hotel chain may ask StayHub to run this pipeline in their own cloud next year. Without moving anything now, make it cheap to move later. Say what you'd change, and what you'd deliberately leave provider-specific.
Proprietary NoSQL or Redis for sessions?
Decision StretchStayHub's sessions move out of the old single-zone Redis (episode 3). Two managed options on our provider:
- A: the provider's proprietary NoSQL key-value service: very scalable, multi-AZ by default, its own API and pricing model.
- B: a managed Redis-compatible cache in multi-AZ mode: a standard protocol every provider offers.
Facts: ~5,000 session reads per second; sessions expire after 24 h; nothing in them must outlive a session; BergHotels may require a deployment in their own cloud next year. Both options cost about the same today.
Write a short decision: "We chose X over Y because…, accepting the risk of…".
Explain it yourself
A colleague says: 'We must avoid vendor lock-in, so no managed services.' How do you respond?