Theo Zourzouvillys

Conviction 42conviction

My one cloud is AWS

By
Theo Zourzouvillys
Published
Tags
architectureinfracloudaws

TL;DR

ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-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.Open ZFN-32 → is the principle: commit to one cloud and go all-in native. This is the part I put my name on — which one. My guidance, with deep hands-on knowledge of all the majors: 100% AWS. It is in a league of its own, and I wouldn’t waste time going down another path.

Be native directly to it: don’t run Kubernetes; use ECSAWS Elastic Container Service (ECS)AWS's native container orchestrator — run containers as tasks and services on EC2 or Fargate, wired directly into IAM, ALB, CloudWatch, and the rest of AWS, without operating a Kubernetes control plane of your own.docs.aws.amazon.com ↗ unless you have a truly exceptional reason — k8s is an entire extra layer of complexity. Lean fully into the native products (SQS, SNS, Kinesis, IAM, ALB, Organizations with shared VPCs and RAM-managed subnets, RDS, DMS, ACM), and learn the Region/Availability-Zone model and build within it. Don’t fight the easy path — learn it. The one place I don’t go native: infrastructure-as-code — use OpenTofuOpenTofuAn open-source, community-governed fork of Terraform: declarative infrastructure-as-code with the broad provider ecosystem and HCL `.tf` authoring. Used here to provision AWS in place of CloudFormation.opentofu.org ↗, not CloudFormation. In a pre-LLM world CloudFormation’s native integration was worth its real pains; now that LLMs write .tf so well, it isn’t. The honest cost: you are deliberately locked into one specific vendor, and I’ll answer for that.

Context

This is a conviction, not an even-handed survey: it’s the specific, current call that ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-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.Open ZFN-32 → leads me to, and the kind of choice you make on earned judgment and put your name onField Note · currentZFN-41 — Make the technical choice you can put your name behindWhen two options would both work, it's fine to choose the one your experience lets you put your name behind, and to resist pressure that isn't about the merits — vendor incentives, politics, top-down preference. Owning the call costs capital up front; being right repays it.Open ZFN-41 →. The principle is durable; this pick is perishable — if the market genuinely shifts, this note gets superseded and ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-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.Open ZFN-32 → doesn’t move.

  • AWS is, in my experience, in a class of its own. People look down on it for being sprawling, having a thousand services, and a real baseline complexity. That complexity is capability, and finding it overwhelming is a knowledge-and-skill problem, not a product flaw — the answer is to work with people who genuinely understand it, not to flee to something that does less. There’s a reason AWS is as popular as it is and can charge what it does.
  • The second-contender hope, for now, is unrealised. There was a window where Google Cloud looked like it might become a genuine second contender, and real competition would have been good for all of us. That fight has, for now, been lost — AWS won it. I genuinely hope a strong new contender emerges, because the field badly needs one; but you build on what exists, not what you wish existed, and right now there simply isn’t an equal.

Recommendation

Pick AWS, commit, and use it natively — this is ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-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.Open ZFN-32 → applied, so the general moves (be native, no portability layer, document everything) carry over. The AWS specifics:

  • Choose AWS, full stop. With genuine cross-platform experience, this is the one I’d stake on; I wouldn’t spend the time evaluating another for a greenfield build.
  • Understand the availability model, and build within it. Learn AWS’s actual reliability guarantees — the Region and Availability Zone model, what each service promises, what’s zonal vs regional vs global — and design and deploy your systems within it: spread across AZs, 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 run Kubernetes; use ECSAWS Elastic Container Service (ECS)AWS's native container orchestrator — run containers as tasks and services on EC2 or Fargate, wired directly into IAM, ALB, CloudWatch, and the rest of AWS, without operating a Kubernetes control plane of your own.docs.aws.amazon.com ↗. k8s is a vast extra layer of complexity and operational surface you almost certainly don’t need, often adopted for portability — the false benefit again. ECS with managed EC2-backed instances (or Fargate) is fantastic, integrates natively with everything, and is a fraction of the burden. Reach for k8s only with a truly exceptional, specific reason.
  • Go all-in on the native products. They’re genuinely excellent and they compose: SQS and SNS for messaging, Kinesis for streams, IAM for identity, ALB for ingress, Organizations with shared VPCs and RAM-managed subnets for multi-account networking, RDS for databases, DMS for migration, ACM for certificates. Using these well is a beautiful thing.
  • The one exception to native — infrastructure-as-code. Provision with OpenTofuOpenTofuAn open-source, community-governed fork of Terraform: declarative infrastructure-as-code with the broad provider ecosystem and HCL `.tf` authoring. Used here to provision AWS in place of CloudFormation.opentofu.org ↗, not AWS CloudFormation. CloudFormation is the native IaC, and in a pre-LLM world its deep integration was genuinely worth its real pains — slow stacks, verbose templates, awkward drift and rollback. That calculus has flipped: LLMs now write Terraform/OpenTofu .tf so well that CloudFormation’s friction no longer earns its keep, and you get OpenTofu’s far larger ecosystem and ergonomics on top. You’re still 100% AWS — this isn’t portability theater, just a better authoring tool for the provisioning layer. It’s the same logic as ZFN-23Field Note · currentZFN-23 — Rewriting an implementation is fine — refactoring isn't always the answerRefactoring isn't always right. When the structure is wrong at the root, it's fine — often better — to rewrite an implementation from scratch. Clean interfaces and data models make the implementation disposable: stable contract, swappable internals. LLMs make it cheaper still.Open ZFN-23 →: once re-implementing against a different tool gets cheap, the integration tax stops being worth paying.
  • 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.

