--- id: 42 title: "My one cloud is AWS" status: current kind: conviction date: 2026-06-12 authors: - "Theo Zourzouvillys" tags: [architecture, infra, cloud, aws] references: - id: ecs title: "AWS Elastic Container Service (ECS)" url: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html abstract: "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." - id: opentofu title: "OpenTofu" url: https://opentofu.org/ abstract: "An 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." summary: "Applying the one-cloud principle (ZFN-32), my pick is AWS — 100%, a league of its own. Go native: skip Kubernetes, use ECS; lean into SQS, SNS, Kinesis, IAM, ALB, RDS. The one exception to native — provision with OpenTofu, not CloudFormation, now that LLMs write .tf so well." supersedes: null superseded_by: null aliases: [] --- ## TL;DR [ZFN-32](/zfn/32-commit-to-one-cloud/) 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 [ECS](ref:ecs)** 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 [OpenTofu](ref:opentofu), 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](/zfn/32-commit-to-one-cloud/) leads me to, and the kind of choice you make on earned judgment and [put your name on](/zfn/41-choices-you-can-put-your-name-behind/). 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. > [!aside] This isn't a new position > > I've given this same AWS recommendation since at least 2015 — back when people told me, with complete > confidence, that you *couldn't possibly* build a telco in the cloud. We did. This isn't a fashionable > new take; it's well over a decade of watching the same answer keep being the right one. ## 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 [ECS](ref:ecs).** 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 **[OpenTofu](ref:opentofu)**, 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](/zfn/23-iterate-and-rewrite-implementations/): 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 - [ECS](ref:ecs) — AWS-native container orchestration; use it instead of running Kubernetes. - [OpenTofu](ref:opentofu) — the IaC tool I reach for instead of CloudFormation, now that LLMs author `.tf` so well. - [ZFN-32](/zfn/32-commit-to-one-cloud/) — the durable principle this applies: commit to one cloud, go all-in native. - [ZFN-41](/zfn/41-choices-you-can-put-your-name-behind/) — why a call like this is one I put my name on, not a hedge. - [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-9](/zfn/9-no-long-lived-cloud-keys/) — going native means using IAM and federated identity properly. ## Changelog - **2026-06-12**: First published as a Field Note — split out of [ZFN-32](/zfn/32-commit-to-one-cloud/) 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.