Theo Zourzouvillys

Conviction 42 conviction

My one cloud is AWS

By
Theo Zourzouvillys
Published
Tags
architectureinfracloudaws

TL;DR

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-32 leads me to, and the kind of choice you make on earned judgment and put your name on. The principle is durable; this pick is perishable — if the market genuinely shifts, this note gets superseded and 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-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-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-32 — the durable principle this applies: commit to one cloud, go all-in native.
  • ZFN-41 — why a call like this is one I put my name on, not a hedge.
  • ZFN-23 — LLMs make re-implementing against a different platform cheap, which undercuts the case for pre-paid portability.
  • 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-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.