Commit to one cloud, and go all-in native

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).

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) 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); own your domain components (ZFN-31). 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) 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.

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).

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 — the specific, current “which cloud” call this principle leads me to: AWS.
• ZFN-30 — use standard protocols/formats; that’s compatible with committing to one cloud’s native services.
• ZFN-31 — own your domain components; lean on the cloud for managed primitives underneath them.
• ZFN-23 — LLMs make re-implementing against a different platform cheap, which undercuts the case for pre-paid portability.
• ZFN-20 — a portability layer (a control plane for its own sake) is accidental complexity you carry forever.
• ZFN-9 — 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.
• 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.