AWS FOR THE REAL WORLD
⏱️
Reading time: 10 minutes
🎯
Main Learning: Every convenience layer AWS built on ECS is dead or dying, while ECS itself has not
changed since 2014. Build on the primitive, and make the layer above it prove itself first.
Hey 👋🏽 Getting started with an AWS service often feels more complicated than it should. - Four concepts must be understood before a single container runs.
- A VPC is required before a single request.
So, the fancy CLI that promises to do all of it for you is tempting. One thing we learned the hard way: learn the primitives once and skip the convenience layer. I (Sandro) learned that with the first thing I ever built on AWS. A mobile app called Deposur (here is an old tweet I've found). It was a full-stack mobile app to track your investments like ETFs or stocks. I used the Amplify v1 CLI for that. It worked great. Amplify generated the whole GraphQL API and DynamoDB schema for me. The issue back then was that there was no way to get out of it. It was very opinionated about things. If you had an issue with a CloudFormation deployment or with some generated path, you were mostly stuck. Newer Amplify versions are much better about that now. I'd still only use the main services! Especially with AI. It is so easy to get in-depth explanations of what each service configuration is doing. Learn it once, apply it forever. That is what today's deep dive is about. Tobi keeps a list of every layer AWS built on top of ECS. Most of it is dead or dying.
Sponsored
Trigger.dev chat.agent • Open Source
One conversation, one durable task.
I have built the same AI chat feature three times now. LangChain, Strands, plain Vercel AI SDK. The orchestrator changes, the plumbing never
does: API Gateway with streaming, Lambda, DynamoDB for conversation state, OTEL into CloudWatch for the traces. It works, but it is annoying.
chat.agent moves that plumbing into one durable task per conversation. Every message is stored on the server, the client only sends the new
one. Responses stream straight into the normal useChat hook. A tool that needs a human answer pauses
the agent until it arrives. And every turn is a span, so you open a session in the dashboard and read what happened.
It is 100% open source. Read the code, self-host it, try it without asking anyone. The
next chat feature I build, I will give it a try.
Give chat.agent a try →
Sponsored by Trigger.dev. The words are Sandro's own.
📚 This Week's Deep Dive
Tobi keeps a list of every layer AWS built on top of ECS. Most of it is dead or dying.
ECS CLI, archived after ten years. Fargate CLI, archived. Copilot CLI, end of life since June. AWS Proton, end of life in October. App
Runner, in maintenance mode since April: no new features, no new customers. We called App Runner "the easy way to run your
containers" back in 2023. That framing has not aged well.
None of them touched ECS itself. Each one put a friendlier CLI or console flow in front of containers that kept running on the same
task definitions and services underneath. Strip the wrapper away and the primitives were there the whole time.
ECS launched in 2014. Its core API has not changed since. Fargate added a capacity mode in 2017, not a new API. Tobi has services on it
running since 2019 that he has not touched once. Zero drama.
So why does the primitive survive while everything on top of it gets cut? Team size is not the difference, ECS has a team too. And two
wrappers, Elastic Beanstalk and Lightsail, are still running a decade on. Any theory of why convenience layers die has to explain those
two.
The article covers the pattern behind the graveyard, the two questions that separate a safe wrapper from a risky one (Terraform and CDK
are wrappers too, and Tobi uses both), and where ECS Express Mode, AWS's newest attempt at the same idea, lands on that line.
|
That's it for this issue. If you take one thing away: when something on AWS promises to make a service easier, check what sits underneath it first. Build on that. Let the layer above it prove it survives before anything production-critical depends on it. And if you are still running on Copilot or Proton: the task definitions and services are still there. You are closer to plain ECS than it feels. See you in the next one! Sandro & Tobi |