--- id: 32 title: "Commit to one cloud, and go all-in native" status: current date: 2026-06-12 authors: - "Theo Zourzouvillys" tags: [architecture, infra, cloud] summary: "Cloud-independence is a false benefit: portability is the least common denominator, costing you the native services that are the point. For end products you run: commit to one cloud, go all-in native. Libraries, software others run, LLM-embeddables, and edge code are exempt." supersedes: null superseded_by: null aliases: ["32-commit-to-one-cloud-aws"] --- ## TL;DR Not all clouds are created equal, and **"cloud-independent" is a false benefit.** Staying portable across providers forces you onto the **least common denominator** — the small overlapping subset every cloud shares — so you give up the native power, integration, and managed services that are the entire reason to be on a cloud at all. The portability is insurance you will almost never claim, and **LLMs now make swapping an implementation easier than ever**, so its value is lower still. So **commit to a single cloud, pick it with real expertise, and go all-in native.** Be native *directly* to the platform: don't insert a portability layer, don't self-host worse versions of the managed primitives, and learn the platform's **availability model** and build within it. The one legitimate reason to run on two clouds is a **migration** from one to the other. *Which* cloud you pick is a separate, more perishable call — and one worth putting your name on; **mine, today, is AWS** ([ZFN-42](/zfn/42-my-one-cloud-is-aws/)). One scope carve-out: this is a rule for **end products — cloud-native systems you build and run yourself**. Libraries, services designed for *other* entities to run, components built for an LLM to embed in someone else's product, and code for remote devices (a boat, local infrastructure) obviously can't bind to your cloud — for them, portability isn't superstition, it's the product requirement. ## Context "Multi-cloud" and "cloud-agnostic" sound like prudence, and they're usually the opposite. The promise is freedom and leverage; the reality is a **tax you pay every single day for an option you almost never exercise**: - **The least-common-denominator trap.** To stay portable, you can only use what *all* your target clouds offer the same way — so you wrap everything in abstraction layers, avoid the genuinely great native services, and reimplement (worse) what the platform already does brilliantly. You bought a cloud and then refused to use it. - **The insurance rarely pays out, and is cheaper to skip now.** Wholesale cloud migrations are rare, deliberate, and large; you don't get there by accident, and a thin abstraction wouldn't save you anyway. And LLMs have dropped the cost of *re-implementing* against a different provider so far ([ZFN-23](/zfn/23-iterate-and-rewrite-implementations/)) that pre-paying for portability makes even less sense than it used to. - **The complexity is capability, and mastering it is a skill.** A powerful cloud is sprawling, has a thousand services, and carries real baseline complexity. That complexity is *capability*, and finding it overwhelming is a knowledge-and-skill problem, not a reason to flee to something that does less — the answer is to work with people who genuinely understand the platform. This isn't anti-standards. Use standard *protocols and formats* ([ZFN-30](/zfn/30-use-standards-dont-reinvent/)); own your *domain components* ([ZFN-31](/zfn/31-own-your-components/)). This note is about the layer underneath: **lean on your one cloud's managed primitives instead of abstracting them away or self-hosting worse versions.** ## Recommendation **Pick one cloud you deeply understand, commit, and use it natively.** - **Commit to a single cloud — and pick it with real expertise.** Don't make this call without genuinely understanding the platforms; it's hard to reverse and sets your ceiling. *Which* one is the perishable part — see the callout below. - **Be native directly to the cloud.** Don't insert a portability layer between you and the platform. The whole value is the deep integration — use it. - **Understand the availability model, and build within it.** Learn your cloud's actual reliability guarantees — its **region** and **zone** model, what each service promises, what's zonal vs regional vs global — and design and deploy *within* it: spread across zones, contain failure inside a region, treat the region as your blast-radius boundary. A great deal of "the cloud failed us" is really a failure to understand and respect this model. - **Don't add an orchestration layer for portability's sake.** A common version of the least-common- denominator trap is reaching for a portable control plane (often Kubernetes) you don't actually need — an entire extra layer of complexity adopted *to* stay cloud-neutral. Prefer the platform's own native compute and orchestration unless you have a truly exceptional, specific reason. - **Go all-in on the native managed primitives.** Messaging, streams, identity, ingress, multi-account networking, databases, migration tooling, certificates — your cloud's managed versions are almost always better than what you'd self-host, and they compose. Using them well is a beautiful thing. - **Don't fight the easy path — learn it.** The friction you feel reaching for an abstraction is usually the signal you haven't learned the native way yet. Invest in the platform knowledge; it pays back enormously. - **Document your systems and what each component does** ([ZFN-1](/zfn/1-engineering-decision-records/)) so the native architecture is legible and the next person inherits understanding, not folklore. **The one exception — multiple clouds while migrating.** The legitimate reason to run on two clouds is a **deliberate migration** from one to the other: for that window you straddle both, on purpose, with a plan to land on one. That's a transition, not an architecture — don't mistake the temporary state for a goal. **The scope carve-out — software whose runtime you don't own.** Everything above is about **end products: cloud-native systems you build and operate yourself**. Software *designed* to run somewhere you don't control is the opposite case, and for it portability isn't superstition — it's the product requirement: - **Libraries and frameworks.** They run inside someone else's stack, on whatever platform *that* team committed to; binding one to your cloud's primitives just shrinks who can use it. - **Services designed for other entities to run.** Self-hosted and on-prem software, anything a customer deploys and operates in their own environment — the cloud commitment is theirs to make, not yours to impose. - **Components built for LLMs to embed.** Tools, MCP servers, agent-composable pieces an LLM picks up and wires into *someone else's* end product or service — you can't know what platform that product went native on. - **Code for remote devices and local infrastructure.** A boat, a vehicle, field hardware at the edge — often there is no cloud reliably in reach at all, by design. The end product these things land *in* should still follow this note; the reusable pieces themselves have to meet their host where it is. > [!aside] Which cloud? — my current call > > This note is the durable part: *commit to one, go native.* **Which** cloud you pick is a separate, > more perishable decision — it depends on the state of the market the day you decide, and it's exactly > the kind of specific, contestable choice you put your name on rather than hedge. With deep hands-on > experience across all the majors, mine — today — is **AWS**, and I hold it as a conviction: > [ZFN-42 — *My one cloud is AWS*](/zfn/42-my-one-cloud-is-aws/). The principle here outlives that pick; > if the market shifts, the pick changes and the principle doesn't. ## Consequences **Easier:** - You use the best of the platform instead of the intersection of all platforms — native services, deep integration, far less glue and abstraction to build and carry. - Dramatically less operational surface: managed services instead of self-hosted ones, one identity and networking model to master, no portability control plane to operate. - One platform to get genuinely expert in, which compounds — the team's depth becomes real leverage. - Lower total complexity, which is the thing that actually slows teams down over time ([ZFN-20](/zfn/20-deliberate-complexity-is-often-simpler/)). **Harder — and honestly:** - **You are locked in, and that's the deal you're knowingly taking.** Deep native use means a real cost to ever leave. I think that trade is right — the daily benefit dwarfs the rare exit — but it is a genuine bet on one vendor, and you should make it with eyes open. - You're exposed to one provider's outages, pricing, and roadmap. (In practice, single-cloud done well is usually *more* reliable than multi-cloud done averagely.) - It's an opinionated, contestable call. Some regulated or specific situations genuinely require multi-cloud; if yours truly does, that's a real exception — but be sure it's real, not portability superstition. - The platform depth is a real investment; you have to actually build the expertise rather than paper over it with abstractions. ## References - [ZFN-42](/zfn/42-my-one-cloud-is-aws/) — the specific, current "which cloud" call this principle leads me to: AWS. - [ZFN-30](/zfn/30-use-standards-dont-reinvent/) — use standard protocols/formats; that's compatible with committing to one cloud's native services. - [ZFN-31](/zfn/31-own-your-components/) — own your domain components; lean on the cloud for managed primitives underneath them. - [ZFN-23](/zfn/23-iterate-and-rewrite-implementations/) — LLMs make re-implementing against a different platform cheap, which undercuts the case for pre-paid portability. - [ZFN-20](/zfn/20-deliberate-complexity-is-often-simpler/) — a portability layer (a control plane for its own sake) is accidental complexity you carry forever. - [ZFN-9](/zfn/9-no-long-lived-cloud-keys/) — going native means using your cloud's identity and federation properly. ## Changelog - **2026-06-12**: First published as a Field Note. - **2026-06-12**: Split into principle and pick — this note now holds the durable principle (commit to one cloud, go native); the specific "which cloud" call (AWS) moved to its own conviction, [ZFN-42](/zfn/42-my-one-cloud-is-aws/). - **2026-06-12**: Added the scope carve-out — this rule is for end products you build and run yourself; libraries, services other entities run, components built for LLMs to embed, and code for remote devices/local infrastructure are explicitly out of scope.