Consequences

Easier:

  • You use the best of AWS instead of the intersection of all clouds — native services, deep integration, far less glue and abstraction to build and carry.
  • Dramatically less operational surface: ECS instead of a k8s control plane, managed services instead of self-hosted ones, one identity and networking model to master.
  • One platform to get genuinely expert in, which compounds — the team’s depth in AWS becomes real leverage.

Harder — and honestly:

  • You are locked into AWS specifically, 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, 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, and a perishable one. If a real second contender emerges, or your situation genuinely demands otherwise, revisit it — but be sure it’s real, not portability superstition.
  • The platform depth is a real investment; you have to actually build the AWS expertise rather than paper over it with abstractions.

References

  • ECSAWS Elastic Container Service (ECS)AWS's native container orchestrator — run containers as tasks and services on EC2 or Fargate, wired directly into IAM, ALB, CloudWatch, and the rest of AWS, without operating a Kubernetes control plane of your own.docs.aws.amazon.com ↗ — AWS-native container orchestration; use it instead of running Kubernetes.
  • OpenTofuOpenTofuAn open-source, community-governed fork of Terraform: declarative infrastructure-as-code with the broad provider ecosystem and HCL `.tf` authoring. Used here to provision AWS in place of CloudFormation.opentofu.org ↗ — the IaC tool I reach for instead of CloudFormation, now that LLMs author .tf so well.
  • ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-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.Open ZFN-32 → — the durable principle this applies: commit to one cloud, go all-in native.
  • ZFN-41Field Note · currentZFN-41 — Make the technical choice you can put your name behindWhen two options would both work, it's fine to choose the one your experience lets you put your name behind, and to resist pressure that isn't about the merits — vendor incentives, politics, top-down preference. Owning the call costs capital up front; being right repays it.Open ZFN-41 → — why a call like this is one I put my name on, not a hedge.
  • ZFN-23Field Note · currentZFN-23 — Rewriting an implementation is fine — refactoring isn't always the answerRefactoring isn't always right. When the structure is wrong at the root, it's fine — often better — to rewrite an implementation from scratch. Clean interfaces and data models make the implementation disposable: stable contract, swappable internals. LLMs make it cheaper still.Open ZFN-23 → — LLMs make re-implementing against a different platform cheap, which undercuts the case for pre-paid portability.
  • ZFN-9Field Note · currentZFN-9 — No long-lived cloud keys; workloads authenticate by federated identityNo static AWS or GCP keys anywhere — not in code, secret stores, or env. Workloads use their runtime's own identity and cross clouds by exchanging it (OIDC) for short-lived credentials via federation. Static keys are a documented carve-out only.Open ZFN-9 → — going native means using IAM and federated identity properly.

Changelog

  • 2026-06-12: First published as a Field Note — split out of ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-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.Open ZFN-32 → to separate the durable principle (commit to one cloud) from this specific, current call (AWS).
  • 2026-06-12: Added the infrastructure-as-code exception — OpenTofu over CloudFormation, now that LLMs write .tf well enough that CloudFormation’s native integration no longer pays for its friction.